homework -03
ps:為毛在首頁顯示的時候一點文件格式都木有了.........
請點開文章看吧還是~!
結對程式設計人員:
11061190 李孟 Lmeng
11061192 周敏軒 Z-Mac
11061193 薛亞傑 VeryBigMan
我們三個人將以下材料仔細閱讀，覺得十分受益。下面是我們的總結和分享：
1）程式碼規範與程式碼複審
程式碼規範：一句話，我們的程式碼是要讓其他人輕易看懂。
這就要求什麼？
當我們拿漢語來作類比的時候，我們就能理解這個問題。為什麼我們能交流無障礙？因為所有中國人都看得懂中文字！為什麼？因為有一本字典（其實就是規範）告訴我們哪個字是什麼意思，組成一個詞又是什麼意思？這個詞怎麼讀？有些方言沒有字典怎麼辦？不成文的約定！雖然沒寫在紙上，但是大家都知道這是什麼意思。而歷史流傳保留下來的這些語言，之所以還能保留，自有它的道理（不是語言學家，只能這麼搪塞，估計是它的易記易理解吧）。程式碼就是人使用程式語言寫出來的一段話，別人一看就能理解。就像別人一聽你說話就知道你在說什麼，你在這個群體中才能無障礙生存一樣，你所寫的程式碼才能被大家所接受。規範，不就是有點科學道理的習慣嗎？這樣做好，大家都這樣做去，都接受了不就是規範了嗎？
下面我們來列舉幾個被推薦的程式碼規範：
縮排：4個空格
括號：在邏輯複雜的地方用括號清楚地區分優先順序
分行：不要把不同的變數定義在一行上
命名：匈牙利法
具體還是參見偉大的鄒老師部落格 吧。。
程式碼複審：
看程式碼是否在“程式碼規範”的框架內正確地解決了問題。
查查程式碼再調bug，也許bug已經少了很多了。還有，一般人對於自己寫的程式碼“喜愛有加”，找小夥伴幫你看看吧~
2）結對程式設計
結對程式設計，可以說是一個新穎又熟悉的概念。新穎，在於我們這學期才開始接觸到這樣一個說法；熟悉，在於我們已經在《軟體工程》課上實踐了這樣一種方法。結對程式設計是極限程式設計的其中一種具體方法。所謂極限程式設計，就是將所有有效的好的方法發揮到極致！而所謂結對程式設計，從形式上理解就是，一對程式設計師肩並肩地、平等地、互補地進行開發工作。兩個程式設計師並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤，同一個滑鼠一起工作。他們一起分析，一起設計，一起寫測試用例，一起編碼，一起單元測試，一起整合測試，一起寫文件等。對，合二為一！我們可以看到生活中很多例子：
越野賽車（駕駛，領航員）
駕駛飛機（駕駛，副駕駛）
戰鬥機的編組（長機，僚機）
這些工作都極具挑戰性和危險性，不容閃失。領航員發出準確指令告訴駕駛員方位、速度，駕駛員馬上反應並精確操作，這是他們成功的關鍵。在比賽的時候他們是將兩個人的兩個腦子，兩個人的兩雙眼睛，兩個人的雙手合併成：一個人的兩個腦子，一個人的四隻眼睛，一個人的四雙手！（說的有點恐怖了。。。但是這不就是特異功能嗎？不就是強大的外星人嗎。。？）而當我們從具體工作上去理解結對程式設計的時候，我們發現結對程式設計可能主要在於這樣幾點優勢：
a)工作熱情。相信我們每個人都有這樣的經驗，當有一個人和你並肩作戰的時候，你能工作得更久更有熱情！這個激情貫穿在我們三個人本次結對程式設計作業的始終！(雖然是三個人，只要踐行結對程式設計的理念就該算是結對程式設計)。
b)程式碼錯誤率低。當自己一個人碼程式碼，即便是寫文件，你總會有疏忽大意的地方。你也許著急把它寫完，但當這時有個人在你背後仔細看著你螢幕上被敲出來的符號，不說大的，小的毛病比如大小寫、標點符號，這種在後期也許可能讓你調了3天最後吐血的錯誤就很大可能在被輸入的2s內被刪除！總之，兩個人盯著，比一個人瞎打好多了！
c)難題解決率高。結對程式設計有利於解決難題，原因在於一方面是兩個腦子在思考，碰撞還能出火花。一方面是意志的相互鼓舞、激勵!
當然，好方法要用在好地方。當一個人是計算機系大牛的，一個人練vs都不知道怎麼開啟，怎麼結對？配對還行。。
3）給人提意見的方式-送一個漢堡包
說道漢堡包，實在是老生常談了。“三明治”，“漢堡包”，或許。。。“肉夾饃”，都一個意思。就是告訴你說話要委婉。先揚後抑再揚，先找出可誇讚的點，先表揚下。以讓暴風雨來得不那麼難以承受。接下來把真正要說的話說出來，說的時候還不能太直接。最後說兩句好聽的，給個臺階下。同是程式猿，相煎何太急啊。
例如：（小X在辦公室裡開小差）
領導：今天開會之前呢，我首先要表揚下小X，他每天都在辦公室待到很晚才回家。這種精神是非常值得表揚啊。不過小X啊，可能你這個效率還有待提升啊。如果在辦公室裡能夠更加專心地做工作，不用太多，加一點點（做手勢，右手食指與大拇指捏攏，表情到位）就好，我是說你已經很棒了，只需要再加一點點，你的工作會更加的出色。這樣你可以早點下班，回家休息。也有助於你身體健康啊。工作重要，也不能虧待身體啊！
當然，還可以以關心的口吻表達你的意見。
例如：（小x工作不上心，拖團隊進度）
領導：小x啊，你最近工作進度有點落後了，這段時間是不是家裡有什麼事兒？看你心情也不是特別開朗？沒事，我雖然是你領導，但是我更是你朋友。有什麼情況直接跟我說，我能幫你的我肯定做到。你看呢，我們們這進度也一直比較趕。大家都在拼命幹活。你趕緊把你的問題處理了，平復下心情，抓緊回到隊伍中來啊。如果有特殊情況，不要藏在心裡，我們們這麼多人呢。大家是一個團隊，就是一家人。
以上。
要求的部分:
你現在使用的程式碼規範是什麼, 和上課前有什麼改進?
homework-2我們用的是c++,現在用的程式碼是c#,因為對於UI的設計,基於c++的MFC我們不會用,而且我們本身對於全是大寫字母的變數命名很是恐懼,很多情況下本來是同樣的單詞但是如果變成大寫字母就好像不認識了一樣,另一點我們也不知道正不正確,但好多地方都在說微軟已經基本放棄MFC這邊了;這次使用的語言是c#,雖然c#這門語言我們是第一次接觸,但是因為有一點點java的基礎所以對於用winform來跑UI還是駕輕就熟的
現在使用的程式碼規範...餓...除了UI部分的設計,演算法方面還是基本上是程式導向的思想,UI方面不可避免的要用的Form類啊各種控制元件類啊等等等等
後來根據老師的提示,我們採用了將maxsum邏輯封裝成類庫,在form中單純呼叫的方式,這樣可以保證maxsum這部分邏輯在其他程式碼中也可以使用,也在一定程度上體現了一點點物件導向的思想
你的同伴有哪些優點 (列出至少三點)， 和那些需要改進的地方 (列出至少三點)
Z-Mac:
優點:
程式碼能力強
debug能力強
為人平和
需要改進的地方:
惰性需要克服
和我們一樣不會將3D模型與陣列資料結合..或者說沒有投入那麼多經歷去搞..
這種神犇作為實驗室的紅人+單詞狂魔......在有限的時間就能完成巨大的工作量,實在是可怕至極
Lmeng:
優點:
文件組織能力強
資料搜尋能力強
作為團隊leader協調能力強
需要改進的地方:
演算法實現能力
和我們一樣不會將3D模型與陣列資料結合..或者說沒有投入那麼多經歷去搞..
孟神作為六系一等一的大忙人...孟神在別人睡覺的時候在忙,在別人睡醒的時候依然在忙碌..
你的程式碼從 作業2 到 作業3 經歷了哪些變化? 哪些程式碼需要重構 （看關於程式碼重構的資料）, 哪些需要重寫, 為什麼？
首先因為作業3中要求將選取的最大子陣列標註出來,所以演算法部分就必須要記錄最大子陣列的位置,於是這一部分我們有了一些變化;
c++->c#關於陣列的定義需要有改變;c++->c#對於輸入檔案錯誤的處理也簡單了一點,因為c#只有readline,所以這裡我們採用了string的split方法處理輸入
需要重構的部分...不知道完全設計UI算不算重構...還有就是每個計算最大子陣列的地方都需要稍微改進記錄最大子陣列位置的地方
還有就是將maxsum部分封裝成類庫
重寫的部分就是關於輸入的處理...還有就是我們要用一個標記陣列mark[,]來記錄我們需要標註的地方
你的設計是如何保證 不同的 maxsum.exe 命令列最後在一個GUI 的介面顯示的? (C++ 的設計模式中有 singleton 的概念, 說明一個類的例項如何在一個程式中保持單例, 我們這裡談的是軟體如何在作業系統中保持 singleton)
這個單例模式是我們第一次聽說,也是第一次實踐.
相比較而言如果在程式啟動之後,單純的新增tabpage會簡單許多,但這裡的要求多次啟動程式只會有一個程式在執行,每次程式執行的結果以新的tabpage的方式呈現,就是一個比較大的難點了..
我們查閱了許多資料,也實踐了很多方法,去csdn求助過,在圖書館看了大量的書,失敗過好多次,最後針對這一問題我們才用了c#的訊息處理機制來實現
首先第一點，
Process current = Process.GetCurrentProcess();
var runningProcess = Process.GetProcessesByName(current.ProcessName).FirstOrDefault(p => p.Id != current.Id);
利用runningProcess是否為null來判斷是不是首次執行該程式,如果是首次執行,那麼直接new 一個Form類的例項就好;如果不是首次執行,那麼就需要sendMessage,然後在Form1.cs中對於Message進行相應處理就好.這裡遇到的一個大的問題是我們需要將Main函式的命令列引數傳入,而Message的LParam本身是個很奇葩的型別,我們搜了很多資料之後查到這裡我們需要新定義一個結構體然後傳遞這個結構體的指標;我們曾經嘗試過在結構體中定義stirng[]陣列來傳args[],但是失敗了,最後我們決定將args[]用space分隔拼接成一個string傳入,然後在Form1.cs中進行相應的字串處理就好,nice !succeed!
在Form1.cs中定義一個全域性的TabControl,在Form的建構函式和訊息處理WndProc中分別構建一個新的tabpage然後跑演算法畫圖就好,這樣就成功的實現了c#中的單例模式,好頂贊!
當然, 請繼續記錄時間的估計和你實際的用時:
| Personal Software Process Stages | 時間百分比(%) | 實際花費的時間 (分鐘) | 原來估計的時間 (分鐘) | |
| Planning | 計劃 | 2.0 | 45 | 60 |
| · Estimate | · 估計這個任務需要多少時間，把工作細化並大致排序 | 2.0 | 45 | 60 |
| Development | 開發 | 88.7 | 2000 | 1500 |
| · Analysis | · 需求分析 (包括學習新技術) | 2.7 | 60 | 60 |
| · Design Spec | · 生成設計文件 | 0 | 0 | 0 |
| · Design Review | · 設計複審 (和同事稽核設計文件) | 0 | 0 | 0 |
| · Coding Standard | · 程式碼規範 (制定合適的規範) | 5.3 | 120 | 60 |
| · Design | · 具體設計 | 5.3 | 120 | 60 |
| · Coding | · 具體編碼 | 62.1 | 1400 | 1200 |
| · Code Review | · 程式碼複審 | 10.6 | 240 | 60 |
| · Test | · 測試（自我們測試，修改程式碼，提交修改） | 2.7 | 60 | 60 |
| Reporting | 總結報告 | 9.3 | 210 | 60 |
| · Test Report | · 測試報告 | 5.3 | 120 | 0 |
| · Size Measurement | · 計算工作量 | 1.3 | 30 | 0 |
| · Postmortem & Improvement Plan | · 事後總結, 並提出改進 | 2.7 | 60 | 60 |
| Total | 總計 | 100% | 總用時 | 總估計的用時 |
| 2255 | 1260 |
以下是這次開發的總結:
先傳一張圖，這次的homework-03我們忙了三天左右,第一天從零開始學習c#將Homework-02的程式碼從c++移植到c#上,第二天架構了整個UI的設計,並實現了單例模式除外的基本功能,第三天費勁曲折實現單例模式並除錯完全,最終看到成果跑出來之後真的是非常激動.
這次的UI設計我們一開始嘗試查詢有沒有現成的表格控制元件,貌似沒有找到?那個datagrid貌似是連資料庫的?而我們對資料庫根本一竅不通...後來想到乾脆用畫筆pen畫線然後用絕對定位填label...後來發現label我們無法解決互相遮蓋的問題,最後決定用Button,並且發現如果用Button完全可以省略畫線過程,於是最後的UI就像圖示這樣,TabControl中的Tabpage上面動態新增button和狀態列,nice美工!
關於選做題:選做題部分要求建立一個3D模型,通過滑鼠操作實現對游泳圈模型的旋轉移動等操作.
由於之前沒有3D建模的基礎,我們蒐集了好多資料,最後決定使用WPF來進行3D設計
現在的進度是理解了light和camera模型,能夠處理簡單立方體的旋轉操作
但對於單單構建一個單純的游泳圈,還是沒有什麼思路...
後來我們學會了用ZAM 3D構建圓環模型,就像這樣
但是還是不會將陣列資料與3D模型結合。。。
