一、背景
本文可能和很多人想的不一樣，沒有那麼高深莫測，但是可能很實用，可能更容易避免出錯。
業務開發中很多人可能面臨這種情況：
1、任務每次都延期，任務時間并沒有通過拆分後單個評估，而是全憑拍腦袋
2、很多函數超過80行，大的意群沒空行，沒拆分出子函數，導緻别人閱讀你的代碼非常痛苦
3、寫代碼沒有靈活性，比如加了緩存的功能，後面需要拿掉，還得重新修改代碼釋出等。
4、到上線了發現經常擔心遺漏一些配置啥的
本文先介紹任務分解和函數拆分的概念和聯系，然後簡單介紹一下面向未來程式設計的習慣。
我這裡指的 “面向未來程式設計”是指寫代碼的時候要适當考慮未來的修改。
二、探讨
2.1 任務分解
極客時間《10x程式員工作法》
大多數人對于可執行的粒度認識是不足的，低估了任務分解的程度，做到好的分解你需要達到“微操作”的程度。有了分解得很小的任務，我們就可以很容易完成一個開發循環，也就讓計劃調整成為了可能。軟體行業在倡導擁抱變化，而任務分解是擁抱變化的前提。
動手做一個工作之前，請先對它進行任務分解
有些公司提供一套完整的效率平台，包括任務的狀态，項目中每個人的拆分，項目涉及的文檔等等。
開發前需要對任務進行分解并且估時。
任務拆分的合理，預估的時間相對就準确，對風險的把控能力就強，如果額外加入了幾個小時的緊急事情，那麼比預計晚多久就相對容易評估出來。
任務分解使任務變得更容易執行，并且時間更容易評估，可以非常清晰的了解目前任務的執行進度，剩餘時間。
建議大家可以借鑒類似的思想來做項目。
另外估時可以适當預留單測的時間，預留應對突然事件的時間，極少數情況會開發的這段時間不需要處理任何緊急插入的其他事務。
如果公司沒有提供工具的話，可以考慮trello
或者
teambition 甚至也可以在有道雲筆記裡，建立待辦來實作。
2.2 函數拆分
很多人喜歡把所有代碼寫到一起，導緻一個函數可能好幾百行，如果其他人修改你的代碼，極其痛苦。
而且自己時間久了需要修改的時候，如果注釋還不夠完善，自己也會浪費很多時間，而且也極容易了解錯誤。
《阿裡巴巴Java開發手冊》中建議一個函數的代碼長度不要超過80行。
為了更好的編寫業務函數，我們應該把業務函數拆分成幾個邏輯單元，比如參數檢查，查詢，資料組裝等。
不同邏輯邊界加上空格，部分大塊功能建議抽取到私有的子函數中。這樣代碼的可讀性更高。
比如我們對concurrentGet代碼重構，其參數和傳回值明确，邏輯清晰，極容易重構，也極容易測試。
2.3 面向未來程式設計
即程式設計時要有靈活性，要面向未來可能出現的一些（不是所有）情況。
2.3.1 比如開發一個緩存功能
為了避免上線後緩存出問題可以及時拿掉，為了測試環境測試不走緩存，可以設定緩存開關。
通過apollo配置，這樣不需要代碼修改和上線可以實作某個功能（不隻是緩存）的開關。
2.3.3 比如某個子產品本來應該獨立成子函數
未來注定要通過其他方式替換掉的，建議獨立寫一個子函數，未來隻需要替換這個函數就好了。
如果寫到一個大的業務代碼中，需要了解上下文，這樣修改的難度就很大了。
比如這裡 我們替換了第三部分，參數傳回值可以不變，隻修改邏輯就好了。
2.3.3 比如調用二方接口
傳回值類型是Map<String,Object> 那麼，即使某個key的值"肯定"是Long,盡量用fastJson的Map轉我們的DTO對象，不要get後單個屬性強轉。
假如二方接口對資料使用使用JSON序列化到Redis裡，然後取出來Long被轉成Integer，如果我們通過get擷取Object進行強轉，如圖所示，含Long類型的資料的map，第二次請求走緩存，會出錯。
但是如果我們也緩存了我們的最終結果，那麼這個反序列化錯誤可能一直被隐藏着。
《JSON序列化導緻Long類型被搞成Integer經典巨坑》
https://blog.csdn.net/w605283073/article/details/90941038面向未來程式設計，決定了我們要意識到雖然測試環境資料正确，不代表未來不會變化，怎樣更好的應對變化是關鍵。
2.3.4 面向未來記筆記，很重要！
比如你新開發一個功能，涉及到某個配置的改動，涉及到SQL的修改，需要依賴的其他服務先上線，上線後需要配置XXX等等情況。
都可以在開發的時候記錄到雲筆記的“上線” 檔案夾的“注意事項”等筆記中。
這樣極大避免了上線前抓耳撓腮的去檢查思考自己的變動，需要的配置，依賴的服務等等。
當然上線前還是要重新思考的，但是極大減輕了工作量，極大避免了遺漏出錯。
開發階段可以記錄未來測試階段需要注意的事項。
甚至需求評審階段，就可以用筆記整理思路，甚至預先設想技術方案等。
功能測試階段可以在雲筆記的“測試”檔案夾，記錄測試所需的賬戶，SQL語句，URL等友善測試的工具，每個測試步驟最好帶上截圖。
這樣後面如果需要再次手動測試，直接copy搞搞就好了。
如果測試想你咨詢某個環節的問題，直接對着筆記看截圖就好了。
我如果得知下午要把提測的内容和測試過一遍，會盡可能的把分支名、改動内容、涉及的函數名、可能幫助測試的日志、測試注意事項提前整理好，到時候就非常輕松。不需要現場組織語言，現場找各種需要的東西，避免了浪費時間。
等等。
2.3.5 面向未來總結經驗
很多人不重視方法，不去學習好的排錯方法（參見《代碼排錯和避免錯誤的正确姿勢》），不去主動夯實基礎，不喜歡總結。
導緻失去了快速成長的機會。
拿排錯來說，錯誤排查的方法主要就那麼幾種，通過紮實的基礎結合邏輯的思考，謹慎的印證絕大多數都可以找到錯誤原因。
我們可以積累排錯經驗，包括F12大法（抓包大法）、Code Review大法，調試大法、日志大法、搜尋引擎大法、控制變量法、換環境大法等。
另外避免上線時遺漏一些事項，我們可以積累上線需要注意的事項，然後每個功能上線前都排查一遍。
比如SQL變更有沒有送出并生效？有沒有修改配置項，是否已經送出并生效？上線順序是怎樣的？上線後怎麼驗證功能有效性？等等。
這些在上線前都要認真檢查的，并且開發階段如果有結論可以提前寫到筆記裡，上線前重新核實。
三、總結
任務分解和函數拆分有極其相似的地方，都是将大的任務拆分成小的更容易執行和評估的單元。
而面向未來程式設計，則是在其中未來注定要替換的部分，可以提取到某個子函數，未來直接重構子函數即可。
面向未來程式設計則是考慮更多未來的變化，提供一些友善的開關等功能。
最後也是最重要的一點是，多讀有助于提高代碼健壯性，可維護性的圖書，在本人的另外一篇部落格上有超多推薦，歡迎參考。
https://blog.csdn.net/w605283073/article/details/89893440當然過度設計也不太好，但是盡可能的“”，思考各種意外的情況，面向未來總結經驗，面向未來做一些準備等。
如果覺得本文對你有幫助，歡迎點贊，歡迎關注我，如果有補充歡迎評論交流，我将努力創作更多更好的文章。
另外歡迎加入我的知識星球，知識星球ID：15165241 一起交流學習。
https://t.zsxq.com/Z3bAiea申請時标注來自CSDN。
————————————————
版權聲明：本文為CSDN部落客「明明如月學長」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/w605283073/article/details/91057040