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:由于開發出的版本過多,最后沒有統一的版本號管理,導致第一次的發布版本險些出現問題,這在實際的軟件工程中應該是很致命的低級錯誤

總結

通過了這學期的軟件工程課,我們集體認為于傳統的軟件工程還是有很多差別的,這也就是習而學與學而習的差別吧.軟件工程課還是應該多動手,多時間,多走彎路,才能真正學到東西.只有這種過程,才可以既掌握了相關的理論知識,又掌握了相應的實現能力