21 | 架構設計：普通程序員也能實現(xiàn)復雜系統(tǒng)？
為什么軟件項目需要架構設計？
精英稀缺、全棧稀缺，通過架構設計讓普通程序員也能參與其中，一起實現(xiàn)復雜系統(tǒng)。
復雜系統(tǒng)，需求不確定、技術復雜。
技術的復雜性體現(xiàn)在
需求讓技術變復雜
人員會讓技術變復雜
技術本身也是復雜的
要讓軟件穩(wěn)定運行是復雜的
架構設計要解決技術復雜性的問題
降低滿足需求和需求變化的開發(fā)成本
幫助組織人員一起高效協(xié)作
幫助組織好各種技術
保障服務穩(wěn)定運行
什么是架構設計？
架構設計，就是通過組織人員和技術，低成本滿足需求以及需求的變化，保障軟件穩(wěn)定高效運行。
目標
用最小的人力成本來滿足需求的開發(fā)和響應需求的變化，
用最小的運行成本來保障軟件的運行。
常見的架構設計
微服務，把復雜系統(tǒng)拆分成一系列小的服務，服務再拆成功能模塊，讓人員更好地分工協(xié)作。
前后端分離，讓程序員更專注于某個知識領域，降低開發(fā)難度
分層設計，隔離業(yè)務邏輯，減少需求變更帶來的影響。
架構設計之道
組織人員和技術進行系統(tǒng)和團隊拆分，
安排好切分后的排列關系，
使拆分后的各部分能通過約定好的協(xié)議相互通信，
共同實現(xiàn)預想的結果。
如何做好架構設計？
一、分析需求，滿足業(yè)務需求是架構設計最基礎的目標。分析功能、界面、用戶、場景。
二、選擇相似的、成熟的架構設計方案。選擇架構方案、開發(fā)語言、框架，根據(jù)項目情況、團隊情況綜合考慮。
三、自頂向下層層細化。
四、驗證和優(yōu)化架構設計方案。架構設計并非一成不表，在實際開發(fā)的過程中，需要根據(jù)實際情況不斷進行優(yōu)化和調整。
22 | 如何為項目做好技術選型？
技術選型就是項目決策
技術選型看起來是個技術的選擇，但其實是一個和項目情況密切相關的項目決策。
回到項目金三角，技術選型同樣受時間、范圍和成本的約束。
要分析可行性和風險。
要考慮利益相關人
項目決策中常見的坑
把聽到的觀點當事實，片面相信網絡上的技術言論。
先入為主，有了結論再找證據(jù)。個人喜好，主觀出發(fā)。
如何做好技術選型？
四個階段，問題定義、調研、驗證、決策。
問題定義
為什么需要技術選型？技術選型的目標是什么？
提升開發(fā)效率，降低開發(fā)成本，不是為了使用新酷技術。
Make It Work！Make It Right！Make It Fast！
只有明確了技術選型的目標，才能有一個標準可以來評判該選擇哪一個方案。
調研
從以下方面對技術進行分析
滿足技術選型目標嗎？
滿足范圍、時間和成本的約束嗎？
是不是可行？
有什么樣的風險？風險是不是可控？
優(yōu)缺點是什么？
驗證
試用、demo，做的過程中才能知道，選擇的技術選型是不是真的能滿足技術選型的目標。
決策
在調研和驗證完成后，就可以召集所有利益相關人一起，就選擇的方案有一個調研結果評審的會議，讓大家提出自己的意見，做出最終的決策。
討論區(qū)歸納
寶玉老師的選型原則
成熟的好過新酷的
流行的好過小眾的
團隊熟悉的好過陌生的
簡單的好過復雜的
開源的好過商業(yè)的（有時候也視情況而定）
23 | 架構師：不想當架構師的程序員不是好程序員
前言
拿破侖那句名言：“不想當將軍的士兵不是好士兵?！痹涫荅very French soldier carries a marshal’s baton in his knapsack”，意思是“每個士兵背包里都應該裝有元帥的權杖”。
其實拿破侖的本意是激勵每一名上戰(zhàn)場的士兵都要有大局觀，有元帥的思維，并不需要每一個人都一定去當將軍、當元帥。
這同樣適用于技術領域，對程序員來說，并不代表一定要有一個架構師的頭銜，而應該心中有大局觀，有架構師的思維。從而能理解架構設計，能寫出好的程序。
什么是架構師思維？
架構師思維，其實就是這幾種思維的集合。
抽象思維
抽象思維可以說是整個架構設計的基礎。需求進行抽象建模，隱藏無關緊要的細節(jié)，在高層次的架構設計。
分治思維
對復雜系統(tǒng)分而治之，分解成小的、簡單的部分。但光分解還是不夠的，還需要保證分解后的部分能夠通過約定好的協(xié)議集成在一起。
復用思維
通過對相同內容的抽象，讓其能復用于不同的場景。
迭代思維
好的架構設計，通常不是一步到位，而是先滿足好當前業(yè)務需求，然后隨著業(yè)務的變化而逐步演進。
好的架構師什么樣？
一個好的架構師，不僅技術要好，還要懂業(yè)務；能從整體設計架構，也能在局部實現(xiàn)功能。
好的架構師，應具備以下幾個條件：
有架構師思維：具備良好的抽象思維、分治思維、復用思維和迭代思維；
懂業(yè)務需求：能很好地理解業(yè)務需求，能針對業(yè)務特點設計好的架構；
有豐富的編碼經驗：像抽象、分治、復用這些能力，都需要大量的編碼練習才能掌握；另外保持一定量的編碼經驗也有助于驗證架構設計；
良好的溝通能力：架構師需要溝通確認需求，需要讓團隊理解架構設計。
如何成為好的架構師？
從程序員開始，付出比普通程序員更多的努力，成為好的架構師，沒有捷徑。
寶玉老師的建議：
成為一個優(yōu)秀的程序員。技術好是成為架構師的基礎條件，首先讓代碼易讀，易擴展，能重用。通過大量的編碼實踐，逐步培養(yǎng)出好的架構師思維。
多模仿多學習。先把業(yè)界成熟的流行的架構吃透，用好。
選擇好行業(yè)和平臺。想當架構師，最好選擇一個合適的行業(yè)，積累足夠的行業(yè)知識，以后才能更好地設計出符合業(yè)務特點的架構。
24 | 技術債務：是繼續(xù)修修補補湊合著用，還是推翻重來？
什么是技術債務？
技術債務，就是軟件項目中對架構質量和代碼質量的透支。
技術債務是有利息的
債務的“利息”，就是在后面對軟件做修改的時候，需要額外的時間成本。
技術債務不一定都是壞的
刻意欠債的場景，如
提升短期的開發(fā)速度，讓軟件能盡快推出，搶占市場。
快速原型開發(fā)中，通過欠技術債務的方式快速開發(fā)快速驗證。
技術債務產生的原因
《重構》中 Martin Fowler從兩個維度分析技術債務產生的原因
1. 輕率（reckless）還是謹慎（prudent）；
2. 有意（deliberate）還是無意（inadvertent）。
不同債務定義、現(xiàn)象及影響
- 輕率 / 有意的債務
定義：團隊因為成本、時間的原因，故意走捷徑沒有設計、不遵守好的開發(fā)實踐，沒有后續(xù)計劃改善債務。
現(xiàn)象：不做設計直接編碼，后期也沒有打算重構代碼?；蛘呤菆F隊成員以新手程序員為主，沒有足夠的資深程序員指導和審查代碼。
影響：通常這類債務會一直積累，會導致利息越來越多，最終帶來的負面效果會越來越大。
- 謹慎 / 有意的債務
定義：團隊清楚知道技術債務的收益和后果，并且也制定了后續(xù)的計劃去完善架構和提升代碼質量的情況。
現(xiàn)象：比如說為了盡快發(fā)布產品，先采用“快猛糙”的方式開發(fā)，后續(xù)再對代碼進行重構。
影響：因為能及時償還，所以既可以短期有一定時間上的收益，長期也不會造成負面影響。
- 輕率 / 無意的債務
定義：團隊不知道技術債務，也不知道要后續(xù)要償還技術債務的情況。
現(xiàn)象：對于什么是架構設計，什么是好的開發(fā)實踐一無所知，代碼一團糟。
影響：這類債務最危險，既沒得到技術債務的收益，還要償還其產生的利息。
- 謹慎 / 無意的債務
定義：團隊其實很重視架構設計和技術債務，但因為業(yè)務的變化，或者其他客觀因素的原因，所產生的債務。
現(xiàn)象：設計的時候，無法準確預測后面業(yè)務的發(fā)展，隨著業(yè)務的發(fā)展，設計無法滿足好新的需求。
影響：債務難以避免，但如果能及時的對架構升級、重構，就能保證不會造成嚴重的影響。
如何管理技術債務？
Is it worth the effort to design software well?
策略：讓技術債務控制在臨界點之下
識別技術債務
開發(fā)速度降低
單元測試代碼覆蓋率低
代碼規(guī)范檢查的錯誤率高
Bug 數(shù)量越來越多
其他，如語言或者框架的版本太老，開發(fā)人員總是需要加班加點才能趕上進度
選擇處理技術債務策略
重寫：推翻重來，一次還清。缺點，工作量很大，新系統(tǒng)沒完成之前，同時要對舊系統(tǒng)維護和增加新功能，壓力非常大；另外新系統(tǒng)重新穩(wěn)定下來需要一段時間。
維持：修修補補，只還利息。缺點，越到后面，維護的成本就越高。
重構：新舊交替，分期付款。缺點，整個過程耗時相對更久。
三種策略并沒有絕對好壞，需要根據(jù)當前項目場景靈活選擇。
實施策略
對于重寫的策略，要當作一個正式的項目來立項，按照項目流程推進；
對于重構的策略，要把整個重構任務拆分成一個個小任務，放到項目計劃中，創(chuàng)建成 Ticket，放到任務跟蹤系統(tǒng)中跟蹤起來；
對于維持的策略，也要把需要做的修補工作作為任務，放到計劃中，放到任務跟蹤系統(tǒng)中。
實施策略的關鍵就在于要落實成開發(fā)任務，做為項目計劃的一部分。
預防才是最好的方法
預先投資，好的架構設計、高質量代碼。
不走捷徑，日常能做好代碼審查、保障單元測試代碼覆蓋率。
及時還債，把欠下的技術債務記下來，放到任務跟蹤系統(tǒng)中，安排在后續(xù)的開發(fā)任務中。
課后感
需求分析師和架構師都是IC但又需要leadership的角色。他們是從兩個維度降低軟件開發(fā)的復雜性。需求復雜度和技術復雜度。同時，他們又要組織好團隊內的相關活動和知識管理，促進組織發(fā)展。
康威定律，Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)。關聯(lián)到架構設計，通俗的理解就是，組織溝通方式決定系統(tǒng)設計。
技術債，可以借債加速發(fā)展，但債是有利息了。當債務巨大的時候，體現(xiàn)在系統(tǒng)就是系統(tǒng)維護需要大量人力，極小的需求改動也需要大量開發(fā)。
