作者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/m.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