《極客與團隊》一溝通也是工程的一部分

本節書摘來異步社群《極客與團隊》一書中的第2章，作者： 【美】brian w. fitzpatrick , ben collins-sussman 譯者： 徐旭銘 責編： 陳冀康, 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

極客與團隊

市面上軟體開發流程方面的書可以說是數不勝數。我們無意在此做過多深入的讨論，隻想提幾點和溝通特别有關的，無論遵循何種開發理念，這些要點都值得關注。

代碼注釋

代碼注釋風格是一樣很主觀的東西。原作者常常通過詳細的注釋解釋自己的意圖和理由，這些對了解代碼都很有幫助，但是卻要付出後續維護的代價：過時甚至不準确的注釋反而會極大地妨礙對代碼的了解。同樣，過于扼要的注釋，或者幹脆沒有注釋也會浪費将來維護或者api使用者的時間。注釋一般是用來說明代碼裡缺失的部分，以及起得不好的名字，然後把代碼的功能再解釋一遍。注釋應該盡量解釋為什麼代碼要那麼寫，而不是去解釋代碼做了什麼。

注釋在函數（或者方法）層面是最有用的，特别是用作api文檔的時候。注釋不應該涉及過多細節，用一句著名的希臘諺語來總結就是“μηδέν άγαν”，即“過猶不及”。此外還應該好好為團隊準備一套注釋風格，然後每個人都要好好遵守——我們認為風格一緻比風格本身更重要1。風格指南還應該自陳存在的理由及其目的——例如，這裡是google c++風格指南的介紹部分2。

c++是很多google開源項目的主力開發語言。每個c++程式員都知道這門語言擁有多少強大特性，然而伴随這種強大特性的是它的複雜性，這也使得代碼更容易出現bug，難以閱讀和維護。

本文的目标是通過講解c++程式設計中的各種要點來駕馭這種複雜度。這些規則在保證代碼可控性的前提下，能讓程式員高效地使用c++的語言特性。

所謂的風格（也就是可讀性），就是管理c++代碼的約定慣例。風格這個詞本身有點不恰當，因為這些約定所涵蓋的内容遠遠不止源檔案格式化那麼簡單。

強制統一代碼的風格是保持代碼可控的一種方法。讓别人快速看懂、了解代碼是非常重要的。保持一緻的風格并遵守約定意味着可以簡單地通過“模式比對”的方式來推斷各種符号的含義以及它們具有哪些不變的特性等資訊。通用和強制要求的習慣和模式可以幫助了解代碼。有時候可能有很好的理由去改變某些風格，但是為了保證一緻性，我們仍然會予以拒絕。

這份指南要解決的另一個問題是c++的特性膨脹。c++博大精深，擁有很多進階特性。有時候我們需要限制（甚至禁止）使用某些特性，這是為了保持代碼簡潔，避免這些特性帶來的各種常見錯誤和問題。本指南會列出這些特性，并一一解釋為什麼要限制它們。

google的開源項目都遵守這份指南的規定。

注意本指南并非c++教程，我們假定讀者對這門語言已經有了相當的了解。

在源檔案裡署名（也就是“作者标簽欄”問題）

每個人都希望自己的工作得到認可，藝術家會在自己的畫作上簽名，文字工作者會把自己的名字放在書脊上或是部落格頂部。無論以何種方式，渴望得到認可是人的本性，但是在我們看來，在源檔案裡留下名字絕對是弊大于利。你一定在各種源檔案的頂部見過這樣的東西，它們往往和版權聲明擠在一塊兒。

在源代碼頂部署名的傳統已經是老黃曆了（我們兩個都這麼幹過，唉！），在程式大多由個人而非團隊編寫的年代這樣做或許還說得過去。但是今天，很多人隻是接觸到一小塊代碼而已，檔案裡的作者标簽欄隻會導緻争吵不休，浪費時間，甚至傷害感情。是以，我們強烈反對在源檔案裡署名的做法（最多也就是署上稽核人的名字，告訴大家在修改這個檔案後首先應該拿去給誰看，但是要小心不要有檔案歸屬的暗示）。

想象一下，假如你在團隊項目裡建立了一個檔案——編寫了幾百行代碼，然後在檔案頂部打上自己的名字和适當的版權資訊，把它送去代碼審查，然後送出給代碼倉庫。到目前為止一切正常。現在假設你的同僚阿德裡安跑過來修改了一下檔案，那麼他要改多少才有資格把自己的名字寫上去呢？一定要修複一個bug以後？還是至少要五個bug？一定要實作一個函數？還是需要兩個函數？要寫多少行代碼才夠呢？如果他寫了一個函數，然後在檔案上加上自己的名字，結果這個函數又被後來的人重寫了呢？這個人能不能也把她的名字加上去？是不是要把阿德裡安的名字拿下來？和其他聯合創作（比如劇作、小說、電影等）不同，軟體即使在“完成”後依然會不斷發生變化。是以電影可以在結尾放心地列出創作人員，可在源檔案上這樣添加、删除名字的做法卻是一件永無止境的瘋狂舉動。

你當然可以通過大量文檔來解決這些問題，但是維護、跟蹤、防止意外發生都要浪費很多時間——這些時間原本都可以

用來寫代碼的。是以我們推薦在項目層面而不是代碼上認可大家的工作。如果需要更多的細節，可以在版本控制系統裡找到答案。一切都會随時間散去，就像雨中的淚滴3。

每個送出都必須經過代碼審查

如果打算要實行某種程式設計标準，那麼就必須要有監控哪些代碼可以成為産品一部分的方法。無論是在送出之前還是之後進行代碼審查，都應該保證每一行進入倉庫的代碼都要有作者之外的人檢查過，檢查的内容有風格、品質，當然還有粗心大意的錯誤。代碼改動應該盡量短小以保證審查的品質——若改動涉及幾千行代碼，那麼除了挑挑格式的毛病外，基本是沒辦法進行審查的。做到這一點不但能提高整個代碼庫的品質，更能從長遠上培養代碼品質的集體榮譽感。

真正的測試和釋出流程

無論你是采用全套的測試驅動開發模式還是隻有一些簡單的回歸測試，自動化程度越高，你在修複bug和添加新特性的時候就越自信。決定好測試所要扮演的角色後，它在程式設計和審查階段都應該占有一席之地。釋出流程也是一樣重要，它應該友善到可以頻繁釋出的程度（比如每周一次），同時也要具備相當的完備性，這樣才能在使用者之前發現問題。