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

看板Soft_Job作者 (wanda wanda)時間2年前 (2021/08/31 21:45), 2年前編輯推噓34(35推 1噓 68→)
留言104則, 50人參與, 2年前最新討論串1/2 (看更多)
看到不錯的文章 翻譯分享一下 原文: 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://www.ptt.cc/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
推
08/31 21:52, 2年前 , 1F
大部分都認同，感謝分享
08/31 21:52, 1F
→
08/31 21:59, 2年前 , 2F
大部分認同 看你PM價值 低價值PM如此
08/31 21:59, 2F
→
08/31 21:59, 2年前 , 3F
vaulable的PM 明天消失 好像很清淨 過幾天就知道.更排山倒海
08/31 21:59, 3F
噓
08/31 22:25, 2年前 , 4F
….有些結論太武斷
08/31 22:25, 4F
他個人心得而已 每個人待過的 Team/遇過的人/做過的事不同會有不一樣的體悟吧
推
08/31 22:30, 2年前 , 5F
不同意紙筆。我說心眼(半小時全盲打)易於專心,但難練
08/31 22:30, 5F
推
08/31 22:33, 2年前 , 6F
Issue tracker很重要
08/31 22:33, 6F
推
08/31 22:35, 2年前 , 7F
九成的PM明天消失對你都沒影響www
08/31 22:35, 7F
推
08/31 23:06, 2年前 , 8F
GO是怪咖語言
08/31 23:06, 8F
推
08/31 23:31, 2年前 , 9F
感謝翻譯
08/31 23:31, 9F
→
08/31 23:37, 2年前 , 10F
等你出名後 就能把這些拿來出書了
08/31 23:37, 10F
→
08/31 23:55, 2年前 , 11F
TDD為什麼這麼容易被唾棄啊
08/31 23:55, 11F
TDD 在適當時機用不錯吧 如果是狂熱到無論如何都要 TDD就過頭
推
09/01 00:13, 2年前 , 12F
能多解釋java沒那模爛這點嗎?
09/01 00:13, 12F
原作沒解釋，以下個人觀點 不過入門語言若是如 Python 等更簡便的語言，通常會覺得 java 很冗吧 不過在現實世界，Java 就是一個語言界 toyota 在效能/物件導向/JVM (開發者不用管理記憶體)中取得平衡， 各種 Solution 都很成熟，生態圈也廣 只是在 oracle 官司爭議後又變臭了
推
09/01 00:15, 2年前 , 13F
感謝翻譯
09/01 00:15, 13F
推
09/01 00:27, 2年前 , 14F
最後的 Code coverage 是指 Test Coverage 嗎
09/01 00:27, 14F
應該是
推
09/01 00:57, 2年前 , 15F
第一點跟刁linting是怪咖有矛盾啊
09/01 00:57, 15F
→
09/01 01:03, 2年前 , 16F
有些偏頗+1 直接面對客戶會變成沒防火牆 客戶會不斷改需求
09/01 01:03, 16F
→
09/01 01:03, 2年前 , 17F
好的PM/scrum master是會帶著整個團隊往前衝
09/01 01:03, 17F
→
09/01 01:05, 2年前 , 18F
其他大致同意 面試真的沒有最客觀的方法
09/01 01:05, 18F
好的 PM 真的工作起來很爽
推
09/01 01:17, 2年前 , 19F
PM那個一定是沒遇過都扛屎缺的PM 沒了屎缺大家分了
09/01 01:17, 19F
→
09/01 01:34, 2年前 , 20F
謝謝翻譯
09/01 01:34, 20F
推
09/01 02:24, 2年前 , 21F
樓樓上，所以原文說九成沒有說全部啊XD
09/01 02:24, 21F
推
09/01 03:44, 2年前 , 22F
好奇TDD有啥特別的問題嗎
09/01 03:44, 22F
推
09/01 03:55, 2年前 , 23F
不錯啊
09/01 03:55, 23F
推
09/01 04:14, 2年前 , 24F
問題不是TDD是purist吧 任何xxx purist都要小心
09/01 04:14, 24F
→
09/01 04:26, 2年前 , 25F
看到Sprint retrospectives 馬上點about 嗯... 果然
09/01 04:26, 25F
→
09/01 04:26, 2年前 , 26F
是Amazon的員工 覺得看看就好
09/01 04:26, 26F
→
09/01 05:02, 2年前 , 27F
6年的L5 看看就好
09/01 05:02, 27F
推
09/01 05:17, 2年前 , 28F
看看就好＋1
09/01 05:17, 28F
推
09/01 05:53, 2年前 , 29F
PM那個實在有夠中肯
09/01 05:53, 29F
→
09/01 06:23, 2年前 , 30F
部份認同
09/01 06:23, 30F
推
09/01 07:39, 2年前 , 31F
看看就好+1 部分認同而已
09/01 07:39, 31F
推
09/01 08:41, 2年前 , 32F
懶惰寫測試就說 牽拖TDD幹麻？
09/01 08:41, 32F
推
09/01 09:01, 2年前 , 33F
部份不認同，我自己的經驗是確實 bug 好發在沒有被 test
09/01 09:01, 33F
→
09/01 09:01, 2年前 , 34F
coverage 到的地方。
09/01 09:01, 34F
還有 31 則推文
※ 編輯: alihue (106.73.26.66 日本), 09/01/2021 20:30:13
推
09/01 20:22, 2年前 , 66F
Scalable 那段是指很多人為了講究「擴展性」而故意寫
09/01 20:22, 66F
→
09/01 20:22, 2年前 , 67F
微服務、K8S 或是用 MongoDB 這種 NoSQL。當初 MongoD
09/01 20:22, 67F
→
09/01 20:22, 2年前 , 68F
B 的著名笑話就是：「我知道 MySQL 很好, But does it
09/01 20:22, 68F
→
09/01 20:22, 2年前 , 69F
scale?」
09/01 20:22, 69F
→
09/01 21:39, 2年前 , 70F
整篇廢話
09/01 21:39, 70F
→
09/01 21:40, 2年前 , 71F
用這篇邏輯來說就是：這篇是廢話，但又沒那麼廢話。
09/01 21:40, 71F
推
09/01 22:55, 2年前 , 72F
好文，推！
09/01 22:55, 72F
→
09/01 22:55, 2年前 , 73F
除了PM那行不同意以外其他都同意；有遇過雷的PM但就算是
09/01 22:55, 73F
→
09/01 22:55, 2年前 , 74F
雷的PM還是有幫RD做了不少溝通的事。
09/01 22:55, 74F
→
09/01 22:55, 2年前 , 75F
最想推的就是YAGNI，有些RD為了他們自以為「未來會有的
09/01 22:55, 75F
→
09/01 22:55, 2年前 , 76F
需求」而先寫了「方便未來scalable的」的多餘的抽象化，
09/01 22:55, 76F
→
09/01 22:55, 2年前 , 77F
十年之後來看他們當初寫的code，那些多餘的抽象化都是從
09/01 22:55, 77F
→
09/01 22:55, 2年前 , 78F
來沒發生作用的廢code，他們完全預估錯了未來需求會發展
09/01 22:55, 78F
→
09/01 22:55, 2年前 , 79F
的方向；而他們為了不需要的抽象化而多寫的那些邏輯反而
09/01 22:55, 79F
→
09/01 22:55, 2年前 , 80F
讓程度中等不敢大刀闊斧砍code的後人、為了實現真正的需
09/01 22:55, 80F
→
09/01 22:55, 2年前 , 81F
求而必須繞來繞去的東加西加，疊床架屋，很多邏輯變得繞
09/01 22:55, 81F
→
09/01 22:55, 2年前 , 82F
，又再加上沒有作用的抽象化code在干擾readability，明
09/01 22:55, 82F
→
09/01 22:55, 2年前 , 83F
明可以很簡單明瞭的東西最後卻變得超雜亂。看完十年git
09/01 22:55, 83F
→
09/01 22:55, 2年前 , 84F
log history，結論真的就是YAGNI，當下真的給進來的需
09/01 22:55, 84F
→
09/01 22:55, 2年前 , 85F
求你再做，不要自以為可以預測未來，事實證明他們預測的
09/01 22:55, 85F
→
09/01 22:56, 2年前 , 86F
沒有一個命中，然後沒自信或趕時間的後人不敢砍掉沒用的
09/01 22:56, 86F
→
09/01 22:56, 2年前 , 87F
抽象化，最後相關的module發展的歪七扭八盤根錯節。假如
09/01 22:56, 87F
→
09/01 22:56, 2年前 , 88F
當初不過度抽象化，就寫最簡單最初學者的那種架構，反而
09/01 22:56, 88F
→
09/01 22:56, 2年前 , 89F
不會危害那麼大。YAGNI！
09/01 22:56, 89F
→
09/02 01:21, 2年前 , 90F
Java忽然就出現了
09/02 01:21, 90F
推
09/02 01:23, 2年前 , 91F
謝謝分享翻譯
09/02 01:23, 91F
→
09/02 12:38, 2年前 , 92F
覺得jennya的例子比較像是失敗的抽象而不是scalable的鍋
09/02 12:38, 92F
推
09/03 00:23, 2年前 , 93F
認同t大說法 那應該是失敗的抽象 過度抽象不至於那麼慘
09/03 00:23, 93F
→
09/03 00:25, 2年前 , 94F
但我也同意有需求再做就好 只是一發現有問題就得重構
09/03 00:25, 94F
→
09/03 00:40, 2年前 , 95F
monolith指的是公司主要的codebase，通常有幾百萬行程
09/03 00:40, 95F
→
09/03 00:40, 2年前 , 96F
式碼，因為美國大公司都可能有幾萬個工程師
09/03 00:40, 96F
推
09/04 14:08, 2年前 , 97F
我同意多數，學習啦
09/04 14:08, 97F
→
09/04 15:54, 2年前 , 98F
9成PM存在與否沒差 這邊的問題在於"設計"者承擔了額外的工
09/04 15:54, 98F
→
09/04 15:54, 2年前 , 99F
作 EX: 工作時間分配與責任 但這也很兩難啦 把全部責任都堆
09/04 15:54, 99F
→
09/04 15:55, 2年前 , 100F
PM上 在這部份和社會文化不合 這社會強調的是為自己做的事
09/04 15:55, 100F
→
09/04 15:55, 2年前 , 101F
負責..分配工作做不完=自己有問題=>那設計者一開始就把自己
09/04 15:55, 101F
→
09/04 15:56, 2年前 , 102F
的產能需求掐住 自己規化工作時程分配 => PM要他幹嘛
09/04 15:56, 102F
→
09/04 15:57, 2年前 , 103F
高度緊密合作(包含工作時程) VS 個人獨立性 前者不被這文化
09/04 15:57, 103F
→
09/04 15:57, 2年前 , 104F
選擇...
09/04 15:57, 104F
‣ 更多 alihue 的文章
文章代碼(AID): #1XBZA9bb (Soft_Job)
‣ 更多 alihue 的文章
文章代碼(AID): #1XBZA9bb (Soft_Job)