《軟件工程之美》打卡第四周
- 2020 年 2 月 18 日
- 筆記
最近筆者參加了極客時間的21天打卡行動，從年初開始到年末，21天無間斷完成了打卡行動。雖然打卡行動已經結束，但還是不想因此就懈怠了，人一嘗點甜頭就容易忘乎所以，所以我想繼續保持學習的習慣。
上周學習完了《軟件工程之美》中的需求分析篇，這周會學習系統設計篇，以下是這周的總結
20 | 如何應對讓人頭疼的需求變更問題？
這節課很有指導意義，軟件工程的存在的目的和意義就是為了解決改善軟件項目管理過程中的問題，需求變更就是我們程序員深惡痛絕的問題。 為什麼軟件項目需求會經常變更？ 原因有以下兩點：
- 需求的不確定性，前期需求的抽象和模糊，導致需求的變更
- 需求的變更成本的意識不足
如何解決需求變更問題？
- 提升需求確定性，把需求分析做好，減少需求變更
- 提高需求變更的成本，讓客戶或者產品經理不能太容易就變更需求，這樣就可以達到減少需求變更的目的。
- 降低響應需求變更的成本，可以方便快捷地響應需求變更。
這三種不同解決方案，不僅僅只是對工程師提出要求，對項目經理、產品經理等不同角色都提出了要求。只有每個角色都能意識到需求變更給項目帶來的後果，提高對需求的理解能力，提高協作效率，減少無用功，提升工作的滿意度，不至於疲於應對需求變更。
21 | 架構設計：普通程序員也能實現複雜系統？
說起架構設計，大部分普通程序員偏向於代碼實現，很少有機會站在全局的視野去進行架構設計，這也是我想去加強的地方。 軟件項目的複雜性有兩個特點：
- 需求不確定性
- 技術複雜性
架構設計的好處在於：
- 降低滿足需求和需求變化的開發成本
- 可以幫助組織人員一起高效協作
- 可以幫助組織好各種技術
- 可以保障服務穩定運行
什麼是架構設計？
- 目標： 最小人力成本滿足需求的開發和響應需求變化，最小的運行成本保障軟件的運行
- 方法： 組織人員和技術把系統和團隊拆分，安排好切分後的排列關係，讓拆分後的部分通過約定好的協議相互通信，共同實現最終的結果
如何做好架構設計？
- 分析需求
- 選擇相似的成熟的架構設計方案
- 自頂向下層層細化
- 驗證和優化架構設計方案
通過良好的架構設計，可以有效降低開發難道和成本，讓普通程序員也能實現複雜系統。
22 | 如何為項目做好技術選型？
技術選型這個話題跟工程師就很相關了，我們日常工作總會遇到要引入新的技術框架，這個時候技術選型就派上用場了。 寶玉老師提到技術選型就是項目決策，受限於以下幾個方面：
- 項目金山角
- 時間
- 範圍
- 成本
- 可行性和風險
- 考慮利益相關人
常見的坑
- 把聽到的觀點當事實
- 先入為主，有了結論再找證據
如何做好技術選型？
- 問題定義清楚： 為什麼需要技術選型和目標是什麼
- 調研清楚技術方案
- 科學驗證技術方案
- 勇於做出決策
23 | 架構師：不想當架構師的程序員不是好程序員
作為一個有追求的程序員本就不應該守着自己的一畝三分地，努力學習架構設計，站在更全局的視野思考業務問題，通過良好是技術來幫助業務成功。 架構師思維：
- 抽象思維（針對需求進行建模，進行高層次的架構設計）
- 分治思維（將複雜系統分而治之，分解成小的、簡單的部分）
- 復用思維（減少重複實現，提升代碼簡潔和維護性）
- 迭代思維（先滿足業務，再隨着業務變化逐步演進架構）
如何成為好的架構師？
- 首先要成為一個優秀的程序員
- 多模仿多學習
- 選擇好行業和平台
24 | 技術債務：是繼續修修補補湊合著用，還是推翻重來？
技術債務： 軟件項目中對架構質量和代碼質量的透支。 技術債務產生的原因：
- 輕率/有意的債務（時間成本原因，故意走捷徑，不遵守好的開發實踐，後續沒有改進計劃）
- 謹慎/有意的債務（團隊清楚技術債務的收益和後果，並且也制定了後續的計划去完善架構和提升代碼質量的情況）
- 輕率 / 無意的債務（團隊不知道技術債務，也不知道後續要償還技術債務的情況）
- 謹慎 / 無意的債務（團隊其實很重視架構設計和技術債務，但因為業務的變化，或者其他客觀因素的原因，造成技術債務的產生）
如何管理技術債務：
- 識別技術債務
- 選擇處理策略
- 實施策略
處理策略（主要取決於投入產出比哪個更好）：
- 推翻重寫
- 優點： 更好的設計，精簡功能和代碼；
- 缺點： 工作量大，壓力大，穩定需要一段時間
- 修修補補
- 優點： 成本低，不用投太大精力
- 缺點： 後續維護成本高
- 重構
- 優點： 對業務影響小
- 缺點： 過程耗時持久
預防才是最好的方法
- 預先投資
- 不走捷徑
- 及時還債
課後思考： 我們項目中的技術債務有很多，舉個例子，App最開始採用的動態化技術是React Native，但隨着技術的演變RN的弊端逐漸暴露出來，比如問題定位困難，需要聯動前端，後面Flutter出來之後，老大又想趁着這次技術更新將動態化切成Flutter，但這不是個簡單的工作，需要評估好成本，然後去逐步驗證。對我來說項目中採用的舊技術方案就是技術債務，承載了很多業務需求。我這邊打算採用的策略是重構，新舊交替，分期付款。在過渡期間做好降級策略，避免引入新技術導致線上問題，能夠降級繼續使用RN。等到Flutter技術應用穩定之後，才把舊的一套完全廢除不再維護。
最後
這周完成的學習目標是軟件工程中的系統設計篇，從這周開始就不強求一定要打卡完7天，對我來說習慣的養成比強制性的執行要來的更有效，所以我允許自己有空隙，因為總會有其他更重要的事情可能會打斷你。本周的學習最大的收穫是，更清晰認識到架構的作用和成為架構師需要培養的思維模式。下周繼續學習軟件工程中開發編碼篇，感謝你的閱讀。
