項目 | 內容 |
---|---|
課程班級博客連接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
這個做業要求連接 | http://www.javashuo.com/article/p-zkvgqdwq-mk.html |
個人課程學習目標 | (1)體驗軟件項目開發中的兩人合做,練習結對編程(Pair programming); (2)掌握Github協做開發程序的操做方法。 |
這個做業在哪些方面幫助我實現課程目標 | 漢堡包法的溝通方式讓咱們更準確地瞭解到對方的觀點和理由,讓結對編程過程更加有趣。 |
結對方學號-姓名 | 王之泰-201771010131 |
結對方本次博客做業連接 | http://www.javashuo.com/article/p-yajscchd-ns.html |
本項目Github的倉庫連接地址 | https://github.com/YHwzt/Query-system-web |
概要部分
(1)代碼符合需求和規格說明麼?
答:符合需求與規格。
(2)代碼設計是否有周全考慮?
答:周全。
(3)代碼可讀性如何?
答:易讀,備註很詳細。
(4)代碼容易維護麼?
答:容易。
(5)代碼的每一行都執行並檢查過了嗎?
答:檢查部分。
設計規範部分
(1)設計是否聽從已知的設計模式或項目中經常使用的模式?
答:是。
(2)有沒有硬編碼或字符串/數字等存在?
答:有。
(3)代碼有沒有依賴於某一平臺,是否會影響未來的移植(如Win32到Win64)
答:沒有依賴,不會影響。
(4)開發者新寫的代碼可否用已有的Library/SDK/Framework中的功能實現?在本項目中是否存在相似的功能能夠調用而不用所有從新實現?
答:能夠實現,不存在。
(5)有沒有無用的代碼能夠清除?
答:基本沒有。
代碼規範部分
(1)修改的部分符合代碼標準和風格麼?
答:符合。
具體代碼部分
(1)有沒有對錯誤進行處理?對於調用的外部函數,是否檢查了返回值或處理了異常?
答:查閱資料並討論之後處理完成,檢查並處理了。
(2)參數傳遞有無錯誤,字符串的長度是字節的長度仍是字符的長度,是以0開始計數仍是以1開始計數?
答:沒有錯誤,字符串的長度是字節的長度,是以0開始計數。
(3)有沒有可能出現死循環?
答:沒有出現死循環。
(4)有沒有使用斷言(Assert)來保證咱們認爲不變的條件真的知足?
答:沒有使用。
(5)對資源的利用,是在哪裏申請,在哪裏釋放的?有沒有可能致使資源泄露?
答:資源是在網上找到的,不會致使資源泄漏。
(6)數據結構中是否有無用的元素?
答:沒有無用的元素。
效能
(1)代碼的效能(Performance)如何?最壞的狀況是怎樣的?
答:代碼簡潔易懂,程序運行正常,功能齊全。
(2)代碼中,特別是循環中是否有明顯可優化的部分?
答:代碼在以前基礎上已經作過優化處理,目前沒有明顯可優化部分。
(3)對於系統和網絡調用是否會超時?如何處理?
答:不會。
可讀性
代碼可讀性如何?有沒有足夠的註釋?
答:代碼註釋詳細,可讀性強。
可測試性
代碼是否須要更新或建立新的單元測試?
答:目前不須要。html
-- 覈查表模板引用自《構建之法-現代軟件工程》git
要求設計開發一款符合我校疫情防控工做需求的信息系統,使之具備如下功能:github
(1)可採集全校各種師生員工疫情信息;web
(2)各二級部門疫情防控工做負責人可查看本部門人員疫情彙總,並提供高級查詢功能進行多屬性組合查詢和可視化統計功能;數據庫
(3)學校防控辦指定負責人登陸《西北師範大學疫情防控信息統計》子系統,可瀏覽全部人員填報彙總數據清單,利用【高級查詢】可進行數據組合篩選,系統以圖形化方式展現各學院已填報和未填報學生統計狀況和關鍵疫情數據統計狀況,可【導出】查詢列表的EXCEL文件;編程
(4)人機交互界面要求GUI界面(WEB頁面、APP頁面均可);windows
(5)附加分功能:定時填報提醒。設計模式
咱們團隊認爲,需求分析就是剖析客戶棱模兩可的需求,將其細緻化,可實行化。據整體需求來看,咱們發現該項目要求有三類人,第一類人只具備填報功能,第二類人可以進行各自範圍的查看彙總,而第三類人則至關因而一個「全能」的人。因此在數據庫中咱們將各種角色設計爲一張表,將疫情信息設計爲一張表,一共兩張表。微信
第一個功能,要求能採集全校學生/教職工的疫情信息。咱們將其抽象爲第一類人,具體應該爲設計能填寫包含一些我的疫情相關信息的表單並將其提交給後臺。除此以外應該不具備查看修改(除了本身填寫的信息)等功能。網絡
第二個功能,要求各二級部門疫情防控工做負責人可查看本部門人員疫情彙總,並可以進行多屬性組合查詢和可視化統計功能。這個需求的角色也就是咱們抽象化的第二類人,該類角色不可以進行增刪改等功能,即只能查看彙總和數據可視化,就現實生活來看該類角色至關於一個彙總人員,考慮到數據真實性等因素,該類角色沒有刪除增長的權限。
第三個功能,要求學校負責人登陸子系統,可瀏覽全部人員填報彙總數據清單,可進行數據組合篩選查詢,以圖形化方式展現各學院已填報和未填報學生統計狀況和關鍵疫情數據統計狀況,可【導出】查詢列表的EXCEL文件。這個角色也就是第三類人,該角色除了可以進行增刪查改等功能外,還能導出表格,以及對數據進行可視化分析。
第四個功能,人機交互界面要求採用GUI,這個不難實現,可採用app和web等多種多樣的頁面實現
附加功能,這個功能,我和同伴討論了好些時間,由於形式多種多樣,他以爲這個功能沒有必要,由於若是足夠重視這件事的話,忘記的可能性實際上是很小的,並且基本每一個人都有手機,手機上最基礎的一個功能就是鬧鈴,本身設置個鬧鐘,方便了開發者也能夠提醒本身。而我認爲這個功能仍是有必要的,好比本身沒有設置鬧鐘,在忙其餘事情的時候忘記了填寫時間,因此咱們最終仍是決定選擇一種形式提醒一下填報人員。咱們構思了不少種方法,例如:經過用微信公衆號作一個天天的定時提醒填報等等,但最後咱們選擇的是採用郵件提醒的方式,定時給用戶發送一個填報提醒。
2019年12月末,中國武漢發生新型冠狀病毒(2019-nCoV) 感染的肺炎疫情,爲遏制疫情蔓延,有效切斷病毒傳播途徑,在中央政府指導下,各級政府部分採起了一系列防控措施: 2020年1 月23 日10時起對武漢「封城」,全國 31個省市也相繼實施了嚴格的防控措施;全國各省市向武漢和湖北派遣醫療隊參與救治工做;在全國範圍內調配口罩、防禦服、藥品等急需的醫療資源支援武漢;指導和督促全國範圍內擁有醫療物資生產資質的企業儘快恢復生產能力;定向撥付專項財政資金用於疾病防控;從其餘省份調集物資保障武漢市民平常生活。
值得一提的是,中國互聯網企業在這次疫情防控中發揮了社會治理方面的重要做用。以騰訊爲例,圍繞應對疫情管控需求開發了十一款產品。其中疫情在線問診功能,對於減小發熱病人之間的相互交叉感染具備重要的做用,患者在家經過互聯網向在線醫生問診,減小了病毒傳播或感染的風險;謠言粉碎對於公衆採起理性態度看待疫情的發展具備重要意義。滴滴出行還在武漢專門組建車隊,服務於醫護人員的通勤,這在實施交通管制的武漢具備重要做用。此外,還有新型肺炎確診患者同行程查詢工具,用戶只須要輸入本身所乘坐交通工具的時間和班次,就能夠確認是否與被確診感染者同行,提早作好自我隔離和就診工做。在疫情防控中,中國互聯網企業不只發展壯大,在承擔社會責任方面也愈來愈成熟。
爲有效配合防控機構有關疫情信息的採集、統計與排查,我校開發了教職工/學生疫情上報系統,該系統由教職工疫情每日上報、學生疫情每日上報、二級部門疫情每日彙總表、疫情防控填報統計四個子系統組成。實現對我校各種人員基本狀況、所在區域及活動軌跡及健康情況的信息收集。師生經過我校企業微信服務大廳訪問該系統進行遠程信息填報。
(1)設計三級註冊登陸功能,並對每一個級別用戶作出功能使用的限制。 (2)系統主要有註冊模塊,登陸模塊,填報模塊,查詢模塊,導出模塊,提醒模塊六大塊構成。 (3)接口設計 1)外部接口 用戶界面: 在界面設計上,採用簡單明瞭,易於操做的原則,突出的顯示重要信息。 軟件與硬件接口: 本系統設有GUI界面,考慮到操做簡單, 易於管理方面,主要硬件接口設備爲PC,鼠標,鍵盤。而軟件接口主要以 windows 平臺爲基本平臺。 2)內部各模塊之間相互獨立又彼此關聯,主要經過方法調用實現各部分的鏈接。 (4)數據結構設計 設計兩張結構表:用戶信息表和疫情信息表。
(1)可採集疫情信息;
(2)各二級角色可查看本部門人員疫情彙總,並提供高級查詢功能進行多屬性組合查詢和可視化統計功能;
(3)三級角色,可瀏覽全部人員填報彙總數據清單,利用【高級查詢】可進行數據組合篩選,系統以圖形化方式展現各學院已填報和未填報學生統計狀況和關鍵疫情數據統計狀況,可【導出】查詢列表的EXCEL文件;
(4)人機交互界面要求GUI界面(WEB頁面、APP頁面均可);
(5)定時填報提醒功能。
定義用戶類(User),聲明私有變量private的序號(id),姓名(username),密碼(Password),用戶類型(type),和封裝各自屬性的方法:set(),get(),由於屬性私有,不可直接訪問,例如id在外邊不可直接設置,可經過setId方法來設置id的值,getId獲取id的值。
定義信息類(virus),聲明私有變量學院(college),班級(myclass),填報日期(startdate),姓名(username),聯繫電話(tel),省(province),市(city),區(areas),留學生(ischinesestudent),武漢學生(iswuhanstudent),湖北學生(ishubeistudent),14天接觸(is14contact),在武漢(isinwuhan),在湖北(isinhubei),今天返校(istodayformother),疑似(islikevirus),確診(isconfirmvirus)。
beans類爲Javabean類,config配置類,mapper爲dao類,service服務類,每類只負責一項職責,每一個方法完成一個計算,程序邏輯簡單,對類有較高的可讀性。設計接口時,給每個接口按必定比例設計分配方法,減小代碼冗餘。且高層模塊不依賴低層模塊。
/** * 將數據寫入到excel中 */ public static void makeExcel(List<List<String>> result,String[] tittle) { try { // 建立一個workbook對應一個excel文件 HSSFWorkbook workbook = new HSSFWorkbook(); // 在workbook中建立一個sheet對應excel中的sheet HSSFSheet sheet = workbook.createSheet("病例日期表"); // 在sheet表中添加表頭第0行,舊版本poi對sheet的行列有限制 HSSFRow row = sheet.createRow(0); // 建立單元格,設置表頭 HSSFCell cell = null; for (int i = 0; i < tittle.length; i++) { cell = row.createCell(i); cell.setCellValue(tittle[i]); } // 寫入數據 for (int i = 0; i < result.size(); i++) { List<String> oneData = result.get(i); HSSFRow row1 = sheet.createRow(i + 1); //建立單元格設值 for (int j = 0; j < oneData.size(); j++) { row1.createCell(j).setCellValue(oneData.get(j)); } } //將文件保存到指定的位置 FileOutputStream fos = new FileOutputStream("D:\\result.xls"); workbook.write(fos); System.out.println("寫入成功"); fos.close(); } catch (Exception e) { e.printStackTrace(); } }
基本功能
(4)人機交互界面要求GUI界面
WEB頁面
附加功能
PSP2.1 | 內容 | 計劃完成須要的時間(min) | 實際完成須要的時間(min) |
---|---|---|---|
Planning | 計劃 | 30 | 40 |
Estimate | 估計這個任務須要多少時間,並規劃大體工做步驟 | 30 | 40 |
Development | 開發 | 1100 | 1330 |
Analysis | 需求分析 (包括學習新技術) | 60 | 180 |
Design Spec | 生成設計文檔 | 30 | 30 |
Design Review | 設計複審 (和同事審覈設計文檔) | 60 | 50 |
Coding Standard | 代碼規範 (爲目前的開發制定合適的規範) | 30 | 40 |
Design | 具體設計 | 240 | 200 |
Coding | 具體編碼 | 500 | 600 |
Code Review | 代碼複審 | 60 | 50 |
Test | 測試(自我測試,修改代碼,提交修改) | 120 | 180 |
Reporting | 報告 | 120 | 180 |
Test Report | 測試報告 | 40 | 60 |
Size Measurement | 計算工做量 | 40 | 30 |
Postmortem & Process Improvement Plan | 過後總結 ,並提出過程改進計劃 | 40 | 90 |
這是我第二次以結對編程的形式來完成項目,相比於第一次結對編程帶給個人新鮮感,此次結對編程給我帶來了不少收穫,不只學會了如何更好地和同伴去溝通交流,還學會了不少新知識。我本身的編程能力和知識儲備都比較差,在結對編程中,我發現個人同伴不只對基礎知識掌握牢固,並且動手能力強,不少時候都是在他的引導下,項目一步步實現,他身上有不少值得我學習的地方。 對於「兩人合做是否真的可以帶來1+1>2的效果」這個問題,我經過本次的結對編程認爲:兩我的合做完成一個項目,要比起本身單獨去完成效果好不少,不只會減輕雙方的工做量,並且每一個人對於同一個事物都會有不一樣的想法,在溝通和交流以後,每每最後呈現的是兩我的好的想法的集合體。而且每一個人擅長的地方不同,在合做中,能夠最大化發揮本身的優勢,同時也能夠從對方身上學到不少本身不擅長的技術。