[[81633]]

1.地獄性的安全問題

McAfee代理禁止使用HelloWorld.java的Zip文件，這意味著禁止從該文件中下載任何構建工具的樣例。McAfee desfktop為了防止惡意代碼的出現(xiàn)而掃描每個文件進程，即使這些文件以單線程模式掃描之后未發(fā)生任何改變，也就是說成千上萬個文件的所有內(nèi)容都需要通過CPU這個核心處理器操作處理。CPU需要花費30分鐘啟動IDE，再花費10分鐘啟動一個構架。

2.酷刑工具

Subversion和 Git兩個版本控制系統(tǒng)的存在，讓所有其他版本控制/配置管理工具運行的很慢/或很痛苦。ClearCase工具是所有開發(fā)人員公認的酷刑工具的始祖。

3.維護團隊

目前，依然有些地方存在固定的團隊，他們做著自己厭煩的工作。嚴重地說，但凡他們能找到一個稍微好點的工作都會離開“維護團隊”。

4.強迫使用Windows

強迫你的開發(fā)人員使用Windows開發(fā)環(huán)境很扯淡，而且，對于非技術性用戶運行項目也會有很多的限制。

5.遠離類庫

多年以前，我還在IBM工作，當時被告知不要使用第三方庫（無論是否開源），除非該庫能幫助自己節(jié)約至少兩個月的開發(fā)時間，這是因為使用第三方庫需要律師的審核，而審核這一切花費的時間可能會超過所需的兩個月。你需要一項政策，規(guī)定在何處如何使用庫，而無需通過正式的審批程序。否則，你犯了侵權行為，迫使你的項目重新開始。

6.WebSphere

WebSphere在使用過程中總是出問題，令開發(fā)人員深惡痛絕，所以盡可能不要安裝使用。

7.持續(xù)編程至“死”

如果迫使開發(fā)人員一成不變進展項目，會讓他們感到崩潰。同時，他們也會感覺自己好像是紙片和膠帶一樣總黏在一起。短期不是問題，如果每個周末都要整理一大堆困境，這顯然沒人愿意做。相反，讓開發(fā)人員用較少的時間，效果則會有更好的改善。

8.2010年是個好年頭，但已經(jīng)過去了

你以為標準化的“老爺版”開發(fā)環(huán)境配置能固住一個程序員，就一直讓他們使用已經(jīng)用了三、四年的IDE，跑在過時的Windows上？別天真了。在激烈競爭的時代，有人會出更大的價錢和更新的工具吸引他們加盟。

9.成為重復編碼的機器

我很同情你討厭 HipsterHacker構架。你不想一個系統(tǒng)被完全的開發(fā)成“看起來很炫，我要下載”。另一方面，讓開發(fā)人員編寫同樣的沒有任何創(chuàng)新思想的代碼，會讓他們思考自己的職業(yè)生涯。綜上所述，讓開發(fā)人員不斷接觸新的東西，進入一個穩(wěn)定構架來緩解風險。

10.無止境虛擬化導致漏洞百出

如果你的公司完全是虛擬的，甚至開發(fā)環(huán)境也是虛擬的。由于硬件資金不足或者沒有協(xié)調(diào)好等原因，而導致一切進程都慢下來，這是很可怕的折磨。有些人是禪宗，不在乎用兩個小時來構建這個過程，而我并不是其中的一員。

11.該死的Scrum每日站立會議

有一個最遭罪的會議被稱為Scrum每日站立會議，會議是為了更新管理的狀態(tài)，每個人都被迫發(fā)言至少五到六分鐘，除了傳達出他們自己工作的內(nèi)容和應該保持現(xiàn)有狀態(tài)外，并不能傳達重要的建設意見。實際上，會議只需他們其中的12個或更多的人，絕大多數(shù)的人可以不必參與。會議進行到30~45分鐘甚至更長時間時，不發(fā)言的人漸漸的都昏昏沉沉的。更糟糕的是，開會之前沒有人準備關于會議的內(nèi)容，因為大家都知道會議的流程。會議結束后，午餐至少要一個小時，就這樣，會議讓你的團隊浪費了整個上午時間，最后一事無成。

12.形式主義

形式主義勝出穿上一套套裝，它可能以意想不到的方式出現(xiàn)。很有諷刺意味的來說，由于制定了標準規(guī)則，寬松的工作環(huán)境對于開發(fā)人員來說是比較困難的，同時，開發(fā)人員也很努力的反對這種正式的工作環(huán)境。寬松的環(huán)境，實際上，也是一個多元化人工合成的環(huán)境。由于某種形式的存在而強迫開發(fā)人員按照規(guī)則去做事情，是對開發(fā)人員思想和精神上的一種虐待。

13.危機管理

有時一個負載測試也會失敗，而管理人員也想了解失敗的根本原因，并得到解決方案。他們甚至不顧一切的恢復到之前狀態(tài)，這是檢查偏離軌道發(fā)展過程一個很好的路徑。管理人員不但有權打斷實施和測試的正常迭代過程，而且使開發(fā)人員不敢嘗試任何新的東西，并對此投入多余的注意力。他們并不了解相關的功能，卻采用威脅和直接的破壞性的行為解決問題，充其量也就是把產(chǎn)品推出來而已。

14.吹毛求疵

如果說某人發(fā)現(xiàn)一個流氓機器，正試圖用它連接Skype上受限制的端口。對此，開發(fā)人員并沒有留意到，這已然觸犯了規(guī)則。然而，當被問及有關指導說明時，他提供不出詳細的說明。開發(fā)人員會因為開發(fā)項目過程中出現(xiàn)的含糊不清、無證限制等原因而被處罰。這些都是管理人員尋找漏洞問題的一個最容易的突破點。

15.細節(jié)！細節(jié)！

一位頭發(fā)豎起的老板：‘’客戶需要一個扭曲功能，你能及時添加實現(xiàn)嗎？“
編碼人員：”不能。這將需要主體架構的改變。在項目啟動之前，我們就詢問過，而且當時被告知盡可能的不會花時間做擴展功能。“
項目啟動之前，寫在需求評估表中的需求量很少，這讓了開發(fā)人員采取更捷徑的方法開發(fā)項目，卻沒考慮到隨時可能添加其他的擴展功能，而后添加的擴展功能讓開發(fā)人員延遲了項目的提交時間。

16.只論結果

有些管理人員要求快速給出解決問題的方案，同時拒絕受理出現(xiàn)問題的推測原因并抵制正確的審查方法。他們只會言語上說：”你不是專家嗎？為什么你不能解釋或解決它呢？“然而，要得到解決方案，你必須調(diào)查出現(xiàn)問題的原因，以及假設原因并對其進行測試。因此，我們不能快速給出解決方案，而需要對其猜測檢驗！

原文轉(zhuǎn)載自：http://my.eoe.cn/baixiaosheng/archive/4413.html