## 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的名字,不是嗎?其實只是指了一個小事情,在你的代碼上面留下你的足跡。這一點,在第一個公司的時候就已經養成了習慣,并且保留到現在。雖然現在沒有諸如此類的要求,但是我還會繼續這么做下去,因為對于自己,對于隊友,都是很重要的好習慣,當別人發現有問題時,可以馬上過來問我:嘿,為什么會有這個問題。他可以節約自己的時間,我也可以有機會再一次增加自己的經驗(參見我之前的感受)。而且留下自己的痕跡,也留下一份責任心,不負責任的人,馬上就能被發現。
至此,終于把這本書看完了一遍,當然最后的附錄和答案沒看。對比自己以往接收的,以及所做的,還比較吻合作者描述的注重實效的程序員,值得欣慰。回憶往事,很多習慣源于第一家公司時候經歷的一切。有時候我會想,一個程序員的第一份工作,很可能影響了他未來的道路。
我還是得感謝在我職業道路上給我醒目燈的第一家公司的同事:老麥。作為同事,師兄,領導,朋友,他無私的給我指明了很多的道路,教了我很多的東西。
- 職業生涯
- 如何提升你的能力?給年輕程序員的幾條建議
- 那些年,那些事
- 阿里巴巴離職DBA 35歲總結的職業生涯
- 人生的四種選擇
- 程序人生的四個象限和兩條主線
- 幾縷代碼與閑思
- 張小龍-學習筆記
- Web前端
- 移動Web手冊
- 精通CSS: 高級Web標準解決方案
- 悟透JavaScript
- 架構設計
- 大型網站技術架構
- 周愛民-大道至簡
- RESTful Web Services Cookbook - 讀書筆記
- 大話設計模式
- Unix編程藝術
- 把程序員修煉之道讀薄
- 學習能力
- 奇特的一生:讀書筆記
- zhh-看源碼那些事
- 一個創業者怎么看待讀書和寫作
- 程序員修煉之道
- 2015/1/5 頭腦風暴
- 書單計劃
- 2014年我讀過的那些書
- 我的后端開發書架2015
- 別人的書單
- 讀書筆記
- 浪潮之巔
- 達內時期自己筆記整理
- Effective Java
- 打造facebook: 讀書筆記
- 面試整理
- 阿里面試的一點感受
- 騰訊的三輪面試
- 三十之惑–面霸
- 前端面試問題匯總
- 八爪網絡面試總結
- 2015面試總結總結
- 找工作流程梳理
- 最全前端面試問題及答案總結
- 前端開發面試題收集
- 百度web前端--2015一面
- 百度web前端--2015二面