2500行代碼的程序一定比500行代碼的程序好嗎？寫出簡潔、高效、高可用的程序的開發(fā)者黯然離場，搞出龐大、復雜又難用的程序的人倒能加薪升職？究竟開發(fā)者的工作應該如何進行評價？來看看下面兩個程序員的故事吧。

兩個程序員的寓言

很久以前，有兩家公司，分別是"Automated Accounting Applications Association "和 "Consolidated Computerized Capital Corporatio"，他們決定，需要一個程序來執(zhí)行自己公司的某項業(yè)務，但這兩家公司并不知道，對于他們的業(yè)務需求來說，要開發(fā)的程序是完全一樣的。

Automated雇用了一位程序員分析師Alan來解決他們的問題。

與此同時，Consolidated決定讓他們新招聘的一名初級程序員Charles來負責這項工作，看看他是否真的那么優(yōu)秀。

Alan曾經(jīng)有過操刀艱難的編程項目的經(jīng)驗，所以他決定使用PQR結構化設計方法。考慮到這一點，他要求部門經(jīng)理再指派三名程序員作為編程團隊。然后，這個團隊就開始工作了，撲到了鋪天蓋地的初步報告和問題分析上。

再看Consolidated這邊，Charles沒忙著動手開干，他花了一些時間思考這個問題。Charles的同事們注意到，他經(jīng)常坐在桌前，把腳抬起來放在桌子上，喝著咖啡。偶爾也會看到他在電腦前忙活，但同事們從他敲擊鍵盤的節(jié)奏就能看出，他其實是在玩《太空侵略者》的游戲。

這時，Automated的團隊已經(jīng)開始寫代碼了。程序員們大約用了一半的項目時間來編寫和編譯代碼，其余的時間都在開會，討論各種模塊之間的接口問題。

而Charles的同事注意到，他終于不再沉迷《太空侵略者》了。他現(xiàn)在要么就是把腳架在辦公桌上喝咖啡，要么在小紙片上亂涂亂畫。他寫在小紙片上的字跡很潦草，當然看起來不是在玩Tic Tac Toe（一種游戲），但也沒有什么意義。

（推薦教程：JavaScript教程）

兩個月過去了，Automated公司的團隊終于發(fā)布了項目實施時間表。再過兩個月，他們將發(fā)布一個測試版的程序。然后再經(jīng)過兩個月的測試和優(yōu)化，便會得到一個完整的最終版程序。

另一頭，Charles的經(jīng)理一直看著Charles上班摸魚，已經(jīng)厭煩了，他對Charles失去了耐心，決定和他攤牌。但當他走進Charles的辦公室時，卻驚訝地看到他在電腦前忙著輸入代碼。他決定等等看會發(fā)生什么，所以打了個哈哈，然后離開了。他開始密切關注Charles，以便抓住機會當面好好教訓他一番。但是預期中那令人不快的對話并沒有出現(xiàn)，因為他很高興地注意到，Charles似乎大部分時間都在忙碌，甚至有人看到Charles忙得連午餐都很晚去吃，而且一周有那么兩三天，下班后他還會留下來加班。

三個月結束時，Charles宣布他已經(jīng)完成了這個項目。他提交了一個包含500行代碼的程序。程序似乎寫得很清楚，經(jīng)過測試，它可以滿足項目既定的所有需求。事實上，它甚至還有一些額外的便利功能，可能會顯著提高程序的可用性。該程序投入實際測試使用后，除了發(fā)現(xiàn)一個可以快速糾正的疏忽外，表現(xiàn)良好。

到這時，Automated的團隊已經(jīng)完成了項目所需的四個主要模塊中的兩個。這些模塊目前正在進行測試，而其它模塊已經(jīng)完成。

又過了三周，Alan宣布，初級版比原計劃提前一周完成。他提供了一份待糾正的缺陷列表。該程序開始進行實際測試使用。除了缺陷列表中列舉的問題，用戶還發(fā)現(xiàn)了一些其它的錯誤和缺陷。正如艾倫所解釋的那樣，這并不奇怪。畢竟這是一個初級版本嘛，有錯誤是意料之中的。

又經(jīng)過大約兩個多月的時間，程序的正式版本開發(fā)完畢。它由大約2500行代碼組成。測試時，它似乎滿足了大部分項目需求。但是它削減了一兩個功能，而且對輸入數(shù)據(jù)的格式非常挑剔。然而，公司還是決定上馬該程序了。他們可以隨時對數(shù)據(jù)錄入人員進行培訓，讓他們嚴格按照要求的格式輸入數(shù)據(jù)。此后該程序移交給了一些負責維護的程序員去補全缺失的功能。

