5. 軟件工程

5.1 概述

技術是爲業務服務的，所有的技術工作的目標都是爲了解決業務問題，此外技術的選擇還要符合軟件工程學，學習軟件工程自然要拜讀被稱作軟件工程聖經的《人月神話》，用生動的語言和故事，深入淺出地揭露了軟件工程的本質，並有大量軟件工程的實踐，讓你少走彎路。無論有志於軟件開發團隊中的任何一個崗位，都應該瞭解軟件工程的方方面面，與團隊保持一致的價值觀，志同道合，團結協作，共同完成目標。

另一本在軟件管理領域的優秀著作《人件》，是軟件管理領域的傳奇經典，被譽爲“對美國軟件業影響最大的一本書”。全書從管理人力資源、創建健康的辦公環境、僱用並留用正確的人、高效團隊形成、改造企業文化和快樂工作等多個角度闡釋瞭如何思考和管理軟件開發的最大問題——人（而不是技術），以得到高效的項目和團隊。

然後就是《軟件工程–實踐者的研究方法》，全面、系統講解了軟件開發的方方面面。最新版好像是第8版。

1.2 敏捷開發

敏捷開發目前已經普及到了軟件開發的各種規模的企業，雖然系統地應用敏捷開發方法體系的企業並不太多，但或多或少得都實踐了部分敏捷開發的實踐，比如每日立會、結對編程、測試先行等。敏捷開發包括很多種方法體系，使用最廣泛的當屬於Scrum和極限編程（XP），而且Scrum是一個框架，與XP可以完美結合。
《敏捷軟件開發》、《Scrum敏捷軟件開發》、《解析極限編程–擁抱變化》這三本基本把敏捷開發主要內容瞭解清楚了。

還有一本值得一讀，甚至作爲手冊的小書《Scrum要素》非常精煉地總結了Scrum的方方面面，並且有作者的獨到見解，讀完前面三本後再讀一下這本，並以後作爲手冊翻閱還是不錯的。比如“故事點”的概念，本人與該作者有着同樣深的感覺，太難了，太難了，真的太難了。所有Scrum的概念裏，這個是最難的，可操作性比較差，最後都只能以“人天”來代替。一方面，團隊內部很難就一個參考的故事作爲參考點達成共識，其次，團隊的成員很難保持不變，再者，很難保證所有團隊成員在一個完整的Sprint中不被打斷。看到作者也解決不了的問題，我也釋懷了，後來再不糾結於“故事點”了：）。

1.3 軟件設計

UML是軟件設計必學技能，無論是產品經理、架構師、程序員都應該理解常用的用例圖、時序圖、類圖、部署圖、通訊圖、活動圖等，都是非常好的表達工具，整個團隊有了統一的交流語言，在溝通上既準確又高效。讀一本《UML用戶摜》也基本就夠了，如果想深入瞭解，可以再買一本《UML參考手冊》。很多軟件都可以支持UML，並通過代碼生成類圖，試過好多，MagicDraw是最專業、最好用的軟件，沒有之一，只是收費的。Star UML試過很多次，可能用MagicDraw太習慣了，感覺太難用。

軟件設計的核心還是軟件，UML只是表達語言，比編程語言更高一層次的表達語言，然後就是如何使用這個語言表達需求、架構的設計。《架構之美》讓最優秀的設計師和架構師來描述他們選擇的軟件架構，剝開架構的各層，展示他們如何讓軟件做到實現功能、可靠、易用、高效率、可維護、可移植和優雅。

再向下就到了架構的實現層面，設計模式是這一層的基礎，”四人幫“的《設計模式》中必讀教材，沒讀過這本書好像都不好說自己是架構師。

正如”好的文章不是寫出來的，而是改出來的“一樣，“好的架構不是設計出來的，而是改出來的”，好的程序也是改出來的，軟件架構、代碼經過不斷的重構、提煉、優化才能越來越精煉、靈活、高效、穩定，可維護性也才能越來越好，這是一個持續的過程，可能是每天都在做的事情。《重構–改善既有代碼的設計》則從更具體的代碼層次，指導程序員如何改出高質量的代碼和設計。

這是一個良好實踐的行爲指南，告訴我們應該怎麼做，同樣還有另一本書告訴我們不應該怎麼做：《反模式-危機中軟件架構和項目的重構》。非常遺憾，這本書在豆瓣中的評分並不高，看來還是被很多人沒有很好地理解，相反在實際工作中真的見太多由於壞的習慣和實踐導致的問題和資源的浪費。比如“複製-粘貼”模式，複製別人的代碼，不去深入理解，一運行正常結果是對的，然後就用於產品中，這是一個很可怕的做法，因爲複製過來的代碼中隱藏着的魔鬼很難被發現，因爲代碼不是你的。

項目成本、進度評估是軟件開發一個非常重要的技能，軟件開發中不確定性最強的因素就是人，如何能夠準確評估項目成本及進度，把握市場與開發的節湊，配置合理的資源，順利交付項目和成本，兩本書需要讀，並且需要不斷地實踐，在實踐中鍛鍊評估的感覺，真的這個真的靠長時間鍛煉出來的感覺。

（待序）