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

前言

大家好,在下蛮咕咕(我是“鸽”王),好久不见啊。

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

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

正文

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

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

  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应用架构介绍

参考

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

关注我

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

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

各大平台都能找到我

  • 微信公众号:后端技术漫谈

原创文章主要内容

  • 后端开发实战
  • 后端技术面试
  • 算法题解/数据结构/设计模式
  • 生活趣闻
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,560评论 4 361
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,104评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,297评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,869评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,275评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,563评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,833评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,543评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,245评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,512评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,011评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,359评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,006评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,062评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,825评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,590评论 2 273
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,501评论 2 268

推荐阅读更多精彩内容