軟體建構之道 2Code Complete 2

 

你是資深員工，是同樣的事做十幾年呢?還是讀書精進了十幾年?不想做前者，這本書聽說當年很有名，網路上有電子版，但我習慣看紙本書，還是從圖書館借來看。 

厚厚的一本，看了頗費腦力，進度很慢，前面大多談寫程式的原則與技巧，太過枯燥就跳過。 

複雜程式簡化

比較有趣的是，他說人腦容量有限，所以程式寫得過於龐大複雜，這樣大家都看不懂。解決的方法就是寫成功能，有需要就呼叫那個功能，不用去理解功能內複雜邏輯，這樣就可把程式控制在可以看得懂的範圍。如果程式過於複雜難解，就是這個系統腐爛的警訊。 

書中提議如下: 

■將整個系統在建築架構的層級劃分為多個子系統'好讓你可以   一次專注系統的一小部分。 

■謹慎地定義類別介面，如此才可以忽略類別內部的連作。 

■將由類別介面表達的抽象概念保存下來，這樣你不用去記關連的細節。 

■避免使用全域資料'因為全域資料會使你在任何一個時間點需要考慮的程式碼大為增加。 

■避免使用深度的繼承層級，因為那需要智力。 

■避免使用深層的迴圈和條件陳述式’因為它可以被較簡讯且不  傷腦力的控制結構所取代。 

■避免使用goto，這個跳躍式的語法會令人摸不清頭緒。 

■謹慎地制定處理錯誤的方法，不要隨恵製造使用各式各樣不同的錯誤處理技術。 

■系統化地使用內建的例外處裡機制，否則它會成為非線性的控 制結構，變得跟goto—樣容易造成混淆。

■不要讓單一類別太過於龐大，鹿大到將整個程式的功用都集 中在它裡面。 

■保持常式簡短。 

■使用淸楚並能充分表示其功用的變數名稱，這棣就可以省F腦  力去記如「i是帳戶索引，j是顧客索引，還是反過來？」之類  細節。 

■盡量滅少傅給曲式參數的數目，或更重要的足，只傅輸為保持常式介面抽象概念必要的參數。             

■迪用慣例以避免浪費腦力去記憶程式碼不同部分無關聯的隨機 的不同。 

■ 一般而言，隨處只耍可能，應攻克第五篇所談的程式碼改善問題。 

AI是否會消滅工程師

最近很紅的AI取代軟體工程師問題，沒想到此書也有解答: 

第30章程式設計工具，提到一段歷史，原來Fortran問世時，也是宣稱工程師與科學家只要輸入方程式，就可寫出程式，也就是說程式設計師以後就要滾回家吃自己。 

這種宣言講了數十年，工具廠商與業界權威人士總是斷言，程式設計由工具取代的日子即將來臨，恐嚇製造危機感，結果就像各種宗教宣稱的世界末日，永遠沒發生。

作者認為，這是因為程式設計是非常困難的工作，就算用很好的工具，面對混亂常變的真實世界，只有真人應付得過來。 

就我自己的經驗，面對諸多用戶提出的需求，這些需求可能彼此矛盾，因為用戶也只知大概大方向，不知細膩的細節，講太多複雜邏輯他們也會昏，怎樣綜合取捨揣摩做出他們滿意的答案，何時要順從何時態度強硬，確實需要真人。 

 所以作者結論，如果又有廠商宣稱"這項新工具能取代電腦程式設計師的工作"時，請不要客氣，掉頭就走!或者向自己笑笑說，難得有廠商如此樂觀。 

作者	Steve McConnell
出版社	學貫行銷