你是否 diss 過別人的代碼？—— 怎樣的代碼纔算優秀？

你必定在心裏吐槽過他的代碼太爛：沒註釋、邏輯混亂、處處都是 magic number、實現方案過期、耦合嚴重、一改就出 bug。

此時心中的怒火油然而生，彷彿本身是正義的化身，要表明月亮消滅這樣的代碼，甚至拼寫錯誤也能夠成爲你 diss 的點。稍等片刻，先抑制一下燃燒的小宇宙，你有沒有認真想過「到底什麼樣的代碼纔算的上優秀？」

在看了 Gerald M. Weinberg 的《The Psychology of Computer Programming》後讓我有了不同的認識。不過我以爲這是一個開放問題，不一樣狀況下會有不一樣答案，歡迎討論。

這是代碼人生系列的第一篇，文章目錄以下：

1. 你是否 diss 過別人的代碼？—— 怎樣的代碼纔算優秀？
2. 程序員和領導對項目delay的理解是否是有誤差？

可行性

做者給出的第一個標準是「程序的可行性」，它是指對於任何一種約定的輸入，程序都能給出指望的輸出。畢竟可行的程序總比不可行的要好。在不知足可行性前提下的優越性能，高可擴展性都不值一提。

但不能否認的是，咱們腦子裏整天考慮的是這些次要問題。甚至會造成「不優雅就是垃圾」的價值觀，好像只有這樣才能夠在心裏自恃高人一等。得到這種莫須有的優越感的代價多是寫出了不可行的代碼，撿了芝麻丟了西瓜。

引用一段原文：

若是程序根本沒法正常運轉，對其效率、適應性及生產成本的評估就毫無心義。不管如何，咱們須要務實一些，須要認可：也許根本沒有哪一個完美的程序曾經被寫出來過。每個真正大型和重要的程序都必然包含不少個紕漏。因此對程序進行評估時，必須考慮到其不完美的一面。

按時性

做者給出的第二個標準是「按時性」。

即便不考慮可行性的問題，效率的問題仍然不是最重要的。程序開發中常常遇到一個問題是要符合開發的日程計劃，推遲完成的程序經常沒有意義。

咱們不得不比較一下，究竟是一個可能在將來完成的高效程序帶來的潛在節省更大，仍是沒有一個程序損失更大。現實中，每每是後者的損失更大。

真正困擾人們的並不是是預先估計的平均開發時間，而是實際消耗時間的標準誤差。就比如大多數人寧肯天天早上花固定的10分鐘等公交車，也不肯意每週有4天只等1分鐘，而最後一天等26分鐘，儘管就平均等待時間而言，後一種方案只須要6分鐘，但因爲某次沒法預測的長時間等待就會打亂計劃，這點好處沒法彌補其損失。因此寧肯承諾一個更留有餘地的排期，而後按時完成。而不是承諾一個滿打滿算的排期，而後delay。

開發過程當中遭遇的各類意外致使實際消耗時間和預估時間造成方差，這一問題是值得咱們深刻思考的。如何提早感知不肯定性，如何快速解決意外，是一項須要不斷提高的能力以減少方差。

適應性 & 效率

做者給出的第三個標準是「適應性」，即程序的可擴展性。緊跟其後的標準是「效率」，即程序運行的性能。

總算輪到了本覺得重要的標準，做者的一席話描述地入木三分：

在軟件生命週期內，多數程序都會被修改，不管其經驗的多少，絕少有哪位程序員能反駁這一論斷。既然如此，爲何在必須修改之前的程序時，咱們老是以爲這項任務如此艱鉅，以致於每每決定棄之不用，乾脆本身從頭寫起呢？只要閱讀過程序，咱們就會透過這些程序發現：實際上，不多有哪位原做者會考慮可能的後續修改。

做者還提了兩個問題來表達程序員的矛盾之處：

在編寫程序時，你曾經有多少次想到過它在將來可能被別人修改？反過來，在修改別人程序時，你又曾經咒罵夠幾次？

之因此把適應性和效率放在一塊兒討論，是由於它們倆會此消彼長，做者用 Fisher 定理來證實這個觀點：

Fisher定理：一個系統對某一特定環境適應性越強，它適應新環境的能力也就越弱。

若是強調的是程序的效率，那麼咱們每每會追求緊密式的代碼，而若是在將來要對這些代碼進行修改，那將會很是棘手。若是使用的是更高層的語言，那麼爲了使程序更高效，咱們每每須要深刻到機器語言層。這種作法至少抵消了本來用更高層語言編程的一個好處 —— 在不一樣機器之間的可移植性。其實際效果是，咱們將被侷限於特定的某臺計算機或特定的某個實現。

回想設計模式，無一例外是經過增長一層抽象以達到可擴展的目的，這樣的設計增長了類的數量，類的構建和類方法調用的都會消耗空間和時間的性能，下降了效率。並且它讓功能的實現變得更加間接，也增長了理解成本，下降了溝通效率。

但做者認爲性能問題不是問題：

運行效率正在成爲計算中一個日益不明朗的問題，隨着單位計算能力成本的逐年降低，以及單位程序開發成本的不斷提升，在程序開發方面比在產品方面投資更多的典型作法，早已不合時宜。所以咱們指望，隨着歲月的推移，咱們聽到的關於效率的言論將會愈來愈少。

緊接着依然是兩個回味無窮的問題：

你是否曾經由於追求效率而延誤了工做進度？反過來，是否曾經由於要趕時間完成而沒有作到盡善盡美？

但有趣的是，面試時，極少有公司是按照上述的優先級來考察候選人的，一般的考察優先級正好相反，即便有算法筆試也是把重點放在實現方案的內存性能或時間性能上，並不會對程序的正確性進一步追究。