無瑕的程式碼 番外篇

無瑕的程式碼 番外篇

無瑕的程式碼本已是軟體工程師必讀作品,作者還出了本番外篇,專講職場做人處事,翻來看受益頗多。

看這本書感覺就像有個親切的老前輩,教導你職場要注意那些事情,想想自己大學畢業投入職場,不懂事硬碰硬,弄得自己一身傷,這樣的老前輩人人必須。

作品有些像懺悔錄,自己年輕時做得蠢事毫不猶豫寫出來,清楚寫出從屁孩走向成人之路,可讀性甚高。比如自恃功力高就不把公司規定當一回事,結果被開除。

還有一次作者在一家明知無望的公司當高層,燒光了第一輪投資,正在找第二三輪投資,每天高壓鞭策屬下、開除無法達到進度的員工,其實他自己都厭惡這樣做。直到有天妻子要他照照鏡子,他看到一個面目可憎的人,突然醒悟不能再繼續,於是辭職,開始做起顧問工作。

書中教很多有用的技巧,比如上級逼問你幾天可以交出程式時,作者建議保守估計,不能做出來就坦誠以告,讓主管能去找備援方案,這才是最負責任的作法。隨便說一個樂觀的日期,最後卻無法達成,是最糟糕的。這一點幾乎馬上就在我現實工作中用到了。

作者也質疑,醫師要經過多年訓練才能主掌開刀,為何大家會覺得工程師剛大學畢業就可以動手做大案子,覺得不可思議。

年輕時看到寫得很爛的程式會開罵,但職場滾久了,現在都覺得很可憐,因為職場願意培訓新人的意願不高,就像作者寫得那樣,所以這些新人就只好土法煉鋼亂寫一通,當然會給後續維護帶來困擾,造成很多不定時炸彈。

作者建議應該讓老人手把手帶新人,老人的身教,經驗與各種寫作習慣,對年輕人都非常重要。作者還推薦結隊寫程式,就是兩個人一起寫程式,雖然不符合工程師孤僻的習性,但結隊會指出彼此的缺點、建議,確實學得特別快。

作者建議應該把多人固定組成一團隊,一次完成一個案子,長久下來培養默契就會有驚人的效率。但常見公司的習慣都是一人塞多件案子,不同案子彼此干擾,打斷專一思考,造成效能低下,作者認為這很荒唐。

但通常這時公司高層會歸咎這名員工素質低劣,不會檢討自己管理問題,然後員工憤而辭職跳槽到別家公司,沒有這種畸形管理,又搖身一變成為高效員工,可見原因根本不在員工本身。

強力推薦這本書給每一位工程師。



作者 Robert C. Martin
出版社:博碩文化
2025-11-14 23:47 發佈
再補一段我覺得有感觸的:

作者建議應該把多人固定組成一團隊,一次完成一個案子,長久下來培養默契就會有驚人的效率。但常見公司的習慣都是一人塞多件案子,不同案子彼此干擾,打斷專一思考,造成效能低下,作者認為這很荒唐。

但通常這時公司高層會歸咎這名員工素質低劣,不會檢討自己管理問題,然後員工憤而辭職跳槽到別家公司,沒有這種畸形管理,又搖身一變成為高效員工,可見原因根本不在員工本身。
這些事情對也不對

程式設計師就像是古代文人一樣

我覺得你沒什麼了不起

你也覺得我沒什麼了不起

最後就是誰也不服誰

所以還是繼續自己寫自己的,自由成長比較好

光是看到 無瑕的程式碼 這種書名就知道沒什麼參考價值

就是個不知世事的高手,多年後才領悟出做人的道理

搞軟體的就是有一種老是不服輸

以為可以靠什麼模式,靠什麼語言,靠什麼開發可以達到完美

可以沒有臭蟲,可以好開發好維護好延伸

但世界上根本沒有這種東西

就是一直在沒事找事做

搞出更多新東西來顯現軟體有在進步

但其實新程式依舊有bug

搶票時依然轉圈圈

雲端一樣會大當機

跟從前其實根本沒什麼不同

為什麼不放下他接受他呢
yoyo0719 wrote:
光是看到 無瑕的程式碼 這種書名就知道沒什麼參考價值

