程序員修煉之道（轉帖）

1 我的源碼讓貓給吃了
　　不要尋找藉口,從自身找原因
　　
　　2 軟件的熵
　　一句話:不以善小而不爲,勿以惡小而爲之.
　　從初期就要做好規範,不要因爲是poc這樣的前提而放鬆對代碼的規範,現在的項目就
　　有這種問題,初期的時候有人認爲(自己也有這種想法)等到以後正式開發的時候再規範
　　,而往往還未到正式開發,到處出現不規範的東西.加上拷貝粘貼的大法,亡羊補牢都晚
　　了.這就是所謂破窗戶理論.
　　
　　3 石頭湯與煮青蛙
　　兩個方面,一還是'軟件的熵'當中的含義,喜歡書裏面的這段話:'大多數的項目的拖
　　延都是一天一天發生的,系統一個特性一個特性的偏離其規範.一個又一個的補丁被打
　　到某段代碼上,直到最初的代碼一點沒有留下'. 二是團隊的協同合作,這樣石頭湯也很
　　鮮美.
　　
　　4足夠好的軟件
　　就是俗話說的一鳥在手勝於二鳥在林.
　　首先得確保軟件可用性,至於亮點,特色,在可用以後才需要考慮.而且還得明確用戶需
　　求(雖然這點始終被強調).大家都知道系統不可能做的完美,但是自己着手開發的時候
　　總是朝着儘可能完美的方向發展,欺騙自己說,這個功能多麼偉大,一定要加上去,那個
　　功能多麼驚天動地,最後反而成爲四不像,使項目延期.
　　在第一次企圖做那個todo list的時候,想着把calendar和task兩項功能完整的結合,
　　同時還想着把contact功能也加入,甚至還有ms porject的管理功能,但是一切都太多,
　　以致於設計了少數幾個界面以後就陷入了無止境的功能權衡中,因爲太多東西又想完美
　　.所以第一次最終結果是除了最後那個簡陋的複雜的界面,什麼東西都沒有,當然如今代
　　碼也已經不知道是不是被自己刪除,能夠留在自己硬盤上並且使用的還是那個簡簡單單
　　的GeeTask,功能不多,但是的確對我來說,足夠好了,如果還有新的功能,添加就是了,不
　　用一次就做一個大而全的玩意出來.
　　也想起在上一個公司參與的第一個項目,房地產的預警系統,先前同事通過研究,不知
　　道從哪裏搞到一些其他人做的預警系統,動用高深的所謂經濟學景氣循環算法來計算,
　　艱難的實現這些公式.當然我們自己也不知道這個是不是準.後來我負責去給客戶實施,
　　在客戶處,得知了驚人的消息:客戶需要的足夠好的軟件其實就是一個新聞發佈功能的
　　東西,因爲他們也不懂,是領導的要求---領導當然也是被上層領導要求.這個例子雖然
　　特殊,但是也說明了一定要及早知道客戶心中的足夠好的軟件是什麼.
　　
　　5 你的知識資產
　　關於學習的一個章節,提到了不少如何學習,把學習知識作爲投資一樣看待,分析的也
　　很在理.自認爲在這方面還是趕上了書中的要求,不然也不會看到這本書了^_^,學習是
　　一個過程,不會有立杆見影的效果,當然我們不是政客,不需要立馬可見的政績,那麼種
　　種樹又何妨呢?學習也要有實踐,把學到的知識找機會就應用起來,起碼,自己沒用到,也
　　可以看看別人怎麼用嘛.學的多了自然有了自己的判斷,前兩天不小心點開了jdk源碼當
　　中關於Arrays.sort方法的實現.看到內部的合併排序法卻不如《算法導論》中描述的
　　那麼簡潔,那麼具有可讀性,這時候,有了判斷了,就不至於傻乎乎的研究它的寫法,當然
　　,jdk裏面的mergesort又有一些額外的處理(小數組優化),這個又是可以學習的地方.對
　　了,這一小節裏面還有一段關於如何獲得答案的方法,和國內論壇風靡一時的《提問的
　　智慧》一文有多處相似之處,不知道作者是否參考了本書.
　　
　　6 交流
　　這個不用說就知道重要了.離開上一家公司最後一個項目就是最好的例子,一開始其
　　他同事從客戶處帶回來老系統的截圖以及一些需求的說明,然後我們就要按照這些支離
　　破碎的東西進行開發.我們不是先知,不是某些領導人,可以自由的發揮,於是絞盡腦汁,
　　開始努力向可以吻合的方向發展,這種日子很不好受,直到我可以與客戶聯繫上以後,直
　　接的面對面的確認客戶的需求(又是需求) 才讓項目的進展在幾天裏面比前面一個月都
　　要好的多.
　　7 重複的危害
　　有時候是copy paste大法帶來的後果，有時候是爲了省事，總之，一份功能相同的代碼在多處出現，更要命的是，需要修改這部分代碼！這個可以毫不客氣的說就是災難，所以在設計，在編碼初期就要有良好的規劃，儘可能避免重複。實際工作中，發行有時候，儘管想要刻意避免，但是還是會出現。其中一個重要原因在於程序員的偷懶，還有是在於模塊的可訪問性。尤其是兩個模塊沒有任何公用模塊的時候，如何避免重複，或者說人工重複纔是問題的關鍵，即使是build腳本去讓兩個模塊出現相同的東西，也比人爲維護兩個東西都要好上千萬倍。
　　
　　8 正交性
　　模塊耦合，代碼耦合，分層分模塊，善用設計模式。正交的目標只有一個，讓系統富有彈性，可以隨需應變。
　　
　　9 可撤銷性
　　還是系統的可變性，是否可以快速應付其中一些改變而快速改變。通常我們用面向接口的方式來做到這些。在前人的基礎上，我們有corba ，com，ejb，webservice，odbc，jdbc等等讓我們快速應變的基石，但是總有一些依賴我們自己的東西，接口，接口！
　　
　　10 曳光彈
　　很炫的名字，可惜就是在講poc，Prove of Concept ，的確很有用。
　　
　　11 原型與便箋
　　原型，沒別的，常用的東西。
　　
　　12 領域語言
　　不同語言有不同的優勢，關鍵在於揚長避短，合理運用，有時候組合起來事半功倍。
　　
　　13 估算
　　開始前做好計劃，過程中最終計劃，磨刀不誤砍柴工。
　　
　　14 純文本的威力
　　很多時候純文本的簡單讓事情更容易。
　　
　　15 Shell遊戲
　　程序員必須掌握命令行，即使在windows下面。
　　
　　16 強力編輯
　　知道vi好，但是隻會那麼幾個簡單的命令，而且，通常我總是在windows下面工作，所以通常用crack的UltraEdit。不少實用的功能，加速編輯。倒是IDE的快捷鍵記住了不少，在實際工作中，發揮了很大的作用。
　　書上提到仍有不少人使用windows notepad寫代碼，我雖然不至於此，但倒是習慣使用它來寫文章，記錄東西，然而就在剛纔，發現手工輸入的東西都會出現幾個黑色的黑框，可見一定要選擇足夠好的編輯器才行，何況，windows notepad只能撤銷一次，而且你也不會知道撤銷的到底是你那次的輸入。
　　
　　17 源碼控制
　　凡是工作過的程序員，沒有不用源碼控制工具的吧？ 只是選擇有所不同。
　　
　　18 調試
　　讀書的時候學習編程，覺得和其他人最不一樣的地方在於兩點，一是自己思考程序的流程，寫下代碼之前，知道代碼將要（預期）執行的順序邏輯，二是會調試代碼，出現錯誤時不像一般人完全不知道該如何是好，而是去調試來尋找出錯的原因。我相信，現在還是有不少工作了的程序員，不習慣去調試，他們期待的是自己的代碼都是一次編寫就能正確無誤的執行，如果不行，那麼別人大概可以幫忙解決。
　　一直以來，一直覺得，一個程序員的經驗豐富情況很大程度依賴於他遇到的bug並解決的數量，所以一個人代碼寫的越多，解決的問題越多，那麼他下次遇到問題時就越容易很快的定位。所以，有時候遇到問題並且成功的選擇另外一個方案繞過去以後，不妨回頭再看看原來到底爲什麼不行，畢竟下次也許你又要遇到，而且，更重要的是，可能到時候不能選擇其他的方案。
　　
　　19 文本操縱
　　這一節沒理解它真正的含義，表面看來是講可以使用程序來讀取操作文本的信息，來加快工作效率，但是到底指什麼呢？不明白。不過倒是在工作上，多次嫌手工執行一些轉換數據庫工作麻煩，而寫一些簡短的工具來做批處理，效果也很不錯。
　　
　　20 代碼生成器
　　經常用，很好用。
　　
　　21 按合約設計
　　以前也看過類似的文章，當時還把它貼到公司的wiki上面，並且自從那以後一直堅持契約的方式編程。長久一來，我一直認爲這是行之有效的方式，每個人把注意力放到自己的代碼中，對他人的代碼只作檢查，不做包容，如果，對方的屁股沒擦乾淨，一腳踹出去比請進來幫他擦更讓人能夠覺得舒暢，而且，也能防止有些傢伙習慣性的先把屁股伸進來。
　　至於斷言，以前學習VC6的時候因爲其對程序的終止而不那麼喜歡，而並非每次都寫JUnit 也讓自己並非常用。
　　
　　22 死程序不說謊
　　代碼總是忠實的執行程序員的指令。一切程序員的錯誤最終將反映到代碼上面來，在代碼中隨時做好踹別人屁股，甚至踹自己屁股的準備，因爲崩潰比繼續錯誤的運行更有好處。
　　
　　23 斷言式編程
　　就是斷言，同21節中的內容。
　　
　　24 何時使用異常
　　因爲在用java所以一直在和異常打交道，系統的，別人寫的或者是自己寫的。異常的處理可以說是所有java應用中最普遍的東西。配合上面3節，合理使用，讓異常發揮最大的效用。
　　
　　25 怎樣配平資源
　　記住並切實的執行一個原則：打開的資源一定要關閉，這個資源可以是文件，內存，io或者其他。雖然有些語言比如java有GC來管理內存，但是卻管理不了文件，c的野指針問題，也都是因爲只顧申請卻不記得釋放導致。還是前面的老話，屁股要自己擦乾淨，擦不乾淨當然會把褲子弄髒，髒了褲子是小，臭味薰了別人是大。
　　
　　26 解耦與得墨忒耳法則
　　沒明白得墨忒耳法則的具體確切內容，不過減少耦合總是不錯的。
　　
　　27 元程序設計
　　很多東西都應該以配置文件的形式來處理，這樣的好處顯而易見：修改這部分內容無需重新編譯代碼。而今，我又有一些新的體會： 配置可能會帶來配置滿天飛的災難，所以一定要清晰易懂的配置。
　　
　　28 時間耦合
　　工作流的東西，到現在還沒有去瞅過，管他呢，用的到時再說吧。
　　
　　29 它只是視圖
　　mvc 常用的不行的東西，發佈/訂閱，這個也是在設計、編碼過程中自然而然想要使用的玩意。
　　
　　30 黑板
　　是指多系統共用數據嗎？看着有點像，不確定。
　　
　　31 靠巧合編程
　　編寫代碼的方式是知道要做什麼，然後寫代碼。所以要清楚的知道自己的代碼每一步都做了些什麼。對於很多程序來說，通常情況下，它是正確的，而某些情況下它卻不正常了，那麼這就可以歸屬於靠巧合編程。程序的錯誤，很多時候在於對邊界條件的判斷。
　　
　　
　　32 算法速率
　　就目前來說，項目已經很少需要精確到一個具體算法的速度，但是在比較廣義的範圍內，減少不必要的計算，提高整體運算速度，還是會是系統看起來更好。本節提到的算法複雜度，在很多書中都被提及，但是我從一開始就忽略了這部分的學習，所以，通常情況下，總是不知道一個算法的具體複雜的（總是忘記某些重要的結論，比如遞歸算法的複雜度計算公式），所以這個一定要補上來。
　　
　　33 重構
　　沒什麼好說的。
　　
　　34 易於測試的代碼
　　測試，保障代碼質量，沒什麼好說的。
　　
　　35 邪惡的嚮導
　　爲了節約時間，出現了各種嚮導工具，同時也讓不明就裏的人失去了瞭解細節的機會，因而，懶惰的人更不會去理會嚮導做了什麼事情，這就是邪惡的原因所在。
　　
　　36 需求之坑
　　終於到了需求的部分，可是有沒什麼好說的了。
　　
　　37 解開不可能解開的迷題
　　有時候問題的解決需要跳出常規的思維。或者簡單一點，用另外一種方法，而不是鑽牛角尖。
　　
　　38 等你準備好
　　不打無準備的仗。沒什麼好說的。
　　
　　39 規範陷阱
　　不要等萬事具備纔開始，因爲不可能萬事具備，用戶總是在變。
　　
　　40 圓圈與箭頭
　　工具是拿來幫助加快開發，而不是束縛開發的。各種各樣眼花繚亂的UML，其實只是爲了能夠清晰描述設計者的思想。當我還是高中生的時候，老師在課堂上面講述着流程圖這種工具，當時甚至5、6年以後我都沒聽說過uml，但是覺得流程圖就是那麼的實用。如今，已經很少見到有誰在使用流程圖來描述。也許和設計的關注點不同有關，但是當自己在使用uml進行設計時，卻又十分的想使用流程圖，可惜，像rose之類的工具都沒有，也不知道uml是否定義。viso倒貌似有，可是還沒用過。前不久找了一個開源的digramdesinger的工具，在這方面倒做的不錯。
　　
　　41 注重實效的團隊
　　項目開發就脫不開團隊，個人的項目除了興趣愛好，還沒聽說過。團隊重要性不言而喻，以往的經歷告訴我一個合理的團隊讓人覺得有歸屬感，反之，就容易萌生去意。一起喝着可樂，聽着破喇叭放出的音樂，並且加着班的團隊在多年以後的記憶裏面顯得那麼的美。
　　
　　42 無處不在的自動化
　　程序的目的之一就是讓原本繁瑣複雜的重複勞動自動化的處理，而軟件開發過程中也一樣需要自動化。我一直堅信別人說過的一句話：凡是有人蔘與的過程，肯定會產生錯誤。所以，我也一直堅持能讓機器去做的事情就交給機器，以減少人的參與，減少錯誤的發生機率。在過去，我嘗試了多次爲某些任務編寫簡單的程序來自動化處理，雖然，我的計劃上，沒有寫一個程序這樣的描述，但是，寫程序自動處理更好，更有效，最重要的是，還能再次重複預設的動作。此外其他的自動化工具也是很值得推薦，比如自動化測試，代碼生成器。
　　
　　43 無情的測試
　　測試是爲了保障代碼的質量。所以越是仔細，全面的測試，越是有助於系統的健壯，不負責任的程序員或者測試，總是拿着可以正常運行的數據來進行着測試。有條件還是需要專職的測試，合格的測試，而不是那種連代碼都看不懂的剛畢業的小姑娘。
　　
　　44 全都是寫
　　文檔和註釋。自認爲註釋方面還過得去，但是有些情況下還是會忽略註釋而後期彌補，這一點需要改正。 至於文檔倒是需要好好努力的，這樣能顯的更“專業”，能更好的記錄代碼的情況。
　　
　　45 極大的期望
　　達到客戶的期望，纔是軟件真正的成功。這一點，其實又涉及到“萬惡的”需求。剛剛經歷了一段做完的曳光彈被客戶槍斃的事情。其實這一切，如果能從一開始就得到客戶的期望，就不會如此的糟糕。而事實卻是客戶的期望，客戶的需求卻並非可以得到。雖說這不是好的軟件工程的典型，但是至少，我們現在知道了什麼是客戶期望的。
　　
　　46 傲慢與偏激
　　很cool的名字，不是嗎?其實只是指了一個小事情，在你的代碼上面留下你的足跡。這一點，在第一個公司的時候就已經養成了習慣，並且保留到現在。雖然現在沒有諸如此類的要求，但是我還會繼續這麼做下去，因爲對於自己，對於隊友，都是很重要的好習慣，當別人發現有問題時，可以馬上過來問我：嘿，爲什麼會有這個問題。他可以節約自己的時間，我也可以有機會再一次增加自己的經驗（參見我之前的感受）。而且留下自己的痕跡，也留下一份責任心，不負責任的人，馬上就能被發現。
　　
　　
　　至此，終於把這本書看完了一遍，當然最後的附錄和答案沒看。對比自己以往接收的，以及所做的，還比較吻合作者描述的注重實效的程序員，值得欣慰。回憶往事，很多習慣源於第一家公司時候經歷的一切。有時候我會想，一個程序員的第一份工作，很可能影響了他未來的道路。
　　
　　我還是得感謝在我職業道路上給我醒目燈的第一家公司的同事：老麥。作爲同事，師兄，領導，朋友，他無私的給我指明瞭很多的道路，教了我很多的東西。