雖然以前在學校有修過軟體工程，但是說實在現在我對建構軟體的整個概念都來自於兩本書：「人月神話」(The Mythical Man-Month)、Code Complete[1]。我畢業後第一份工作是軟體研發工程師，我們公司所開發的系統大約有近百位工程師共同維護，當然各有依功能與專業知識將系統劃分不同的區 塊來維護，在面對大型的系統與這麼多人寫程式是以前在學校沒有遇過的，因此也開始思考怎樣才是好的軟體開發方式。從大學好友那探聽到了Code Complete這本書，花了上千元買了英文版，（現在中文版已出，簡體版聽說只要三分之一的價錢）認真讀了幾篇之後，真是如獲至寶，於是自己讀過後，還跟同事組成讀書會一同研討這本書。
作者Steve McConnell (個人Blog http://www.stevemcconnell.com/)著作不算量大，但是我看過的幾本質量都很好，印象中他曾經在微軟工作過，後來成立一家軟體顧問公司 Construx Software。
這本書(書本網站 http://cc2e.com/Default.aspx)的討論主題很廣泛，但是並不空泛，從最小的、最基本的如何寫出好的程式， 例如函式(routine)、註解 (comment)、變數的命名等，也談整個軟體建構的過程除錯、測試，最後也談到軟體工程師個人能力與技術生涯的發展，算是各方面都有提及。但是我比較 建議有半年以上的實際程式經驗來讀這本書比較適合，我自認為如果我在學生時代接觸本書，可能沒有什麼太大的感觸，因為面對的都是小格局、人數少的小系統， 書中所探討的原則與例子，很多時候沒有團隊開發或大型系統的經驗，很難體會。但稍有經驗的人，看完之後保證在程式撰寫與軟體開發方面的觀念會有很大的提 昇。
Table of Content
Laying the Foundation
1 Welcome to Software Construction
2 Metaphors for a Richer Understanding of Software Development
3 Measure Twice, Cut Once: Upstream Prerequisites
4 Key Construction Decisions
Creating High Quality Code
5 Design in Construction
6 Working Classes
7 High-Quality Routines
8 Defensive Programming
9 The Pseudocode Programming Process
Variables
10 General Issues in Using Variables
11 The Power of Variable Names
12 Fundamental Data Types
13 Unusual Data Types
Statements
14 Organizing Straight-Line Code
15 Using Conditionals
16 Controlling Loops
17 Unusual Control Structures
18 Table-Driven Methods
19 General Control Issues
Code Improvements
20 The Software-Quality Landscape
21 Collaborative Construction
22 Developer Testing
23 Debugging
24 Refactoring
25 Code-Tuning Strategies
26 Code-Tuning Techniques
System Considerations
27 How Program Size Affects Construction
28 Managing Construction
29 Integration
30 Programming Tools
Software Craftsmanship
31 Layout and Style
32 Self-Documenting Code
33 Personal Character
34 Themes in Software Craftsmanship
35 Where to Find More Information
對個人來說要提昇程式碼的品質，建議可以看Creating High-Quality Code、Variables、Statement，這幾部份從這些程式的最基本元素 ：變數等開始談起，帶讀者去重新思考在運用這些元素時，該思考的軟體工程觀點是什麼？他並不是只是提供一些撰寫的原則，進而更告訴你怎樣作有什麼影響，或 是告訴你某種作法背後的考量是什麼，有些輔以研究統計數據來支持他的觀點。進階一點的就可以再看Code Improvemnets，因為這部份可能需要更多的實務經驗才能瞭解。
在學校裡面學的軟體工程課程，通常只有提到一些大格局的、概念性的程序，實際上到底要怎樣提昇軟體的品質卻沒有明確的提到，而在學校裡面跟少數幾位同學一 起寫程式，跟面對業界真實系統下寫程式是有天壤之別，但是卻沒有一個方法與途徑告訴你要怎樣從學校裡的學生式寫法，轉換到實務上良好、成熟的寫法，通常只 能在錯誤中學習，這本書就提供良好的指引，讓你從學生工程師轉變成能寫出良好程式碼的專業的軟體工程師。
本書也有在System Considerations提到大格局的軟體工程程序，所以可以看得出來本書側重在programming部份。
最後Software Craftmanship的主題Layout, Comment是工程師一般比較不重視的部份，但作者告訴你這部份仍然對軟體有著相當影響，因為程式碼通常寫的時間很短，但後續閱讀的人跟時間卻很多、很 長，糟糕的排版與註解大大影響著程式的可維護性與可讀性，所以常遇到很多工程師，寧願寫新的程式，也不願維護別人的程式。因為習慣跟電腦互動的工程師常忘 了一點：程式碼是寫給人看的不是寫給電腦看的，而這個「人」也包含自己。
33,34章是很特別的兩章，因為很少有技術的書談到這個方面，33章Personal Character，是在談作者認為對軟體設計有幫助的人格特質，但他特別提到一些多數人誤以為有幫助但其實沒那麼有用的特質，最常遇到的就是Gonzo Programming，中文我不知怎麼翻譯，意思接近於「沒日沒夜的寫程式」，當然很多時候我們是被逼如此，只是有些人會認為這是一個對程式狂熱投入的 良好表現，但作者卻不認為這樣跟產生良好的程式有直接關聯。在本章作者也提供一個工程師技術生涯的發展階梯，我認為對技術人的專業發展給予良好的方向。 34章我認為應該是最精華的一章，像是一個久經沙場的老兵對新兵的幾個建議，這些建議的詳細實施方式，就是前面數十章所談的細節。
以下提幾個在工作上常遇到的議題：
要寫註解、文件嗎？
以前曾聽一位朋友說過，他們程式沒什麼註解、也很少文件，他們的軟體工程方法就是給工程師較好的薪水，減少流動，所以不需要軟體工程。這樣說就某個方面來 說沒錯，不過也有幾個問題，第一「軟體工程」不等於「寫文件」。第二，人員不流動並不代表不需要註解，因為即使是同一個人寫的程式，一段時間之後連自己都 有可能忘記當初這段程式碼的目的。
註解主要描述一些從程式碼上無法得知的資訊，例如一些前提、假設。
public void bSearch(int[] number, int target){
//search target in number
...
}
以上述method為例，如果原設計者其實假設傳進來的number要事先排序過，這個bSearch才能正常運作，那麼如果沒有在註解中明白表示，可能要看完整個method的程式碼或甚至是發生錯誤了才會發現。
註解的作用在於補強程式碼的不足，因為不是所有的設計思維都可以直接從程式碼上推論得到，任何程式語言你懂得語法就看得懂程式，但是我們常常是不懂為甚麼某段程式碼要這麼寫？到底這樣寫的目的為何？
軟體工程有用嗎？
對個人而言，軟體工程思維提供一個良好的程序、方法，提昇個人程式碼的品質。對團隊而言，軟體工程提供一個共同的架構，引導工程師做對的事情，使這個團隊在方法、步調上維持一致，進而提高軟體系統的品質。
如何開始？
就個人來說，開始去思考從需求分析、程式撰寫、測試、除錯、發佈的整個過程，有沒有什麼可以改進的地方、如何用自動化省去繁瑣規律的動作、如何降低bug 等、並引入適當的工具或方法來達成，建立Personal Software Process，並時時修正，就是一個良好的開始。
以團隊來說，我認為最好的開始是version control system，多人協同開發最常遇到的問題就是程式碼的混亂、整合、build code、發佈的問題，version control system可以協助管理程式碼，並將這樣的問題降低，而這樣的系統建製成本並不高，免費的CVS、SubVersion就可以滿足大部分的功能，到了相 當規模再來考慮商業產品。
[1] 書籍資料, 天瓏書局 http://tlsj.tenlong.com.tw/WebModule/BookSearch/bookSearchViewAction.do?isbn=9789866800115&sid=39097
留言