M2总结报告
團隊成員
李嘉良 ??http://home.cnblogs.com/u/daisuke/
王熹 ? ??http://home.cnblogs.com/u/vvnx/
王冬 ? ??http://home.cnblogs.com/u/darewin/
王泓洋 ??http://home.cnblogs.com/u/fiverice/
劉明 ? ? ?http://home.cnblogs.com/u/liumingbuaa/
由之望 ??http://www.cnblogs.com/kdoo/
付博揚 ??http://www.cnblogs.com/dabishen/
項目簡介
TimeLine軟件是一款Win8風格一款時間管理軟件，可以用于管理待辦事項，記錄一些需要提醒的信息等。有事件提醒、與Google賬戶同步、
課程表等功能。TimeLine操作人性化，UI界面清新簡潔，使用Win8 Metro風格，小而便捷，占用內存小。 功能 用于管理待辦
事項，事件管理，課程表查詢等功能。可以與Google日歷同步。
發布版本
該發布版本為TimeLine 3.0.1
兼容
兼容Windows xp、Windows7、Win8,32位和64位
新特性
1、?解決方案整個框架重寫
2、?再次改進了頁面風格
3、 優化后臺數據庫，完善課程表功能
4、 增加隱藏功能（最小化到托盤）
5、 增加貼邊功能
6、 增加釘在最上功能
7、 其他Bug修復及優化
?
代碼規范
規范的重要性?
1?????????? 增加開發過程中代碼的強壯性、可讀性、易維護性
2?????????? 減少有經驗和無經驗開發人員編碼所需的腦力工作
3?????????? 為軟件的良好維護性打下好的基礎
4?????????? 在項目組內部易于代碼層面的溝通
5?????????? 使新的開發人員快速的適應項目氛圍
6?????????? 一個優秀而且職業化的開發團隊所必須的素質
?規范制定原則
1 方便代碼的交流和維護。
2 不影響編碼的效率不與大眾習慣沖突。
3 使代碼更美觀、閱讀更方便。
4 使代碼的邏輯更清晰、更易于理解。
列寬 ????
代碼列寬控制在110字符左右。
換行?????
當表達式超出或即將超出規定的列寬遵循以下規則進行換行?????
1、? 在逗號后換行。?????
2、? 在操作符前換行。????
3、? 規則1優先于規則2。????
??????? 當以上規則會導致代碼混亂的時候自己采取更靈活的換行規則。???????
縮進?????
?縮進應該是每行一個Tab(4個空格)不要在代碼中使用Tab字符。
空行
空行是為了將邏輯上相關聯的代碼分塊以便提高代碼的可閱讀性。 在以下情況下使用兩個空行????
1、? 接口和類的定義之間。???
2、? 枚舉和類的定義之間。??
3、? 類與類的定義之間。????????
在以下情況下使用一個空行????
1、? 方法與方法、屬性與屬性之間。????
2、? 方法中變量聲明與語句之間。??
3、? 方法與方法之間。??
4、? 方法中不同的邏輯塊之間。???
5、? 方法中的返回語句與其他的語句之間。???
6、? 屬性與方法、屬性與字段、方法與字段之間。???
7、? 注釋與它注釋的語句間不空行但與其他的語句間空一行。
空格
在以下情況中要使用到空格???????
1、? 關鍵字和左括符 “(” 應該用空格隔開。注意在方法名和左括符 “(” 之間不要使用空格,這樣有助于辨認代碼中的方法調用與關鍵字。多個參數用逗號隔開,每個逗號后都應加一個空格。
2、? 除了 . 之外所有的二元操作符都應用空格與它們的操作數隔開。一元操作符、++及--與操作數間不需要空格。
3、? 語句中的表達式之間用空格隔開。
花括號 - {}???????
1、??? 左花括號 “{” 放于關鍵字或方法名的下一行并與之對齊。???????????????????????
2、??? 左花括號 “{” 要與相應的右花括號 “}”對齊。??????
3、??? 通常情況下左花括號 “{”單獨成行不與任何語句并列一行。
注釋概述
1???????? 修改代碼時總是使代碼周圍的注釋保持最新。
2???????? 在每個例程的開始提供標準的注釋樣本以指示例程的用途、假設和限制很有幫助。注釋樣本應該是解釋它為什么存在和可以做什么的簡短介紹.
3???????? 不要在代碼行的末尾添加注釋行尾注釋使代碼更難閱讀。不過在批注變量聲明時行尾注釋是合適的,在這種情況下,將所有行尾注釋在公共制表位處對齊。
4???????? 避免雜亂的注釋,如一整行星號。而是應該使用空白將注釋同代碼分開。
5???????? 避免在塊注釋的周圍加上印刷框。這樣看起來可能很漂亮,但是難于維護。
6???????? 在部署發布之前移除所有臨時或無關的注釋,以避免在日后的維護工作中產生混亂。
7???????? 如果需要用注釋來解釋復雜的代碼節
8???????? 在編寫注釋時使用完整的句子。注釋應該闡明代碼而不應該增加多義性。
命名概述
名稱應該說明“什么”而不是“如何”。通過避免使用公開基礎實現,它們會發生改變的名稱,可以保留簡化復雜性的抽象層。例如可以使用 GetNextStudent()而不是 GetNextArrayElement()。?
命名原則是
? ?選擇正確名稱時的困難可能表明需要進一步分析或定義項的目的。使名稱足夠長以便有一定的意義并且足夠短以避免冗長。唯一名稱在編程上僅用于將各項區分開。表現力強的名稱是為了幫助人們閱讀,因此提供人們可以理解的名稱是有意義的。不過請確保選擇的名稱符合適用語言的規則和標準。 以下幾點是推薦的命名方法。
1、? 避免容易被主觀解釋的難懂的名稱,如方面名 AnalyzeThis()或者屬性名 xxK8。這樣的名稱會導致多義性。
2、? 在類屬性的名稱中包含類名是多余的如 Book.BookTitle。而是應該使用 Book.Title。
3、? 只要合適,在變量名的末尾或開頭加計算限定符Avg、Sum、Min、Max、Index。
4、? 在變量名中使用互補對如 min/max、begin/end 和 open/close。?
5、? 布爾變量名應該包含 Is這意味著 Yes/No 或 True/False 值如 fileIsFound。
?
團隊項目進展(燃盡圖)
?
?
團隊成員貢獻
?
?
先上瀏覽量和下載量
一共發布了三個版本，截圖如下：
NO.1 第一次發布
No.2 第二次發布
NO.3 第三次發布
值得說明的是，前兩次都是在同一個晚上截得的結果，基本就是水木社區的固定用戶的使用情況，隨著時間遷移，水木用戶的活躍度基本降到了0。之后的宣傳集中在學校和我們的老同學之間，基本上都是看的多，下的少。
之后上大家的評價
NO.1 來自水木版主的評價（給版主發了一封站內信希望暫時置頂，版主給予了好評，但置頂后增加的效果并不明顯）
NO.2 校內論壇的評價（保證無槍手，其余評價都是寫沙發板凳什么的）
NO.3來自水木網友的評價
這里的評價比較多，截圖太麻煩，語言總結一下：大部分還是給予好評，但也給出了許多好的建議
建議1：單純的桌面軟件可能不太好用，希望有移動版
建議2：不要使用framework
建議3：希望能強化Google candler部分的功能
上討論圖
事后諸葛亮會議
?
問題1:雖然開始做出了計劃,但是考試加上各種大作業,使得我們在10天的代碼工作之后的時間里工作有些混亂,沒有確定的計劃,導致新添加的功能測試不夠,出現了一些bug
問題2:第一次發布軟件,沒有什么經驗,只在水木社區,未來花園,人人網做了發布推廣,但是cnbeta實在是沒有搞明白該怎么發布(感覺那是個做新聞的網站,不知道怎么發帖啊)
問題3:工作分工雖然很明確,但由于小組成員的水平有差距,有些任務還是不能嚴格執行,需要大家互相幫助才能夠客服,這需要我們不斷提高自己的實力才行
問題4:由于開發出的版本過多,最后沒有統一的版本號管理,導致第一次的發布版本險些出現問題,這在實際的軟件工程中應該是很致命的低級錯誤
總結
通過了這學期的軟件工程課,我們集體認為于傳統的軟件工程還是有很多差別的,這也就是習而學與學而習的差別吧.軟件工程課還是應該多動手,多時間,多走彎路,才能真正學到東西.只有這種過程,才可以既掌握了相關的理論知識,又掌握了相應的實現能力
轉載于:https://www.cnblogs.com/WWW-Buaa/archive/2013/01/07/2848930.html
總結
- 上一篇： 统计通话次数和时间的软件_通话时间统计a
- 下一篇： 三、Multisim放置门电路