毀滅程式設計師效率的 15 個障礙

來自：碼農網，編譯：小峰

會議，什麼都不懂的經理，生產效率指標——這就是你和下一個偉大軟體之間的天塹。

昨天必須得釋出產品。使用者爭鬧和咆哮某個缺失的功能。老闆的老闆說，我們最好迅速行動起來否則就炒我們的魷魚。感覺一切都有心無力。

沒有人滿意開發人員這種已經“竭盡全力”改變世界的速度，每個人都希望程式碼像消防水管裡的水一樣能夠源源不斷地流出來，但沒有人願意提供給開發人員更好地完成工作的條件。正如那個想要我們昨天就完成工作的老闆，他不願意僱傭更多的人，不願意購買速度更快的機器，也不願意做任何其他可以讓程式設計師專注於程式設計的事情，又想馬兒跑，又不給馬兒吃草。

下面就是現實世界中的15個程式設計障礙。

程式設計效率障礙No.1：會議

最常見的抱怨是打斷開發人員編碼思緒的會議。如果老闆信任該程式設計師，就會要求他們時不時地去那間數週甚至數年昏昏暗暗的會議室 閒聊有關細節。儘管程式設計師通常歸咎於是管理人員毀了會議，但他們偶爾也會指責其他的程式設計師老是跑過來詢問有關或bug或功能或架構策略的問題。

雖然有些抱怨是愚蠢的——但程式設計師依然會埋怨，如果老闆讓他們自己在黑暗中摸索，沒有一點溝通——任他們自己在軟體的抽象世界裡埋頭苦幹，自己去面對各種困境。快餐廚師和咖啡調配師或許還能夠兼顧不同的需求，但如果是切換大腦到正確的模式來操作抽象演算法則通常需要時間。從會議模式中切換回編碼模式，可能會浪費一個小時左右的工作時間。

程式設計效率障礙No.2：答覆所有的電子郵件

如果說會議很糟糕，那麼這一種可能更糟糕：需要檢視發來的無窮無盡的郵件。回覆郵件需要時間，而且沒人會對回覆結果表示滿意。然後那些最不耐煩的開發人員或許會選擇簡單的回覆——“tl;dr”(即too long，didn’t read。篇幅過長，沒有閱讀)。

有的團隊試圖開設每週一天的禁郵日。還有的團隊就完全不用郵件。雖然解決了郵件過載的問題，但卻是以溝通為代價的。要是突然不在一起工作。這還能算是好辦法嗎？

程式設計效率障礙No.3：試圖衡量生產力

總會有管理團隊受那些所謂“你不能管理你無法衡量的東西”的書籍啟發，於是開始衡量提交的或程式碼庫或軟體程式碼行或bug修復。他們認為，計數就是衡量，而且衡量一定是好事。

但是程式設計師並不是砌磚工，不能數數砌了多少磚就知道其效率。相反，為了寫出更好的程式碼，程式設計師需要或專注於編寫的程式碼行，或解決bug，或提交到程式碼倉庫，或做一些無法計數的事情。如果bug修復可以加分，那麼一些微小bug的報告就會激增，bug修復也會如此。有人因為報告bug得到了獎勵，然後另一個人因為修復它也能得到獎勵。或者，如果是計數程式碼行數，那麼那些可以用10行程式碼解決問題的程式設計師，可能就會轉而表示5000行的程式碼將更靈活或功能更相容——任何可以新增到5000行中的都加進去。

衡量效率實際上會因為鼓勵功能豐富，程式碼過度設計的長檔案，而讓程式碼庫變得更糟。

對於此問題還沒有真正的解決方法。我們需要跟蹤bug。我們需要組織工作流程，協調軟體的建立。這種優雅是無法衡量的。

程式設計效率障礙No.4：妄自尊大的開發人員

對於程式設計師而言，有這樣一個同事比Boss更難以忍受：建立了程式碼的最後一次迭代，卻不再工作於這個專案。正如每個房屋裝修承包商會貶低上一個木匠的技能，每個程式設計師也會快速指出可怕的，不可原諒的，完全是死腦筋的上一代的行為。

當然，這可能是事實，但它很少像程式設計師說得那麼糟糕。如果有什麼區別的話，問題通常也不是由於技能匱乏而引起的。主要還是風格的不同，並且風格還會隨著時間而改變。上一代和我們今天訪問的庫不同。他們也不曾閱讀過有關最佳做法的最新著作。

