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

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

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

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

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

開發(fā)時(shí)間緊，很多時(shí)候是沒有設(shè)計(jì)時(shí)間的，需求討論一下就開始敲代碼，因?yàn)闀r(shí)間真的很緊。單元測(cè)試用例覆蓋度？哪有時(shí)間寫單元測(cè)試呢。

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

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

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

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

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

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

一定要花時(shí)間摸清楚老代碼，有些程序員接手一個(gè)項(xiàng)目的時(shí)候，寧可重新寫一個(gè)新方法，也不愿意修改老代碼，長(zhǎng)此以往，這項(xiàng)目的代碼就真的沒人敢動(dòng)了。

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

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

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

第一，程序的復(fù)雜程度，如果一個(gè)簡(jiǎn)單幾十行代碼搞定的小程序，可以保證沒有bug。

第二，程序測(cè)試程度，當(dāng)然過于復(fù)雜的系統(tǒng)或程序只能說測(cè)試時(shí)間越長(zhǎng)bug會(huì)慢慢減少，并不能保證完全無bug。

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

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