網(wǎng)友解答: 可以的，但是請保證需求一次性寫好并且考慮完善，而且給程序員留出足夠的設計和開發(fā)時間。完成的項目開發(fā)，包括：提出需求、需求分析、架構設計、概要和詳細設計、開發(fā)、測試、上線。但是

可以的，但是請保證需求一次性寫好并且考慮完善，而且給程序員留出足夠的設計和開發(fā)時間。

完成的項目開發(fā)，包括：提出需求、需求分析、架構設計、概要和詳細設計、開發(fā)、測試、上線。但是在實際的開發(fā)過程中，開發(fā)人員經(jīng)常會遇到這樣的問題：

業(yè)務人員也不知道自己想做什么。是的，你沒有聽錯，很多業(yè)務人員自己都不了解業(yè)務。所以他們提的需求會天馬行空，也會經(jīng)常變化，甚至開發(fā)還沒有結束，需求已經(jīng)變了。

需求人員就是傳話筒，業(yè)務人員說什么，需求人員寫什么，不做篩選和加工。

開發(fā)時間緊，很多時候是沒有設計時間的，需求討論一下就開始敲代碼，因為時間真的很緊。單元測試用例覆蓋度？哪有時間寫單元測試呢。

測試只會頁面點點點，只能測到表面，比如我見過這樣的BUG：“頁面的按鈕名字叫做【新增】，需求寫的是【新建】，所以這是一個BUG”。好吧，這確實是一個BUG，但是你們不能只找這種程度的BUG啊。

由此可見，項目流程中的每一個步驟，都會造成BUG的產生，只不過大部分鍋都是由開發(fā)人員背的。

細說一下開發(fā)，我們既然不能要求別人怎么樣，但是至少要把開發(fā)做到最好：

開發(fā)人員盡可能的早一些參與到需求討論和確定中。不一定非得是開發(fā)人員，可以是項目經(jīng)理、架構師或敏捷開發(fā)中的PO/Master。這樣有幾個好處：盡早了解客戶需求，如果有不合理的地方可以及時糾正；避免需求在傳遞中縮減或理解偏差；還可以在需求討論過程中，完成一部分設計。

可以沒有設計文檔，但并不是說可以沒有設計，我認為在開發(fā)之前，一定要留出一部分時間，想一想實現(xiàn)方案。

增加代碼的復用性，我們經(jīng)常會遇到這樣的問題：相同的邏輯四處都有，修改的時候要改很多地方，這樣增加了測試的難度；還有就是，可以減少我們開發(fā)的工作量。

一定要花時間摸清楚老代碼，有些程序員接手一個項目的時候，寧可重新寫一個新方法，也不愿意修改老代碼，長此以往，這項目的代碼就真的沒人敢動了。

說回測試用例，最好能投入一些時間去寫，前期是一件非常痛苦的事情，但是當測試用例覆蓋度積累到一定程度之后，很多隱形的BUG就能避免了。

最后，希望業(yè)務、需求、開發(fā)、測試、運維可以一條心，把一個項目做好，而不是出現(xiàn)BUG之后互相指責。

個人經(jīng)驗，首先了解bug和什么有關，當然程序員能力也是一方面，這里就不提！

第一，程序的復雜程度，如果一個簡單幾十行代碼搞定的小程序，可以保證沒有bug。

第二，程序測試程度，當然過于復雜的系統(tǒng)或程序只能說測試時間越長bug會慢慢減少，并不能保證完全無bug。

第三，很多邏輯問題存在悖論，也就導致無論怎么做都不可能完美的解決，也會導致bug。

即便是微軟的windows 系統(tǒng)，阿里的淘寶還是昨天被羊毛黨擼了200億(數(shù)據(jù)不知道真假，圈內了解的大概也有8位數(shù))都是存在bug，即便是現(xiàn)在都還是存在一些很難解決的bug！所以即便在厲害的程序員也不能保證完全沒有bug！