在 Usersnap，我們在能很好的組織網(wǎng)站開發(fā)有超過20(總和)年的經(jīng)驗。我們認為這些過去的經(jīng)驗?zāi)茏屛覀兒芎玫姆直娉鍪裁词呛?、壞和丑陋的網(wǎng)站開發(fā)。如今我們不想把注意力放在消極的部分，但就這一次，我們將把以往不好的地方做一下總結(jié)，順便作為我們“ Web開發(fā)***實踐”系列文章邏輯的后續(xù)。

1.將20個關(guān)鍵點用郵件發(fā)出去

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

2. 抄送給整個團隊

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

3. 把測試留給其他人

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

4. 前后端之間的戰(zhàn)爭

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

5. 發(fā)布未經(jīng)測試的代碼

如果僅僅因為這是HiPPO某某(薪水***的那位)的代碼，就發(fā)布未經(jīng)測試的代碼，絕對是個糟糕的想法。更為糟糕的是: 這種事發(fā)生在周五下班前。當然，除非你是周末加班族，則另當別論了…

6. 過早進行優(yōu)化

是的，聽起來有點兒刺耳。但是在沒有任何人看過你的頁面之前就開始改進CSS動畫效果，對于做事情并沒有什么好處。如果你還有后臺任務(wù)或者報告，當服務(wù)沒有裝載完畢時，讓它跑個5到10秒并不是什么問題。應(yīng)當在所有事情都正常工作之后再開始優(yōu)化。

美國斯坦福大學(xué)的已經(jīng)退休的計算機科學(xué)家和榮譽教授Donald Ervin Knuth，是精選著作集´計算機編程藝術(shù)(The Art of Computer Programming)´的作者。在他的‘使用goto語句進行結(jié)構(gòu)化編程‘論文中他寫到: