前言
在程式設計和軟體開發的圈子中，有幾本經典的書籍即便在資訊科技快速變遷的時代中仍歷久彌新（你第一個在腦海中浮現的可能是人月神話等書）。這次要為讀者們介紹的是筆者最近又重新閱讀的 Joel on Software 約耳趣談軟體這本書（有中文譯本，但已停止出版）。事實上，這本書還有一本續集 More Joel on Software 約耳續談軟體。Joel on Software 約耳趣談軟體，主要是談論軟體專案管理以及人才培訓與軟體創業經營的議題，而約耳續談軟體主要是討論軟體開發人員的職涯規劃和發展等議題。兩本都是值得軟體開發人員一讀的好書。
在介紹這本書的內容之前，我們先來介紹這位作者 Joel Spolsky。有些讀者可能沒有聽過 Joel 的大名，但事實上 Joel 是知名程式設計問答平台 Stack Overflow 和看板軟體 Trello 的共同創辦人，也曾參與 Microsoft 的 Excel 應用開發，同時也是早期非常知名的技術部落客和作者，特別的是他後來移居紐約開創事業而非傳統的加州矽谷灣區，同樣跳脫了一般人的思考框架。
書中的內容主要是整合 Joel on Software blog 部落格的內容並額外新增一些新的主題。書中使用輕鬆詼諧的文筆介紹軟體開發和專案管理的相關議題討論，除了有些技術探討的章節外不會覺得太過生硬。接下來本文會摘錄一些書中重要的內容和觀念以及加入筆者個人自己的一些心得進行分享。
如何打造良好的軟體開發環境？
作者在開頭導讀用一個有趣的虛構小故事點出許多軟體開發人員在職涯中時常會遇到的難題：在公司組織內要繼續當一個獨立貢獻者（Individual Contributors）還是轉作管理職？
引言中一位技術優秀的軟體工程師在面對主管去高空彈跳受傷後接任管理者的角色，每天工作大部分時間面對的不再是單純的技術問題、程式碼和學習新的技術，而是大部分的時間要應付西裝筆挺的 BD、業務、奇裝異服的設計師以及高層老闆等牛鬼蛇神，更別提的是每天開不完的例行會議和團隊成員的 1-1 meeting 以及績效考核評比。
此時許多開發人員會不禁內心吶喊：為何不能只專心寫好程式就好？
優秀的軟體開發者要成為同樣優秀的專案管理者需要補足額外的技能（例如：商業知識、產品思維、心理學和領導管理能力等）
如果你真的無法逃避成為專案的管理者又不想落入彼得原理 Peter Principle的窠臼當中，不妨用約耳測試（Joel Test）當作一個檢視目前團隊中軟體開發品質作為努力的方向（雖然作者提出這個觀點年代是在西元 2000 年左右，但目前來看仍有許多參考價值，不得不佩服作者的一些前瞻的眼光）。以下摘錄一些書中重要的內容以及加入筆者個人自己的一些心得進行分享。
- 你有使用原始碼控制系統嗎？
使用版本控制系統可以更容易讓團隊協作或是確保程式碼的保存。換成今日的說法：你們團隊是否有在使用Git等版本控制工具呢？ - 你能用一個步驟建出所有結果嗎？
意思就是說，你們團隊需要花多少步驟和時間可以從原始碼部屬可以推出的產品？若是每次要推出產品總是要經過 20、30 個步驟，那若出現緊急狀況一定雞飛狗跳。換成今日的說法：你們團隊是否有使用合適的 CI/CD 和 Container 等自動化整合和部屬及雲端服務工具呢？ - 你有進行每日編譯嗎？
你們團隊是否每天都有提交並整合程式碼？確保持續整合才不會遇到有團隊請假時成專案無法編譯或是合併上遇到問題，導致其他成員無法做事情。可能的作法是約定每天中午或是下班前一定要提交今天的工作成果進行整合，若是尚未完成的功能就使用 feature toggle 等方式進行。 - 你有沒有問題資料庫？
不管是使用看板或是Scrum甚至是其他的軟體開發方法論，透過 issue/bug tracking 系統可以更容易追蹤並管理團隊和系統遇到的問題，不會讓問題漂浮在個別成員的腦海中或是散落在各地。從今天開始就選一套喜歡的 issue 追蹤管理系統，並寫好如何 reproduce 重製問題、預期的行為、發生的錯誤、問題負責人以及目前的狀態（也可以因此評估問題是否真的值得需要被解決）。 - 你會先把問題都修好再寫新的程式碼嗎？
若沒有在解決既有問題前持續開發新功能，就像是在搖搖欲墜的大樓上再蓋大樓，不僅開發時程難以正確預估也容易產生風險並降低開發團隊的士氣，當然問題托的越久有可能相關人員的記憶和文件早已消失不見。當然這時候怎麼和 PM 和老闆據理力爭爭取除錯和解決技術債的時間也是一門溝通的藝術，可以先把問題快速解決再固定排時間徹底修復問題。 - 你有一份最新的時程表嗎？
專案管理若沒預計排定的時程，就像是永遠到不了的終點。同時給自己設定死線也可以避免功能過度膨脹（scope creep）。試試看選擇一個好用的工具同步更新專案時程表，評估預計時間和真正花費的時間以及任務的優先順序並持續更新，漸漸的就會對於時程的掌握越來越精準。記得要讓該任務的實際負責人來評估時程並要求把任務切分成（break down）足夠小的細項，並加入整合、除錯以及國定假日等彈性緩衝時間才不會讓評估失真。 - 你有寫規格嗎？
關於寫規格這件事情作者形容的十分生動：寫規格就像是使用牙線一樣，大家都同意是好事情但卻很少人那麼做。確認需求並寫好規格再開始動工可以避免寫完程式後才發現寫錯方向了，造成修正的成本更大。良好的規格文件同樣也可以降低不同工作人員和跨部門、團隊的溝通成本。 - 程式設計人員有沒有安靜的工作環境？
雖然開放式辦公環境是目前許多新創公司或是網路軟體公司主打的特色，但有研究指出對於研發創意人員來說，這樣的環境反而不容易進入心流的工作狀態。留意一下團隊裡的工程師是不是不喜歡在辦公室工作或是每次員工大會都要求公司提供全罩式耳機的補助，如果有這樣的跡象的話，有可能辦公室的環境對於工程師來說真的太吵雜了。適當的提供獨立的辦公空間或是會議室可以讓團隊可以專注在安靜的空間進行開發工作或許是一個解決方式。 - 你有沒有用市面上最好的工具？
如果開發人員希望使用付費但好用的編輯器、除錯和測試工具，團隊管理者應該盡量協助。若是沒有好用的工具因而導致花費太多時間，生產效率低下反而得不償失。 - 你有沒有測試人員？
若有專門的測試人員負責產品的測試，就可以為團隊產品進行把關，避免省小錢卻推出問題很多的產品。若人手缺乏的話，可以嘗試尋找兼職人員或是遠端測試人員進行補強。 - 是否在面試時要求面試的對象寫程式？
透過有良好設計的技術問題讓面試者可以展現自己的思考和程式能力及人格特質並一起模擬工作解決問題，避免腦筋急轉彎或是煩瑣的背誦問題，找到符合人格特質且聰明能解決問題的人。 - 是否進行過走廊使用性測試？
走廊使用性測試意思為在走廊上攔下一位經過的人，請他試用剛寫好的程式或是快速製作好的原型，透過加快使用者測試和回饋的速度，可以更容易找到程式設計上的問題和設計出使用者想用的產品。
以上評比若有的話可以得一分，最後算出得分總分幾分。若是分數越高穩定交付產品的紀律團隊（若是剛起步的新創團隊當然要一次到位十分困難，所以一步步進步也是一個很好的開始）。當然這個評估也只能是參考性質，若是評估分數很高，但組織內部有複雜的政治性問題和微觀管理（Micromanagement），也有可能導致團隊的效率和產出十分不穩定。
可以像炸薯條一樣製作出品質一樣的軟體嗎？
很多專案管理者都曾幻想若能像麥當勞一樣透過強大的 SOP 在世界每一個角落就可以製作出一模一樣的品質的軟體（薯條）。然而，軟體開發本質是人，如同筆者之前在 The Zen Programmer 程式設計之禪書摘 所提到的程式開發背後是透過人來進行，人的狀態往往會影響程式設計品質良窳，人在憤怒、情緒不穩定和極度高壓力下往往寫出的程式品質會有許多問題。關於人的問題雖然可以我們可以設計出一些方法論和工具來提升軟體專案管理和開發的效率但畢竟軟體開發跟單純的炸薯條來說變因相對難控制。
此外，不同的軟體有不同的世界，開發 C2C 的網路軟體和 B2B 套裝應用程式、內部用工具，甚至是嵌入式系統、遊戲開發、用過即丟的軟體等，每一個世界會遇到不同的問題，所以也很難把所有的思考框架和解決方式套用在不同地方。理解並尊重不同世界會遇到的問題並努力和團隊一起學習找出問題的可能解決方式，邊開火邊移動，持續改善或許是更好的方式。
為什麼程式設計師應該培養寫作力？
對許多軟體開發人員來說寫規格和寫文件是一件很排斥的事情：我是來寫程式的又不是來寫文件的。然而對於程式開發人員來說，寫出良好的程式和文件其實是一體兩面的事情，寫程式和寫文件一樣不單只是自己要能看得懂，重點是要讓其他工作人員也能理解並閱讀。此外，軟體開發本質上有很多情況會需要非同步的溝通：不管是在公司內部 issue tracking board 上的留言更新或是 Scrum 看板的任務描述，甚至是回覆不認識的開源程式碼的使用者來信、開源程式碼的使用文件和技術推廣理念等都十分仰賴好良好的寫作能力。
試想若是 Linux 或知名的開源程式碼的開發者沒有具備良好的溝通或是寫作能力，如何能將自己的軟體或是理念傳播出去產生影響力呢？
作者也表示會把寫作力不好的同仁送到寫作班進行訓練。雖然這可能只是玩笑話，但也再次強調寫作力和溝通表達能力對於軟體開發人員的重要性。如果你也是一個想在軟體開發和程式設計領域持續學習，追求卓越的開發者，歡迎一起加入CoderBridge 技術內容創作分享社群，分享你的觀點和學習心得，讓我們一起變得更強。把心得和觀點組織紀錄並分享出來，最後受惠最多的也會是你自己！
總結
以上簡單整理了約耳趣談軟體（Joel on Software）導讀書摘，接下來筆者會持續透過閱讀分享更多經典的軟體開發和程式設計、專案管理以及產品設計書籍與讀者分享。優秀的軟體開發者要成為同樣優秀的專案管理者需要補足額外的技能，透過更多元的視野也會慢慢理解到什麼時候該先用 workaround 解決方法再慢慢修正問題以及如何面對專案管理和技術選擇的決策。若讀者有建議提醒或是新的想法也歡迎一起交流討論！
