開發(fā)流程與思考
DoD 驗收標準列表
- DoD的每一個檢查項都是可驗收的
- 在開始著手于一件事上時，就需要確定好細節(jié)項
- 盡快消除不確定項，達成共識
精益創(chuàng)業(yè)
- 面向不確定性創(chuàng)建新事物
- 方式論：創(chuàng)建（build ）-測量（measure）-認知（learn），三者循環(huán)迭代
- 用最少的成本，干有價值的事
- 作為一個開發(fā)人員。在平時，產(chǎn)品提出的需求雖然可行，但在當下有限的人力，物力，時間的，及該需求的重要度低的情況下可延后處理。
- 開發(fā)人員遵循開發(fā)原則是 當需求來臨時，你需要知道它為什么要做，有什么意義與好處（可通過用戶故事體現(xiàn)），才能去做。而不應該逆來順受，來什么，做什么。
開發(fā)方式
從未來考慮問題
- 進行一次沙盤模擬
- 從結果入手，如果需要開發(fā)一個產(chǎn)品。待入上線后的情況，從未來考慮，比如上線時需要什么配置，上線后系統(tǒng)崩潰怎么辦，線上數(shù)據(jù)如何準備？
分解任務
- 不同層級的人，任務分解程度不同，比如作為一個剛了解開發(fā)的人，將任務，分為 獲取鏈接，分析，上傳三步。
- 當任務得到合理的分解，執(zhí)行起來也就按部就班，有條不紊。
- 分解成各個微操之后，也會讓任務執(zhí)行得以擁抱變化。當被打斷時候，能很容易開啟下一個流程的開發(fā)。
- 做好微任務的安排
測試先行
- 測試 - 開發(fā) - 重構 環(huán)環(huán)相扣
- 測試先行可以更好理清當前開發(fā)的需求，完成特定需要的功能
代碼防腐
代碼的不斷交接，不斷腐化
- 當需要維護一段代碼時，每個人只是完成了當時一部分的工作，代碼中的異味會越來越重
- 開發(fā)人員每當維護別人的代碼時，總是覺得別人的代碼很亂。給這段代碼添加新功能時，不免產(chǎn)生 “代碼都這樣了，我不能亂改，我只能按照它原來的風格，就給它添加功能就好了” 的想法。
- 解決方法：設計原則，SOLID。
設計模式，設計原則？
- 在編程時，總想著去套用一系列設計模式，當有時卻適得其反。
- 無法正確使用設計模式，或感覺其無用，往往是因為沒有形成自己的知識體系。
- 設計模式只是戰(zhàn)略上的建議，要想形成體系，靈活運用就得領悟設計原則。
- 在遵循SOLID原則的前提下，進行編碼，在不經(jīng)意間就能使用到設計模式，盡管你不知道模式的名稱
- 比如，單一職責：
- Robert Martin的架構整潔之道中，描述單一職責為 “一個模塊僅僅對一類
角色負責” - 有一個Employee類，有三個方法 ：
- calculatePay() 是財務部門關心的
- reportHours() 是人力資源部門關心的
- save() 是系統(tǒng)業(yè)務部門關心的
- 因為calculatePay與reportHours都有 正常工作時間的計算，為了避免重復將它抽為 regularHours方法
- 現(xiàn) 財務部門修改正常工作時間的方式，人力資源部不需要修改。你只看到了calculatePay調用了regularHours，所以修改了regularHours，然而卻導致人力資源部查詢的錯誤，從而導致公司受損
- 此處的regularHours 在為不同的
角色服務，所以一旦需求變化，它就是修改的重災區(qū) - 這個時候，就應該將上述三個方法分拆為三個面向不同
角色的類
- Robert Martin的架構整潔之道中，描述單一職責為 “一個模塊僅僅對一類
- 小到開發(fā)中的每個方法，對象。大到對大型系統(tǒng)架構的微服務拆分，轉型。 都需要 識別不同
actor，正確理清限界的上下文，劃分能夠獨自演進的功能模塊
維護他人代碼時
當接手一項新工作，新環(huán)境時
1.業(yè)務
- 第一步先理解工作業(yè)務（做什么，解決了什么，流程是什么）
2.技術
- 了解技術棧
- 系統(tǒng)的業(yè)務架構是什么（有哪些模塊，與哪些外部系統(tǒng)有交互）
- 外部接口方式，承接的協(xié)議是什么
- 內部各個模塊如何劃分，模塊職責是什么，分層抽象的東西是什么
- 系統(tǒng)構建的腳本，代碼的結構怎么樣的
3.團隊運作
- 外部：需求來源是那兒，產(chǎn)品和面向的用戶是誰
- 內部：定期的和日?；顒佑惺裁?，企業(yè)文化
