Re: [討論] 寫程式的追求？

※ 引述《del680202 (HANA)》之銘言：
: ※ 引述《neo5277 (I am an agent of chaos)》之銘言：
: : 純粹對工作上來說
: : 好抽換，好接手(易閱讀)，好維護(包含升級，測試
: 好接手，易閱讀…
: 我想到一個故事
看到你的故事，讓我想起好多當年犯過的錯誤

: 幾年前有個同事，號稱國中時期就開始接案寫代碼
: clean code,DDD滾瓜爛熟,對coding極度潔癖
: 印象比較深的是入職時說了句：我看到不規範的代碼會非常生氣
我年輕的時候也這樣，但做久了慢慢可以理解凡事都是 trade-off
寫得很漂亮，卻沒商業價值的 code，根本沒人在用，
對比寫得很亂，卻實際有大量使用者的 code，很難說哪個是比較好的。
剛進業界第一份工作，很認真的幫每個 function 寫滿註解跟 API doc，
努力遵循各種 best practice，幾個月後專案取消了，這 code 從來沒上 production
對比那些可怕的 legacy code，每天都好好的運行著賺錢的服務。
後來開始懂得要考量 business 的需求，有時候犧牲一點品質，搶占先機是必要之惡

: 上工第一案子，設計一個工具網站，拆了七個GitHub repo
這我當年剛學 git/github 也做過，把個巨大專案拆了十幾個 repo，
原先要解決的問題是，希望每個元件可以降低耦合，容易獨立使用，分開 deploy。
隨著時間，逐漸發現各個元件需要共用的東西越來越多，互相 dependency 逐漸變多
這時候各個元件之間需要正確的版本，才能互相搭配，管理起來卻成了噩夢
有些直接 include 就能用的東西，拆在兩個 repo 掛 submodule 變得很難維護
build rules / makefile 也因此複雜了起來，最後有點後悔一開始把他們拆開。
體驗過就能理解為何很多大公司最後走向 monorepo 架構，全公司專案都在一個 repo
其中一個經典案例就是 google，幾乎全公司所有 code 在一個巨無霸 repo 內。
不同程式互相引用，就少有版本管理問題，開發的複雜度降低很多。

: Micro services, grpc當年流行的工具全套了一輪
: 說是將低耦合，高內聚做到極致
剛進業界的時候，我也是剛學了 microservice，很開心地把手上系統全拆了
拆分得很乾淨，每個服務都可以分開擴展，一開始還覺得這是 best practice
後來學到血淚教訓。因為業務的改變，需求大幅度改變了。原先的拆分並不合適
反而讓開發、測試、跟部署變得複雜，印證了 "monolith first" 的建議!
在早期需求還不明朗的時候，全部塞在一起，其實不是壞事，延遲到真正出現擴展需求
再來拆分，會比過早拆分要好。這跟不要 premature optimization 感覺很像。

就跟一開始學 OOP 都狂寫 interface，後來才發現根本沒有其他 implementation
白白多了一堆無謂的繼承，最後又發現需要不同的行為，於是換了 interface
本來定義的抽象化不但沒用到，還因為要保持相容，造成日後擴充的阻礙。
後來就學到 "concrete first"，不要起手式就急著開 abstract interface，
可以延後到真的有需要再來做，有時候反而會更合適。
做久了慢慢對這些東西有不同的感受，best practice 通常要放在特定情境下才是 best如果很清楚自己做了什麼 trade-off，違反它們不見得是錯誤的。

: 其中一個repo 甚至只放了一個utils
: 後來來了另一個人接手
: 改個功能要先看懂七個repo之間關聯，跟找大秘寶似的
: 在review code階段，還埋個彩蛋，發現了隱藏的第八個repo
: 新來的同事說改不動了，就算加個menu都很麻煩
: 心一橫，提案該網站功能也不複雜，全部打掉重做
: 就自己埋頭花了兩週重做了那個網站加遷移
兩個禮拜是不是沒算到寫 test 跟重作 QA 的時間 XD
寫 code 相對快，大部分開發時間本就都花在其他地方
這種大霹靂式的重寫，通常是很危險的 XD

: 工程師追求的很簡單，(自己）好閱讀，（自己）好維護就行了
: -----
: Sent from JPTT on my iPhone

--
Sent from PCMan on PCMan's PC

--