沒完沒了的大會小會、啥也不懂的直屬領(lǐng)導(dǎo)、流于形式的生產(chǎn)指標(biāo)——正是這冠冕堂皇的一切扼殺了無數(shù)即將誕生的偉大軟件。

[[91638]]

十五大編程生產(chǎn)力殺手

產(chǎn)品本來昨天就應(yīng)該搞定出爐。用戶們怒吼著質(zhì)問為什么其中尚存在功能缺失。老板的老板表示你們這幫開發(fā)人員***快點行動，不然就準(zhǔn)備滾蛋。總之，一切似乎都在朝著最壞的可能發(fā)展。

每個人都希望代碼都像消防帶里的水一樣傾泄而出、酣暢淋漓，但卻沒人愿意為開發(fā)人員提供他們完成工作所需要的一切。沒錯，那些要求提前搞定工作的老板從來不愿意多顧幾位技術(shù)員工、采購性能更強(qiáng)的設(shè)備或者作出哪怕一丁點有利決策，從而幫助程序員們簡化工作流程。

在今天的文章中，我們將一同回顧十五大橫亙于程序員面前的障礙。由于采用非正式調(diào)查形式，因此我們輕松得到了開發(fā)人員們的心聲——帶著同情之心與他們交談，一切不快與委屈將不再是秘密。

[[91639]]

1. 開會

朋友們對哪種狀況抱怨最多？毫無疑問就是沒完沒了的會議。經(jīng)過我們的調(diào)查核實，很多程序員都不得不擠在昏暗的會議室里，呆望頂頭上司閑談那些無關(guān)緊要的細(xì)枝末節(jié)。程序員們一般會把會議失敗的原因歸結(jié)在管理者身上，偶爾也把怨氣與指責(zé)丟向其他在漏洞、功能或者架構(gòu)策略上犯了錯誤的技術(shù)同行。

不過即使是會議確實是在討論軟件抽象世界中的深層難題，程序員們一樣會對此感到不滿?？觳蛷N師也許能夠迅速應(yīng)對各種不同類型的需要，但切換思維方式從而與抽象算法對接則需要預(yù)熱時間——而且會議往往令正常工作受到一小時甚至更長時間的耽擱。

[[91640]]

2. 回復(fù)全部郵件

如果說會議太多令人厭煩，那么另一種狀況則更讓我們難以承受：無窮無盡、洶涌而來的郵件。光是回復(fù)這些郵件就要花上幾個小時，而且不過是對方還是我們自己都無法對郵件的結(jié)果表示滿意。這時，開發(fā)人員們往往會以惡劣的態(tài)度回復(fù)“tl;dr”并產(chǎn)生某種奇特的自豪感。

某些團(tuán)隊正在嘗試每周選擇一天禁止郵件流通，另一些更加堅決的朋友則主張徹底告別郵件。這雖然解決了處理內(nèi)容過多的問題，但卻同時提高了通信成本。如果人們忽然之間就失去了協(xié)作的紐帶，這從任何角度來看都不是什么好事。

[[91641]]

#p#

3. 試圖衡量生產(chǎn)指標(biāo)

似乎總有管理團(tuán)隊盲目遵從這樣一條格言，“你無法管理自己不能衡量的事物”。好吧，他們開始不斷統(tǒng)計提交量、軟件代碼行或者漏洞修復(fù)數(shù)。他們以為這種數(shù)字統(tǒng)計就是衡量，而衡量意味著良好的結(jié)果。

不過程序員們都是出色的游戲玩家，而生產(chǎn)力衡量指標(biāo)則成為他們的追求的分?jǐn)?shù)排行榜。在這種機(jī)制的推動下，他們不再將編寫優(yōu)質(zhì)代碼作為***要務(wù)，反而專注于編寫盡可能多的代碼行、解決更多漏洞、***程度增加提交量或者其它任何能夠被計入績效的工作。事實證明，衡量生產(chǎn)力指標(biāo)確實會讓代碼質(zhì)量變得更糟——這相當(dāng)于鼓勵大家開發(fā)出體積龐大且塞滿功能的文件，其中遍布被過度設(shè)計的代碼。

對于這一難題，目前還沒有切實有效的解決辦法。我們需要追蹤漏洞、我們需要組織工作流同時協(xié)調(diào)軟件創(chuàng)建。這一切都是只可意會而無法言傳的任務(wù)，根本不能簡單用數(shù)字加以評估。

