十五種糟糕方式讓編程生產力跌入谷底
譯文沒完沒了的大會小會、啥也不懂的直屬領導、流于形式的生產指標——正是這冠冕堂皇的一切扼殺了無數即將誕生的偉大軟件。
十五大編程生產力殺手
產品本來昨天就應該搞定出爐。用戶們怒吼著質問為什么其中尚存在功能缺失。老板的老板表示你們這幫開發人員***快點行動，不然就準備滾蛋。總之，一切似乎都在朝著最壞的可能發展。
每個人都希望代碼都像消防帶里的水一樣傾泄而出、酣暢淋漓，但卻沒人愿意為開發人員提供他們完成工作所需要的一切。沒錯，那些要求提前搞定工作的老板從來不愿意多顧幾位技術員工、采購性能更強的設備或者作出哪怕一丁點有利決策，從而幫助程序員們簡化工作流程。
在今天的文章中，我們將一同回顧十五大橫亙于程序員面前的障礙。由于采用非正式調查形式，因此我們輕松得到了開發人員們的心聲——帶著同情之心與他們交談，一切不快與委屈將不再是秘密。
1. 開會
朋友們對哪種狀況抱怨最多？毫無疑問就是沒完沒了的會議。經過我們的調查核實，很多程序員都不得不擠在昏暗的會議室里，呆望頂頭上司閑談那些無關緊要的細枝末節。程序員們一般會把會議失敗的原因歸結在管理者身上，偶爾也把怨氣與指責丟向其他在漏洞、功能或者架構策略上犯了錯誤的技術同行。
不過即使是會議確實是在討論軟件抽象世界中的深層難題，程序員們一樣會對此感到不滿。快餐廚師也許能夠迅速應對各種不同類型的需要，但切換思維方式從而與抽象算法對接則需要預熱時間——而且會議往往令正常工作受到一小時甚至更長時間的耽擱。
2. 回復全部郵件
如果說會議太多令人厭煩，那么另一種狀況則更讓我們難以承受：無窮無盡、洶涌而來的郵件。光是回復這些郵件就要花上幾個小時，而且不過是對方還是我們自己都無法對郵件的結果表示滿意。這時，開發人員們往往會以惡劣的態度回復“tl;dr”并產生某種奇特的自豪感。
某些團隊正在嘗試每周選擇一天禁止郵件流通，另一些更加堅決的朋友則主張徹底告別郵件。這雖然解決了處理內容過多的問題，但卻同時提高了通信成本。如果人們忽然之間就失去了協作的紐帶，這從任何角度來看都不是什么好事。
#p#
3. 試圖衡量生產指標
似乎總有管理團隊盲目遵從這樣一條格言，“你無法管理自己不能衡量的事物”。好吧，他們開始不斷統計提交量、軟件代碼行或者漏洞修復數。他們以為這種數字統計就是衡量，而衡量意味著良好的結果。
不過程序員們都是出色的游戲玩家，而生產力衡量指標則成為他們的追求的分數排行榜。在這種機制的推動下，他們不再將編寫優質代碼作為***要務，反而專注于編寫盡可能多的代碼行、解決更多漏洞、***程度增加提交量或者其它任何能夠被計入績效的工作。事實證明，衡量生產力指標確實會讓代碼質量變得更糟——這相當于鼓勵大家開發出體積龐大且塞滿功能的文件，其中遍布被過度設計的代碼。
對于這一難題，目前還沒有切實有效的解決辦法。我們需要追蹤漏洞、我們需要組織工作流同時協調軟件創建。這一切都是只可意會而無法言傳的任務，根本不能簡單用數字加以評估。
4. 過分自戀的開發者
對于程序員們來說，除了老板之外、另一類同行也是他們打壓的重點——即那些創建出***一套迭代就不再負責對應項目的開發者。正如每次找來的家裝設計師都會對原先屋子里的工程不屑一顧，程序員們也有能力快速發現前任技術工作者犯下的腦殘失誤。
事實上，程序員的表達方式幾乎要比任何其他行業的繼任者都更為激烈。這往往與兩代技術人員的技能水平無關，他們只不過偏好不同的開發風格，而且隨著時間的推移、風格也會有所變化。上一代程序員可能并不具備我們當下所擁有的代碼庫，也并不了解如今已經成為***實踐的解決方案。
這種極度自戀、抨擊他人的態度會拖慢項目進程，因為他們會由于沖動而丟棄大量代碼、從而按照自己的想法“從頭開始”重新構建整個項目。
5. “稍后修復”心態，或者叫“技術債務”
在項目開發工作當中，沒有一天或者沒有任何一個階段能真正為我們提供充裕的時間——需要創建的內容總是多到幾乎無法承受。在這樣的狀況下，我們往往會偷工減料、提供代碼補丁并利用這種“虛擬膠帶”到處修修補補。睿智的管理者會在對項目進行精密審查后將這些工作稱為“技術債務”，而“債務”當然是需要償還的。即使對編碼工作一無所知，他們還是能夠弄清“債務”的概念與影響。
每個項目當中都會存在一定的技術債務。有時候我們能快速加以解決，但大多數情況下這些債務會在繼任者接手后才開始搗亂，迫使他們面對大量意料之外的難題。只有搞定這些遺留問題，項目才能真正順暢運作——這有點像國債，只不過規模沒那么龐大。
6. 不懂技術的管理者
大家在公司里肯定經常見到這樣的家伙，他們熱情、積極、面帶微笑，能夠在各個方面表現出友善的態度——除了與編程項目相關的計算機科學。也許他們是靠裙帶關系爬上來的，或者是在正確的時間出現在了正確的地方，總之老板讓他們當經理、負責技術事務——即使這幫人連自己的黑莓手機都找不著。
某些程序員喜歡這樣的頂頭上司，因為他們很容易會能被糊弄過去。如果大家告訴他們Johnson DB沒能取得巨大成功，他們往往會信以為真并在公司里到處傳播這個“不幸”的消息——這樣公司高層就會出現收拾這幫外行了。還有些人發現這類管理者總愛召集會議并妨礙程序員的正常工作。他們幾乎拿不出什么指導建議，最出色的發揮也就是些略有實效的質量測試。
#p#
7. 懂技術的管理者
雖然程序員們可能無法忍受與不懂技術的管理者正面交流，但當頂頭上司變成真正的技術大牛時，情況也許會更糟。
這些曾經的技術天才們可能會從微觀層面著手項目管理，并把整體代碼拆分成一個個零散的部分——理由？因為他們有著自己的見解。再有，他們可能會喋喋不休于如何通過一半的代碼行數來完成同樣的任務，并大談他們當初在8080、C或者Java編程領域的輝煌歷史。無論如何，他們往往更關注技術細節而非宏觀形勢，雖然后者才是他們的首要任務。
8. 簡單粗暴的程序員
程序員們也承認，有些問題確實應該歸咎于他們自己。
程序員們往往不擅長溝通，也不太關注其他人的感受或者對自己的行為加以反省。他們對技術問題的糾結程度就像緊盯著骨頭的狗。客戶們想要什么并不重要；程序員團隊本身就會因為設計思路分歧而吵得不可開交。
程序員往往會忽略掉不同合作者的個性與特質，但如果一個團隊中的開發者全都過于溫順、項目也會陷入失敗。兩個人之間存在不同觀點非常正常，例如同一個團隊也可能會在動態語言和NoSQL之間僵持不下。最終程序員只能以投票的形式解決這類難題——但這并不能從根本上化解危機。團隊內部的沖突就像一場百年戰爭，成員們不是正在爭吵就是走在通往爭吵的路上。
9. 特立獨行的程序員
從他的代碼里找到了為空指針？別想讓他認錯，我們只能自己動手修改。再有，大家***在輸入數字0之前認真檢查幾遍，因為這類程序員絕對不會檢查代碼中是否存在除以0這類錯誤。對，這全都是我們自己的工作。
特立獨行的程序員看起來很酷、做起工作也是迅如閃電，但這只是因為他們會把大量漏洞和測試任務留給其他同事。只有幫他們認真做好善后、他們的成果才不至于讓系統陷入崩潰。
很多團隊在發現這種狀況時都已經為時過晚。代碼塊在早期測試當中運行良好，但在向其中導入真實數據后，每個人都發現其實程序根本沒有經過認真檢查。啊哦，完蛋了！
10. 糟糕的文檔說明
我承認編寫文檔說明很耗時間，但同志們，這也是有工資可領的啊。很多企業都會以代碼行數為依據核算程序員薪酬，而編寫文檔說明正是賺錢的好機會。別擔心，領導會把這些記入績效并按量發工資的。
有時候文檔說明量實在太大，但這是為了能讓人們在幾個月甚至幾年之后都能順利用上當前版本的代碼。哦，我提到這些說明數據會被保存在Footable里嗎？這已經是前數兩代的開發方式了，而且我也沒時間重新捋順這些代碼并對陳舊說明加以修正。不過這只是遲早的事情，躲不掉的。
#p#
11. 盲目提交說明文檔
雖然缺少文檔說明的項目讓人血壓上升，但那些空話太多而代碼太少的項目同樣無法獲得成功。在調查中，確實有受訪者拿出一大堆說明資料并表示“他們就靠這些文檔獲取報酬。”光是讀這些說明就得花上一年。
程序員常常被要求就項目本身撰寫評論，就像是根據《太空堡壘卡拉狄加》或者《神秘博士》編寫觀后感。這類資料往往缺乏總結或者根本沒能抓住要點，而只是沒完沒了地羅列微不足道的細節信息。如果文檔不能以抽象形式概括項目作用或者幫助閱讀者理解，那么單純陳述代碼作用只會讓人心生反感。我只能說這么干的家伙根本沒開竅：寫說明不是讓你把代碼翻譯成英文。
12. 噪雜的環境令人分心
一位客戶堅持讓我走進他們的辦公室并在里面通過一周時間體驗工作狀態。事實上，這家公司的技術人員根本沒有自己的辦公空間，因此我不得不跟屋里的六位實習生打交道，聽他們用半天時間講述頭一天晚上發生了哪些新鮮事、再用半天時間展望今天晚上要去哪瘋玩。好吧，其實聽聽這些事情也挺有意思，但結果是我幾乎什么正事都沒干成。
程序員通常需要像圖書館一樣的安靜環境。喋喋不休的談話、令人心煩的敲擊聲或者電話鈴都可能把程序員從抽象的思維活動中揪出來，并狠狠地摔在現實冰冷的地面上。我們往往需要再花幾分鐘讓自己重新進入狀態，這對生產力絕對是種毀滅性打擊。
我的許多企業希望能用乒乓球桌這樣的娛樂設施裝點程序員的工作環境——但他們忘了這種噼噼啪啪的聲音跟開發者所需要的安靜與集中嚴重沖突。
13. “文化契合”
如果每一位成員都擁有類似的工作風格，那么整個團隊就能運作得更好。而無法快速求同存異的團隊則會很快陷入失敗局面。如果成員之間無法有效溝通，那么各自向目標邁進的狀況將把整個部門五馬分尸。
人們往往能夠輕松勾勒出自己心目中的良好工作環境，但這其實還是得與團隊本身結合起來才能發揮效果。在處理底層維護以及基礎設施建設時，即使受到其他人的干擾也沒什么大礙——畢竟這不算什么需要高度集中的工作。當我們等待某項建設工作完成的時候，即使有人在喊大叫也不至于引發太嚴重的進度中斷。畢竟我們同處一個團隊之下，互相喊一喊既能提高效率又能緩和氣氛。
不過如果大家正在創建一套復雜的算法，而其中的組件又處于不斷變化當中，那么任何談話、走動乃至鍵盤敲擊都可能讓我們偏離思路軌道。在這種情況下，擁有自己的辦公室是***的辦法。
14. 執著于傳統技術
如果大家在Dice.com網站上查找與Cobol相關的崗位，會發現列表中竟然擁有680個結果——相較于網站上的七萬多個招聘崗位總量，其比例接近1%。擁護者們堅持認為這是一項卓越的技術，完全能夠勝任目前的工作需要。為什么要重新改寫已經成熟的解決方案？
這樣的說法雖然不是毫無道理，但他們忽略了一大事實——沿用陳舊代碼是會帶來額外成本的。其中所有內容都需要經過翻譯，而翻譯過程往往需要借助定制代碼。其中一部分代碼甚至寫于ASCII誕生之前，這意味著連輸入與輸出內容都可能需要轉換。陳舊系統在檢查數據庫內容時通常會把空格計算進來，要排除這些干擾需要更多轉換過程。
程序員們在屏幕截取、重新格式化以及臨時性系統對接方面表現出色，但在一段時間之后，他們往往會把主要精力放在更新膠合邏輯而非編寫新邏輯方面。
15. 過分追求******的技術
我們都跟某位仁兄打過交道，在他眼中Java就是“我爺爺才愛用的編程語言”。而Node.js——這才是201x年的風格。
***的工具用起來當然很有樂趣，但如果不認真對之前一段時間的工作進行備份、我們根本不敢把它們直接引入工作環境。走在技術前沿的人們總愛全盤否定API整體并加以重寫，這就迫使下游開發者不得不隨之重寫自己的代碼。
在很多情況下，新型工具并沒有經過時間的檢驗。Node.js確實能帶來令人驚訝的速度表現，但前提是我們得重新了解死鎖機制，這將迫使人們首先創建新的線程。通常來說，前沿方案相當于以偷工減料的方式為使用者帶來看似很美的結果——也許不會出問題、但也有可能讓之前的心血付之一炬。
