【译文】工作六年后，我对软件开发的认知转变

妖狐艹你老母 2022-10-29 15:21 131阅读 0赞

# 前言 #

大家好，在下蛮咕咕（我是“鸽”王），好久不见啊。

最近我司已经放假过年了，在家里就不免会多逛一些“稀奇古怪”的网站，通过阮一峰的每周新闻，发现了一篇比较不错的英文文章。

里面的**大部分**观点我都比较认同，在这里做了一个比较接地气的翻译，分享给大家。

# 正文 #

在软件产业工作六年后，我对软件行业的一些想法发生了改变。

**以下这些观点是我以前内心比较矛盾，但是现在坚信的事情：**

> 1.  当你工作在一个开发人员众多且拥有不同开发水平的小组中，使用强类型语言显然更为合适。

> 1.  站会（敏捷开发中的站立会议）对于跟进团队中新手的进度来说，非常有用。

> 1.  敏捷开发中的迭代复盘会，是有其意义的，前提是为了纠正过往迭代的失误（比如发现一些“这样做真蠢！”的故事），而不是在一些‘敏捷大师’的教条下，浪费大家的时间。

> 1.  软件架构比任何东西都要重要。一个好的抽象，就算是实现的比较拉胯，对于代码来说伤害非常小。但是如果没有好的抽象，就算实现的再漂亮，那也是在堆屎，对代码伤害极大。

> 1.  Java并不是那么烂（译者注：看来大佬对Java怨念颇深）。

> 1.  炫技的代码通常并不是好代码，一个清晰明了的代码比任何代码都好。

> 1.  你永远想象不到垃圾代码能写的多么奇葩。

> 1.  所谓的“最佳实践（Best Practise）”通常是有特定背景的，不具有广泛的适用性。盲目地追随他们会使你成为一个蠢货。

> 1.  在不需要的时候强行去设计高度可伸缩的系统，会让你成为一个糟糕的工程师。

> 1.  代码静态分析是很有用的。

> 1.  DRY（Don’t repeat yourself）不要造轮子：通常是用于避免一个特定的问题，而不是作为一个终极目的，所以不要盲目追求没有重复。

> 1.  通常情况下，RDBMS（关系数据库）优于 NoSql （特指非关系数据库）。

> 1.  函数式编程仅仅是另一种编程手法，而不是灵丹妙药。

**以下是我这一路以来了解到并认可的观点：**

> 1.  第一，YAGNI（非必要时不加入新代码）, 其次， SOLID（面向对象设计）, 第三， DRY（不要重复造轮子），按照这个优先级去写代码。

> 1.  铅笔和纸是最好的编程工具，而且经常会用到。

> 1.  用纯粹性换取实用性通常是个不错的选择。

> 1.  往项目中增加更多的技术框架，通常不是个好选择。

> 1.  直接与客户交谈总是能在更短的时间内，通过更高的准确性来暴露更多的软件问题。

> 1.  “可伸缩性”这个词在软件工程师的头脑中有一种神秘而令人震惊的力量。仅仅这一句话就能把他们搞的心力憔悴。

> 1.  尽管被称外人称为“工程师”，但大多数开发人员的决定都是根据个人喜好或者“看心情”，没有数据的支持。

> 1.  有90%，甚至93%的项目经理明天可能就会消失，并且并不会造成影响，甚至会提升效率。（译者注：这个原文意思不知道我理解的对不对）

> 1.  在完成了100多次面试之后，我依然不知道如何让面试变得更好，。（译者注：面试很难真正看清一个人的开发水平）

**以下是这么多年来我依然不变的观点：**

> 1.  过分强调代码风格、规则或其他细节的人是极端分子，毫无意义。

> 1.  代码覆盖率对于提升代码质量没有丝毫帮助。

> 1.  在大多数情况下，大应用（Monoliths）的效果是很好的，并不一定要细分成非常复杂的微服务。

> 1.  无脑信奉TDD（测试驱动开发）的人是最糟糕的，他们脆弱的小脑袋无法处理不同工作流程的存在。

> 1.  在10年后，让我们再看看，这些观点是否会发生变化。

