前陣子因為 老涂的咁仔店: 軟體業界有救了?! 這一篇得知了這本書..
自認還是新手的我(新手愛買書)就上網訂了一本回來..
反正我最近應該很閒..
乾脆寫寫心得..
但應該都是寫我犯過的錯..
或是我有興趣的重點或笑話..
想要一窺書中精華的人..
還是去買一本回家慢慢啃吧..
900多頁真的是要用啃的..
第一章-歡迎加入軟體建築的行列
寫 Code 請經過大腦..
事前要設計..
一開始你認為節省的時間..
後來很可能都會乘上一百倍又射在你臉上..
第二章-用隱喻角度探討軟體開發
其實這章我覺得比較像..
如果跟不懂的人或者是你老闆(你有種的話)解釋為何需要花時間設計的理由..
寫程式就像蓋房子..
我覺得很有道理..
試想想你敢買一間完全沒有設計圖..
建商直接叫工人直接蓋起來的房子嗎..
更屌的是蓋到一半又告訴你一樓隔間全部打掉要改成停車庫..
這種房子沒有人敢買..
但是這種程式倒是許多不 Care 的人在用..
第三章-三思而後行:上游的前置作業
先不論設計..
開始編寫程式時最好是能充份了解客戶的需求..
小弟我最近才發生過..
整個功能我都寫好了..
老闆隔週竟完全翻盤..
變成了一個完全不同的需求..
還好這塊我有獨立挖出來編寫..
要不應該又是幹了吃力又沒薪水多拿的苦差事..
反正我覺得 了解客戶需求 > 設計..
你在女廁蓋個容易抽換的小便斗是有屁用..
第四章-重要構築決策
這章在介紹各種程式語言..
而我最有印象的只有"程式設計語言影響程式設計人員很大"..
他舉了一個例..
原本都在寫 Fortran 的工程師正以 C++ 編寫新系統..
但卻是經過偽裝的 Fortran.. 囧rz
個人深受 Turbo J 的荼毒很久了..
第五章-構築的設計
為何要做設計..
除了為了因應未來的變化外..
最主要就是要降低複雜度..
世上應該多少人能掌握整個專案的所有細節吧..
若在開始編寫時就將整個專案模組化..
我們不但對系統能有各概念化的認識..
同時也分解了原本很複雜龐大的工作..
反正你要一頭栽進泥沼是你家的事..
不要連累到我就好.. 囧rz
第六章-工作類別
這章已經進入實際編寫階段..
就是書上已經可以看到範例程式碼了.. Orz
關於類別..
看下來我都沒啥犯錯的地方..
反正不外乎是..
封裝類別內的成員..
內聚力要高(類別內是否都是做一致的事情)..
藕合力要低(類別與其它類別的關聯性)..
"繼承"只有兩種使用方式:小心使用,以及禁止使用..
我自己是覺得..
有時候就是懶或是寫昏頭..
反正最後出包倒楣的還是自己(或是接你包的人).. Orz
上面..
誰 Care 這個勒..
第七章-高品質常式
先說一下常式就始類別裡的方法(我自認為)..
這章零星的重點很多..
我覺得要自己親自去看..
發現"原來不能這樣喔"的效果會比較好..
反正最大兩重點就是..
常式命名要清楚..
林北改人家扣就看過..
方法名稱 - doSomething(int inValue);
當下真想幹他祖宗十八代..
度喪心..度..度林娘親..
個人覺得這真的是 RD 最不道德的行為之一..
還有會這樣寫的人通常也不會寫註解(幹)..
將複雜的步驟包裝成一個常式..
比如說你今天要去大便..
你要先..
脫外褲();
脫內褲();
拉大便();
擦屁股();
穿內褲();
穿外褲();
若你程式三不五時就要你去大便 若 你又超愛用 Copy & Paste..
你程式碼到處都有以上6個的呼叫區段..
其實你就直接包裝進一個新的常式(叫去上大號()好了)..
這新的常式會去呼叫以上六個常式..
看你程式的人也比較不吃力..
對你 上大號() 有興趣的人在點進去看就好了..
另外也比較好修改..
像我上面少打了 沖水();
你用 CP 大法..
那你就慢慢找出來改吧..
若都包裝成一個常式了..
改一個地方全部搞定..
這章節我比較有印象的錯誤只有..
不要修改常式傳入的參數..
之前就是為了一個類似的 Bug (前輩寫的)..
花了我兩到三天的時間..
現在想起來頭皮就發麻..
以上拉拉雜雜寫一堆..
主要是自己放 Pi 一下也比較有印象..
看完的人有興趣去書店翻翻書吧.. Orz
之後章節有看就會寫..