16種折磨開發者的方式

　　在日常開發過程中，開發者會遇到許多折磨自己的問題，如：安全性問題，工具使用等，這裡Andrew C. Oliver為大家總結了公司裡最常見的16種折磨開發者的方式，看看你遇到幾個？

 

　　1.地獄性的安全問題

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

　　2.酷刑工具

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

　　3.維護團隊

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

　　4.強迫使用Windows

　　強迫你的開發人員使用Windows開發環境很扯淡，而且，對於非技術性使用者執行專案也會有很多的限制。

　　5.遠離類庫

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

　　6.WebSphere

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

　　7.持續程式設計至“死”

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

　　8.2010年是個好年頭，但已經過去了

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

　　9.成為重複編碼的機器

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

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

　　如果你的公司完全是虛擬的，甚至開發環境也是虛擬的。由於硬體資金不足或者沒有協調好等原因，而導致一切程式都慢下來，這是很可怕的折磨。有些人是禪宗，不在乎用兩個小時來構建這個過程，而我並不是其中的一員。

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

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

　　12.形式主義

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

　　13.危機管理

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

　　14.吹毛求疵

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

　　15.細節！細節！

　　一位頭髮豎起的老闆：‘’客戶需要一個扭曲功能，你能及時新增實現嗎？“
編碼人員：”不能。這將需要主體架構的改變。在專案啟動之前，我們就詢問過，而且當時被告知儘可能的不會花時間做擴充套件功能。“
專案啟動之前，寫在需求評估表中的需求量很少，這讓了開發人員採取更捷徑的方法開發專案，卻沒考慮到隨時可能新增其他的擴充套件功能，而後新增的擴充套件功能讓開發人員延遲了專案的提交時間。

　　16.只論結果

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

　　文章來源： infoworld.com