前言

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

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

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

注释

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

以下这些观点是我以前心田比拟矛盾，然而当初深信的事件：

1. 当你工作在一个开发人员泛滥且领有不同开发程度的小组中，应用强类型语言显然更为适合。
2. 站会（麻利开发中的站立会议）对于跟进团队中老手的进度来说，十分有用。
3. 麻利开发中的迭代复盘会，是有其意义的，前提是为了纠正过往迭代的失误（比方发现一些“这样做真蠢！”的故事），而不是在一些‘麻利巨匠’的教条下，节约大家的工夫。
4. 软件架构比任何货色都要重要。一个好的形象，就算是实现的比拟拉胯，对于代码来说挫伤十分小。然而如果没有好的形象，就算实现的再丑陋，那也是在堆屎，对代码挫伤极大。
5. Java 并不是那么烂（译者注：看来大佬对 Java 怨念颇深）。
6. 炫技的代码通常并不是好代码，一个清晰明了的代码比任何代码都好。
7. 你永远设想不到垃圾代码能写的如许奇葩。
8. 所谓的“最佳实际（Best Practise）”通常是有特定背景的，不具备宽泛的适用性。自觉地追寻他们会使你成为一个蠢货。
9. 在不须要的时候强行去设计高度可伸缩的零碎，会让你成为一个蹩脚的工程师。
10. 代码动态剖析是很有用的。
11. DRY（Don’t repeat yourself）不要造轮子：通常是用于防止一个特定的问题，而不是作为一个终极目标，所以不要自觉谋求没有反复。
12. 通常状况下，RDBMS（关系数据库）优于 NoSql（特指非关系数据库）。
13. 函数式编程仅仅是另一种编程手法，而不是灵丹妙药。

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

1. 第一，YAGNI（非必要时不退出新代码）, 其次，SOLID（面向对象设计）, 第三，DRY（不要反复造轮子），依照这个优先级去写代码。
2. 铅笔和纸是最好的编程工具，而且常常会用到。
3. 用纯正性换取实用性通常是个不错的抉择。
4. 往我的项目中减少更多的技术框架，通常不是个好抉择。
5. 间接与客户交谈总是能在更短的工夫内，通过更高的准确性来裸露更多的软件问题。
6. “可伸缩性”这个词在软件工程师的头脑中有一种神秘而令人震惊的力量。仅仅这一句话就能把他们搞的心力憔悴。
7. 只管被称外人称为“工程师”，但大多数开发人员的决定都是依据集体爱好或者“看情绪”，没有数据的反对。
8. 有 90%，甚至 93% 的项目经理今天可能就会隐没，并且并不会造成影响，甚至会晋升效率。（译者注：这个原文意思不晓得我了解的对不对）
9. 在实现了 100 屡次面试之后，我仍然不晓得如何让面试变得更好，。（译者注：面试很难真正看清一个人的开发程度）

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

1. 过分强调代码格调、规定或其余细节的人是极端分子，毫无意义。
2. 代码覆盖率对于晋升代码品质没有丝毫帮忙。
3. 在大多数状况下，大利用（Monoliths）的成果是很好的，并不一定要细分成非常复杂的微服务。
4. 无脑崇奉 TDD（测试驱动开发）的人是最蹩脚的，他们软弱的小脑袋无奈解决不同工作流程的存在。
5. 在 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 利用架构介绍

参考

https://chriskiehl.com/articl…

关注我

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

次要关注后端开发，数据安全，边缘计算等方向，欢送交换。

各大平台都能找到我

• 微信公众号：后端技术漫谈
• Github：@qqxx6661
• CSDN：@蛮三刀把刀
• 知乎：@后端技术漫谈
• 掘金：@蛮三刀把刀
• 腾讯云 + 社区：@后端技术漫谈
• 博客园：@后端技术漫谈
• BiliBili：@蛮三刀把刀

原创文章次要内容

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

集体公众号：后端技术漫谈

如果文章对你有帮忙，求各位大佬点赞反对一下，你的点赞和在看是我更新的能源~