PTT推薦

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

看板Soft_Job標題[心得] (轉)軟體開發六年後我改變想法的事情作者
alihue
(wanda wanda)
時間推噓36 推:37 噓:1 →:69

看到不錯的文章 翻譯分享一下

原文:
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留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 106.73.26.66 (日本)
PTT 網址
※ 編輯: 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

bjk08/31 21:52大部分都認同,感謝分享

kvjo08/31 21:59大部分認同 看你PM價值 低價值PM如此

kvjo08/31 21:59vaulable的PM 明天消失 好像很清淨 過幾天就知道.更排山倒海

gn0183833508/31 22:25….有些結論太武斷

他個人心得而已 每個人待過的 Team/遇過的人/做過的事不同會有不一樣的體悟吧

enthos08/31 22:30不同意紙筆。我說心眼(半小時全盲打)易於專心,但難練

yamakazi08/31 22:33Issue tracker很重要

viper970908/31 22:35九成的PM明天消失對你都沒影響www

jack020408/31 23:06GO是怪咖語言

amiwry08/31 23:31感謝翻譯

shooter55508/31 23:37等你出名後 就能把這些拿來出書了

MOONY13508/31 23:55TDD為什麼這麼容易被唾棄啊

TDD 在適當時機用不錯吧 如果是狂熱到無論如何都要 TDD就過頭

k90042109/01 00:13能多解釋java沒那模爛這點嗎?

原作沒解釋,以下個人觀點 不過入門語言若是如 Python 等更簡便的語言,通常會覺得 java 很冗吧 不過在現實世界,Java 就是一個語言界 toyota 在效能/物件導向/JVM (開發者不用管理記憶體)中取得平衡, 各種 Solution 都很成熟,生態圈也廣 只是在 oracle 官司爭議後又變臭了

ian9091109/01 00:15感謝翻譯

RunRun556609/01 00:27最後的 Code coverage 是指 Test Coverage 嗎

應該是

jete09/01 00:57第一點跟刁linting是怪咖有矛盾啊

umum2909/01 01:03有些偏頗+1 直接面對客戶會變成沒防火牆 客戶會不斷改需求

umum2909/01 01:03好的PM/scrum master是會帶著整個團隊往前衝

umum2909/01 01:05其他大致同意 面試真的沒有最客觀的方法

好的 PM 真的工作起來很爽

em123409/01 01:17PM那個一定是沒遇過都扛屎缺的PM 沒了屎缺大家分了

taipoo09/01 01:34謝謝翻譯

rotalume09/01 02:24樓樓上,所以原文說九成沒有說全部啊XD

pttassassin09/01 03:44好奇TDD有啥特別的問題嗎

ga01307709/01 03:55不錯啊

fantasychese09/01 04:14問題不是TDD是purist吧 任何xxx purist都要小心

deangood0109/01 04:26看到Sprint retrospectives 馬上點about 嗯... 果然

deangood0109/01 04:26是Amazon的員工 覺得看看就好

matyih09/01 05:026年的L5 看看就好

rtoday09/01 05:17看看就好+1

WaterLengend09/01 05:53PM那個實在有夠中肯

nanashi0709/01 06:23部份認同

CoverMind09/01 07:39看看就好+1 部分認同而已

strlen09/01 08:41懶惰寫測試就說 牽拖TDD幹麻?

brianhsu09/01 09:01部份不認同,我自己的經驗是確實 bug 好發在沒有被 test

brianhsu09/01 09:01 coverage 到的地方。

brianhsu09/01 09:04然後 TDD 那個看程度,我猜他指的是那種非常堅持要先有

brianhsu09/01 09:04test code 才寫 production code 的狀況。但實務上滿多

brianhsu09/01 09:04是先寫一小段 production code,再補一小段 test code

brianhsu09/01 09:04的。

MOONY13509/01 09:23樓上那個是莫非定律 你就是沒想到會有bug的部分

MOONY13509/01 09:24你的測試當然也是沒寫到了 所以總會出現在沒cover的地方

alihue09/01 09:25就跟寫論文先有實驗結果再回去寫假設一樣

triplee09/01 09:39不需要時去設計scalable system 就是爛工程師 這點有點玩

triplee09/01 09:40味 因為遇到的場景通常是你以為你不需要 結果日後碰到了

triplee09/01 09:41才發現你的系統動彈不得 這篇文的背景跟觀點應該是有絕對

triplee09/01 09:42性的關聯 跟之前另一篇分享個人覺得有差別

triplee09/01 09:4610年工程師的酒後牢騷那篇

brianhsu09/01 09:47我自己是同意紙筆非常好用。畫流程/架構圖、簡單的測資

brianhsu09/01 09:47或 puesdo code,整理思或緒釐清問題都很好用又快速。

brianhsu09/01 09:48很多時候紙筆整理完,就知道程式碼要怎麼寫了。

