| 專案 | 內容 |
|---|---|
| 這個作業屬于哪個課程 | 2021春季計算機學院軟體工程(羅杰 任健) |
| 這個作業的要求在哪里 | 結對專案-第一階段 |
| 我們在這個課程的目標是 | 和團隊開發真正的軟體，一起提升開發與合作的能力 |
| 這個作業在哪個具體方面幫助我們實作目標 | 通過結對編程學習協作設計與編碼、代碼復審、CI使用等 |
成員介紹
| 專案 | 內容 |
|---|---|
結對專案第一階段的Gitlab倉庫地址 |
Pair Programming |
| 二人的學號后四位 | 3110, 3142 |
| 博客地址 | MadokaHomura(朱正陽), zixfy(趙子軒) |
一、關于解題
1. 設計與編碼
a. 事前設計
本次作業最終需要實作一個基于記憶體的檔案系統，它允許用戶通過各類輸入指令來進行檔案的增刪查改等互動，資料結構是樹型結構，
在邏輯上某一條指令的處理流程圖如下:
graph LR input[指令輸入]-->parse[決議地址] parse.->pathE>路徑格式錯誤] parse-->instrType{指令型別} instrType--增-->instrAdd[獲取路徑倒數第二級目錄] instrType--查刪改-->instrOther[獲取路徑最后一級目錄/檔案] instrType--遞回創建-->instrMkdirp[遞回創建目錄] instrAdd.->getFileE>目錄/檔案不存在] instrOther.->getFileE>目錄/檔案不存在] instrMkdirp.->typeE>目錄/檔案型別沖突] instrAdd.->typeE>目錄/檔案型別沖突] instrOther.->typeE>目錄/檔案型別沖突] instrAdd-->addOp[增加子目錄/檔案] addOp.->existE>子目錄已存在] instrOther--查改-->modifyOp[操作檔案/目錄] modifyOp.->contentE>檔案內容格式錯誤] instrOther--刪-->delOp[父目錄洗掉此目錄/檔案] delOp.->delPerE>洗掉作業目錄或其上級目錄] style pathE fill:red,fill-opacity:0.1 style contentE fill:red,fill-opacity:0.1 style getFileE fill:red,fill-opacity:0.1 style typeE fill:red,fill-opacity:0.1 style existE fill:red,fill-opacity:0.1 style delPerE fill:red,fill-opacity:0.1因此我們將程式所需實作的功能/模塊列出
-
PathManager: 一個決議路徑的迭代器
a. 通過路徑構造，并在構造時判斷路徑型別(絕對路徑、相對路徑)
b. 將路徑分級（分段），作為迭代器回傳下一級決議出的單級地址 -
FileLike: 檔案類/目錄類的父類，下簡稱類檔案
a. 保存類檔案的基本資訊, 名字，絕對路徑，創建/修改時間，父目錄，大小
b. 自底向上更新檔案/目錄大小 -
Directory: 目錄類，管理子檔案/目錄
a. 對子檔案/目錄進行增、刪、查
b. 向檔案系統提供根據路徑索引檔案/目錄的靜態方法
c. 向檔案系統提供根據路徑索引對應檔案/目錄的父目錄的靜態方法
d. 向檔案系統提供根據路徑遞回創建目錄的靜態方法 -
File: 檔案類，管理檔案存盤內容
a. 追加/覆寫檔案內容
b. 對檔案內容進行轉義以輸出 -
MyFileSystem: 檔案系統類，通過呼叫底層類按指令語意進行操作或拋出例外
我們隨手畫的草稿如下:
最終經過縫縫補補改改刪刪后完成時的UML類圖
而且一條指令的執行程序中可能在流程圖中任一執行階段觸發例外，因此我們使用Java的例外處理機制來處理錯誤輸入，我們所定義的各種例外類如下
由于本次作業不區分不同例外輸入對應的輸出資訊格式，因此只要在MyFileSystem中的方法呼叫程序中catch到相應例外就直接輸出Path x is invaild的錯誤資訊，如果后續需要分辨不同的例外情況，我們只需修改嵌套的try-catch-throw的邏輯即可
b. 具體細節
對于PathManager迭代器的實作，選擇了使用自動機，因為路徑的格式定義比較簡單，所以用自動機撰寫不難，而且可以清楚地考慮到各種特殊情況，并且迭代器分級決議地址時同時進行了格式檢查，所以相比于check + split不需要額外存盤空間
對于"根據路徑索引對應檔案/目錄的父目錄”, 考慮到我們規定PathManager決議完時next()回傳特殊值null，因此只要將目錄分成根目錄、單級目錄、兩級以上的目錄(/, /a, /a/b or a/b/c/......)三種情況分別處理就行了，同時在獲取父目錄結束時決議出最后一級地址（檔案名），Java不能回傳多值，因此封裝了一個資料結構保證只掃一遍地址就okay
對于檔案內容的轉義，我們的實作是在檔案類File中只維護轉義后的檔案內容,在fappend指令中對連接處可能新產生的"@n"作特判
c. 測驗與提交
mytql, 根據他的方法我們在CI / CD運行環境中配置好了maven，并使用jacoco-maven-plugin生成測驗結果報告(一個網頁和一個表格)，最后一次提交得到的測驗報告如下圖
cobetura與jacoco都能得到這種頁面，但在查看分支覆寫率時貌似都只能查看某一分支的遺漏分支數量，并不能了解在條件運算式在何種布爾運算式下是沒有被測驗過的,希望能有dalao指點(
為了代碼覆寫率達標，當然要對各模塊中的例外的拋出也進行測驗啦，我們使用Junit中的函式標注@Test(expected = myException.class)進行拋出例外的斷言，以及在測驗函式中自己手動進行try-catch測驗例外是否如預期拋出
二、關于結對
1.結對形式
現場結對編程的照片:
2.結對流水賬
- 3/22: 摸石過河
- 15:05 - 15:30: 設計與思路交流
- 15:30 - 17:30: 編碼
- 18:21 - 20:20: 編碼
- 20:40 - 22:30: 編碼
- 3/23: 撥云見日
- 15:55 - 18:25: 編碼
- 18:30 - 20:30: 編碼
- 20:51 - 21:20: 總代碼復審
- 3/24: 再復審
- 14:31 - 16:20: 代碼復審 評測 報告
在本階段二人決定角色定位將更有傾向性，但是二人進行了充分的交流，并在一些時間段交換作業，所以都對代碼知根知底，兩人不同角色的作業比例大概都是七三開，本次朱正陽擔任Driver，主要職責是具體源代碼實作，趙子軒擔任Navigator，主要職責是測驗與把握整體設計
3.結對感受
(a) 朱正陽
在第一次結對編程中，我主要擔當的是駕駛員（Driver）的角色，通過這次結對編程，我主要從以下兩方面發表自己的感想
-
關于結對編程
最開始結對的時候效率并不高，我認為原因主要有以下三點
- 兩個人在某些細節上想法有所不同
- 交流上存在一定障礙，有時雙方都無法及時get到對方的點
- 我沒有提前做好準備，許多東西我還需要進一步消化理解
隨著結對不斷進行，雙方交流效率也提高了，任務效率也逐漸高了起來，
結對編程也是一個很好的向他人請教的機會，能夠近距離看到隊友是如何編程的，對于這個問題他又是怎么想的，確實能夠識訓很多，
結對編程還是一個強迫與他人進行思想上的交流以及傳遞自己想法與觀點的程序，
-
關于開發流程
在此前的編程中，我很少將大部分精力放在設計以及測驗上，通過這次結對，我學習到了很多關于單元測驗的知識，也真正認識到了設計以及測驗的重要性，
-
關于隊友
有一個非常靠譜的隊友確實可以大幅提高編程的效率以及質量，隊友的編程習慣比較好，對于程式的架構也把握的很好；在我編程的程序中不斷的指導我，耐心糾正我的很多不良的編程習慣以及冗余；做事比較認真負責，通過這三天的結對編程，我也從他那里學習到了很多東西，這是我一個人編程所做不到的，我很感激能有一個這樣的隊友，因此后續也會一起努力，一起進步
接下來應該還會有第二次第三次結對編程的任務，希望能在之后的任務中繼續向隊友學習，更加放開交流，努力完成任務，提升自己，
(b) zzx
在第一次結對編程中，我主要擔當的是Navigator，我的體會與反思：
紙上得來終覺淺，在親歷Pair之后，我認為Pair最大的好處是提升代碼的質量，畢竟在二人協作時讀懂代碼是交流的先決，總是會不自覺地想去保證代碼的可維護性，我認為好的結對編程需要以下長期的要素: 信任、執行力以及可見的詳盡計劃，
- 關于信任，我想這就是教材里說的道德水平吧，但這更應該是每一個程式員的基本素養，單槍匹馬在以后作業中更是不可能，所以無論是采取何種的合作形式都應該對搭檔給予信任，這是“平等地位”的先決，本次我與zzy全程都在相互支持，并及時進行溝通
- 關于執行力，這是
Pair效率的保證，好在zzy與我都是做事比較投入的那種人，結對現場基本沒有摸魚機會(，但實際上也因此沒有保證每小時都有休息時間，以后一定會協調好時間的 - 關于計劃，這是我們本次有所忽略的，我作為
Navigator沒有給出細致到小時級別、功能級別的編碼計劃，這一方面使得編碼變成了步步為營，另一方面也導致有時二人并沒有是為了同一個小目標而作業，從而降低了作業效率，我決定后續一定要在動手前先制定好作業計劃，磨刀不誤砍柴工
我在本次Pair中發現自己的不足如下:
- 上文3.
- 我向來是不擅長與他人深入交流的baka，因此
Pair實際上是對我的一次考驗，而且我在經常性的交流中更難專注想事情 - 我太菜了，作為編程苦手，想到要6天內完成
OO的“第五單元”就頓感亞歷山大，在擔任Navigator時不能保證總是給zzy正確有效的指引，對于整體架構，在實作時自己卻還在改來改去，在自己寫的一些方法里還Bug頻出 - 本次
Pair之前我對Junit一知半解，但為了能跟上整體代碼的進度，所寫的單元測驗代碼便相當的臭長
總之第一階段的Pair讓我明白了團隊計劃與編碼能力的重要性，希望后續能努力做得更好
三、作業量
1.PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | ||
| · Estimate | · 估計這個任務需要多少時間 | 5 | 5 |
| Development | 開發 | 515 | 1025 |
| · Analysis | · 需求分析 (包括學習新技術) | 30 | 25 |
| · Design Spec | · 生成設計檔案 | 30 | 30 |
| · Design Review | · 設計復審 (和同事審核設計檔案) | 15 | 10 |
| · Coding Standard | · 代碼規范 (為目前的開發制定合適的規范) | 20 | 30 |
| · Design | · 具體設計 | 30 | 30 |
| · Coding | · 具體編碼 | 180 | 480 |
| · Code Review | · 代碼復審 | 30 | 60 |
| · Test | · 測驗（自我測驗，修改代碼，提交修改） | 180 | 360 |
| Reporting | 報告 | 70 | 140 |
| · Test Report | · 測驗報告 | 30 | 60 |
| · Size Measurement | · 計算作業量 | 10 | 20 |
| · Postmortem & Process Improvement Plan | · 事后總結, 并提出程序改進計劃 | 30 | 60 |
| 合計 | 585 | 1170 |
2.碼量
| Java | 總行數 | 代碼行數 | 注釋行數 | 空行數 |
|---|---|---|---|---|
| Src | 918 | 629 | 180 | 109 |
| Test | 745 | 622 | 0 | 123 |
| Total | 1663 | 1251 | 180 | 232 |
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/270921.html
標籤：其他
上一篇：專訪 CNCF 大使王煒：讓云原生開發回歸原始而又簡單
下一篇：源代碼之整潔代碼