收假前來看點故事吧，今天要推薦的是這篇：
軟體開發者的培養 - 卡米哥

這篇的主軸圍繞在作者 20 年來的學習歷程，以及過程中培養的各項價值觀

從剛入門大家都有過的「寫了能跑、越短越好」開始，隨著問題越來越難、越複雜，也開始有了效能、可讀性、可維護性等等的考量

作者很貼心的把培養出來的這些價值觀分項列點地說明。推薦大家直接過去看原文，段落明確，說明清晰，值得收藏

但因為我畫的重點太多了（老毛病），多到沒辦法直接整車拉過來，因此今天也按照慣例，簡單粗暴地列一下內容收進我的筆記庫就好

程式碼執行成本（效能）

要處理的資料量變大了，程式寫爛了要跑半天了，得開始重視效能
➡️ 學習資料結構和演算法，辨別程式執行時間和實作方案的優劣

程式碼修改成本（可維護性）

專案開始被改來改去了，每次修改都要花成本
➡️ 如果能讓修改更方便快速，那當然就可以增加產能
➡️ 需要版本控制，以及改用能夠抽換實作的寫法

程式碼理解成本（可讀性）

改東西的時候會因為程式碼太亂，光是讀懂就花了大量時間
➡️ 專案規模越來越大，要讀的東西也越來越多，花的時間也越來越長
➡️ 只能動手整理程式碼，開始乖乖拆模組、好好取名等等

（作者推薦看怦然心動的人生整理魔法，我也有點怦然心動）

程式碼彈性

開始觀察需求的生長方向來留擴充點，使用物件導向原則和設計模式來保留彈性

（我個人感覺有點像是可維護性的延伸議題，而且我還菜，有時會分不出來彈性和過度設計 QQ）

程式碼測試成本

重構（作者很誠實，他寫「重寫」）的時候很容易改壞之前寫好的部分
➡️ 專案規模越大也就代表測試成本越高
➡️ 需要開始碰自動化測試了

保留修改權、保留反悔權

如果面臨兩個解決方案，想一想：

  • 選擇某個方案之後，要再進一步修改的成本有多高？
  • 選擇某個方案之後，想反悔了改成另一個方案的成本有多高？

例如修改變數名稱的成本遠低於修改 DB 的欄位；或是存圖片的時候先保存完整圖片，把真的效能炸裂的時候換成保存壓縮後圖片的選項保留起來等等

總之就是：避免做出悔不當初的選擇

學習前人經驗

有一句我覺得作者講得挺好，切中我心，直接轉上來

一開始會以為只會用套件做東西的人很弱，能自己實作才強，但現在完全不會這樣想。 只會靠自己累積經驗的學習方式最慢，能吸收他人經驗來加速學習，才能站在巨人的肩膀上。

前面列了蠻多價值觀的，那如果這些價值觀衝突了呢？

這時候就要根據情況對價值觀進行優先度的排序：

在不同的情況下，價值觀的優先序也會跟著不同，例如開發完成就不會再增加需求的小專案就不需要考慮修改成本。

價值觀的篇幅結束了之後，作者還談了一些通靈能力、協作能力的部分。例如多人開發的時候，就像同居時每個室友對乾淨的看法不同，勢必要先喬好，最好能留下規約，把髒亂的環境打掃成乾淨的環境

但因為我信奉的是游泳池原則（軟體專案就像游泳池，每個人都會在裡面尿尿），所以就不特別截了。

只是最後有一段讓我有被打到的港覺：

身為資深軟體開發者，應該要有能力培養技術等級低的開發者，而不是排擠或邊緣化他們。一個有能力培養新進開發者的資深開發者是更有價值的。在遊戲裡，30% 團隊戰鬥力加成的靈氣，通常是很強的技能。

要是我們整隊都有 30% 靈氣還能疊加該有多強啊！這也許正是現在的我所缺少的。特別筆記下來。

真的很喜歡看這些前輩們的觀念文或經驗談，感覺像是窺見前輩們思考裡的其中一角，正在挖的大泥球都變香了呢

那麼，今天的轉貼就到這邊，我們明天見～