[[91642]]

4. 過分自戀的開發(fā)者

對于程序員們來說，除了老板之外、另一類同行也是他們打壓的重點——即那些創(chuàng)建出***一套迭代就不再負(fù)責(zé)對應(yīng)項目的開發(fā)者。正如每次找來的家裝設(shè)計師都會對原先屋子里的工程不屑一顧，程序員們也有能力快速發(fā)現(xiàn)前任技術(shù)工作者犯下的腦殘失誤。

事實上，程序員的表達(dá)方式幾乎要比任何其他行業(yè)的繼任者都更為激烈。這往往與兩代技術(shù)人員的技能水平無關(guān)，他們只不過偏好不同的開發(fā)風(fēng)格，而且隨著時間的推移、風(fēng)格也會有所變化。上一代程序員可能并不具備我們當(dāng)下所擁有的代碼庫，也并不了解如今已經(jīng)成為***實踐的解決方案。

這種極度自戀、抨擊他人的態(tài)度會拖慢項目進(jìn)程，因為他們會由于沖動而丟棄大量代碼、從而按照自己的想法“從頭開始”重新構(gòu)建整個項目。

[[91643]]

5. “稍后修復(fù)”心態(tài)，或者叫“技術(shù)債務(wù)”

在項目開發(fā)工作當(dāng)中，沒有一天或者沒有任何一個階段能真正為我們提供充裕的時間——需要創(chuàng)建的內(nèi)容總是多到幾乎無法承受。在這樣的狀況下，我們往往會偷工減料、提供代碼補(bǔ)丁并利用這種“虛擬膠帶”到處修修補(bǔ)補(bǔ)。睿智的管理者會在對項目進(jìn)行精密審查后將這些工作稱為“技術(shù)債務(wù)”，而“債務(wù)”當(dāng)然是需要償還的。即使對編碼工作一無所知，他們還是能夠弄清“債務(wù)”的概念與影響。

每個項目當(dāng)中都會存在一定的技術(shù)債務(wù)。有時候我們能快速加以解決，但大多數(shù)情況下這些債務(wù)會在繼任者接手后才開始搗亂，迫使他們面對大量意料之外的難題。只有搞定這些遺留問題，項目才能真正順暢運作——這有點像國債，只不過規(guī)模沒那么龐大。

[[91644]]

6. 不懂技術(shù)的管理者

大家在公司里肯定經(jīng)常見到這樣的家伙，他們熱情、積極、面帶微笑，能夠在各個方面表現(xiàn)出友善的態(tài)度——除了與編程項目相關(guān)的計算機(jī)科學(xué)。也許他們是靠裙帶關(guān)系爬上來的，或者是在正確的時間出現(xiàn)在了正確的地方，總之老板讓他們當(dāng)經(jīng)理、負(fù)責(zé)技術(shù)事務(wù)——即使這幫人連自己的黑莓手機(jī)都找不著。

某些程序員喜歡這樣的頂頭上司，因為他們很容易會能被糊弄過去。如果大家告訴他們Johnson DB沒能取得巨大成功，他們往往會信以為真并在公司里到處傳播這個“不幸”的消息——這樣公司高層就會出現(xiàn)收拾這幫外行了。還有些人發(fā)現(xiàn)這類管理者總愛召集會議并妨礙程序員的正常工作。他們幾乎拿不出什么指導(dǎo)建議，最出色的發(fā)揮也就是些略有實效的質(zhì)量測試。

[[91645]]

#p#

7. 懂技術(shù)的管理者

雖然程序員們可能無法忍受與不懂技術(shù)的管理者正面交流，但當(dāng)頂頭上司變成真正的技術(shù)大牛時，情況也許會更糟。

這些曾經(jīng)的技術(shù)天才們可能會從微觀層面著手項目管理，并把整體代碼拆分成一個個零散的部分——理由？因為他們有著自己的見解。再有，他們可能會喋喋不休于如何通過一半的代碼行數(shù)來完成同樣的任務(wù)，并大談他們當(dāng)初在8080、C或者Java編程領(lǐng)域的輝煌歷史。無論如何，他們往往更關(guān)注技術(shù)細(xì)節(jié)而非宏觀形勢，雖然后者才是他們的首要任務(wù)。

[[91646]]

8. 簡單粗暴的程序員

程序員們也承認(rèn)，有些問題確實應(yīng)該歸咎于他們自己。

