楼主:
alihue (wanda wanda)
2021-08-31 21:45:42看到不错的文章 翻译分享一下
原文:
https://chriskiehl.com/article/thoughts-after-6-years
翻译:
软件开发六年后我改变想法的事情:
- 如果你的队友经验参差不齐，Typed languages 是比较好的选择
- Standups 会议以注意新人来说是有用的
- Sprint retrospectives 如果拿来做真正的流程修正(course correction)是有用的；
而不是一些敏捷/scum master 拿来浪费大家时间的
- 软件架构比啥都重要。有好的抽象再烂的实作都不太会弄脏 code base；烂抽象或
missing layer 可以让 code base 变成一坨屎。
- java 没那么烂
- Clever code 通常不是什么好 code；清晰好读(Clarity)的 code 最重要
- 烂 code 可以被以任何方式写出来 (in any paradigm)
- 所谓的 best practices 是要看上下文，并非通用解。盲目追求会让你看起来像白痴
- 在你不需要时硬去设计一个 scalable system，你就是烂工程师
- Static analysis 有用
- DRY(dont repeat yourself) 是为了避免特定问题，并不是最终追求目标。
- 一般来说 RDBMS > NoSql
- Functional programming 是另一个工具，不是万用解/灵丹
一路走来坚持的观念
- YAGNI, SOLID, DRY 请按造这个顺序
- YAGNI:You aren't gonna need it
- SOLID: 某个 OO 原则（单一功能、开闭原则、里氏替换、接口隔离、依赖反转）
- DRY: dont repeat yourself
- 纸笔是最好的开发工具但很少人用
- 用干净/可读(purity)为代价换取实用性是个好方法
- 狂导入额外的技术不是好方向
- 直接跟客户/需求端理解需求会比较快又精确
- "scalable"这个词在码农中有股神秘的力量，仅仅这个字可以让他们陷入疯狂，然后仅
仅为了这个字可以做出疯狂的设计
有点难翻XD 原文:
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.
- 虽然叫工程师，但其实很多决策都是跟风(cargo-cult)，并不是有严谨的分析、资料数
据佐证
- 大概九成的 PM 明天消失对你都没影响，甚至效率还会变好
- 当我做了一百场面试后: 面试方法彻底崩坏，我也不知道怎么做更好
没变的观念
- 会刁 code style, linting rules 或枝微末节的都怪咖
- Code coverage 跟 code 品质完全没差
- Monoliths (大概指微服务的反面)系统在大部分情境都是很好的
- TDD 主义者(purists)是最糟糕的存在，他们的脑不能理解现实中存在不同的 workflows
作者:
bjk (Up2u)
2021-08-31 21:52:00大部分都认同，感谢分享
作者:
kvjo (同名专辑)
2021-08-31 21:59:00大部分认同 看你PM价值 低价值PM如此vaulable的PM 明天消失 好像很清净 过几天就知道.更排山倒海
作者:
enthos (影斯作业系统)
2021-08-31 22:30:00不同意纸笔。我说心眼(半小时全盲打)易于专心,但难练
作者:
yamakazi (大安吴彦祖)
2021-08-31 22:33:00Issue tracker很重要
作者:
jack0204 (Jarbar王朝)
2021-08-31 23:06:00GO是怪咖语言
作者:
amiwry (肥墩墩大人)
2021-08-31 23:31:00感谢翻译
作者:
k900421 (qq)
2021-09-01 00:13:00能多解释java没那模烂这点吗?
作者:
ian90911 (xopowo)
2021-09-01 00:15:00感谢翻译
最后的 Code coverage 是指 Test Coverage 吗
作者: jete 2021-09-01 00:57:00
第一点跟刁linting是怪咖有矛盾啊
作者:
umum29 (....)
2021-09-01 01:03:00有些偏颇+1 直接面对客户会变成没防火墙 客户会不断改需求好的PM/scrum master是会带着整个团队往前冲其他大致同意 面试真的没有最客观的方法
作者:
em1234 (em)
2021-09-01 01:17:00PM那个一定是没遇过都扛屎缺的PM 没了屎缺大家分了
作者:
taipoo (要成功要积极)
2021-09-01 01:34:00谢谢翻译
作者:
rotalume (rotalume)
2021-09-01 02:24:00楼楼上，所以原文说九成没有说全部啊XD
作者: ga013077 (Daky) 2021-09-01 03:55:00
不错啊
问题不是TDD是purist吧 任何xxx purist都要小心
看到Sprint retrospectives 马上点about 嗯... 果然是Amazon的员工 觉得看看就好
作者:
matyih (mat)
2021-09-01 05:02:006年的L5 看看就好
作者:
rtoday (rtoday)
2021-09-01 05:17:00看看就好＋1
作者: nanashi07 (NaNashi) 2021-09-01 06:23:00
部份认同
作者:
CoverMind (Goa ai Giok-Chin)
2021-09-01 07:39:00看看就好+1 部分认同而已
作者:
strlen (strlen)
2021-09-01 08:41:00懒惰写测试就说 牵拖TDD干麻？
部份不认同，我自己的经验是确实 bug 好发在没有被 testcoverage 到的地方。然后 TDD 那个看程度，我猜他指的是那种非常坚持要先有test code 才写 production code 的状况。但实务上满多是先写一小段 production code，再补一小段 test code的。
楼上那个是莫非定律 你就是没想到会有bug的部分你的测试当然也是没写到了 所以总会出现在没cover的地方
楼主:
alihue (wanda wanda)
2021-09-01 09:25:00就跟写论文先有实验结果再回去写假设一样
作者: triplee (none) 2021-09-01 09:39:00
不需要时去设计scalable system 就是烂工程师 这点有点玩味 因为遇到的场景通常是你以为你不需要 结果日后碰到了才发现你的系统动弹不得 这篇文的背景跟观点应该是有绝对性的关联 跟之前另一篇分享个人觉得有差别10年工程师的酒后牢骚那篇
我自己是同意纸笔非常好用。画流程/架构图、简单的测资或 puesdo code，整理思或绪厘清问题都很好用又快速。很多时候纸笔整理完，就知道程式码要怎么写了。
作者:
chuegou (chuegou)
2021-09-01 10:04:00纸笔是整理思绪的好工具
作者:
expiate (夜露死苦)
2021-09-01 11:01:00推有心翻译
作者: geniusturtle (小龟) 2021-09-01 11:14:00
推
作者:
molopo (mmm)
2021-09-01 11:49:00推纸笔
作者:
kvjo (同名专辑)
2021-09-01 13:27:00PM这段很简单 就把PM拿掉 过一些日子 还是会发现需要有个人PM是软能力大于硬能力的ROLE 本来就很难评估
作者:
bnd0327 (阿噗噗)
2021-09-01 14:19:00比较惊讶要花六年才相信静态分析有用
abstract 翻抽象怪怪的，翻成接口不是顺畅点？
楼主:
alihue (wanda wanda)
2021-09-01 15:58:00抽象是过程，接口是输出XD
楼主:
alihue (wanda wanda)
2021-09-01 17:02:00没事还会在那玩小游戏而不是跳过会议
极端TDD信仰者和重构之前不写Test Code都蛮麻烦的前者是不好合作，后者是在埋地雷
Scalable 那段是指很多人为了讲究“扩展性”而故意写微服务、K8S 或是用 MongoDB 这种 NoSQL。当初 MongoDB 的著名笑话就是：“我知道 MySQL 很好, But does itscale?”
作者:
DrTech (竹科管理处网军研发人员)
2021-09-01 21:39:00整篇废话用这篇逻辑来说就是：这篇是废话，但又没那么废话。
作者:
jennya (Jennya)
2021-09-01 22:55:00好文，推！除了PM那行不同意以外其他都同意；有遇过雷的PM但就算是雷的PM还是有帮RD做了不少沟通的事。最想推的就是YAGNI，有些RD为了他们自以为“未来会有的需求”而先写了“方便未来scalable的”的多余的抽象化，十年之后来看他们当初写的code，那些多余的抽象化都是从来没发生作用的废code，他们完全预估错了未来需求会发展的方向；而他们为了不需要的抽象化而多写的那些逻辑反而让程度中等不敢大刀阔斧砍code的后人、为了实现真正的需求而必须绕来绕去的东加西加，叠床架屋，很多逻辑变得绕，又再加上没有作用的抽象化code在干扰readability，明明可以很简单明了的东西最后却变得超杂乱。看完十年gitlog history，结论真的就是YAGNI，当下真的给进来的需求你再做，不要自以为可以预测未来，事实证明他们预测的没有一个命中，然后没自信或赶时间的后人不敢砍掉没用的抽象化，最后相关的module发展的歪七扭八盘根错节。假如当初不过度抽象化，就写最简单最初学者的那种架构，反而不会危害那么大。YAGNI！
作者:
MDay56 (他妈妈冲击波)
2021-09-02 01:21:00Java忽然就出现了谢谢分享翻译
作者: triplee (none) 2021-09-02 12:38:00
觉得jennya的例子比较像是失败的抽象而不是scalable的锅
认同t大说法 那应该是失败的抽象 过度抽象不至于那么惨但我也同意有需求再做就好 只是一发现有问题就得重构
作者: dein0522 (Dennis) 2021-09-03 00:40:00
monolith指的是公司主要的codebase，通常有几百万行程式码，因为美国大公司都可能有几万个工程师
作者:
bndan (seed)
2021-09-04 15:54:009成PM存在与否没差 这边的问题在于"设计"者承担了额外的工作 EX: 工作时间分配与责任 但这也很两难啦 把全部责任都堆PM上 在这部份和社会文化不合 这社会强调的是为自己做的事负责..分配工作做不完=自己有问题=>那设计者一开始就把自己的产能需求掐住 自己规化工作时程分配 => PM要他干嘛高度紧密合作(包含工作时程) VS 个人独立性 前者不被这文化选择...