作者alihue (wanda wanda)
看板Soft_Job
标题[心得] (转)软体开发六年後我改变想法的事情
时间Tue Aug 31 21:45:42 2021
看到不错的文章 翻译分享一下
原文:
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
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 106.73.26.66 (日本)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1630417545.A.965.html
※ 编辑: alihue (106.73.26.66 日本), 08/31/2021 21:46:43
※ 编辑: alihue (106.73.26.66 日本), 08/31/2021 21:47:58
※ 编辑: alihue (106.73.26.66 日本), 08/31/2021 21:49:21
1F：推 bjk: 大部分都认同，感谢分享 08/31 21:52
2F：→ kvjo: 大部分认同 看你PM价值 低价值PM如此 08/31 21:59
3F：→ kvjo: vaulable的PM 明天消失 好像很清净 过几天就知道.更排山倒海 08/31 21:59
4F：嘘 gn01838335: ….有些结论太武断 08/31 22:25
他个人心得而已
每个人待过的 Team/遇过的人/做过的事不同会有不一样的体悟吧
5F：推 enthos: 不同意纸笔。我说心眼(半小时全盲打)易於专心,但难练 08/31 22:30
6F：推 yamakazi: Issue tracker很重要 08/31 22:33
7F：推 viper9709: 九成的PM明天消失对你都没影响www 08/31 22:35
8F：推 jack0204: GO是怪咖语言 08/31 23:06
9F：推 amiwry: 感谢翻译 08/31 23:31
10F：→ shooter555: 等你出名後 就能把这些拿来出书了 08/31 23:37
11F：→ MOONY135: TDD为什麽这麽容易被唾弃啊 08/31 23:55
TDD 在适当时机用不错吧
如果是狂热到无论如何都要 TDD就过头
12F：推 k900421: 能多解释java没那模烂这点吗? 09/01 00:13
原作没解释，以下个人观点
不过入门语言若是如 Python 等更简便的语言，通常会觉得 java 很冗吧
不过在现实世界，Java 就是一个语言界 toyota
在效能/物件导向/JVM (开发者不用管理记忆体)中取得平衡，
各种 Solution 都很成熟，生态圈也广
只是在 oracle 官司争议後又变臭了
13F：推 ian90911: 感谢翻译 09/01 00:15
14F：推 RunRun5566: 最後的 Code coverage 是指 Test Coverage 吗 09/01 00:27
应该是
15F：推 jete: 第一点跟刁linting是怪咖有矛盾啊 09/01 00:57
16F：→ umum29: 有些偏颇+1 直接面对客户会变成没防火墙 客户会不断改需求 09/01 01:03
17F：→ umum29: 好的PM/scrum master是会带着整个团队往前冲 09/01 01:03
18F：→ umum29: 其他大致同意 面试真的没有最客观的方法 09/01 01:05
好的 PM 真的工作起来很爽
19F：推 em1234: PM那个一定是没遇过都扛屎缺的PM 没了屎缺大家分了 09/01 01:17
20F：→ taipoo: 谢谢翻译 09/01 01:34
21F：推 rotalume: 楼楼上，所以原文说九成没有说全部啊XD 09/01 02:24
22F：推 pttassassin: 好奇TDD有啥特别的问题吗 09/01 03:44
23F：推 ga013077: 不错啊 09/01 03:55
24F：推 fantasychese: 问题不是TDD是purist吧 任何xxx purist都要小心 09/01 04:14
25F：→ deangood01: 看到Sprint retrospectives 马上点about 嗯... 果然 09/01 04:26
26F：→ deangood01: 是Amazon的员工 觉得看看就好 09/01 04:26
27F：→ matyih: 6年的L5 看看就好 09/01 05:02
28F：推 rtoday: 看看就好＋1 09/01 05:17
29F：推 WaterLengend: PM那个实在有够中肯 09/01 05:53
30F：→ nanashi07: 部份认同 09/01 06:23
31F：推 CoverMind: 看看就好+1 部分认同而已 09/01 07:39
32F：推 strlen: 懒惰写测试就说 牵拖TDD干麻？ 09/01 08:41
33F：推 brianhsu: 部份不认同，我自己的经验是确实 bug 好发在没有被 test 09/01 09:01
34F：→ brianhsu: coverage 到的地方。 09/01 09:01
35F：→ brianhsu: 然後 TDD 那个看程度，我猜他指的是那种非常坚持要先有 09/01 09:04
36F：→ brianhsu: test code 才写 production code 的状况。但实务上满多 09/01 09:04
37F：→ brianhsu: 是先写一小段 production code，再补一小段 test code 09/01 09:04
38F：→ brianhsu: 的。 09/01 09:04
39F：→ MOONY135: 楼上那个是莫非定律 你就是没想到会有bug的部分 09/01 09:23
40F：→ MOONY135: 你的测试当然也是没写到了 所以总会出现在没cover的地方 09/01 09:24
41F：→ alihue: 就跟写论文先有实验结果再回去写假设一样 09/01 09:25
42F：→ triplee: 不需要时去设计scalable system 就是烂工程师 这点有点玩 09/01 09:39
43F：→ triplee: 味 因为遇到的场景通常是你以为你不需要 结果日後碰到了 09/01 09:40
44F：→ triplee: 才发现你的系统动弹不得 这篇文的背景跟观点应该是有绝对 09/01 09:41
45F：→ triplee: 性的关联 跟之前另一篇分享个人觉得有差别 09/01 09:42
46F：→ triplee: 10年工程师的酒後牢骚那篇 09/01 09:46
47F：推 brianhsu: 我自己是同意纸笔非常好用。画流程/架构图、简单的测资 09/01 09:47
48F：→ brianhsu: 或 puesdo code，整理思或绪厘清问题都很好用又快速。 09/01 09:47
49F：→ brianhsu: 很多时候纸笔整理完，就知道程式码要怎麽写了。 09/01 09:48
50F：推 chuegou: 纸笔是整理思绪的好工具 09/01 10:04
51F：推 expiate: 推有心翻译 09/01 11:01
52F：推 geniusturtle: 推 09/01 11:14
53F：推 molopo: 推纸笔 09/01 11:49
54F：→ cunankimo: 大部份认同 09/01 12:22
55F：→ alongalone: 有战的潜力 09/01 12:43
56F：推 aa155495: pm那段不完全认同 09/01 13:07
57F：→ kvjo: PM这段很简单 就把PM拿掉 过一些日子 还是会发现需要有个人 09/01 13:27
58F：→ kvjo: PM是软能力大於硬能力的ROLE 本来就很难评估 09/01 13:27
59F：推 bnd0327: 比较惊讶要花六年才相信静态分析有用 09/01 14:19
60F：推 zebraseven: abstract 翻抽象怪怪的，翻成介面不是顺畅点？ 09/01 15:21
61F：→ alihue: 抽象是过程，介面是输出XD 09/01 15:58
62F：推 sunsamy: 敏捷/scum master是拿来浪费大家时间的 09/01 16:38
63F：→ alihue: 没事还会在那玩小游戏而不是跳过会议 09/01 17:02
64F：推 polola6212: 极端TDD信仰者和重构之前不写Test Code都蛮麻烦的 09/01 18:21
65F：→ polola6212: 前者是不好合作，後者是在埋地雷 09/01 18:22
※ 编辑: alihue (106.73.26.66 日本), 09/01/2021 20:30:13
66F：推 yamiodymel: Scalable 那段是指很多人为了讲究「扩展性」而故意写 09/01 20:22
67F：→ yamiodymel: 微服务、K8S 或是用 MongoDB 这种 NoSQL。当初 MongoD 09/01 20:22
68F：→ yamiodymel: B 的着名笑话就是：「我知道 MySQL 很好, But does it 09/01 20:22
69F：→ yamiodymel: scale?」 09/01 20:22
70F：→ DrTech: 整篇废话 09/01 21:39
71F：→ DrTech: 用这篇逻辑来说就是：这篇是废话，但又没那麽废话。 09/01 21:40
72F：推 jennya: 好文，推！ 09/01 22:55
73F：→ jennya: 除了PM那行不同意以外其他都同意；有遇过雷的PM但就算是 09/01 22:55
74F：→ jennya: 雷的PM还是有帮RD做了不少沟通的事。 09/01 22:55
75F：→ jennya: 最想推的就是YAGNI，有些RD为了他们自以为「未来会有的 09/01 22:55
76F：→ jennya: 需求」而先写了「方便未来scalable的」的多余的抽象化， 09/01 22:55
77F：→ jennya: 十年之後来看他们当初写的code，那些多余的抽象化都是从 09/01 22:55
78F：→ jennya: 来没发生作用的废code，他们完全预估错了未来需求会发展 09/01 22:55
79F：→ jennya: 的方向；而他们为了不需要的抽象化而多写的那些逻辑反而 09/01 22:55
80F：→ jennya: 让程度中等不敢大刀阔斧砍code的後人、为了实现真正的需 09/01 22:55
81F：→ jennya: 求而必须绕来绕去的东加西加，叠床架屋，很多逻辑变得绕 09/01 22:55
82F：→ jennya: ，又再加上没有作用的抽象化code在干扰readability，明 09/01 22:55
83F：→ jennya: 明可以很简单明了的东西最後却变得超杂乱。看完十年git 09/01 22:55
84F：→ jennya: log history，结论真的就是YAGNI，当下真的给进来的需 09/01 22:55
85F：→ jennya: 求你再做，不要自以为可以预测未来，事实证明他们预测的 09/01 22:55
86F：→ jennya: 没有一个命中，然後没自信或赶时间的後人不敢砍掉没用的 09/01 22:56
87F：→ jennya: 抽象化，最後相关的module发展的歪七扭八盘根错节。假如 09/01 22:56
88F：→ jennya: 当初不过度抽象化，就写最简单最初学者的那种架构，反而 09/01 22:56
89F：→ jennya: 不会危害那麽大。YAGNI！ 09/01 22:56
90F：→ MDay56: Java忽然就出现了 09/02 01:21
91F：推 MDay56: 谢谢分享翻译 09/02 01:23
92F：→ triplee: 觉得jennya的例子比较像是失败的抽象而不是scalable的锅 09/02 12:38
93F：推 s0914714: 认同t大说法 那应该是失败的抽象 过度抽象不至於那麽惨 09/03 00:23
94F：→ s0914714: 但我也同意有需求再做就好 只是一发现有问题就得重构 09/03 00:25
95F：→ dein0522: monolith指的是公司主要的codebase，通常有几百万行程 09/03 00:40
96F：→ dein0522: 式码，因为美国大公司都可能有几万个工程师 09/03 00:40
97F：推 v9290026: 我同意多数，学习啦 09/04 14:08
98F：→ bndan: 9成PM存在与否没差 这边的问题在於"设计"者承担了额外的工 09/04 15:54
99F：→ bndan: 作 EX: 工作时间分配与责任 但这也很两难啦 把全部责任都堆 09/04 15:54
100F：→ bndan: PM上 在这部份和社会文化不合 这社会强调的是为自己做的事 09/04 15:55
101F：→ bndan: 负责..分配工作做不完=自己有问题=>那设计者一开始就把自己 09/04 15:55
102F：→ bndan: 的产能需求掐住 自己规化工作时程分配 => PM要他干嘛 09/04 15:56
103F：→ bndan: 高度紧密合作(包含工作时程) VS 个人独立性 前者不被这文化 09/04 15:57
104F：→ bndan: 选择... 09/04 15:57
105F：推 jason82714: YAGNI 说到心坎里 10/29 14:50
106F：推 jason82714: 这篇也讲得不错 10/29 14:53