沒有人滿意開發(fā)人員這種已經(jīng)“竭盡全力”改變世界的速度，每個(gè)人都希望代碼像消防水管里的水一樣能夠源源不斷地流出來，但沒有人愿意提供給開發(fā)人員更好地完成工作的條件。正如那個(gè)想要我們昨天就完成工作的老板，他不愿意雇傭更多的人，不愿意購買速度更快的機(jī)器，也不愿意做任何其他可以讓程序員專注于編程的事情，又想馬兒跑，又不給馬兒吃草。

下面就是現(xiàn)實(shí)世界中的15個(gè)編程障礙。

編程效率障礙No.1：會議

最常見的抱怨是打斷開發(fā)人員編碼思緒的會議。如果老板信任該程序員，就會要求他們時(shí)不時(shí)地去那間數(shù)周甚至數(shù)年昏昏暗暗的會議室閑聊有關(guān)細(xì)節(jié)。盡管程序員通常歸咎于是管理人員毀了會議，但他們偶爾也會指責(zé)其他的程序員老是跑過來詢問有關(guān)或bug或功能或架構(gòu)策略的問題。

雖然有些抱怨是愚蠢的——但程序員依然會埋怨，如果老板讓他們自己在黑暗中摸索，沒有一點(diǎn)溝通——任他們自己在軟件的抽象世界里埋頭苦干，自己去面對各種困境?？觳蛷N師和咖啡調(diào)配師或許還能夠兼顧不同的需求，但如果是切換大腦到正確的模式來操作抽象算法則通常需要時(shí)間。從會議模式中切換回編碼模式，可能會浪費(fèi)一個(gè)小時(shí)左右的工作時(shí)間。

編程效率障礙No.2：答復(fù)所有的電子郵件

如果說會議很糟糕，那么這一種可能更糟糕：需要查看發(fā)來的無窮無盡的郵件?；貜?fù)郵件需要時(shí)間，而且沒人會對回復(fù)結(jié)果表示滿意。然后那些最不耐煩的開發(fā)人員或許會選擇簡單的回復(fù)——“tl;dr”（即too long，didn’t read。篇幅過長，沒有閱讀）。

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

編程效率障礙No.3：試圖衡量生產(chǎn)力

總會有管理團(tuán)隊(duì)受那些所謂“你不能管理你無法衡量的東西”的書籍啟發(fā)，于是開始衡量提交的或代碼庫或軟件代碼行或bug修復(fù)。他們認(rèn)為，計(jì)數(shù)就是衡量，而且衡量一定是好事。

但是程序員并不是砌磚工，不能數(shù)數(shù)砌了多少磚就知道其效率。相反，為了寫出更好的代碼，程序員需要或?qū)Ｗ⒂诰帉懙拇a行，或解決bug，或提交到代碼倉庫，或做一些無法計(jì)數(shù)的事情。如果bug修復(fù)可以加分，那么一些微小bug的報(bào)告就會激增，bug修復(fù)也會如此。有人因?yàn)閳?bào)告bug得到了獎(jiǎng)勵(lì)，然后另一個(gè)人因?yàn)樾迯?fù)它也能得到獎(jiǎng)勵(lì)?；蛘?，如果是計(jì)數(shù)代碼行數(shù)，那么那些可以用10行代碼解決問題的程序員，可能就會轉(zhuǎn)而表示5000行的代碼將更靈活或功能更兼容——任何可以添加到5000行中的都加進(jìn)去。

衡量效率實(shí)際上會因?yàn)楣膭?lì)功能豐富，代碼過度設(shè)計(jì)的長文件，而讓代碼庫變得更糟。

對于此問題還沒有真正的解決方法。我們需要跟蹤bug。我們需要組織工作流程，協(xié)調(diào)軟件的創(chuàng)建。這種優(yōu)雅是無法衡量的。

編程效率障礙No.4：妄自尊大的開發(fā)人員

對于程序員而言，有這樣一個(gè)同事比Boss更難以忍受：創(chuàng)建了代碼的最后一次迭代，卻不再工作于這個(gè)項(xiàng)目。正如每個(gè)房屋裝修承包商會貶低上一個(gè)木匠的技能，每個(gè)程序員也會快速指出可怕的，不可原諒的，完全是死腦筋的上一代的行為。

當(dāng)然，這可能是事實(shí)，但它很少像程序員說得那么糟糕。如果有什么區(qū)別的話，問題通常也不是由于技能匱乏而引起的。主要還是風(fēng)格的不同，并且風(fēng)格還會隨著時(shí)間而改變。上一代和我們今天訪問的庫不同。他們也不曾閱讀過有關(guān)最佳做法的最新著作。

妄自尊大的編程態(tài)度往往會減緩項(xiàng)目。驕傲和利己主義的混合發(fā)酵會導(dǎo)致程序員拋棄完全能夠勝任的代碼，只為了按照他們認(rèn)為的“正確方式”重建。

編程效率障礙No.5：“以后修復(fù)”的思維定式，又名“技術(shù)債”

