The Pragmatic Programmer 是一本已出版 20 年的經典書籍。書如其名，對於想把軟體落地，產生改變的工程師們，這是一本必須要看的經典。裡面講述的原則至今仍然重要，可以讓工程師們受到啟發與學習。
石頭湯策略：改變，從小處著手
石頭湯策略講述一位戰後的士兵想與村明索取一些食物卻遭拒絕，索性用石頭作為湯底，最終吸引村民們各自貢獻食材，共同煮成一鍋美味的湯。在故事中，石頭扮演著起頭的角色，讓大家知道需要的是什麼，最終透過群體的合作來達成目標。
軟體開發也是一樣。在工作崗位上的大家可能都忙著把資源花在自己的任務上。若你想推動什麼，那就是自己先作，吸引他們的目光後，也許就會有人開始討論『這個可以這麼改善』、『我覺得這個不太適用於我們的情境』、『也許我們可以把他整進系統』。重點是，你要先有一個大家足以討論的石頭湯在他們面前，並且讓大家知道你想煮湯。
舉個具體的例子，一位團隊成員曾覺得整個系統的狀態管理部分有些問題，於是在他的任務內捨棄原先團隊使用的狀態管理方式，用自己的方式重構了一小部分程式碼。我們在程式碼審查 (Code Review) 會議上討論了這個改動，最終的結果是我們重新的調整對於狀態管理方式的作法，並且有一個比較一致的狀態管理方式。在這裡，這一小部分的程式碼就扮演著石頭湯的角色，負責『打響第一砲』，他可能不是完美的，但是沒有這位成員提出的這段，就不會有後續的討論與改變發生，最終影響了整個團隊的工作方式和技術標準。
幫你確認目標的『曳光彈』
曳光彈是在子彈底部裝有少量煙曳光藥劑的子彈或砲彈。 發射時，曳光藥劑點燃發亮，使彈丸的軌跡在白天也可見，而在夜間發射時則非常明亮。 這使射手可以觀測彈丸的飛行路徑，幫助進行彈道校正，確認射擊的方向與目標正確。
這種東西在產品開發中，有另一個名詞叫做最小可行性產品 MVP，目的是透過最小的投入來確認產品可行。而本書是給工程師看的，因此講的則是比較偏向技術面的，透過最小的投入來確認整個軟體系統的技術可行性。
面對一些大家不熟悉的新項目時，就是實施這種方法的時機，我們會先著手規劃與實現項目的核心功能，也就是先發射一顆曳光彈來確認目標。務求最小精力完成這些核心功能，再根據用戶反饋和實際使用情況，對它們進行迭代和改進，逐漸完善整個功能。對使用者來說也有好處，有了實際可操作的系統，就能給予實際操作的回饋，這也讓工程師們能夠在功能開發過程中能持續維持在目標上。
任務的切分與預估
當一個任務估時超過一天，或者是你沒有辦法一句話就解釋這個任務要作的事情的流程的時候，不如試試這樣作：將此任務的流程畫出來，並試著拆解成獨立可單獨實作的小塊。
這有幾個好處：
- 透過流程圖，了解任務的範疇以及影響的系統範圍
- 把流程拆解成幾個部分的過程，會增強你對此流程本質的熟悉程度
- 拆出獨立可單獨實作的小塊，代表後續維護也是如此
- 透過拆分出來的東西，可以更精準的知道任務的預估時程與進度
- 如果你臨時需要人幫忙，有了這些架構交接會比較容易，可以選擇部分小塊交接，或是把整個架構交接（當然，以上都記得要文件化）
其實以上就是一個系統規劃與定規格介面的過程，只是很多人都覺得這個要資深工程師或者是複雜的功能才要作，或者是 PM 要作，但實際上只要搞不清楚的任務的時候就應該要作。
可以理解有些人不愛寫文件、畫流程圖，這些真的超花時間，但把自己搞不清楚的概念釐清，其實有助於縮減後續實作甚至是維護的時間。加上現在有了 AI 的幫忙，作這些事情的速度可以提升很多。甚至可以請 AI 當作你的小 PM 助理，協助定義任務範疇、流程、拆解、寫規格。
終極目標：任務拆的夠小夠簡單，就讓 Copilot 幫你完成程式碼，你要負責的就是把任務拆解成對的幾個元件。
選擇工具與方法：適合的就是最好的
任何的工具和方法都應該被視為協助我們完成任務的手段，而不是硬性規定我們必須遵循的規則。在開發過程中，我們是自己產出程式碼的主人，靈活地使用工具和方法來達成我們的目標。
在軟體開發的實踐中，這種思維方式非常重要。它鼓勵開發者們不僅僅依賴於現有的工具和既定的方法，而是要根據具體的項目需求和實際情況，選擇最適合的工具和方法。這種靈活性不僅能夠提高工作效率，還能確保開發出來的軟體更加貼合使用者的需求和預期。
舉個例子，Design Pattern 一書中可能講了各種設計方法，但每個方法都有其適用的情境。又或是講到網頁效能調整，很多人會用 pagespeed 來看。但這些方法或工具都只是給你一個參考，對自己來說還是需要針對當下需要解決的重點，來決定需要如何去處理。Overengineering 是一個可以多想想的詞。
另一個角度的想法是，工具與方法不是主人，你才是。工具與方法不用負責任，而你需要對你的任務負責任。你的責任就是確保你用的工具與方法有解決到問題，你不能寫了一段錯誤的程式碼然後說這是 ChatGPT 寫的，對吧？
破窗理論與程式碼品質
破窗效應這概念意指一旦一棟建築的窗戶被破壞未及時修復，很快其他窗戶也會遭到破壞。
在軟體開發中也有類似狀況：一旦程式碼中出現了小錯誤或問題，如果不立即修復，這些小問題將導致更多，甚至產生更嚴重的問題。所謂的小錯誤有可能在系統的修改途中被拉扯變形，從小破口變成一個大洞。因此，請大家遵守童子軍規則：『離開營地前，讓營地比使用前更加乾淨。』
這也與團隊對品質的要求有關聯性，好的程式碼審查流程會盡量把可能的潛在錯誤作足夠的討論，就算不一定能當下處理，也要能產生後續的處理方式。對品質的持續要求是一個團隊的行為，成員們互相激勵求進步，總比一同軟爛沈淪好。
重點：除非你是鈴木一朗，不然弄破窗戶就馬上補好，或是叫人來修。
溝通技巧：用不同角度解釋自己的程式碼
通過不同的方式 — — 口頭講解、圖表流程圖或書面說明 — — 來解釋你的程式碼，這不僅有助於別人理解你的工作，同時也能加深你自己對程式碼的理解。這種多元化的溝通方式能夠從不同角度揭示程式碼的功能和邏輯，有助於發現潛在的問題，並增強整體的程式碼品質。
當你嘗試以不同方式解釋你的程式碼時，你不僅在向其他人傳達你的思路，同時也在進行一次自我檢查，確保你的代碼不僅功能正確，而且邏輯清晰。甚至，有時候你會需要與不同的角色進行溝通，那麼用他們的語言講你懂得東西就很重要了。
同一個任務，跟工程師講、設計師講、跟業務講、跟老闆、跟使用者講，你會用同樣的方法說嗎？他們都聽得懂嗎？如果他們聽不懂那要如何確認你做的東西是大家有共識的？如果你不知道要怎麼跟不同角色的人闡述你做了什麼，那有可能你其實不知道該角色在意的點在哪，這種情況下就要思考功能是否有辦法滿足對方。
小結
書中其他有用的內容也不少，有各種思考層面的、執行層面的內容，都對工程師們很有幫助。這裡僅挑一些比較少看到有人討論，或者是覺得對自己比較有用的收穫來講。
最後還是要說，書名 Pragmatic Programmer 就已經破題是給『務實』的工程師，如果你的任務其實沒有時間壓力、或是純粹理論派的，那這些就不一定需要作就是。但除此之外，大多組織內的工程師應該都可以受益才對。
如果你也希望成為務實的工程師，或者說，能產生影響力的工程師。那麼多與其他同行交流也是重要的，明年 1/6 來松菸參加我們舉辦的數位職涯博覽會，與更多務實的工程師交流交流！活動網址在這：
ps. 我是一名超過十年經驗的工程師，這裡是從我的經驗衍生出的的看法與想法，如果有跟你不同的地方，也許可以留言交流交流？
