在 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語句進行結構化編程‘論文中他寫到: