現代軟件工程講義源代碼管理

時間 2019-11-06

標籤現代軟件工程講義源代碼管理简体版

原文原文鏈接

【現代軟件工程課件】html

源代碼管理 -- 以實踐促進學習git

移山軟件學院的學生果凍問老師：爲啥須要源代碼管理? 我本身寫代碼多爽，別人要，就用QQ 傳過去好了。程序員

老師問：原始人怎麼建房子？github

果凍：或者找一個洞，或者本身挖一個洞，上面搭個棚子擋雨...apache

老師問：現代人怎麼建房子？安全

果凍：那就要有樓房，固然還要搭腳手架，還要升降機，起重機，等等工具。服務器

老師問：若是原始人穿越到如今，要蓋房，是否能夠不要腳手架，你們直接搬磚從一樓砌牆，而後站在一樓砌二樓，而後站在二樓砌三樓... 砌到十樓麼？ide

果凍：這有不少問題：工具

　　- 人力搬磚效率底下，人的體力有限，必須有工具幫忙。單元測試

　　- 若是牆砌歪了，沒有人來看，砌到五樓才發現從二樓開始就歪了，怎麼辦？

　　- 現代房屋有各類成型的模塊（門框，窗框，各類預製板，各類管道線路），沒有工具，光憑人力根本搞不定。

老師：對，咱們須要腳手架，升降機，起重機，水泥攪拌車，各類檢測工具來保證一個大樓能順利建好。咱們說過，

　　軟件 = 程序 + 軟件工程

　　軟件_的質量 = 程序_的質量 + 軟件工程_的質量

軟件工程的質量要靠軟件工具和軟件流程來保證，你們看過正在建設中的高樓，半完工的樓頂上矗立着巨大的塔吊。這個塔吊不是用戶需求的一部分 （用戶但願完工的樓房上面沒有塔吊！），可是，這是建築工程上不可缺乏的環節，那麼怎麼把塔吊順利地安裝上，隨着樓房的增高而增高（動畫，迪拜塔的建設），讓塔吊高質量地工做，怎麼作安全檢查，防止它倒下來？這就是工程的要求。

軟件工程中，也有相似腳手架，塔吊這樣的工程系統，工具和流程。軟件的源代碼管理工具（source code control system），加上構建系統（build system）, 能保證一個複雜軟件能在多個角色，多個團隊的合做下，按時以合適的質量發佈。若是你寫一個Hello World 程序，固然不須要這些工具，就像你用兒童積木搭房子過家家，你本身高興，但這不是建築工程。

源代碼管理的10 個實踐問題：

源代碼管理的重要性無需贅述，可是在實際中，不少團隊都是小和尚唸經 - 有口無意。嘴上說重要，可是實際上仍是經過QQ 傳遞源代碼，或者演示一結束，源代碼馬上沒有能夠工做的版本。咱們請各個團隊舉出例子，說明本身是用什麼樣的源代碼系統 (subversion, CVS, github, TFS, etc) ，如何處理團隊開發中可能會遇到的各類問題。若是團隊仍是用QQ 傳遞代碼，請說明QQ 如何解決下列的問題。

每一個團隊寫一個博客，回答下列問題，（每一個回答要加上截屏顯示）：

0. 在吹牛以前，先回答這個問題：若是你的團隊來了一個新隊員，有一臺全新的機器， 大家是否有一個文檔，只要設置了相應的權限，她就能夠根據文檔，從頭開始搭建環境，併成功地把最新、最穩定版本的軟件編譯出來，並運行必要的單元測試？（在這過程當中，不須要和老隊員作任何交流）

1. 你的團隊的源代碼控制在哪裏？用的是什麼系統？ 如何處理文件的鎖定問題？

場景： 程序員果凍正在對幾個文件進行修改，實現一個大的功能，這時候， 程序員小飛也要改其中一個文件，快速修復一個問題。怎麼辦？

一個代碼文件被簽出 (check out) 以後，另外一個團隊成員能夠簽出這個文件，並修改，而後簽入麼？

有幾種設計，各有什麼優缺點？

例如，簽出文件後，此文件就加鎖，別人沒法簽出；或者，全部人均可以自由簽出文件

2. 如何看到這個文件和以前版本的差別？如何看到代碼修改和工做項（work item），缺陷修復（bug fix) 的關係。

