全腦思維®實例：軟體開發的全腦環走
by Andrew Swerlick / 赫曼國際首席軟體開發工程師

軟體開發，乍看之下不像是會常用到HBDI全腦思維®的工作。畢竟所做的事看起來大部分都鎖定在技術、分析的A象限。確實，我們在產品設計、需求收集的前期會跟其他的內部團隊一起合作，但當我們拿出鍵盤開始寫程式碼的時候，其他象限的事情就消失了，對吧？

如果是幾年前剛到赫曼工作的我大概會深表同意。但我們的開發團隊在最近開始採用了一些實際作法，讓我看見了運用HBDI全腦思維®來編寫程式碼的價值。

一切的改變起源於我們重新設計「程式碼審核流程」。

只要是工程師都知道：「程式碼審核」是每個開發團隊為了確保軟體的品質都會採用的一種做法。就如同字面上所說的，「程式碼審核」意即一位工程師在完成程式碼的同時，將他的成品給至少一位同事審核以確保正確性。審核者(們)會檢查程式碼的樣式問題、是否清楚、有無明顯的bug、以及檢查新的東西運作得如何。一次審核循環之後，我們對於我們審核流程的完善度提出檢討，並決定給審核者制定更正式的審核方針。

那時候我們想：如果把全腦®環走的概念應用在審核方針的結構上，應該會蠻有趣的。我們不確定結果會如何，但這看起來是個有趣的開始。

剛開始我有點擔心這份HBDI全腦思維®環走會非常偏重在A象限上，但令我驚喜的是，當我開始著手進行全腦環走時我發現：四個象限都能夠為審核程式碼這件事情帶來許多價值。在經過幾次的討論與幾版修改後，以下是我們的成品：

聲明：這份HBDI全腦思維®環走對於不是工程師的讀者可能會有些技術性，但即便如此，你還是能很快地看出：全腦®環走能夠幫助我們完善的思考各種議題，確保我們不會遺漏任何重要的元素。

A象限

專注在程式碼「如何運作？」，以及是否符合驗收標準，無論是顯性和隱性的（例如：效能，安全性，可部署性）

● 這個程式碼的功能是什麼？（對照驗收標準）
● 這個程式碼實際實際上有什麼作用？
● 這個程式碼是否可以存取資料庫（Database）？是否有效率？我怎麼知道？
● 資料儲存方式是否符合商業模式？有任何寫入的操作會導致無效的儲存嗎？
● 這些程式碼是否經過測試？那些測試是否包含極限的狀況？測試和實際運行的環境是否一致？
● 這些修改是否會影響現有程式的其他部分？這些影響已經測試過了嗎？
● 當程式碼實際運作時，產品端會發生什麼事情？我確定測試的結果足以代表產品端嗎？
● 在藍綠部屬（Blue-green deployment）時，新舊兩個程式碼同時運作會發生什麼事？
● 部屬此程式碼需要哪些步驟？能夠自動化嗎？如果需要手動，是否有紀錄？

B象限

聚焦在程式碼是「如何被編寫」，它是否符合我們的各種標準（樣式，安全性等）？ 它是否與應用程序中的其餘程式碼一致？

● 此程式碼是否包含來自用戶端（瀏覽器等）的輸入？ 是否有驗證過正確性和安全性？

● 程式碼是否遵循安全守則？

● 這段程式碼符合樣式規定嗎？ （例如：有關各個應用程式和一般樣式指南，請參閱樣式指南文件。）

● 此程式碼是否遵循與其他程式庫相同的結構原則？ 如果沒有，為什麼？

● 此程式碼是否使用新工具，如果有，為什麼需要？

C象限

專注在「這個程式碼是為誰寫的？」。對象同時包含實際運用程式碼的終端用戶以及負責維護程式碼的其他開發人員。

● 有哪些終端用戶會使用到這個程式碼帶來的功能？這個程式碼是否有考慮到終端用戶的使用性及安全性
● 程式碼的實際運作是否能夠清楚的對應到終端用戶的實際行為？你能夠用簡單易懂的方式向終端用戶概述這個應用程式的作用嗎？他們完全理解了嗎？如果不行，落差在哪裡？
● 這個程式碼有適當的加上註解嗎？
● 這個程式碼對於其他開發者來說容易閱讀嗎？
● 你清楚明白這個程式碼會對應用程式裡其他部分造成的影響嗎？如果有人在你放假的時候要更動應用程式，他們是不是能夠簡單的確保不會出問題？

D象限

專注在「這個程式碼如何對應到公司商業上的大局」。探索不同的方法與模型，不論是程式碼的整體結構還是單體。

● 這個程式碼的概念及想法是否能夠對應到公司實際的目標與思想？如果彼此有落差，是否是為了夠好的原因？
● 如果我們高階目標的需求改變了，這個程式碼會如何應著改變？容易改變嗎？
● 這個程式碼有使用第三方的工具和函式庫嗎？這些工具和函式庫的影響是什麼？
● 要達到同樣的目標，有其他的方式來編寫這段程式碼嗎？為什麼要選擇這個特定的編寫方式。

我們使用這份全腦®環走至今一個多月了，我們觀察到：

● 總體來說，上面這份具體的、全面的問題清單對於我們的程式審核流程非常有幫助，甚至在工程師自己審核自己的程式碼的階段也一樣有效。同時，它也在Pull Request中激發了更多的對話。

● C象限中的：「你的程式碼是否對於其他開發者來說容易閱讀」確確實實地讓我們更有意識的在處理程式碼的樣式和註解。它在Pull Request的階段促進了更多的討論，並且讓所有人對於程式碼基模（codebase）有一致的理解。

● 使用A象限來記錄和發展效能，部署步驟和產品行為幫助我們的發佈產品更加順利。它還幫助我們找到了了不一定會出現在我們的開發環境中的問題。

這份環走產生的價值讓我們願意繼續使用這個方法並且繼續精修清單。對於我來說，這是個非常好的案例足以說明：全腦環走是個非常好用的工具，它完全可以應用在各種任務，即便是像這種非常偏重於某個象限的工作。