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

前言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在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.