妄自尊大的程式設計態度往往會減緩專案。驕傲和利己主義的混合發酵會導致程式設計師拋棄完全能夠勝任的程式碼，只為了按照他們認為的“正確方式”重建。

程式設計效率障礙No.5：“以後修復”的思維定式，又名“技術債”

我們總感覺不夠時間在專案中按計劃構建我們想要構建的東西。於是，我們偷工減料，給程式碼打補丁，纏滿了虛擬膠帶。曾有明智的經理將此稱為是“技術債”，因為“債”是以後必須要還的。即使他們不理解程式碼，也知道“債”的含義。

每個專案都有一定的技術債務。有時它會快速見效，但通常直到下一代才會發現這已經成為了一個坑。他們需要構建上一代沒有做到的東西。就像滾雪球一樣，越滾越大。

程式設計效率障礙No.6：非程式設計師經理

總會有那些面帶微笑，西裝筆挺，卻不是主修電腦科學，也不懂程式設計專案的傢伙成為了經理。也許他們娶了老闆的女兒；也許他們正好在“正確”的時間出現在了“正確”的地方。但是，老闆讓他們擔任了經理，即使他們一竅不通。更糟的是，他們會用外行人的眼光來看待問題，哪怕不倫不類，文不對題。

有一些程式設計師表示很歡迎這樣的經理，因為愚弄他們很容易。而且他們還承擔了來自於更高管理層的炮火。但也有人承認，這些人只會不斷地開會，只會妨礙程式設計。他們幾乎給不了任何有用的指導，他們可以提供的只是那麼一點質量檢測。

程式設計效率障礙No.7：程式設計師經理

雖然程式設計師可能會因為不得不與非程式設計師經理打交道而抱怨，但他們經常悄悄地表示，程式設計人員去做管理人員更糟糕——有時甚至更糟糕得多。

他們是前任的天才，可能會決定微觀管理專案，然後果決地撕裂大片的程式碼，因為他們有了一個新的展望。或者，也許他們會閒談，對於同樣的事情，他們是如何用8080彙編或C或Java程式設計寫了一半的程式碼。在任何情況下，他們更痴迷於技術細節而不是大局，雖然他們被僱來的目的是盯牢後者。

程式設計效率障礙No.8：善於社交的程式設計師，又名“brogrammer”

雖然程式設計師可以將每個問題和任何中斷的責任歸咎於巧言令色的銷售團隊，但程式設計人員也必須承認，有一些問題在於他們自己。程式設計師被聘請的目的在於他們的計算機技術，而不是他們的人際交往能力。

程式設計師通常不善於溝通，不知道如何表達他們的感受和思維。他們可以準確抓住技術引數，就像庖丁解牛一樣迎刃有餘。無論客戶想要改變什麼都不要緊：程式設計師總是時刻思索著技術引數，即使是在公司野餐上也不外如是。

儘管程式設計師通常可以過濾掉對方的特質，但當程式設計師之間發生磕磕絆絆時也會讓團隊失敗。當同一個團隊中兩個人有著不同的政治觀點，比方說，動態語言或NoSQL，那麼團隊就會永無寧日。一切都像是在戰場一樣，戰火紛飛，硝煙瀰漫。

程式設計效率障礙No.9：自私或牛仔程式設計師

你從他的程式碼裡發現一個空指標？捕捉空指標於是成為了你的工作。你最好多想一遍要不要傳遞一個零，因為自私的程式設計師不會檢查除以零錯誤。這也成為了你的工作。

牛仔程式設計師的工作又酷又快，但這是因為他的程式碼中遺留了許多漏洞，並且沒有經過測試。於是這也成為了你的工作，因為如果你不處理這些瑣事的話，程式碼就會崩潰。

很多團隊在最終認識到這一點的時候已經為時已晚。程式碼塊在早期測試中執行良好，但當輸入真正的資料之後，各種問題就開始暴露出來。真是一場災難。

程式設計效率障礙No.10：可憐的文件

寫文件需要時間。但由於老闆僱我們來是來寫程式碼的，並且通常透過我們寫的程式碼行數來衡量我們的效率。因此既然你想要結果，那麼我們就只做你想要的那部分。當然最終我們還是會寫文件的，但質量的好壞就不論了。

