如何寫好業務代碼？

01-01

如題，如何寫好業務代碼？

多和客戶喝喝酒。

了解客戶到底是為什麼會有這麼奇葩的需求。

比如我有個銀行的客戶，在我們系統裡面，他希望任務的「完成」狀態，在報表（給領導看的表格）裡面不能叫「完成」，根據任務的計劃時間來算，該「延遲」的延遲，該「預警」的「預警」，除非他手動驗收了，才能叫「完成」。

為什麼會要求這樣？後來和他一塊吃飯，才知道，他希望他能把任務的進度控制權把握在手裡，不是說手下的人做完任務要求的工作了，就完了，手底下的人求他驗收才行。還有一個原因就是，如果工作繁忙，來不及驗收，他希望是任務延遲，這樣他在給領導解釋為什麼還沒「完成」的時候，可以推給任務負責人，和他沒什麼關係。

果然程序員接觸這一類的項目都會助紂為虐，會變壞。我無時無刻不在想著去做自己的事業，不再干這diao毛工作。

奉勸要入行的人，不要給銀行政府做項目。尤其是土了吧唧的單位，腦子裡就沒點先進的管理思想，他們所謂的體驗和管理，就是自己怎麼舒服怎麼來，怎麼能避免自己的過失，怎麼能把過失推給其他人，怎麼把更多的工作交給其他人，自己只需要用滑鼠點點點就好。這些人又沒怎麼學過編程，我接觸的pmo的人又是半吊子的技術人員。

很多所謂的需求，根本就違反了編程理念。什麼他媽的設計模式多線程，吔屎啦你。

————

一些知友質疑用戶的需求是對的，用戶只是希望把任務進度控制在自己手中。可能我沒有表述清楚，補充一點，這個用戶沒有控制進度的許可權，他只是負責驗收，不作為任務的負責人，正常的流程是：任務發布，任務進行，任務完成（進度100%），任務驗收。任務進行期間（即進度未到100%），並且超出了計劃完成時間，才應該顯示「延期」。該名用戶希望控制為：在報表裡面，任務進度即使為100%（可任務模塊並沒有相應的改動），如果他沒有驗收，超出計劃完成時間，也算為「延期」。在我們約定的概念里，延期是任務負責人沒有按時完成任務，是任務負責人要背鍋的。

三個步驟：

理解業務
抽象與拆分
代碼實現

做到業務瞭然於胸，不藉助代碼，就可以演練出業務發生的場景。

然後就是抽象，拆分業務，先不要動代碼，先把業務抽象，拆分，然後再從你的抽象重建回去，看能否還原到原來的業務。

最後是寫代碼，寫完代碼再回溯，看能否還原業務。

重複迭代這個過程，就能寫好業務代碼。

零缺陷開發技巧，簡單易懂，一學即會，一用就有效果，讓你寫10K代碼只有1個bug的方法

個人實踐效果：10K代碼1個bug, 個人負責的70%的版本0 bug

內容簡介：

1個原則：2/8原則

20%的代碼完成80%的功能，80%的代碼用來處理20%概率出現的異常和分支

現在看看你的代碼，如果沒有達到這個標準，說明代碼不夠完善，考慮不夠周全

2個技巧：防禦性編程、代碼寫三遍

每行代碼都考慮分支或者錯誤情況（注意考慮並不代表一定要寫，沒有就不用寫，只是要培養自己的這種意識，如果沒有這樣的意識，那就會導致該寫的也都遺漏了），

第一遍代碼完成基本功能，第二遍代碼完善異常和分支處理，第三遍代碼優化（包括編程規範、性能、邏輯等）

3個條件：熟悉編程語言、單元測試、熟悉業務

特別注意編程語言的坑，例如PHP的==和===

單元測試不用多說，能夠以最小的代價發現隱藏很深的問題

代碼寫的再好，如果業務理解錯了都是白搭

詳細請看：

零缺陷」開發技巧 - 下載頻道 - CSDN.NET

寫完就要立馬補充1：

很多人評論說這樣會很耗費時間（意料之中的），但其實不然，磨刀不誤砍柴工，我的開發效率也是數一數二的，寫代碼的時候，多寫一些分支和異常判斷，並不會增加編碼時間，因為這些分支想到後寫起來是很快的，無需複雜的設計和實現，關鍵是一定要有意識去想！

而且這些分支判斷，實際上本來也是業務上需要考慮的，只是需求和設計文檔中不會這麼細緻而已，如果為了追求完成任務省略這些思考和處理，到了測試階段甚至上線運行後，總會有一天觸發這個邏輯缺陷，那個時候花費的時間比你編碼時花費的時間，增加10倍100倍都可能！

記住：出來混，總是要還的！

記住：編碼！= 完成正常邏輯

記住：編程！= 打字

