該如何寫出更好的軟體？─ 系列訪談之一 (下)

在看過《該如何寫出更好的軟體？─ 系列訪談之一 (上)》之後，你是否對工程師在撰寫程式之餘，所必須考量的各個面向有進一步的認識了呢？快跟著看完系列訪談之一的下篇吧！

圖片作者：Marjan Krebelj

某些專案牽涉多重規範並有多家公司參與其中，此時通用標準 (如工具、設計指南、開發流程) 的重要性為何？

當談到軟體工程時，一般都認為「標準」極為重要。不管你要稱之為「SCRUM」或「KANBAN」或「SCRUMBAN」；不論你使用了「Git」或「Mercurial」工作流程；不論你使用了 Google 或 Mozilla 的 Javascript 風格指南。這些我都不管。但你絕對需要某些通用的程序與標準，尤其像是開放源碼的大型工程團隊，或 Mozilla 的一般開發作業更是如此。這些標準的界線比較模糊。我們很容易就耗掉太多時間去定義/辯護這些標準與通用程序的用途，卻忽略了真正的目標。所以我認為不要忘了「這些只是工具」。這些工具很重要，但畢竟只是協助我們的工具。我們應該要能看情況而靈活變通。

我們針對程式碼風格進行了許多審查作業，但最後就是為了要發佈修正檔。如果你的程式碼風格有問題，我希望你能自己修正。但如果你又想快點發佈修正檔並進版，那就先直接進版並發送臭蟲報告，以利追蹤後續情況；審查人員若有時間也能代勞。

Firefox OS 是由 Gonk、Gecko、Gaia 所構成。而對新手來說，這些系統又龐大、又複雜、又嚇人。你定期提交修正檔到 Gecko 與 Gaia 中。你是什麼時候加入了現有專案，又是怎麼了解這個系統？

我想沒有特別的技巧或訣竅。我自己覺得好用的，別人也不見得適合。我只是儘量閱讀程式碼內外的相關說明文件。程式碼負責人可能忙到沒空或撰寫別的程式碼，所以我會看情況親自去詢問。我一開始都儘量不要逐行查看程式碼，且在深入程式碼的特定區段之前，都會先試著了解整個粗略的架構。我覺得只要時間久了，你累積的經驗也夠了，就能自己看出程式碼的模式和通用的架構，幫自己找到當前的問題。

在不熟悉的領域開始撰寫程式碼時，你怎麼確保你更改的部份不會對系統造成意外的影響？大部分都透過測試解決嗎？

是的，基本上都必須測試、測試，再測試；你想得到的各種測試都要做。當然，你主要應先根據審查人員的意見，而且你和審查人員之間也有某種程度的信任。在詢問品質管理或審查人員之後，也可自己額外進行其他測試。

換個角度看，如果你是審查人員，在你說「好，這程式碼可新加進此功能。那又怎麼確認不會影響到系統的其他部分？」的時候，你也會依賴測試作業嗎？

如果我覺得修正檔會造成任何影響，我就會進行測試。我都在測試用伺服器上執行程式，也會要求開發者自行測試。

換你當審查人員時，審查重點在哪？

我一般都先看整個程式碼的正確性。也就是說，「修正檔」應該要能確實修復其針對的問題，而且當然不能又造成更多副作用而拖累整個程式。如果時間允許，或是很重要的修正檔，我都會自行測試修正檔，以確實了解其運作情形，避免對系統造成負面影響。我也會注意該程式碼的效能與安全性。同樣的，如果我覺得程式碼是用於修正檔，我也會要求進行測試。最後，我都會注意程式碼的品質、流程、說明文件、編碼風格、貢獻成果、開發流程等正確性。

在將 Firefox Accounts 整合至 Firefox OS 時，我曾處理過一大部分的修正檔，也記得當時是你曾負責審查。我覺得你審查似乎極為強調一致性？

我們必須考量到整體程式碼的品質。在我進行審查時，像這類的評語我都會標記為 Mozilla 內部常用的「nit:」，代表「我想看看這部份更改之後會是什麼樣子。如果你沒有修改，我也還是會給你正面的審查評語。但我真的很想看看更改之後的結果。」

這個問題分成兩個部分。當你審查程式碼時，你怎麼讓開發者覺得你給的評語並未摻雜個人因素？反之，當你是開發者角色時，你又怎麼讓自己不會覺得審查人員對事不對人？

到目前為止，我自己也收過很多大改特改的審查結果，但我從未覺得有任何個人恩怨的因素。我一直把審查結果當做正面的學習經驗。我也知道大家都很忙，負責審查的人沒什麼多餘時間，也同樣必須寫程式碼。所以他們只是很快的寫下「這裡必須修改」，根本不會有多餘的時間去斟酌要不要寫一些不傷人的措詞。審查人員只會提出他們認為程式碼中「不正確」的部份；而不會特別講「正確」的地方。我想大家剛開始的時候都必須學著適應這一點。

但只要你開始撰寫程式碼，你就會了解審查人員之所以不斟酌用詞的原因。而對我這種非以英文為母語的人又特別困難。有時候我想用最親切的方式表達意見，但又缺乏能加強表達審查結果的詞彙。所以我試著儘量加用一些笑臉符號。同樣的，我自己覺得「r-」不太客氣，所以也儘量避免。我會改用「feedback +」或其他標記。

你說過自己都當做是開發時的學習經驗。那在擔任審查人員時，你也會將審查作業都做另類的教學機會嗎？

當然是教學相長的概念。單單只是審查修正檔，就是絕佳的教學經驗。你等於向撰寫人員表達自己認為較正確的部份。有時候審查意見並沒有理論基礎，但我們仍應該解釋可能的理由，儘量讓整個流程更完善。

你是否有留任何程式碼片段 (自己或別人的都算)，是自己認為特別值得別人借鏡、學習的？

我對自己的程式碼很挑剔，所以我不覺得有任何程式碼片段漂亮到足以分享。但如果要我快速想一個自己看了很開心的範例，大概就是最近對 Gaia Dialer App 撥號記錄資料庫的大幅度重構，或是最近建構的 Mobile Identity API。

你現在想鼓勵大家加入哪個開放源碼專案，又要從何著手呢？

當然就是 Firefox OS！真的，我覺得 Firefox OS 讓軟體工程師有機會能參與絕佳的開放源碼社群。從初階到前端的程式碼，裡面有多倒數不清的技術難題等你挑戰。你們在如此開放的環境中，有機會深入瀏覽器與行動作業系統的底層。剛開始要加入整個流程與程式碼時，你可能會覺得有點困難，但現在 MDN 上已經提供豐富的Firefox OS 說明文件，也有一堆人在 IRC (#b2g 與 #gaia)、電子郵件群組 (dev-b2g 與 dev-gaia)、ask.mozilla.org 上熱情相助。

大家要如何隨時知道你工作的最新情況？

我沒有部落格，但有公開的 GitHub 與 Twitter 帳號。

訪談逐字稿

感謝莫雷諾參與的訪談。可到 GitHub 上找到完整的逐字稿。

下篇文章

下一篇訪談是雲端服務團隊的華納 (Brian Warner)。這位安全專家將分享安全概念、分析威脅、可供稽核的程式碼。

另外一提，我其實很享受整個訪談的過程，也希望你能告訴我這個系列是否對你有所助益。我現在正想繼續訪談幾位 Mozillian。如果你想推薦某人甚至你自己，就快寄信到 stomlinson@mozilla.com 讓我知道吧！

原文連結：How can we write better software? – Interview series, part 1