我們總感覺不夠時(shí)間在項(xiàng)目中按計(jì)劃構(gòu)建我們想要構(gòu)建的東西。于是，我們偷工減料，給代碼打補(bǔ)丁，纏滿了虛擬膠帶。曾有明智的經(jīng)理將此稱為是“技術(shù)債”，因?yàn)椤皞笔且院蟊仨氁€的。即使他們不理解代碼，也知道“債”的含義。

每個(gè)項(xiàng)目都有一定的技術(shù)債務(wù)。有時(shí)它會快速見效，但通常直到下一代才會發(fā)現(xiàn)這已經(jīng)成為了一個(gè)坑。他們需要構(gòu)建上一代沒有做到的東西。就像滾雪球一樣，越滾越大。

編程效率障礙No.6：非程序員經(jīng)理

總會有那些面帶微笑，西裝筆挺，卻不是主修計(jì)算機(jī)科學(xué)，也不懂編程項(xiàng)目的家伙成為了經(jīng)理。也許他們?nèi)⒘死习宓呐畠?；也許他們正好在“正確”的時(shí)間出現(xiàn)在了“正確”的地方。但是，老板讓他們擔(dān)任了經(jīng)理，即使他們一竅不通。更糟的是，他們會用外行人的眼光來看待問題，哪怕不倫不類，文不對題。

有一些程序員表示很歡迎這樣的經(jīng)理，因?yàn)橛夼麄兒苋菀?。而且他們還承擔(dān)了來自于更高管理層的炮火。但也有人承認(rèn)，這些人只會不斷地開會，只會妨礙編程。他們幾乎給不了任何有用的指導(dǎo)，他們可以提供的只是那么一點(diǎn)質(zhì)量檢測。

編程效率障礙No.7：程序員經(jīng)理

雖然程序員可能會因?yàn)椴坏貌慌c非程序員經(jīng)理打交道而抱怨，但他們經(jīng)常悄悄地表示，編程人員去做管理人員更糟糕——有時(shí)甚至更糟糕得多。

他們是前任的天才，可能會決定微觀管理項(xiàng)目，然后果決地撕裂大片的代碼，因?yàn)樗麄冇辛艘粋€(gè)新的展望?；蛘撸苍S他們會閑談，對于同樣的事情，他們是如何用8080匯編或C或Java編程寫了一半的代碼。在任何情況下，他們更癡迷于技術(shù)細(xì)節(jié)而不是大局，雖然他們被雇來的目的是盯牢后者。

編程效率障礙No.8：善于社交的程序員，又名“brogrammer”

雖然程序員可以將每個(gè)問題和任何中斷的責(zé)任歸咎于巧言令色的銷售團(tuán)隊(duì)，但編程人員也必須承認(rèn)，有一些問題在于他們自己。程序員被聘請的目的在于他們的計(jì)算機(jī)技術(shù)，而不是他們的人際交往能力。

程序員通常不善于溝通，不知道如何表達(dá)他們的感受和思維。他們可以準(zhǔn)確抓住技術(shù)參數(shù)，就像庖丁解牛一樣迎刃有余。無論客戶想要改變什么都不要緊：程序員總是時(shí)刻思索著技術(shù)參數(shù)，即使是在公司野餐上也不外如是。

盡管程序員通?？梢赃^濾掉對方的特質(zhì)，但當(dāng)程序員之間發(fā)生磕磕絆絆時(shí)也會讓團(tuán)隊(duì)失敗。當(dāng)同一個(gè)團(tuán)隊(duì)中兩個(gè)人有著不同的政治觀點(diǎn)，比方說，動(dòng)態(tài)語言或NoSQL，那么團(tuán)隊(duì)就會永無寧日。一切都像是在戰(zhàn)場一樣，戰(zhàn)火紛飛，硝煙彌漫。

編程效率障礙No.9：自私或牛仔程序員

你從他的代碼里發(fā)現(xiàn)一個(gè)空指針？捕捉空指針于是成為了你的工作。你最好多想一遍要不要傳遞一個(gè)零，因?yàn)樽运降某绦騿T不會檢查除以零錯(cuò)誤。這也成為了你的工作。

牛仔程序員的工作又酷又快，但這是因?yàn)樗拇a中遺留了許多漏洞，并且沒有經(jīng)過測試。于是這也成為了你的工作，因?yàn)槿绻悴惶幚磉@些瑣事的話，代碼就會崩潰。

很多團(tuán)隊(duì)在最終認(rèn)識到這一點(diǎn)的時(shí)候已經(jīng)為時(shí)已晚。代碼塊在早期測試中運(yùn)行良好，但當(dāng)輸入真正的數(shù)據(jù)之后，各種問題就開始暴露出來。真是一場災(zāi)難。

編程效率障礙No.10：可憐的文檔