(推薦教程：Java教程）

后記：

起初，Charles的上司對他在這個項目上的表現(xiàn)還是比較滿意的。但當他通讀程序源代碼的時候，他發(fā)現(xiàn)這個項目真的比他最初想象的要簡單得多?，F(xiàn)在看來，即使是對一個初學編程的人來說，這顯然也不是什么難事。

Charles每天確實產(chǎn)出了大約5行代碼，這或許是略高于業(yè)內(nèi)平均水平。然而，基于程序是這么簡單，他的表現(xiàn)也就并沒有什么特別了，而且他的上司還記得他那兩個月的“摸魚劣跡”。

在下一次薪酬調整時，Charles得到了加薪，加薪幅度約為這一時期通貨膨脹率的一半（很可憐吧），公司沒有給他升職。大約一年后，他變得心灰意冷，離開了Consolidated。

在Automated公司，Alan因如期完成了項目而受到嘉獎。他的上級看了看他們編寫的程序，他瀏覽了幾分鐘，恩，是遵守公司關于結構化編程的標準的。然后他很快就不再繼續(xù)嘗試往下看了，這程序看起來似乎很難理解。這時他意識到，這個項目確實比他原先設想的要復雜得多，他再次對Alan的成就表示祝賀。

Alan團隊的每個程序員每天產(chǎn)出3行多的代碼。這在業(yè)內(nèi)大約是平均水平，但考慮到這個項目所要解決的問題的復雜性，可以說是很不錯的產(chǎn)出啦。Alan因此獲得了豐厚的加薪，并被提升為系統(tǒng)分析師，以表彰他的成就。

（推薦教程：python教程）

來自Tim Mensch的評論：

我曾經(jīng)是一名年輕但是聰明的程序員，這個故事令我產(chǎn)生了強烈的共鳴。即使在我還是個職場新人的時候，我也能做到令很多資深開發(fā)人員都感到有挑戰(zhàn)的事情。在我的第一份工作中（作為游戲開發(fā)者），我的經(jīng)理說我在幾天內(nèi)創(chuàng)建的代碼，感覺比一個更有經(jīng)驗的開發(fā)者經(jīng)過幾個月的推敲后完成的代碼都要好（從物理意義上講）。在我的第二份工作中，我對一個有十年以上經(jīng)驗的高級開發(fā)人員編寫的工具程序進行了優(yōu)化，使其只需幾分之一秒就能完成一個任務，而不用花費幾分鐘。我的整個職業(yè)生涯充斥了這樣一連串的奇聞軼事。

在我從事編程以來的多年開發(fā)和學習經(jīng)歷中，我意識到經(jīng)驗確實很重要。但是，底層技能也同樣重要。實際上，就像上面講到的兩個程序員的寓言一樣，底層技能可能比經(jīng)驗更重要，我認為這個事實已經(jīng)被許多當代的開發(fā)者忽略了。

話雖如此，我也曾經(jīng)踩過坑，跟上文提到的第二個開發(fā)者類似，創(chuàng)建了一個比實際所需要的復雜得多的系統(tǒng)。我知道一個復雜的解決方案，并且知道自己可以實現(xiàn)它，但這并不意味著它就是最好的解決方案，我需要時不時地提醒自己這個事實。

于是，我嘗試做出妥協(xié)，甚至質疑我自己的解決方案，持續(xù)尋找能夠改進和簡化的方法。我曾遭到指責：因為我傾向于花費更多的時間去思考一個問題，而不是僅僅用顯而易見的方法去解決它；我希望能找到更簡潔的方法去解決問題。因為花了很多時間思考，看起來好像不務正業(yè)，但是充分地思考可以讓我產(chǎn)出更好的結果----代碼量更少，更健壯、更可擴展而且更容易閱讀。

這就是為什么我認為上面這個寓言如此重要的原因。開發(fā)經(jīng)驗固然重要，但在項目設計和實施上的技能都可以完勝經(jīng)驗，如果你同時具備經(jīng)驗和技能，就可以實現(xiàn)相當?shù)钠孥E。只要你持續(xù)質疑自己的想法并持續(xù)思考如何更好地完善它，而不要一味地認為自己的第一個設計構思就是足夠完美的。

原文鏈接：realmensch.org/2017/08/25/the-parable-of-the-two-programmers/?