跳到主要內容

Code Complete, 2ed (中譯:軟體建構之道) 讀後心得

Code Complete, 2ed (中譯:軟體建構之道) 讀後心得

雖然以前在學校有修過軟體工程,但是說實在現在我對建構軟體的整個概念都來自於兩本書:「人月神話」(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

書中每章幾乎都是獨立的主題,可以分開閱讀,所以可以先選有興趣、有相關性的先看。Laying the Foundation談軟體建構的範疇,包含從問題、需求、分析、設計、編程、測試、除錯、維護的相關活動,並談到建構初期的活動:需求分析。

對個人來說要提昇程式碼的品質,建議可以看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

留言

這個網誌中的熱門文章

JavaScript 關掉瀏覽器頁面

如果你直接呼叫 window.close() 來關掉目前的頁面的話,你應該會在 console 看到以下訊息:
Scripts may close only the windows that were opened by it.
( 我在 Chrome, Firefox, IE 11 都試過)
主因就是你並沒有用 JavaScript 開啟這個頁面,所以也不能用 JavaScript 關掉它。這是 HTML window.close() 的規格規定,各家瀏覽器應該都遵循。

隨著瀏覽器安全性增加,以下方法已經不適用了,可參考這個討論


有個變通的辦法就是:
window.open(location, '_self').close();


ZK 教學中文書 - ZK 教練

2016年開始做了不少場教育訓練,覺得台灣工程師應該會蠻希望有一本中文的教材,因為目前網路上多是零散的文章,英文的文件雖然完整,但是太龐大,大部分的人應該無從下手。因此最近開始撰寫一本教學書:「ZK 教練」(書名是老婆提供的點子),也為自己在這份工作推出一個代表作。
本書會包含以下幾個特點,幫助讀者更有效地學習:
範例專案
本書附帶一個範例專案,裡面包含所有書中提到的範例程式。你可以輕易地將整個專案執行在 jetty 上,透過瀏覽器看到執行結果,有助於了解程式碼。練習專案
執行 maven 指令可以產生一個練習專案,它以範例專案為基礎,但是刻意移除部分程式碼,好讓讀者練習之用。因此你可以產生範例專案來練習,若真的遇到困難再參考完整程式。圖片解說
儘量以各式圖片解說概念。我認同 Head First Design Pattern 一書中提及的理念,學習不是只能靠文字,其他的媒介可以讓大腦得到更多資訊,更增強學習效果。情境 FAQ
ZK 目前已經是個頗為成熟的框架,功能很多,因此不熟悉的人常常不知道實務上某個情境要用什麼功能來解決,這裡會列出各個常用的情境並提供連結指向建議使用的 ZK 特性 當然目前本書尚未完成,歡迎給予回饋。
去看看 ZK 教練