編者按：2500行代碼的程序一定比500行代碼的程序好嗎？寫出簡潔、高效、高可用的程序的開發者黯然離場，搞出龐大、複雜又難用的程序的人倒能加薪升職？究竟開發者的工作應該如何進行評價？來看看下面兩個程序員的故事吧。本文譯自RealMensch，作者 Neil W. Rickert，原标題為“The Parable of the Two Programmers”。

兩個程序員的寓言

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

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

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

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

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

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

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

兩個月過去了，Automated公司的團隊終于發布了項目實施時間表。再過兩個月，他們将發布一個測試版的程序。然後再經過兩個月的測試和優化，便會得到一個完整的最終版程序。

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

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

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

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

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

後記：

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

Charles每天确實産出了大約5行代碼，這或許是略高于業内平均水平。然而，基于程序是這麼簡單，他的表現也就并沒有什麼特别了，而且他的上司還記得他那兩個月的“摸魚劣迹”。

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

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

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

來自Tim Mensch的評論：

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

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

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

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

這就是為什麼我認為上面這個寓言如此重要的原因。開發經驗固然重要，但在項目設計和實施上的技能都可以完勝經驗，如果你同時具備經驗和技能，就可以實現相當的奇迹。隻要你持續質疑自己的想法并持續思考如何更好地完善它，而不要一味地認為自己的第一個設計構思就是足夠完美的。

譯者：張茉茉

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!