寫完就要立馬補充2：

零缺陷是一種理念，是一種方法論，別扣字眼，認為只要有1個bug就不是零缺陷，這是教條主義，就像說二八原理，難道我75%的代碼用來處理異常和錯誤分支就不符合二八原理了么？

1，代碼模塊化。

根據業務需求準備對應模版，做到類似邏輯寫出代碼風格一樣。

2，通用模塊介面多樣化。

考慮可能被調用場景，介面多樣化一點，滿足各個場景。

3，忌諱自由發揮。

類似邏輯有大量現存代碼，模仿原有邏輯去寫，性能沒有明顯改善的話，不要自由發揮。

4，代碼簡單短小。

整體業務分割成多個函數組成，不要一塊邏輯上千行堆一起，三目運算別用，遞歸盡量少用。

5，邊寫邊測。

測試不需要很嚴謹和保留測試資料，做到運行通過結果正確就可以。忌諱代碼全部寫完測試前一次都沒有走。

6，業務邏輯的探討。

和業務人員探討邏輯，給選擇題要比給填空題好，因為你永遠不知道對面的腦迴路。

7，業務邏輯整理。

首要抓住input 和output。這個是整個業務邏輯的重中之重。

1. 了解業務，要求產品有可交互的文檔，在文檔不清晰之前千萬不要搞資料庫和介面設計。

2. 碰到不清晰的地方一定要跟產品溝通，千萬不要自己瞎猜，要不然最後是你自己背鍋。

3. 一定要拆分拆分拆分，發現需求模塊很大的時候，一定要拆分。

4. 發現不對勁的時候，業務奇怪或者自己代碼實現起來很奇怪的時候，一定要停下來跟別人確認，如果是自己一開始沒理解需求導致自己的設計不好實現的時候，一定要停下來，跟資深的工程師溝通，不要自己強行實現。

5. 不要寫死不要寫死不要寫死。

重構

首先要實現功能，其次做好優化，最後加入自己的一點見解啦，能夠提升用戶體驗的，最最最後就是一定要跟客戶確定好需求！！！！給我按手指，發毒誓，喝血水，錄音一系列操作走一遍，保證好需求不會有太大的變動才是王道~~~~~~~~~~~~~~~~~~~~~~~~~~

需求理解

功能拆分

邊界定義

不斷小構

不要重構

直接重寫

慎用繼承

組合實現

單一職責

業務痛點

技術亮點

借力耕耘

業務代碼範疇有大有小，所以剛開始的時候無須糾結模塊化獨立性之類的，因為這些是可以通過迭代優化達成的。所以說即便一個function，只要涉及對數據的計算和處理，都可以算是業務代碼。

業務代碼其實只有一個總體原則：首先邏輯清晰，邊界完整；然後兼顧效率。

業務代碼，要求對業務的了解十分充分。

接手個功能拆分的任務。

管理端四個功能的增刪查改要放到內網。

就debug先走一遍功能。

發現有一個功能的查，不能用。一個功能的增，有問題。

這項目少說四年了，就一直這樣沒人發現。

寫代碼的沒管這事兒，用項目的我沒管這事兒。

寫代碼的有可能偷懶了，用項目的可能四年沒碰過這些功能。

當然了，是政府部門項目（　＾ω＾）

客戶用著好，你寫的就是好。

┐（─__─）┌

各位大大已經說的很全面了.

一個很少觸及的方面-代碼可讀性. 如果代碼維護以後都是自己做,盡量用中文代碼實現業務邏輯吧. 畢竟業務描述中的很多中文詞翻譯成英文還不如沿用文檔中的中文原詞.

在下沒有在商業項目中實踐過,但有些實驗項目在: 中文編程的嘗試歷程小記 - 知乎專欄

兩個雛形: 基於spring的進銷存, 彙編語言編譯器

跟業務掛鉤的代碼，意味著頻繁的修改，突發的需求，多變的狀態……

所以，什麼樣的業務代碼才算好呢？

用時最少的。

在需求確定的情況下，依靠個人對需求的抽象理解能力，通俗地講就是理解完需求，按白話文的方式寫代碼。

在需求不確定的情況下，先別寫代碼，確定了再寫，省去多餘的無用功。

首先寫出來的功能拓展性要強，有時間的話可以多重構些代碼，抽象出來函數，這樣在拓展的時候就很方便。因為需求不可能不變。

其次，就是重構balabala

寫出來機器懂的代碼很容易，但是寫出人能看得懂的代碼則是一件難事。

出問題甩鍋，我不是最菜的那一個

搞業務先搞技術，搞清楚架構設計，不管是垃圾狗屎還是牛逼設計，然後吃業務，一點點吃，一塊塊搞，多和需求溝通

多讀源碼，領悟，沉澱！