寫文檔需要時(shí)間。但由于老板雇我們來是來寫代碼的，并且通常通過我們寫的代碼行數(shù)來衡量我們的效率。因此既然你想要結(jié)果，那么我們就只做你想要的那部分。當(dāng)然最終我們還是會寫文檔的，但質(zhì)量的好壞就不論了。

有時(shí)候，文檔雖然很多，但卻是幾個(gè)月或幾年前老代碼的版本。我們只是還沒來得及修改這些舊文檔而已，但是，以后我們會同步的——相信我。

編程效率障礙No.11：成為文檔的奴隸

雖然我們都經(jīng)歷過沒有文檔的項(xiàng)目，但是空話太多、編碼太少反而導(dǎo)致項(xiàng)目失敗也很常見。曾有幾個(gè)人指著滿滿一書架的文件夾，向我炫耀說：“我專門請人來寫文檔?！比欢x完這么多文檔需要一年的時(shí)間。

程序員通常在處理需求時(shí)，會寫一些評論和注釋，之后充作文檔。因此這樣的文檔，都是一些微小的細(xì)節(jié)，沒有經(jīng)過認(rèn)真地總結(jié)或沒有說到要點(diǎn)上。這在文檔中將可能是致命的，當(dāng)他們沒有提供太多的抽象和理解，就只寫代碼流水賬的時(shí)候。這樣的文檔并不具啟發(fā)性，只是翻譯下代碼而已。

編程效率障礙No.12：很容易導(dǎo)致分心的環(huán)境

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

雖然銷售和營銷團(tuán)隊(duì)可以在背景噪音的環(huán)境下茁壯成長，但程序員通常需要圖書館般安靜的背景。閑聊，令人心煩意亂的敲擊聲，或鈴聲將驅(qū)逐程序員的思維走出抽象的工作區(qū)，回到現(xiàn)實(shí)中。然后，需要幾分鐘的時(shí)間才能重新沉浸于工作區(qū)。

有一位開發(fā)人員告訴我，他恨他的新辦公桌，因?yàn)樗繑n空調(diào)出風(fēng)口，噪音令人難以置信的響，使得他真的很難集中注意力。這可能略有夸張，但的確是一個(gè)事實(shí)。

雖然許多企業(yè)會提供程序員類似乒乓球桌的娛樂活動(dòng)，但他們往往忘記了開發(fā)人員需要在安靜的氛圍中集中精神。甚至，他們還將程序員轉(zhuǎn)移到大房間，認(rèn)為這可以促進(jìn)合作，殊不知卻會導(dǎo)致一有風(fēng)吹草動(dòng)，整個(gè)房間的程序員都受到干擾。

編程效率障礙No.13：“文化契合”

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

如果團(tuán)隊(duì)成員之間的風(fēng)格相似。那么這支團(tuán)隊(duì)往往才能更好地工作。無法找到共同點(diǎn)的團(tuán)隊(duì)很快就會失敗。沒有溝通，最后只會南轅北轍，不知所謂。

編程效率障礙No.14：死守傳統(tǒng)技術(shù)

很多捍衛(wèi)者認(rèn)為古老的技術(shù)依然很偉大，依然能夠完成任務(wù)。因此對于為什么要重寫代碼表示疑慮重重。

他們想得沒錯(cuò)，但他們忘記了保持這些古老代碼的成本。所有一切通常都需要用自定義代碼進(jìn)行翻譯。某些代碼甚至寫在ASCII之前，這意味著需要轉(zhuǎn)換輸入和輸出。舊系統(tǒng)經(jīng)常會計(jì)數(shù)空格字符只是為了在數(shù)據(jù)庫中指出這是什么。這就更加需要轉(zhuǎn)換了。

當(dāng)然程序員可以通過屏幕抓取，重新格式化，臨時(shí)構(gòu)建系統(tǒng)來做大量的工作，但一段時(shí)間以后，他們往往需要花費(fèi)更多的工作來清理混沌的邏輯，以致于騰不出時(shí)間來寫新的邏輯。

編程效率障礙No.15：對最新的渴望

最新的工具自然有意思，但卻在沒有經(jīng)過大量時(shí)間再次編碼以往的工作之前，是不會被開發(fā)工作室采用的。走在時(shí)代尖端的人總是會扔掉API的整個(gè)部分，并重新編寫，從而迫使我們這些下游的程序員不得不跟著一起改寫代碼。我厭煩過，當(dāng)我不得盡力用Python 2.7的代碼對付Python 3.0的代碼時(shí)，因?yàn)橐垃F(xiàn)在的情況，Python已經(jīng)是一種相對穩(wěn)定的代碼庫。

在許多情況下，新的工具并沒有戰(zhàn)斗化。例如，Node.js，雖然說相當(dāng)快，但是只有當(dāng)你重新學(xué)習(xí)所有關(guān)于死鎖的經(jīng)驗(yàn)教訓(xùn)之后，知道線程優(yōu)先的時(shí)候才能發(fā)揮作用。世上沒有免費(fèi)的午餐，工具雖好但都是有代價(jià)的。

責(zé)任編輯：wv