我有一個很熟的朋友,他現在忙的不可開交。他手上有一大堆沒有完成的合同,而且一個跟他一起開發的助手也離他而去。於是,在三個大客戶的催命鬼時的督促下,他已經連續好幾個星期沒休息了。
其中有個客戶跟他討論他給這個客戶做的iPad應用程式,客戶告訴他“我們花錢僱了另外一個程式設計師來審查你的程式碼,他說你的程式碼寫的很爛。”
我有一個很熟的朋友,他現在忙的不可開交。他手上有一大堆沒有完成的合同,而且一個跟他一起開發的助手也離他而去。於是,在三個大客戶的催命鬼時的督促下,他已經連續好幾個星期沒休息了。
其中有個客戶跟他討論他給這個客戶做的iPad應用程式,客戶告訴他“我們花錢僱了另外一個程式設計師來審查你的程式碼,他說你的程式碼寫的很爛。”
當他告訴我這個故事時,我只是微微一笑,想起了我以前是怎麼唾棄別人的程式碼的。當我剛開始程式設計時,我看到過一段程式,我認為那是毋庸置疑的寫的很爛的,我刪掉了那段程式碼,用自己認為更好的方面重新寫了一遍。當我變成的成熟後,我回頭再看,發現我所刪掉的那段程式碼其實是用了一個很好的設計模式,而我重寫的確是醜陋無比。
我就這樣被上了一課。
之後的日子裡,我經常會遇到我認為是醜的不能再醜的程式碼。儘管如此,我也不通篇否定它們了,我只會在其中找一些特別的無法容忍的部分重新編寫。可10次中有9次,當我快要完成時,我發現了一個問題使我不得不對自己說“哦,怪不得他們要寫成這樣了”,然後把程式碼恢復成原樣,或也使用同樣“醜的不能再醜”方式完成它。
現在我變的更成熟了,我可以充滿自信的告訴你,我再也不會看著別人編的程式碼說“哦,這程式碼很爛”了。我知道,在沒有了解整個程式的解決方案之前,你不可能就那麼輕易的判斷程式碼的好和壞。真的,有時候它看起來很傻,或完成的不好,或沒有文件標註(我的意思是自我註釋),然而,你根本就不可能知道程式設計師在寫這段程式碼時腦袋裡是怎麼思考的。更多的情況是,他們要選擇這樣做是有一定的理由的,除非去深入的研究它們,你不可能再有其他簡單快速的方法來理解程式的上下文環境。
所以,每當聽到有人看著別人的程式碼說很爛時,我只會微微一笑,讓我想起我當年的天真和盲目自信。的確,我以前堅信自己是個出色的開發人員,堅信知道每種演算法的最優設計。我很想念當時的自大,但是我很高興現在學到的這些理念,我知道,我唯一能鄙視的程式碼只能是我自己的程式碼,鄙視的原因就是我不能使它變的更好。