团队作业第二周
目录
需求规格说明书
修改与完善
-
组员分工调整：我们组第一周的任务分配是两人负责布局，两人负责数据库与服务器的搭建，一人负责内部代码的编写。但在任务执行过程中，发现当下最急迫的需求是提前做好大体布局，于是对组员的分工作了如下调整，并进一步具体化了每个组员的任务。
- 冷冲：任务清单界面的布局（侧滑组件的涉及，任务星标功能，下拉刷新）
- 张端云：登陆注册界面的完善与美化（组件的半透明度，布局间的比例，背景图的设置）
- 董其鹏：新建任务界面的大体布局（日历功能，选择课程功能）
- 陆彦杰：新建任务界面的进一步优化（时间选择器，背景图的设置，布局间的比例调整，弹窗）
- 郑力元：LeanCloud云端数据库的搭建与本地安卓的连接（数据库的增删查改、更新操作，注册登录界面布局与代码的结合）
-
需求规格说明书格式调整为Markdown
小组代码规范
核心原则
- 1.代码应该简洁易懂，逻辑清晰
- 不要过分追求技巧，降低程序的可读性
- 简洁的代码可以让bug无处藏身。要写出明显没有bug的代码，而不是没有明显bug的代码
- 2.面向变化编程，而不是面向需求编程
- 3.先保证程序的正确性，防止过度工程
- 过度工程（over-engineering）：在正确可用的代码写出之前就过度地考虑扩展，重用的问题，使得工程过度复杂
命名规范
类命名
- 首字母大写，每个单词首字母大写（大驼峰命名法）
- 尽量使用能够反映类功能的名词短语
- eg：UserManage ,UserData等
- 控件类型直接使用尾端的驼峰单词
- eg：UIView -> xxxView
- eg：UIButton -> xxxButton
- 类名过长，取中间的单词作为尾端
- eg:UIActivityIndicatorView -> xxxActivity
方法命名
- 首字母小写，之后每个单词首字母都大写(小驼峰法命名法)
- 方法名使用动词短语
- 如果该方式对内部使用的在前面加 "_"
- eg: (void) _loadData{}
- 如果该方法对外使用不需要加“_”
- eg: (void)viewDidLoad{}
- 如果该方式对内部使用的在前面加 "_"
变量命名
- 首字母小写，之后每个单词首字母都大写
- 具有足够的说明性
- 成员变量不需要添加“_”前缀
- 成员变量添加“_”前缀
- eg：NSMutableDictionary *_dataDic;
注释
- 在方法内部注释的地方使用 //即可
- 在方法上或属性注销的要用文档注释 com+sh+.
- 文件下的方法区域分类，使用#pragma mark -，可以把在文件路径下的方法分类并标记
- eg：#pragma mark - Http
理由
- 由于本项目是团队协作完成，代码的规范可以极大的促进团队之间的合作效率。如果代码不规范统一，那么就会出现每个人代码风格迥异的情况，当多人开发同一模块或需要整合分工的合作时，团队代码之间的理解就会由于可读性差而变得很困难。所以，统一代码的规范显然在团队开发的过程中是非常有益且必要的。
团队项目的数据库设计及相应ER图
后端架构设计
团队分工
象限法确立核心优先级
Leangoo子功能工作分配
ToDolist与燃尽图
分工与工作量比例
| 成员 | 任务 | 比例 |
|---|---|---|
| 冷冲 | UI设计，美化页面 | 20% |
| 张端云 | UI设计，美化页面 | 20% |
| 陆彦杰 | 内部代码，部分布局 | 20% |
| 郑力元 | 云数据库操作 | 20% |
| 董其鹏 | 内部代码，部分布局 | 20% |