程序員寫的代碼就不能沒有Bug嗎？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。