大家好,在下蛮咕咕(我是“鸽”王),好久不见啊。
最近我司已经放假过年了,在家里就不免会多逛一些“稀奇古怪”的网站,通过阮一峰的每周新闻,发现了一篇比较不错的英文文章。
里面的大部分观点我都比较认同,在这里做了一个比较接地气的翻译,分享给大家。
正文在软件产业工作六年后,我对软件行业的一些想法发生了改变。
以下这些观点是我以前内心比较矛盾,但是现在坚信的事情:
- 当你工作在一个开发人员众多且拥有不同开发水平的小组中,使用强类型语言显然更为合适。
- 站会(敏捷开发中的站立会议)对于跟进团队中新手的进度来说,非常有用。
- 敏捷开发中的迭代复盘会,是有其意义的,前提是为了纠正过往迭代的失误(比如发现一些“这样做真蠢!”的故事),而不是在一些‘敏捷大师’的教条下,浪费大家的时间。
- 软件架构比任何东西都要重要。一个好的抽象,就算是实现的比较拉胯,对于代码来说伤害非常小。但是如果没有好的抽象,就算实现的再漂亮,那也是在堆屎,对代码伤害极大。
- 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.
小尾巴之前也翻译过一篇比较经典的外文文章,感兴趣的朋友可以回看下之前的文章:
通俗易懂的生产环境Web应用架构介绍
参考https://chriskiehl.com/article/thoughts-after-6-years
个人公众号:后端技术漫谈