[心得] (轉)軟體開發六年後我改變想法的事情

作者: 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 明天消失 好像很清淨 過幾天就知道.更排山倒海
作者: gn01838335 (寂靜的生存者)   2021-08-31 22:25:00
….有些結論太武斷
作者: enthos (影斯作業系統)   2021-08-31 22:30:00
不同意紙筆。我說心眼(半小時全盲打)易於專心,但難練
作者: yamakazi (大安吳彥祖)   2021-08-31 22:33:00
Issue tracker很重要
作者: viper9709 (阿達)   2021-08-31 22:35:00
九成的PM明天消失對你都沒影響www
作者: jack0204 (Jarbar王朝)   2021-08-31 23:06:00
GO是怪咖語言
作者: amiwry (肥墩墩大人)   2021-08-31 23:31:00
感謝翻譯
作者: shooter555 (shooter)   2021-08-31 23:37:00
等你出名後 就能把這些拿來出書了
作者: MOONY135 (談無慾)   2021-08-31 23:55:00
TDD為什麼這麼容易被唾棄啊
作者: k900421 (qq)   2021-09-01 00:13:00
能多解釋java沒那模爛這點嗎?
作者: ian90911 (xopowo)   2021-09-01 00:15:00
感謝翻譯
作者: RunRun5566 (跑跑五六)   2021-09-01 00:27: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:00
PM那個一定是沒遇過都扛屎缺的PM 沒了屎缺大家分了
作者: taipoo (要成功要積極)   2021-09-01 01:34:00
謝謝翻譯
作者: rotalume (rotalume)   2021-09-01 02:24:00
樓樓上,所以原文說九成沒有說全部啊XD
作者: pttassassin (0)   2021-09-01 03:44:00
好奇TDD有啥特別的問題嗎
作者: ga013077 (Daky)   2021-09-01 03:55:00
不錯啊
作者: fantasychese (林阿宅)   2021-09-01 04:14:00
問題不是TDD是purist吧 任何xxx purist都要小心
作者: deangood01 (跨斯歐鵝)   2021-09-01 04:26:00
看到Sprint retrospectives 馬上點about 嗯... 果然是Amazon的員工 覺得看看就好
作者: matyih (mat)   2021-09-01 05:02:00
6年的L5 看看就好
作者: rtoday (rtoday)   2021-09-01 05:17:00
看看就好+1
作者: WaterLengend (Leeeeeeeeooooooo)   2021-09-01 05:53:00
PM那個實在有夠中肯
作者: 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幹麻?
作者: brianhsu (墳墓)   2021-09-01 09:01:00
部份不認同,我自己的經驗是確實 bug 好發在沒有被 testcoverage 到的地方。然後 TDD 那個看程度,我猜他指的是那種非常堅持要先有test code 才寫 production code 的狀況。但實務上滿多是先寫一小段 production code,再補一小段 test code的。
作者: MOONY135 (談無慾)   2021-09-01 09:23:00
樓上那個是莫非定律 你就是沒想到會有bug的部分你的測試當然也是沒寫到了 所以總會出現在沒cover的地方
作者: alihue (wanda wanda)   2021-09-01 09:25:00
就跟寫論文先有實驗結果再回去寫假設一樣
作者: triplee (none)   2021-09-01 09:39:00
不需要時去設計scalable system 就是爛工程師 這點有點玩味 因為遇到的場景通常是你以為你不需要 結果日後碰到了才發現你的系統動彈不得 這篇文的背景跟觀點應該是有絕對性的關聯 跟之前另一篇分享個人覺得有差別10年工程師的酒後牢騷那篇
作者: brianhsu (墳墓)   2021-09-01 09:47:00
我自己是同意紙筆非常好用。畫流程/架構圖、簡單的測資或 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
推紙筆
作者: cunankimo (F5)   2021-09-01 12:22:00
大部份認同
作者: alongalone (沿著孤單的路)   2021-09-01 12:43:00
有戰的潛力
作者: aa155495 (冷月狂刃)   2021-09-01 13:07:00
pm那段不完全認同
作者: kvjo (同名專輯)   2021-09-01 13:27:00
PM這段很簡單 就把PM拿掉 過一些日子 還是會發現需要有個人PM是軟能力大於硬能力的ROLE 本來就很難評估
作者: bnd0327 (阿噗噗)   2021-09-01 14:19:00
比較驚訝要花六年才相信靜態分析有用
作者: zebraseven (Die walkuere)   2021-09-01 15:21:00
abstract 翻抽象怪怪的,翻成介面不是順暢點?
作者: alihue (wanda wanda)   2021-09-01 15:58:00
抽象是過程,介面是輸出XD
作者: sunsamy   2021-09-01 16:38:00
敏捷/scum master是拿來浪費大家時間的
作者: alihue (wanda wanda)   2021-09-01 17:02:00
沒事還會在那玩小遊戲而不是跳過會議
作者: polola6212 (Polo)   2021-09-01 18:21:00
極端TDD信仰者和重構之前不寫Test Code都蠻麻煩的前者是不好合作,後者是在埋地雷
作者: yamiodymel (YamiOdymel)   2021-09-01 20:22:00
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:00
Java忽然就出現了謝謝分享翻譯
作者: triplee (none)   2021-09-02 12:38:00
覺得jennya的例子比較像是失敗的抽象而不是scalable的鍋
作者: s0914714 (YA)   2021-09-03 00:23:00
認同t大說法 那應該是失敗的抽象 過度抽象不至於那麼慘但我也同意有需求再做就好 只是一發現有問題就得重構
作者: dein0522 (Dennis)   2021-09-03 00:40:00
monolith指的是公司主要的codebase,通常有幾百萬行程式碼,因為美國大公司都可能有幾萬個工程師
作者: v9290026 (CH)   2021-09-04 14:08:00
我同意多數,學習啦
作者: bndan (seed)   2021-09-04 15:54:00
9成PM存在與否沒差 這邊的問題在於"設計"者承擔了額外的工作 EX: 工作時間分配與責任 但這也很兩難啦 把全部責任都堆PM上 在這部份和社會文化不合 這社會強調的是為自己做的事負責..分配工作做不完=自己有問題=>那設計者一開始就把自己的產能需求掐住 自己規化工作時程分配 => PM要他幹嘛高度緊密合作(包含工作時程) VS 個人獨立性 前者不被這文化選擇...

Links booklink

Contact Us: admin [ a t ] ucptt.com