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