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:由于开发出的版本过多,最后没有统一的版本号管理,导致第一次的发布版本险些出现问题,这在实际的软件工程中应该是很致命的低级错误

总结

通过了这学期的软件工程课,我们集体认为于传统的软件工程还是有很多差别的,这也就是习而学与学而习的差别吧.软件工程课还是应该多动手,多时间,多走弯路,才能真正学到东西.只有这种过程,才可以既掌握了相关的理论知识,又掌握了相应的实现能力