chuegou09/01 10:04紙筆是整理思緒的好工具

expiate09/01 11:01推有心翻譯

geniusturtle09/01 11:14

molopo09/01 11:49推紙筆

cunankimo09/01 12:22大部份認同

alongalone09/01 12:43有戰的潛力

aa15549509/01 13:07pm那段不完全認同

kvjo09/01 13:27PM這段很簡單 就把PM拿掉 過一些日子 還是會發現需要有個人

kvjo09/01 13:27PM是軟能力大於硬能力的ROLE 本來就很難評估

bnd032709/01 14:19比較驚訝要花六年才相信靜態分析有用

zebraseven09/01 15:21abstract 翻抽象怪怪的,翻成介面不是順暢點?

alihue09/01 15:58抽象是過程,介面是輸出XD

sunsamy09/01 16:38敏捷/scum master是拿來浪費大家時間的

alihue09/01 17:02沒事還會在那玩小遊戲而不是跳過會議

polola621209/01 18:21極端TDD信仰者和重構之前不寫Test Code都蠻麻煩的

polola621209/01 18:22前者是不好合作,後者是在埋地雷

※ 編輯: alihue (106.73.26.66 日本), 09/01/2021 20:30:13

yamiodymel09/01 20:22Scalable 那段是指很多人為了講究「擴展性」而故意寫

yamiodymel09/01 20:22微服務、K8S 或是用 MongoDB 這種 NoSQL。當初 MongoD

yamiodymel09/01 20:22B 的著名笑話就是:「我知道 MySQL 很好, But does it

yamiodymel09/01 20:22 scale?」

DrTech09/01 21:39整篇廢話

DrTech09/01 21:40用這篇邏輯來說就是:這篇是廢話,但又沒那麼廢話。

jennya09/01 22:55好文,推!

jennya09/01 22:55除了PM那行不同意以外其他都同意;有遇過雷的PM但就算是

jennya09/01 22:55雷的PM還是有幫RD做了不少溝通的事。

jennya09/01 22:55最想推的就是YAGNI,有些RD為了他們自以為「未來會有的

jennya09/01 22:55需求」而先寫了「方便未來scalable的」的多餘的抽象化,

jennya09/01 22:55十年之後來看他們當初寫的code,那些多餘的抽象化都是從

jennya09/01 22:55來沒發生作用的廢code,他們完全預估錯了未來需求會發展

jennya09/01 22:55的方向;而他們為了不需要的抽象化而多寫的那些邏輯反而

jennya09/01 22:55讓程度中等不敢大刀闊斧砍code的後人、為了實現真正的需

jennya09/01 22:55求而必須繞來繞去的東加西加,疊床架屋,很多邏輯變得繞

jennya09/01 22:55,又再加上沒有作用的抽象化code在干擾readability,明

jennya09/01 22:55明可以很簡單明瞭的東西最後卻變得超雜亂。看完十年git

jennya09/01 22:55 log history,結論真的就是YAGNI,當下真的給進來的需

jennya09/01 22:55求你再做,不要自以為可以預測未來,事實證明他們預測的

jennya09/01 22:56沒有一個命中,然後沒自信或趕時間的後人不敢砍掉沒用的

jennya09/01 22:56抽象化,最後相關的module發展的歪七扭八盤根錯節。假如

jennya09/01 22:56當初不過度抽象化,就寫最簡單最初學者的那種架構,反而

jennya09/01 22:56不會危害那麼大。YAGNI!

MDay5609/02 01:21Java忽然就出現了

MDay5609/02 01:23謝謝分享翻譯

triplee09/02 12:38覺得jennya的例子比較像是失敗的抽象而不是scalable的鍋

s091471409/03 00:23認同t大說法 那應該是失敗的抽象 過度抽象不至於那麼慘

s091471409/03 00:25但我也同意有需求再做就好 只是一發現有問題就得重構

dein052209/03 00:40monolith指的是公司主要的codebase,通常有幾百萬行程

dein052209/03 00:40式碼,因為美國大公司都可能有幾萬個工程師

v929002609/04 14:08我同意多數,學習啦

bndan09/04 15:549成PM存在與否沒差 這邊的問題在於"設計"者承擔了額外的工

bndan09/04 15:54作 EX: 工作時間分配與責任 但這也很兩難啦 把全部責任都堆

bndan09/04 15:55PM上 在這部份和社會文化不合 這社會強調的是為自己做的事

bndan09/04 15:55負責..分配工作做不完=自己有問題=>那設計者一開始就把自己

bndan09/04 15:56的產能需求掐住 自己規化工作時程分配 => PM要他幹嘛

bndan09/04 15:57高度緊密合作(包含工作時程) VS 個人獨立性 前者不被這文化

bndan09/04 15:57選擇...

jason8271410/29 14:50YAGNI 說到心坎裡

jason8271410/29 14:53這篇也講得不錯