有時候，文件雖然很多，但卻是幾個月或幾年前老程式碼的版本。我們只是還沒來得及修改這些舊文件而已，但是，以後我們會同步的——相信我。

程式設計效率障礙No.11：成為文件的奴隸

雖然我們都經歷過沒有文件的專案，但是空話太多、編碼太少反而導致專案失敗也很常見。曾有幾個人指著滿滿一書架的資料夾，向我炫耀說：“我專門請人來寫文件。”然而要讀完這麼多文件需要一年的時間。

程式設計師通常在處理需求時，會寫一些評論和註釋，之後充作文件。因此這樣的文件，都是一些微小的細節，沒有經過認真地總結或沒有說到要點上。這在文件中將可能是致命的，當他們沒有提供太多的抽象和理解，就只寫程式碼流水賬的時候。這樣的文件並不具啟發性，只是翻譯下程式碼而已。

程式設計效率障礙No.12：很容易導致分心的環境

有一個客戶堅持要我每天去他們的辦公室，堅持要我使用他們的電腦。然後，他們沒有提供任何的辦公空間，所以我只能和六個實習生在會議室寫程式碼，此外，這些實習生還需要我用半天的時間回答他們前一天晚上碰到的問題。另外半天的時間則用來指示今天晚上做什麼。於是，我基本上做不來自己的工作。

雖然銷售和營銷團隊可以在背景噪音的環境下茁壯成長，但程式設計師通常需要圖書館般安靜的背景。閒聊，令人心煩意亂的敲擊聲，或鈴聲將驅逐程式設計師的思維走出抽象的工作區，回到現實中。然後，需要幾分鐘的時間才能重新沉浸於工作區。

有一位開發人員告訴我，他恨他的新辦公桌，因為它靠攏空調出風口，噪音令人難以置信的響，使得他真的很難集中注意力。這可能略有誇張，但的確是一個事實。

雖然許多企業會提供程式設計師類似乒乓球桌的娛樂活動，但他們往往忘記了開發人員需要在安靜的氛圍中集中精神。甚至，他們還將程式設計師轉移到大房間，認為這可以促進合作，殊不知卻會導致一有風吹草動，整個房間的程式設計師都受到干擾。

程式設計效率障礙No.13：“文化契合”

你想擁有自己的辦公室？或者你更喜歡團隊化的辦公室，這樣你就可以直接喊出你的問題？你喜歡在清晨開始工作，亦或是你更喜歡熬夜？

如果團隊成員之間的風格相似。那麼這支團隊往往才能更好地工作。無法找到共同點的團隊很快就會失敗。沒有溝通，最後只會南轅北轍，不知所謂。

程式設計效率障礙No.14：死守傳統技術

很多捍衛者認為古老的技術依然很偉大，依然能夠完成任務。因此對於為什麼要重寫程式碼表示疑慮重重。

他們想得沒錯，但他們忘記了保持這些古老程式碼的成本。所有一切通常都需要用自定義程式碼進行翻譯。某些程式碼甚至寫在ASCII之前，這意味著需要轉換輸入和輸出。舊系統經常會計數空格字元只是為了在資料庫中指出這是什麼。這就更加需要轉換了。

當然程式設計師可以透過螢幕抓取，重新格式化，臨時構建系統來做大量的工作，但一段時間以後，他們往往需要花費更多的工作來清理混沌的邏輯，以致於騰不出時間來寫新的邏輯。

程式設計效率障礙No.15：對最新的渴望

最新的工具自然有意思，但卻在沒有經過大量時間再次編碼以往的工作之前，是不會被開發工作室採用的。走在時代尖端的人總是會扔掉API的整個部分，並重新編寫，從而迫使我們這些下游的程式設計師不得不跟著一起改寫程式碼。我厭煩過，當我不得盡力用Python 2.7的程式碼對付Python 3.0的程式碼時，因為依現在的情況，Python已經是一種相對穩定的程式碼庫。

在許多情況下，新的工具並沒有戰鬥化。例如，Node.js，雖然說相當快，但是隻有當你重新學習所有關於死鎖的經驗教訓之後，知道執行緒優先的時候才能發揮作用。世上沒有免費的午餐，工具雖好但都是有代價的。