絕非如此。這本書主要是教導如何寫得讓程式碼簡潔易懂。

軟體工程師生命短暫,但他們所寫的程式碼可能會長久留存,活在這世界上。就像我爸已經過世,但他發明的感應式自動開燈開關,卻留在世界上,讓我看到就覺得他還活著。

我相信每個工程師,都希望他寫的程式能傳承萬年,對世界文明造成偉大影響。就算你說的軟體改朝換代,舊程式碼還是會被挖出來放在新軟體裡。

但要做到這件事,你的程式就必續簡潔易懂,這樣等你離職後人接手,遇到公司制度改變局勢動盪時,別人都能輕易了解你的程式並改寫,有彈性容易變更,是程式壽命長最主要因素。

但如果像我前面講的,大學剛畢業菜鳥沒人帶土法煉鋼,也沒架構師管理,往往就把程式寫得一團亂,可能過久了他自己都看不懂。等到有新的需求,或局勢發生變化,只能整個打掉重來。這樣對公司不好,對工程師而言,他的程式也極為短命。

yoyo0719 wrote:
程式設計師就像是古代文人一樣
我覺得你沒什麼了不起
你也覺得我沒什麼了不起
最後就是誰也不服誰
所以還是繼續自己寫自己的,自由成長比較好

我前公司也有這問題,主管這樣抱怨,但實際問題大家都看得出來。

幾個工程師,主管會挑最會講話的人某甲主導,但他的謊言與問題,有寫程式的都看得出,所以當然不服,主管只覺得大家都心高氣傲很難管。

過幾年後,別人都能克服種種難題把事情做出來,某甲總是有各種推託之詞,別人說明寫得不好,別人交代事情達不到他需要的水平等等,怎樣就可以了不須導入新版等等,幾次做不出來還是別的工程師救火,久了主管心裡也有數,他也就黑掉了,最後被資遣。

主導的架構師一定要很有經驗能力很強,通常薪水不低,如果公司很摳隨便找個嘴甜的人做,就變成你說的局面。
只能說書名翻譯的有點超過了
看原文吧

這兩本我都有


這類的我比較推code complete 第一版那本
第二版我還沒看過
我是碼農
學程式的實戰老實說就是丟一個案子給你看
後面讓你新增修改維護

老實說我很傳統的孤僻
所以要跟人家一起寫程式很困難
不過我學會了看風格,照著原作風格寫程式
同事誰寫的,久了都可以看得出來
也可以照著他風格維護
甚至原作都搞不清這功能是我寫的還是他寫的

當然這個就是如果我看到垃圾
那我寫出來也一樣是垃圾
......

還有
每個人處理手法我都知道
優劣也心裡有數
但是新功能要用誰的手法比較漂亮
要怎麼取各家長處卻維持一種格調去寫
就比較難取捨

剪貼容易沒錯
真正難的是把各種剪貼融為一種好修改維運的統一風格
所謂風格說穿就是思考方式
你的思考決定程式邏輯與運作

抄也不能抄到自己不好維護
那是給自己先挖墳
蠢蛋才不先理解就通篇照抄
fujinla_001 wrote:
老實說我很傳統的孤僻
所以要跟人家一起寫程式很困難
不過我學會了看風格,照著原作風格寫程式
同事誰寫的,久了都可以看得出來
也可以照著他風格維護
甚至原作都搞不清這功能是我寫的還是他寫的

你已經是比較厲害的了
比較差的就只會自己那一套,別人的都看不下去
fujinla_001 wrote:
老實說我很傳統的孤僻
所以要跟人家一起寫程式很困難

作者也沒有要人天天跟別人一起結隊寫,就是偶爾為之練功一下,收穫確實會很多。

團隊合作跟結婚一樣,一開始都有磨合期,等到你摸熟對方優缺點,找出因應之道,習慣了就能開始正常運作,產能也開始大幅提升。

所以作者反對每個人塞一堆案子,不停拆散組合團隊。這樣就像不停結婚離婚,每天都在磨合期,想想也是滿恐怖地。
內文搜尋
X
評分
評分
複製連結
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?