場景：程序員果凍看到某個文件被修改了，他怎麼看到這個文件在最近的修改究竟改了哪些地方？（例子）

場景：程序員果凍看到某個文件在最新版本被改動了100 多行，那麼和這100多行對應的其餘修改在什麼文件中呢？這個修改是爲了解決哪些問題而做的呢？那些問題有工做項（work item，issue），或者bug 來跟蹤麼？

3. 若是某個文件在你簽出以後已經被別人修改，而且簽入了，那麼你在簽入你的修改的時候， 如何合併不一樣的修改（merge)? 你用了什麼工具來幫助你？

4. 你有20個文件都是關於同一個功能的修改，你要如何保證這些文件都 同時簽入成功（修改的原子性），或者同時簽入不成功？

場景：程序員果凍要簽入 20 個文件，他一個一個地簽入，在簽入完5 個 .h 文件以後，他發現一些 .cpp 文件和最新的版本有衝突，他正在花時間琢磨如何合併... 這時候，程序員小飛從客戶端同步了全部最新代碼，開始編譯，可是編譯不成功 - 由於有不一樣步的 .h 文件和 .cpp 文件！這時候，別的程序員也來抱怨一樣的問題，果凍應該怎麼辦？

5. 你的PC 上有關於三個功能的修改，可是都沒有完成，有不少文件處於半完工的狀態，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，保證在乾淨的環境中修改這個 bug, 併成功地簽入你的修改 --- changelist management。

6. 規範操做和自動化

你的團隊規定開發者簽入的時候要作這些事情：

- 運行單元測試，相關的代碼質量測試。

- 代碼複審（要有別的員工的名字）

- 和此次簽入相關的issue 編號，任務/task，缺陷/bug 編號，等等，以備查詢。

請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入全部信息而後提交麼？（高級功能，代碼提交以後，相關bug 的狀態會改動爲「fixed」，而且有連接指向此次簽入。）

例子。

7. 如何給你的源代碼 創建分支？

場景：大家須要作一個演示，因此在演示版本的分支中對各處的代碼作了一個臨時的修改，同時，主要的分支還保持原來的計劃開發。大家怎麼作到的？在演示以後，演示版本的有些修改應該合併到主分支中，有些則不用，大家是怎麼作到的？

場景：大家的軟件發佈了，有不少用戶，一天，一個用戶報告了一個問題，可是他們是用某個老版本，並且沒有條件更新到最新版本。這時候，你如何在本地構建一個老版本的軟件，並試圖重現那個問題？

8. 一個源文件，如何知道它的 每一行都是何時簽入的，爲了什麼目的簽入的 （解決了哪一個任務，或者哪一個bug）？

場景：一個重要的軟件歷經幾年，幾個團隊的開發和維護，突然出如今某個條件下崩潰的事故， 程序員果凍通過各類debug手段，發現問題是在某一個文件中有一行代碼彷佛顯然出了問題，可是這個模塊被不少其餘模塊調用，這行代碼是何時，爲了什麼目的，通過誰簽入的呢？若是貿然修改，會不會致使其餘問題呢？怎麼辦？

9. 如何給一個系統的全部源文件都打上標籤，這樣別人能夠同步全部有這個標籤的文件版本？

代碼天天都在變，有時質量變好，有時變差，咱們須要一個 Last Known Good （最後穩定的好版本）版本，這樣新員工就能夠同步這個版本，咱們若是須要發佈，也是從這個版本開始。那麼如何標記這個 Last Known Good 版本呢？

10. 你的項目的 源代碼和測試這些代碼的單元測試，以及其餘測試腳本都是放在一塊兒的麼？修改源代碼會確保相應的測試也更新麼？你的團隊是否能部署自動構建的任務？

在簽入以前，程序員可否自動在本身的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？

在程序員提交簽入以後，服務器上是否有自動測試程序，完成編譯，測試，若是成功，就簽入，不然，就取消簽入？

團隊是否配置了服務器，它自動同步全部文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊

做業題，分析比較各類軟件構建環境：

就像一個廚師要分析各類廚房用具，挑選適合本身的工具組合，一個軟件團隊也要挑選適合本身的源代碼管理和其餘配套工具，請選擇至少三種，比較各自的優勢缺點，成本：