經常是某司線上又出bug了，然后是給公司造成多少損失，追根究底總是可以找到一些原因，諸如：寫代碼邏輯考慮不全面，或者代碼有硬傷，也有測驗不充分，甚至不測驗都有，也有是運維的問題等等，
我對測驗部專業，測驗是否可以發現所有問題我不好說，但是可以肯定的是從很多大廠出過的問題來看，測驗只能減少問題，不能徹底規避問題，
可能你會說需要監控等手段并用，那是必須的，但是首先還是需要把代碼寫好，
作為開發人員需要有些追求，寫出高階一點的代碼，不然只是這次發現問題，但是一些不好的習慣或者代碼水平不提高還是會出錯，
問題代碼：隨心隨意流水賬，一開始代碼還比較少，后面越寫越多，
業務也有《重構》的思想，但是很多人還是不能真正的理解，或者到了自己寫代碼的時候依然很差，最好是一步到位，而不是后期再重構，
對于一個已經上線的代碼，重構可以想象代碼多么大，如果設計資產專案造成損失后果不可估量，
那么代碼怎么樣才是好的呢？
1.唯一 一段代碼只做一件事情，最好是封裝為私有函式，不是共有函式不要暴露出來，
2.還是唯一，這個唯一就比第一個唯一高階一點，也比較難理解一點點，
代碼第一段是組合引數，那么第二段就不應該繼續組合引數，而是把這個封裝一起，
第三段是條件判斷，第四段，第五段還是判斷，那么都需要合并到一個方法，然后這個方法再根據這3個判斷的不同確定是否需要細分3個方法，
最后是輸出引數排序等轉換作業，
可以總結為 ： 輸入，業務處理，輸出，三步，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/251686.html
標籤：AI
上一篇：寫個取代自己的工具：Coco —— 自動化專案分析與建議
下一篇：隨筆