Chapter2 Process and Tools of Software Construction
主要介紹了軟件開發的基本過程，傳統軟件開發過程模型，敏捷開發，軟件配置管理SCM，版本控制系統VCS，Git作爲配置管理工具；
廣義的軟件構造過程，Eclipse作爲java構造工具，軟件構造各階段的常見工具，狹義的軟件構造：build，常見的build工具；
2.1 Software Lifecycle and Configuration Management
2.1.1 Software Development Lifecycle(SDLC)
軟件構造遵循的過程:
①From 0 to 1 (從到無到有)
②From 0 to n (從有到好)
軟件的生命週期:
計劃(產品經理) -> 需求(需求工程師) -> 設計(架構師) -> 構造(實現)(程序員) -> 測試(程序員) -> 部署(運維工程師) -> 運維(運維工程師)
2.1.2 Traditional Software process models
選擇合適的過程模型的依據：
①用戶參與程度，適應變化的能力
②開發效率，管理複雜度
③開發出的軟件的質量
傳統軟件過程模型:
| Basic types | Linear(線性過程) | Iterative(迭代過程) |
| Existing models | Waterfall(瀑布過程，線性/整體推進（無迭代），階段劃分清楚，管理簡單，無法適應需求，拓展->V字模型), Incremental(增量過程，線性推進（無迭代），增量式（多個瀑布的串行），比較容易適應需求的增加) | Spiral(螺旋過程， 多輪迭代基本遵循瀑布模式，每輪迭代有明確的目標，遵循原型過程，進行嚴格的風險分析，方可進入下一輪迭代) |
迭代：開發出來會後有用戶試用、評審，發現問題反饋給開發者，開發者修改原有的實現，繼續交給用戶評審。循環往復，直到用戶滿意，時間代價高，但開發質量高
使用圖示查看各個模型過程還是很直觀的
瀑布模型
增量模型
V字模型
原型模型
螺旋模型
2.1.3 Agile development and eXtreme Programming(XP)
敏捷開發和極限編程
| Agile development（敏捷開發） | eXtreme Programming（極限編程） |
| 通過快速迭代和小規模的持續改進，以快速適應變化；極限的用戶參與，極限的小步驟迭代，極限的確認、驗證 | Strengthen communication; start from simple; seek feedback; be brave in seeking truth from facts(近螺旋式開發) |
Waterfall vs Agile
2.1.4 Software Configuration Management(SCM)
Terminology(專業術語)
| Software Configuration Management(SCM, 軟件配置管理) | Configuration Item(SCI, 軟件配置項) | Baselines(基線) | CMDB(配置管理數據庫) | Versioning(版本控制) |
| 追蹤和控制軟件的變化 | 軟件中發生變化的基本單元(eg. 文件) | 軟件持續變化過程中的”穩定時刻”(eg. 對外發布的版本) | 存儲軟件的各配置項隨時間發生變化的信息+基線 | 爲軟件的任一特定時刻(Moment)的形態指派一個唯一的編號, 作爲”身份標識” |
Version Control System(VCS, 版本控制系統)
重要性：回滾上一個版本；比較兩個版本的差異；備份軟件版本歷史；獲取備份；合併；多個開發者之間共享和協作；記錄每個開發者的動作，便於”審計”。
terminology：
倉庫：即SCM中的CMDB
工作拷貝：在開發者本地機器上的一份項目拷貝
變化：即code churm，兩個版本之間的差異
HEAD：當前版本
| Local VCS(本地版本控制系統) | Centralized VCS(集中式版本控制系統) | Distributed VCS(分佈式版本控制系統) |
| 倉庫存儲於開發者本地機器, 無法共享和協作 | 倉庫存儲於獨立的服務器, 支持多開發者之間的協作 | 倉庫存儲於獨立的服務器+每個開發者的本地機器 |
2.1.5 Git & GitHub
Git的結構、工作原理、基本指令
GitHub
Git管理軟件演變過程中的變化
這裏按照圖示，基本概述一下Git管理的相關指令操作：
要在本地創建一個倉庫，首先需要git init 生成.git，.git保存所有版本控制數據，即本地的CMDB；
將工作目錄（本地文件系統，workspace）文件加入暫存區，使用git add file（git add . 將當前目錄下所有文件加入暫存區），此時狀態爲Staged，已暫存；
使用git commit -m "comment"將暫存區文件加入到本地倉庫（local repository），此時狀態爲Committed，已提交；
將本地倉庫同步到遠程倉庫使用git push origin master （master，主線）；
如果遠程倉庫發生了改變，需要先使用git fetch 同步本地倉庫。
Git的管理變化，每個文件只保存一份，在每個版本中，如果發生改變則更改，否則使用前一個版本的文件，該版本中不顯示，如下圖：
Object Graph
版本之間的演化關係圖，一條邊A->B表徵了“在版本A的基礎上作出變化，形成了版本B”；
其中每次commit（提交），都是一個當前整個項目的快照，展示爲一個樹節點；同時包含一個日誌信息，who，when，short log message，以hash值作爲區別；
這裏可以使用git lol 在git bash上得到演變樹；
下面是Git項目的歷史演變構成一個directed acyclic graph（DAG），保存在.git中，而使用git commit就是向該圖中增加節點；
使用git show commithash 以展示某次提交的詳細情況；
Branch and Merge（分支與合併）
master爲主線，其餘爲分支，可以將分支與主線進行合併；
可以使用git checkout 切換分支或恢復工作樹文件；git merge brname 合併分支；
collaboration（合作）
主要涉及commit、push、merge、fetch等交互操作；
關於GItHub
Git的web服務器
Basic process: commit， branch and merge
Collaboration process: fork and pull request，issues
2.2 Process, Systems, and Tools
2.2.1 General process of sofrware construction
廣義的軟件構造過程:
Design（設計） -> Programming/refactoring（重構） -> Debugging（調試） -> Testing（測試） -> Build（構建） ->Release（發佈）
| Programming/refactoring(編程/重構) | Review and static code analysis(代碼評審) | Debugging(dumping and logging) and Testing(調試和測試) | Dynamic code analysis/profiling(動態分析) |
| 重構: 在不改變功能的前提下優化代碼 | Formal code review(正式代碼評審會議); Lightweight code review(輕量級的代碼評審, eg. Pair programming-結對編程); Static code analysis(利用工具進行的靜態代碼分析, eg. CheckStyle, FindBugs, PMD) | 測試：發現程序是否有錯誤; 調試: 定位錯誤, 發現錯誤根源 | executing programs, profiling(對代碼的運行時狀態和性能進行度量) |
2.2.2 Narrow-sense process of software construction（build）
粗略理解build，就是從build-time到run-time，藉助工具，將軟件構造各階段的活動”自動化”，提高構造效率；
狹義的軟件構造過程(Build):
Validate(驗證) -> Compile(編譯) -> Link(鏈接) -> Test(測試) -> Package(打包) ->Install(部署) ->Deploy(發佈)
| Build system | Build variants and build language | Build tools |
| components and process | Makefile, build.xml | Make, Ant, Maven, Gradle, Eclipse, Travis CI（Continuous Integration，CI，持續集成） |