[心得] (轉)軟體開發六年後我改變想法的事情
看到不錯的文章 翻譯分享一下
原文:
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
--
大部分都認同，感謝分享
大部分認同 看你PM價值 低價值PM如此
vaulable的PM 明天消失 好像很清淨 過幾天就知道.更排山倒海
….有些結論太武斷
他個人心得而已 每個人待過的 Team/遇過的人/做過的事不同會有不一樣的體悟吧
不同意紙筆。我說心眼(半小時全盲打)易於專心,但難練
Issue tracker很重要
九成的PM明天消失對你都沒影響www
GO是怪咖語言
感謝翻譯
等你出名後 就能把這些拿來出書了
TDD為什麼這麼容易被唾棄啊
TDD 在適當時機用不錯吧 如果是狂熱到無論如何都要 TDD就過頭
能多解釋java沒那模爛這點嗎?
原作沒解釋，以下個人觀點 不過入門語言若是如 Python 等更簡便的語言，通常會覺得 java 很冗吧 不過在現實世界，Java 就是一個語言界 toyota 在效能/物件導向/JVM (開發者不用管理記憶體)中取得平衡， 各種 Solution 都很成熟，生態圈也廣 只是在 oracle 官司爭議後又變臭了
感謝翻譯
最後的 Code coverage 是指 Test Coverage 嗎
應該是
第一點跟刁linting是怪咖有矛盾啊
有些偏頗+1 直接面對客戶會變成沒防火牆 客戶會不斷改需求
好的PM/scrum master是會帶著整個團隊往前衝
其他大致同意 面試真的沒有最客觀的方法
好的 PM 真的工作起來很爽
PM那個一定是沒遇過都扛屎缺的PM 沒了屎缺大家分了
謝謝翻譯
樓樓上，所以原文說九成沒有說全部啊XD
好奇TDD有啥特別的問題嗎
不錯啊
問題不是TDD是purist吧 任何xxx purist都要小心
看到Sprint retrospectives 馬上點about 嗯... 果然
是Amazon的員工 覺得看看就好
6年的L5 看看就好
看看就好＋1
PM那個實在有夠中肯
部份認同
看看就好+1 部分認同而已
懶惰寫測試就說 牽拖TDD幹麻？
部份不認同，我自己的經驗是確實 bug 好發在沒有被 test
coverage 到的地方。
然後 TDD 那個看程度，我猜他指的是那種非常堅持要先有
test code 才寫 production code 的狀況。但實務上滿多
是先寫一小段 production code，再補一小段 test code
的。
樓上那個是莫非定律 你就是沒想到會有bug的部分
你的測試當然也是沒寫到了 所以總會出現在沒cover的地方
就跟寫論文先有實驗結果再回去寫假設一樣
不需要時去設計scalable system 就是爛工程師 這點有點玩
味 因為遇到的場景通常是你以為你不需要 結果日後碰到了
才發現你的系統動彈不得 這篇文的背景跟觀點應該是有絕對
性的關聯 跟之前另一篇分享個人覺得有差別
10年工程師的酒後牢騷那篇
我自己是同意紙筆非常好用。畫流程/架構圖、簡單的測資
或 puesdo code，整理思或緒釐清問題都很好用又快速。
很多時候紙筆整理完，就知道程式碼要怎麼寫了。
紙筆是整理思緒的好工具
推有心翻譯
推
推紙筆
大部份認同
有戰的潛力
pm那段不完全認同
PM這段很簡單 就把PM拿掉 過一些日子 還是會發現需要有個人
PM是軟能力大於硬能力的ROLE 本來就很難評估
比較驚訝要花六年才相信靜態分析有用
abstract 翻抽象怪怪的，翻成介面不是順暢點？
抽象是過程，介面是輸出XD
敏捷/scum master是拿來浪費大家時間的
沒事還會在那玩小遊戲而不是跳過會議
極端TDD信仰者和重構之前不寫Test Code都蠻麻煩的
前者是不好合作，後者是在埋地雷
Scalable 那段是指很多人為了講究「擴展性」而故意寫
微服務、K8S 或是用 MongoDB 這種 NoSQL。當初 MongoD
B 的著名笑話就是：「我知道 MySQL 很好, But does it
scale?」
整篇廢話
用這篇邏輯來說就是：這篇是廢話，但又沒那麼廢話。
好文，推！
除了PM那行不同意以外其他都同意；有遇過雷的PM但就算是
雷的PM還是有幫RD做了不少溝通的事。
最想推的就是YAGNI，有些RD為了他們自以為「未來會有的
需求」而先寫了「方便未來scalable的」的多餘的抽象化，
十年之後來看他們當初寫的code，那些多餘的抽象化都是從
來沒發生作用的廢code，他們完全預估錯了未來需求會發展
的方向；而他們為了不需要的抽象化而多寫的那些邏輯反而
讓程度中等不敢大刀闊斧砍code的後人、為了實現真正的需
求而必須繞來繞去的東加西加，疊床架屋，很多邏輯變得繞
，又再加上沒有作用的抽象化code在干擾readability，明
明可以很簡單明瞭的東西最後卻變得超雜亂。看完十年git
log history，結論真的就是YAGNI，當下真的給進來的需
求你再做，不要自以為可以預測未來，事實證明他們預測的
沒有一個命中，然後沒自信或趕時間的後人不敢砍掉沒用的
抽象化，最後相關的module發展的歪七扭八盤根錯節。假如
當初不過度抽象化，就寫最簡單最初學者的那種架構，反而
不會危害那麼大。YAGNI！
Java忽然就出現了
謝謝分享翻譯
覺得jennya的例子比較像是失敗的抽象而不是scalable的鍋
認同t大說法 那應該是失敗的抽象 過度抽象不至於那麼慘
但我也同意有需求再做就好 只是一發現有問題就得重構
monolith指的是公司主要的codebase，通常有幾百萬行程
式碼，因為美國大公司都可能有幾萬個工程師
我同意多數，學習啦
9成PM存在與否沒差 這邊的問題在於"設計"者承擔了額外的工
作 EX: 工作時間分配與責任 但這也很兩難啦 把全部責任都堆
PM上 在這部份和社會文化不合 這社會強調的是為自己做的事
負責..分配工作做不完=自己有問題=>那設計者一開始就把自己
的產能需求掐住 自己規化工作時程分配 => PM要他幹嘛
高度緊密合作(包含工作時程) VS 個人獨立性 前者不被這文化
選擇...
YAGNI 說到心坎裡
這篇也講得不錯
![Re: [心得] (轉)軟體開發六年後我改變想法的事情](https://martinfowler.com/bliki/images/microservice-verdict/path.png "Re: [心得] (轉)軟體開發六年後我改變想法的事情")
爆
Re: [心得] 如果可以, 真的建議不要再去創業公司了看到這篇好幾天了，想想還是也來分享一點個人經驗 我自己在業界的資歷沒有很久，也不是本科出身。 從十幾年前玩 open source 專案，誤打誤撞一路寫 code 到現在， 後來去國立資工所洗了一下 XD 所以現在也號稱本科了 研究所畢業後進入稍有規模的新創，後來也待了大公司。31
Re: [心得] AmazingTalker/台灣樂天市場 面試心得AmazingTalker CTO 回覆面試心得 (此為 AmazingTalker 人資部門代為轉發) 感謝版友分享在AmazingTalker的面試心得，也感謝各位大大的關心。 在招募過程中，我們一直檢討，並作出相應調整和改善。 當天面試過程不著墨太多。37
[心得] 機械轉軟體工程師經驗分享# 前言 想分享一下當初從進公司幾乎不會寫程式 到現在負責做軟體的porting to Linux的經歷 如果你想轉軟體工程師，最好先進到願意讓你寫程式的公司 但是這不一定辦得到，我底下分享一些自己做的功課![[心得] 機械轉軟體工程師經驗分享](https://cdn.sstatic.net/Sites/stackoverflow/Img/apple-touch-icon@2.png?v=73d79a89bded "[心得] 機械轉軟體工程師經驗分享")
23
Re: [討論] 怎樣算是一個合格的junior cpp programme針對關於 TDD 的討論另外回一篇好了 覺得用推文太長了 XD : 推 stupidlove0: 朝聖！重要的真的是unit test 08/23 18:47 : → HZYSoft: 回樓上 TDD 問題，TDD 不只要測試，還要先寫測試才寫code 08/23 21:33 : → HZYSoft: 很多人無法習慣這種順序，是否一定要 TDD 這有爭議 08/23 21:3421
Fw: [心得] 機械轉軟體工程師經驗分享作者: wulouise (在線上!=在電腦前) 看板: Tech_Job 標題: [心得] 機械轉軟體工程師經驗分享 時間: Thu Jan 21 20:45:46 2021 # 前言 想分享一下當初從進公司幾乎不會寫程式20
Re: [分享] 用一個簡單的數學公式來幫忙設計OOP類別先講結論: 我反對原文的結論「OOP易學難精」 就我個人到現在的感受是「難學易精」 為什麼呢? 以下分享個人看法![Re: [分享] 用一個簡單的數學公式來幫忙設計OOP類別](https://i.ytimg.com/vi/KIto1OQxwsY/maxresdefault.jpg "Re: [分享] 用一個簡單的數學公式來幫忙設計OOP類別")
15
[請益] 非本科一年半經驗 求問未來方向小弟目前三十三歲，本身就私立科大化工系畢業，完完全全的非本科 在 2020 年的六月正式踏入軟體業作為全端工程師，實際工作資歷約一年半 因為去年疫情有停止工作三個月 現在有點迷莽的是我之後的工程師生涯規劃到底要怎麼樣比較好呢？ 希望各位大大可以指點一下，謝謝9
[心得] 後端/系統分析 面試 數家去年10月由於前一份工作無端捲入政治鬥爭，還有薪水共體時艱到甚至比新人還低了..心灰意冷下決定換工作. 由於前一份工作經歷了公司黑暗期，所以前後端，系統分析，系統架構，資料庫啥的都搞過. 但是個人比較喜歡後端跟系統分析，所以找工作以這兩個為主. 個人背景是10年工作經驗，112本科學士 以下順序並沒有依照面試日期或是公司名稱，完全是先想到哪家就哪家. 1. Sr. Software Engineer Manulife HK: Manulife就是宏利人壽，這個缺其實不需要寫code. 主要是review外包商的code, 喬事情.2
Re: [請益] 這是什麼語法 (for C)?-c : 不怕各位笑，小弟摸C語言這麼久，今天第一次看到這種寫法 : 看了半天，實在是不知道是什麼意思 : 程式碼我Compile過，確定是可以編譯可以Run的 : 有高手能給個解答嗎？
![Re: [心得] AmazingTalker/台灣樂天市場 面試心得](https://lh4.googleusercontent.com/tM7r9m2aWuaCBYPLM-y3xCN-n2M0E3SJD5UVxw2aooO0RHNL60y-uBXLH3JavmjNcbY=w1200-h630-p "Re: [心得] AmazingTalker/台灣樂天市場 面試心得")