飛揚跋扈的技術人員如何管理？ – 領導力

開發是一切——何時寫文件

對於技術管理來說，很多公司會非常注重文件。雖然開發的結果是代碼，但對於管理來說，代碼往往難以閱讀，也很少有人擅長接手別人的系統。為了讓代碼不至於被丟棄，公司管理人員就祭起文件這個法寶。我認為文件是很重要的，但也發現這些文件中很典型地存在幾個問題：文件和代碼不同步;文件的可讀性差，需要的文件沒寫，不需要的文件寫了一大堆;文件和代碼脫節，文件很多，開發出來的成果很少。

我們應該何時寫什麼文件，這是需要有嚴格定義，並且有檢查過程的，而不是任由大家自然發展就可以完善的。代碼的編寫需要按不同類型，定義好在各個階段中所需要完成的部分。

設計類文件—— 這類文件往往在項目、模組啟動的時候，大家都會想到要去寫，作為討論和最後決議的成果，顯然是很自然的。然而在項目進入開發之後，碰到實際問題時，往往就不能完全按照設計的初衷去做了，所以通常設計文件就在這個時候和代碼脫離了聯繫。但有一點是絕對可以做的，就是在重構的時候，按照現有狀況，重新增加重構前的系統狀況說明，然後再加入上重構後的設計。這樣就把重構的設計和文件的更新結合到一起了。

API(應用寫程式介面)文件——現代軟體都希望能提高重用的程度，因此很多程式員都會自己構造自己的業務API，以便在之後的開發中使用。而這種業務API，也是很多分工合作的基礎。這種代碼的說明，會直接影響日常的開發，因此非常有必要保證和代碼的高度一致性。

使用文件—— 一般來說，一個軟體的使用文件必須包括以下幾個：《產品版本說明》、《產品安裝和部署文件》、《產品使用教學以及例程》、《產品FAQ文件》。這裡面的《產品版本說明》應該在每次發版的時候，作為發佈流程的一個固有環節來設計。《產品使用教學以及例程》是我認為所有文件中，最值得花大力氣去寫好的。《產品安裝和部署文件》內容越少越好，應該讓安裝部署盡量智慧化、自動化。

瞭解什麼是軟體架構

瞭解軟體架構的範疇，才能有針對性地去把握軟體開發中的風險，從而管理好軟體開發的過程。簡單來說，軟體架構就是應對需求所產生的“一系列決定”。軟體會根據這些決定來開發。根據軟體需要應對的需求，軟體架構一般包括以下幾個部分。

邏輯架構 主要是為了明確“功能性需求”而做的設計，針對需求以及需求變化作為架構目的所做出的關於代碼之間的劃分、耦合、關聯的決定。採用合理的邏輯架構，將會大大降低需求變更對開發的延遲作用。邏輯架構最直接指導代碼中互相耦合的情況，仔細設計好耦合的規則，會讓後續開發事半功倍。

運行時架構 運行時架構是為了滿足運行期的質量需求，所做出的關於對像行文、程式結構、通信協定、資料結構等方面的決定。運行架構一旦確定，等於大部分的“實現”代碼都確定了，設計有足夠延伸性和可用性的運行架構，可以為後續工作節省時間，也降低了系統在運行期對開發工作的干擾。

開發架構 為了滿足開發時的需求所做的決定，主要是軟體根據分工開發、測試驗證流程等需求劃分的軟體層次和區功能變數以及各種介面設計，也包括使用的軟體包、元件庫、開發工具，以及編譯構建的方法。一個好的開發架構，可以讓溝通成本降低，開發速度提高。

部署架構 現代軟體系統，基本上都內含了用戶端和服務端程式，如何快速、高效、穩定地部署和發佈這些程式，如網路機房的分佈、伺服器硬體的搭配、監控和維護工具軟體的安裝、開發測試網路和運營網路的設定。可以獲得安全性的配置，良好的部署能力，能推動軟體進行更頻繁、更全面的測試，從而提高軟體質量和開發效率。

資料架構 資料是軟體項目的核心財富，關於資料的結構，資料的存放、備份、傳輸會直接影響到運行效能、業務功能、部署、安全等需求。在面向對象的開發模式下，資料到對象的ORM架構也是很重要的設計。一個完整的資料架構內含了資料流圖、資料字典、ORM結構(如果需要的話)、資料索引和備份機制等幾個方面。

何時以及如何評審

相信大部分公司都有評審這個環節，評審可以內含專案評審、代碼評審、項目專項議題的評審，比如對存留Bug的處理評審等。而這些評審，常常會變成一個挑毛病的會議。要解決評審給產品帶來的負面影響，同時發揮這個活動的優點，我們需要關注以下幾個方面。

評審由誰發起 相對照較好的是，由負責此項目的“領導”來召集人員評審，並且一定要有負責開發的人員參加評審。參與評審的受邀請人員可能會與專案送出者就一些問題有分歧，但送出者有最終決定權。要把權力給有能力承擔它的人。這樣做可以讓“防止風險”的一部分人和“注重效率”的開發人員形成平等的意見交換。

什麼時候做評審 應該在每個迭代、每個較大的版本開工前，或是僅僅是某個認為比較重要的決定做出前，都來一次簡短的評審。如果開始時只是做一個DEMO，那麼需要評審的東西也比較少，而隨著不斷的開發，評審也能遍歷所有的開發。

做評審的方法 真正對項目有說明的，是瞭解項目的需求，分析面臨的難點，思考專案為何這樣做，提出自己的解決專案，給項目開發者以建議和啟發。多說“我建議這樣解決這個問題”，而不要僅僅去說“這樣做可能有問題，應該添補這樣的功能”。以建設性的心態和思路去做評審，而不是以找問題的思路去做，這就是兩種做法的最大區別。

分層開發，盡快運行

為了降低軟體耦合給開發帶來的負面影響，正確的做法是要高度重視軟體開發方法，從代碼風格、軟體架構、設計模式、開發模式方面來提高水平。其中一個最簡單有效的做法，就是分層。在經典的架構模式中，分層模式幾乎是所有模式的基本模式：把代碼按照你所需的範圍劃分層次，然後規定層次之間的耦合介面，層次之間只可單向依賴，而且盡量減少跨層耦合。劃分層次的範圍，由你的開發團隊水平和項目的複雜程度決定。