1. 程式人生 > >程式設計師修煉之道 筆記與感想

程式設計師修煉之道 筆記與感想

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的名字,不是嗎?其實只是指了一個小事情,在你的程式碼上面留下你的足跡。這一點,在第一個公司的時候就已經養成了習慣,並且保留到現在。雖然現在沒有諸如此類的要求,但是我還會繼續這麼做下去,因為對於自己,對於隊友,都是很重要的好習慣,當別人發現有問題時,可以馬上過來問我:嘿,為什麼會有這個問題。他可以節約自己的時間,我也可以有機會再一次增加自己的經驗(參見我之前的感受)。而且留下自己的痕跡,也留下一份責任心,不負責任的人,馬上就能被發現。


至此,終於把這本書看完了一遍,當然最後的附錄和答案沒看。對比自己以往接收的,以及所做的,還比較吻合作者描述的注重實效的程式設計師,值得欣慰。回憶往事,很多習慣源於第一家公司時候經歷的一切。有時候我會想,一個程式設計師的第一份工作,很可能影響了他未來的道路。

我還是得感謝在我職業道路上給我醒目燈的第一家公司的同事:老麥。作為同事,師兄,領導,朋友,他無私的給我指明瞭很多的道路,教了我很多的東西