程序員們往往不擅長溝通，也不太關(guān)注其他人的感受或者對自己的行為加以反省。他們對技術(shù)問題的糾結(jié)程度就像緊盯著骨頭的狗?？蛻魝兿胍裁床⒉恢匾怀绦騿T團(tuán)隊本身就會因為設(shè)計思路分歧而吵得不可開交。

程序員往往會忽略掉不同合作者的個性與特質(zhì)，但如果一個團(tuán)隊中的開發(fā)者全都過于溫順、項目也會陷入失敗。兩個人之間存在不同觀點非常正常，例如同一個團(tuán)隊也可能會在動態(tài)語言和NoSQL之間僵持不下。最終程序員只能以投票的形式解決這類難題——但這并不能從根本上化解危機(jī)。團(tuán)隊內(nèi)部的沖突就像一場百年戰(zhàn)爭，成員們不是正在爭吵就是走在通往爭吵的路上。

[[91647]]

9. 特立獨行的程序員

從他的代碼里找到了為空指針？別想讓他認(rèn)錯，我們只能自己動手修改。再有，大家***在輸入數(shù)字0之前認(rèn)真檢查幾遍，因為這類程序員絕對不會檢查代碼中是否存在除以0這類錯誤。對，這全都是我們自己的工作。

特立獨行的程序員看起來很酷、做起工作也是迅如閃電，但這只是因為他們會把大量漏洞和測試任務(wù)留給其他同事。只有幫他們認(rèn)真做好善后、他們的成果才不至于讓系統(tǒng)陷入崩潰。

很多團(tuán)隊在發(fā)現(xiàn)這種狀況時都已經(jīng)為時過晚。代碼塊在早期測試當(dāng)中運行良好，但在向其中導(dǎo)入真實數(shù)據(jù)后，每個人都發(fā)現(xiàn)其實程序根本沒有經(jīng)過認(rèn)真檢查。啊哦，完蛋了！

[[91648]]

10. 糟糕的文檔說明

我承認(rèn)編寫文檔說明很耗時間，但同志們，這也是有工資可領(lǐng)的啊。很多企業(yè)都會以代碼行數(shù)為依據(jù)核算程序員薪酬，而編寫文檔說明正是賺錢的好機(jī)會。別擔(dān)心，領(lǐng)導(dǎo)會把這些記入績效并按量發(fā)工資的。

有時候文檔說明量實在太大，但這是為了能讓人們在幾個月甚至幾年之后都能順利用上當(dāng)前版本的代碼。哦，我提到這些說明數(shù)據(jù)會被保存在Footable里嗎？這已經(jīng)是前數(shù)兩代的開發(fā)方式了，而且我也沒時間重新捋順這些代碼并對陳舊說明加以修正。不過這只是遲早的事情，躲不掉的。

[[91649]]

#p#

11. 盲目提交說明文檔

雖然缺少文檔說明的項目讓人血壓上升，但那些空話太多而代碼太少的項目同樣無法獲得成功。在調(diào)查中，確實有受訪者拿出一大堆說明資料并表示“他們就靠這些文檔獲取報酬。”光是讀這些說明就得花上一年。

程序員常常被要求就項目本身撰寫評論，就像是根據(jù)《太空堡壘卡拉狄加》或者《神秘博士》編寫觀后感。這類資料往往缺乏總結(jié)或者根本沒能抓住要點，而只是沒完沒了地羅列微不足道的細(xì)節(jié)信息。如果文檔不能以抽象形式概括項目作用或者幫助閱讀者理解，那么單純陳述代碼作用只會讓人心生反感。我只能說這么干的家伙根本沒開竅：寫說明不是讓你把代碼翻譯成英文。

[[91650]]

12. 噪雜的環(huán)境令人分心

一位客戶堅持讓我走進(jìn)他們的辦公室并在里面通過一周時間體驗工作狀態(tài)。事實上，這家公司的技術(shù)人員根本沒有自己的辦公空間，因此我不得不跟屋里的六位實習(xí)生打交道，聽他們用半天時間講述頭一天晚上發(fā)生了哪些新鮮事、再用半天時間展望今天晚上要去哪瘋玩。好吧，其實聽聽這些事情也挺有意思，但結(jié)果是我?guī)缀跏裁凑露紱]干成。

