跳到主要內容

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 教學 - 使用 MVC 或 MVVM?

不管是現在剛開始接觸 ZK 或是用過一陣子的人都可能會遇到的問題是到底要用 MVC 或 MVVM 的方式開發。從 ZK 8 之後又把 MVVM 的能力更佳的擴展,所以 MVVM 會是一個功能更強的開發方式。但 MVC 在使用上比較直覺,仍有其優勢,所以我想決定性的因素會比較是開發者的偏好專案的特性。你可參考下面的比較來決定哪種方式比較適合你。優勢比較MVVMViewModel 較不易受畫面變動影響。
因為 ViewModel 沒有變數直接指向 ZK 元件,因此若是畫面上有元件更改,ViewModel 一般不需要修改ViewModel 較易於在不同頁面中重用。
因為 ViewModel 只包含資料跟業務邏輯,若是不同頁面需要的資料跟業務邏輯相同,就可以重用同一個 ViewModel例如 A 頁面按按鈕執行搜尋,B 頁面點選單執行同樣的搜尋,則可以重用同一個 ViewModel 中的 command,只是兩個頁面 data binding 寫在不同的元件上。畫面較易於重用(易於模組化)。
透過 shadow component 跟 template 機制,可以將一段頁面的片段做成可以接受傳入參數套用 Responsive Design 的成本較低。
通常需要針對不同裝置設計不同版面,但是顯示的資料內容大同小異,因此 ViewModel 多半可以重用易於套用美工所設計的畫面,或是網路上現成的元件。易於整合第三方 javascript library 或 widget。
因為 ZK 8 提供了一個可以讓你透過 javascript 去呼叫 ViewModel 中的 command (client side binding) 的方式來跟後端溝通ViewModel 的可測試性較好。
因為 ViewModel 不需要繼承特定類別跟實作特定介面,可以輕易地執行單元測試MVC操控元件方式直覺好學、易懂。
MVVM 控制元件較不直接,需要了解 zk framework data binding 的行為可以完全使用元件所提供的所有 API。
仍有極少部分 ZK 元件行為沒辦法用 MVVM 控制。例如產生 Messagebox, Listbox.renderAll(), Popup.open()。但這都可以改用直接控制元件的方式來解決,只是就是非 MVVM 的方法,喜歡維持一致的開發模…

ZK 教學中文書 - ZK 教練

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