# 英文原文 #

Software development topics I’ve changed my mind on after 6 years in the industry.

Things I now believe, which past me would’ve squabbled with:

*  Typed languages are better when you’re working on a team of people with various experience levels
 *  Standups are actually useful for keeping an eye on the newbies.
 *  Sprint retrospectives have their place so long as they’re for actual course correction (i.e. “holy shit, that went poorly!”) and not some god awful ‘agile’ / ‘scum master’ driven waste of everyone’s time
 *  Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.
 *  Java isn’t that terrible of a language.
 *  Clever code isn’t usually good code. Clarity trumps all other concerns.
 *  Bad code can be written in any paradigm
 *  So called “best practices” are contextual and not broadly applicable. Blindly following them makes you an idiot
 *  Designing scalable systems when you don’t need to makes you a bad engineer.
 *  Static analysis is useful  
    DRY is about avoiding a specific problem, not an end goal unto itself.  
    In general, RDBMS > NoSql  
    Functional programming is another tool, not a panacea.

Opinions I’ve picked up along the way

*  YAGNI, SOLID, DRY. In that order.
 *  Pencil and paper are the best programming tools and vastly under used
 *  Trading purity in exchange for practicality is usually a good call
 *  Adding more technology is rarely a good call
 *  Talking directly to the customer always reveals more about the problem, in less time, and with higher accuracy
 *  The word “scalable” has a mystical and stupefying power over the mind of the software engineer. Its mere utterance can whip them into a depraved frenzy. Grim actions have been justified using this word
 *  Despite being called “engineers,” most decision are pure cargo-cult with no backing analysis, data, or numbers
 *  90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
 *  After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.

Old opinions unchanged:

*  People who stress over code style, linting rules, or other minutia are insane weirdos
 *  Code coverage has absolutely nothing to do with code quality
 *  Monoliths are pretty good in most circumstances
 *  TDD purists are just the worst. Their frail little minds can’t process the existence of different workflows.

We’ll see which of these have flipped or changed at year 10.

# 小尾巴 #

之前也翻译过一篇比较经典的外文文章，感兴趣的朋友可以回看下之前的文章：

[通俗易懂的生产环境Web应用架构介绍][Web]

# 参考 #

https://chriskiehl.com/article/thoughts-after-6-years

# 关注我 #

我是一名奋斗在一线的互联网后端开发工程师。

主要关注后端开发，数据安全，边缘计算等方向，欢迎交流。

**各大平台都能找到我**

*  **微信公众号：后端技术漫谈**
 *  **Github：[@qqxx6661][qqxx6661]**
 *  CSDN：[@蛮三刀把刀][Link 1]
 *  知乎：[@后端技术漫谈][Link 2]
 *  掘金：[@蛮三刀把刀][Link 3]
 *  腾讯云+社区：[@后端技术漫谈][Link 4]
 *  博客园：[@后端技术漫谈][Link 5]
 *  BiliBili：[@蛮三刀把刀][Link 6]

**原创文章主要内容**

*  后端开发实战
 *  后端技术面试
 *  算法题解/数据结构/设计模式
 *  生活趣闻

**个人公众号：后端技术漫谈**

![个人公众号：后端技术漫谈][e963a6996f115b4fa82ffc9dee19ea5c.png]

**如果文章对你有帮助，求各位大佬点赞支持一下，你的点赞和在看是我更新的动力~**

[Web]: https://zhuanlan.zhihu.com/p/57735030
[qqxx6661]: https://github.com/qqxx6661
[Link 1]: http://blog.csdn.net/qqxx6661
[Link 2]: https://www.zhihu.com/people/yang-zhen-dong-1/
[Link 3]: https://juejin.im/user/5b48015ce51d45191462ba55
[Link 4]: https://cloud.tencent.com/developer/user/1706868
[Link 5]: https://www.cnblogs.com/rude3knife/
[Link 6]: https://space.bilibili.com/18324091
[e963a6996f115b4fa82ffc9dee19ea5c.png]: /images/20221024/d95ee5bc75fb4d5c9d3bd5f17b68442b.png