幾周前，布萊斯在網上發帖，漫談自己對編程工作的看法。在Reddit上引起了廣泛討論。討論的焦點集中在程序員的等級——“優秀”、“良好”、“糟糕”和“極差”。我發現，討論中一些用語十分不妥。"好"與"壞"都是道德評價，評價之後似乎便給人貼上了永久不變的標籤。
可以肯定的說，我曾被另一個程序員稱作是“極差”的程序員。我也承認，我確實寫過一些極差的代碼；但我也自認爲曾寫過相當多的“好”代碼。
要評判很久以前寫出的代碼是優是劣很不容易，因爲現在已經不知道當時爲什麼編寫這些代碼，也不知道爲誰編寫了這些代碼。
問問自己，現在正爲誰編寫代碼？
爲了按時交付任務
也許最常見的原因就是爲了按時交付任務。走走捷徑，寧可複製粘貼刪掉幾行代碼也不願意重構代碼，然後匆匆交工。我們都這麼做過，也都知道這是不妥的。
爲了突出的考覈結果
當管理者本身不懂代碼，卻有一套程序員“好壞”評價標準時，會出現什麼情況？程序員要理清這套標準並不困難，因爲他們的特長就是解決難題，然後他們會努力完善自己，從而迎合評價標準。代碼行數、已解決Bug數量、註釋的密度、代碼深度等都可能是衡量編碼人員的指標，但這些又都是相對標準，而不是絕對標準。也有些新穎的衡量手段（比如“已刪除代碼的行數”）。
爲計算機編寫
從某種意義上來說，所有的程序都是爲計算機編寫的，但計算機應當程序員最後才考慮的。計算機只注重語法，不注重註釋和變量名稱。大多數程序語言也不注重間距與代碼格式化。當然，你還是要選擇正確的算法，但不要想着通過微小的優化來加速算法。在for循環中，使用i++還是++i並不重要，編譯器和JITs會解決這些問題。在考慮優化算法之前，還是應該先把代碼寫的清晰易懂。要知道編碼在使用通用模式時，計算機和編譯器運行的更快。
爲了自己
雖然學習一門新的程序語言很有趣，不過如果你將整個公司架構都建立興趣之上是不切實際的。Hacker News上曾有一則相關故事，LambdatheUltimate網站上還有更糟糕的案例。如果你是爲自己寫代碼，你可以不加註釋，可以隨意使用糟糕的變量名，甚至使用其他“怪癖”，但這樣寫出來的怪異代碼別人很難看明白。不過沒關係，因爲每個人都會時不時想在某些事上找點漏洞出來。
爲後來者編程
編程是把抽象觀念轉換成計算機可以理解的形式。即使是細微的抽象觀念，轉換成代碼也是很不簡單。因此很多軟件項目都衍生出了成千上萬甚至是上百萬行的代碼，相當於一本代碼書。通過有限的語法與其他人交流這些概念，大多數時候都註定失敗。
我所寫的最出色代碼就是我願意花時間來添加註釋、列出代碼流、甚至附上一些ASCII文字圖的代碼。編寫過程專注於如何把自己抽象概念，與今後將有可能讀到這些程序的、不幸的程序員進行傳遞和交流。我認爲專注於這種交流，代碼會變得越來越好，因爲你會更深入地思考抽象概念以及如何對正在做的事情分層，而不是一味的編寫代碼和轉到下一個程序塊。
註釋使代碼變得更好理解。每當你再次做某事的時候，總會比上一次更好。當你在編寫代碼和註釋時，就是將抽象概念向讀者解釋了兩遍。這會迫使你思考更多。很多次我寫完一個代碼以後都會對它寫一個註釋。然後從頭修訂代碼，甚至改變了一些小地方，例如選擇更好的變量名稱，來更好的交流想法。
評價代碼/程序員
綜合前文所述，可以看出，編程人員孰優孰劣確實難以定奪。因爲難以明確他們編寫代碼目的。你可以考評代碼，但你無法得知代碼編寫者當時的心理狀況。或許那天是星期五，他急着要趕去維加斯度週末；也許是程序出了問題，他不得不採取緊急補救措施，但這些補救措施一用就是5年；也可能他原本就是個不合格的程序員。
也許編程真是一門藝術？
我不知道如何公正地考覈編程人員，我想也沒幾個公司能做到。看看程序員的面試流程就清楚了，他們只不過坐在桌前被問幾個問題而已；根本沒有什麼標準測試能讓計算機科學專業的學生證明自己已經掌握了必要的技能。
編程工作帶有太多藝術色彩，所以不可能通過測試手段或者固定的考覈標準來評價。
你知道還有哪個領域也是通過視覺媒介將抽象的概念傳達給其他人？美術和繪畫作品。今天，我們或許會說梵高是個大人物（其畫作聞名於世），但是仍然有人不喜歡他的作品。類似表達抽象概念的事物不應該用“好”或“壞”來評價。
程序員可以做到的就是時刻提醒自己，編程的目的要正確。不能僅僅要求編譯器能識別就行，不能爲了迎合某種考覈標準，也不能爲了按時交工而編程。相反，應該適時註解或寫文檔，解釋或記錄代碼功能。只要用心，你就能編寫出優秀代碼。如此一來，以後就會有人誇你是個優秀程序員，而不會因你那一萬行的代碼文件而“咒罵”你是“極品”程序員。歡迎在評論或微博中分享你的觀點。