程序員通常需要像圖書館一樣的安靜環(huán)境。喋喋不休的談話、令人心煩的敲擊聲或者電話鈴都可能把程序員從抽象的思維活動中揪出來，并狠狠地摔在現(xiàn)實冰冷的地面上。我們往往需要再花幾分鐘讓自己重新進(jìn)入狀態(tài)，這對生產(chǎn)力絕對是種毀滅性打擊。

我的許多企業(yè)希望能用乒乓球桌這樣的娛樂設(shè)施裝點程序員的工作環(huán)境——但他們忘了這種噼噼啪啪的聲音跟開發(fā)者所需要的安靜與集中嚴(yán)重沖突。

[[91651]]

13. “文化契合”

如果每一位成員都擁有類似的工作風(fēng)格，那么整個團(tuán)隊就能運作得更好。而無法快速求同存異的團(tuán)隊則會很快陷入失敗局面。如果成員之間無法有效溝通，那么各自向目標(biāo)邁進(jìn)的狀況將把整個部門五馬分尸。

人們往往能夠輕松勾勒出自己心目中的良好工作環(huán)境，但這其實還是得與團(tuán)隊本身結(jié)合起來才能發(fā)揮效果。在處理底層維護(hù)以及基礎(chǔ)設(shè)施建設(shè)時，即使受到其他人的干擾也沒什么大礙——畢竟這不算什么需要高度集中的工作。當(dāng)我們等待某項建設(shè)工作完成的時候，即使有人在喊大叫也不至于引發(fā)太嚴(yán)重的進(jìn)度中斷。畢竟我們同處一個團(tuán)隊之下，互相喊一喊既能提高效率又能緩和氣氛。

不過如果大家正在創(chuàng)建一套復(fù)雜的算法，而其中的組件又處于不斷變化當(dāng)中，那么任何談話、走動乃至鍵盤敲擊都可能讓我們偏離思路軌道。在這種情況下，擁有自己的辦公室是***的辦法。

[[91652]]

14. 執(zhí)著于傳統(tǒng)技術(shù)

如果大家在Dice.com網(wǎng)站上查找與Cobol相關(guān)的崗位，會發(fā)現(xiàn)列表中竟然擁有680個結(jié)果——相較于網(wǎng)站上的七萬多個招聘崗位總量，其比例接近1%。擁護(hù)者們堅持認(rèn)為這是一項卓越的技術(shù)，完全能夠勝任目前的工作需要。為什么要重新改寫已經(jīng)成熟的解決方案？

這樣的說法雖然不是毫無道理，但他們忽略了一大事實——沿用陳舊代碼是會帶來額外成本的。其中所有內(nèi)容都需要經(jīng)過翻譯，而翻譯過程往往需要借助定制代碼。其中一部分代碼甚至寫于ASCII誕生之前，這意味著連輸入與輸出內(nèi)容都可能需要轉(zhuǎn)換。陳舊系統(tǒng)在檢查數(shù)據(jù)庫內(nèi)容時通常會把空格計算進(jìn)來，要排除這些干擾需要更多轉(zhuǎn)換過程。

程序員們在屏幕截取、重新格式化以及臨時性系統(tǒng)對接方面表現(xiàn)出色，但在一段時間之后，他們往往會把主要精力放在更新膠合邏輯而非編寫新邏輯方面。

[[91653]]

15. 過分追求******的技術(shù)

我們都跟某位仁兄打過交道，在他眼中Java就是“我爺爺才愛用的編程語言”。而Node.js——這才是201x年的風(fēng)格。

***的工具用起來當(dāng)然很有樂趣，但如果不認(rèn)真對之前一段時間的工作進(jìn)行備份、我們根本不敢把它們直接引入工作環(huán)境。走在技術(shù)前沿的人們總愛全盤否定API整體并加以重寫，這就迫使下游開發(fā)者不得不隨之重寫自己的代碼。

在很多情況下，新型工具并沒有經(jīng)過時間的檢驗。Node.js確實能帶來令人驚訝的速度表現(xiàn)，但前提是我們得重新了解死鎖機(jī)制，這將迫使人們首先創(chuàng)建新的線程。通常來說，前沿方案相當(dāng)于以偷工減料的方式為使用者帶來看似很美的結(jié)果——也許不會出問題、但也有可能讓之前的心血付之一炬。
 

原文鏈接：http://www.infoworld.com/slideshow/129821/the-15-worst-ways-kill-programming-productivity-231450#slide1