Web開發中的6個壞習慣

　　在 Usersnap，我們在能很好的組織網站開發有超過20(總和)年的經驗。我們認為這些過去的經驗能讓我們很好的分辨出什麼是好、壞和醜陋的網站開發。如今我們不想把注意力放在消極的部分，但就這一次，我們將把以往不好的地方做一下總結，順便作為我們“ Web開發最佳實踐”系列文章邏輯的後續。

　1.將20個關鍵點用郵件發出去

　　將20個關鍵點郵件發給別人，列出所有的bug、功能需求和別人被拒絕的要求，是和商品一樣的問題。通常他們會帶來指責或者類似“為什麼你不解決掉$XY這個問題？我五個周之前不是就提指出了嗎？”這樣的追問。一旦你的開發經理不把這些對話落實到切實可行的計劃，你就可能忘記事情。與其抱怨所有的這些事情你媽媽都沒有教過你，不如嘗試教給你的客戶或者經理如何使用Bug追蹤器或者專案管理工具*。那樣的話，你不僅將節省無數傳送冗長的郵件的時間，接收郵件的人也會更加清楚你最近正在忙於什麼工作。

　2. 抄送給整個團隊

　　把問題抄送給所有人，意味著: 關於誰能處理這個問題，你沒有任何想法。這種做法本身就有問題。如果你這樣做了，很可能沒有人會回答或者覺得應該對該問題負責。還有:閱讀這些郵件浪費了無關人員大量的寶貴時間。儘量找出誰是責任人，然後只給他一個人發郵件。

　3. 把測試留給其他人

　　讓某人測試一個功能，而他卻不知道該功能最初有什麼錯誤，這是浪費團隊成員時間的另一種方式。例如: 有客戶抱怨說在IE瀏覽器中某個按鈕不管用。首先接手該問題的一名開發人員解決了這個問題，然後另外一名QA測試它的時候，甚至不知道如何重現該問題。

　4. 前後端之間的戰爭

　　把你的開發團隊分成固定的部分是個壞主意，也是極為不敏捷的(別擔心，我們沒有使用這個詞兒的習慣)。區分‘前端’和‘後端’導致了“Grabenkämpfe” (或者稱之為:前後端之間的戰爭)，毫無疑問這是不符合團隊精神的。前端開發者會抱怨說“後臺變更的太慢了”，而後臺開發人員則會抱怨說“這可是今年第五次修改API了”。

　5. 釋出未經測試的程式碼

　　如果僅僅因為這是HiPPO某某(薪水最高的那位)的程式碼，就釋出未經測試的程式碼，絕對是個糟糕的想法。更為糟糕的是: 這種事發生在週五下班前。當然，除非你是週末加班族，則另當別論了…

　6. 過早進行優化

　　是的，聽起來有點兒刺耳。但是在沒有任何人看過你的頁面之前就開始改進CSS動畫效果，對於做事情並沒有什麼好處。如果你還有後臺任務或者報告，當服務沒有裝載完畢時，讓它跑個5到10秒並不是什麼問題。應當在所有事情都正常工作之後再開始優化。我們還是非常提倡優化的，請參見我們上一篇文章中的第九條!

　　美國史丹佛大學的已經退休的電腦科學家和榮譽教授Donald Ervin Knuth，是精選著作集´計算機程式設計藝術(The Art of Computer Programming)´的作者。在他的‘使用goto語句進行結構化程式設計‘論文中他寫到:

程式設計師們花費了大量時間來思考、或者擔心他們的程式中無關緊要的部分的速度，而這會給程式碼的除錯和維護工作帶來很大的負面影響。我們應該忘掉細微部分的效率，對於97%的時間來說：過早優化是萬惡之源。然而我們也不應該錯過那關鍵的3%。

　　簡而言之：在你弄清楚你到底要優化什麼這個問題之前就開始優化，會帶來各種各樣的不必要的麻煩和錯誤。

　　我們應該，我的意思是，我也不會提倡不做備份就對產品進行更改或者沒有清晰的思路和說明就進行開發。但幸運的是，你不會經常遇到這些錯誤。

　　本系列的第三講我們將探討：程式設計世界裡黑暗與醜陋的一面。

　　*你可能想給不同的黨派設定不同的（編輯中）許可權。

　　**資料殺死了HiPPO明星

　　原文地址：http://usersnap.com/blog/bad-habits-in-web-development/