十分宠爱--凡事预则立
【十分宠爱-凡事预则立】
前言
凡事豫（预）则立，不豫（预）则废，豫者预也。 ———《礼记·中庸》
这句话道出了这样的道理：做任何事情，事前有准备就可以成功，没有准备就会失败。说话先有准备，就不会词穷理屈站不住脚；行事前计划先有定夺，就不会发生错误或后悔的事。
在这里我们迎来了团队的第五次作业——项目冲刺！
在这篇随笔中，在项目冲刺之前，我们在这里做一些准备和计划，为后面的冲刺提供指引与方向，为更好做出项目做一定的保障。
1.冲刺的时间计划安排
冲刺时间为期七天，我们计划安排在11月7日到11月13日之间。在此之前做一些先期的准备与学习。（要学的东西实在是太多啦555
团队项目开发预期安排
| 日期 | 目标 |
|---|---|
| 11月1日 | 系统设计和数据库设计完成，博客撰写完成 |
| 11月2日 | 团队演讲PPT，课程结束后开会讨论问题，明确方向 |
| 11月3日——5日 | UI设计出界面样本，明确具体功能实现，其他人进行自己模块的准备工作 |
| 11月6日——11日 | 前端后端进行对应的编程工作，同时对设计不足之处进行反馈和修改 |
| 11月12日 | 进行自己设计部分单元测试，找出bug并修改 |
| 11月13日 | 相互之间进行测试，防止固有思维产生的bug，并进行告知和修改 |
| 11月14日 | 前后端接口连接，同时进行测试，找出bug并修改 |
| 11月15日 | 进行答辩PPT准备 |
2.针对提出的问题的回答
问题回答Q&A
Q1：流程图不清晰
A1:可能是PPT展示时候的原因，我们进行了加粗加字号的改正！
Q2:用户的评论点赞等要在数据库中体现出来
A2:在数据库中我们有体现帖子的评论点赞数，但是没有转发记录，以进行改正
Q3:流程图看不太清楚
A3:亲请看A1回答
Q4:宠物店具体信息都有什么呢？
A4:在原形中我们没有体现出来，这里解释：宠物店里会有店名，地址，评价，评分，提供服务等内容。
Q5:如果寄养宠物的过程中，宠物的主人和寄养的人发生了矛盾，你们将怎样调解呢？
A5:我们只提供这样一个平台，这样细节的问题我们在大的方面做不了什么。但是我们有一定的举报机制，到出现矛盾用户可以收集证据进行举报，平台会一定程度降低被举报人的信誉度甚至拉黑处理。
Q6:各种流程图都过小，比起美观的插图，希望能更突出要展现的产品内容
A6:嗯嗯我们会改正的，下次一定更大的重点！
Q7:PPT模板不错，发我一份！
A7:好的呢亲！
Q8:如何维护宠物百科的内容
A8:首先宠物百科是有一定权威的内容信息，一般很少出现这样的问题。如果出现了这些问题，用户可以在论坛分享出来，管理员会即时更正的。
Q9:PTT展示流程图过小，希望有子图
A9:好的，我们会改正的。
Q10:1.类图跟数据库不对应 没有及时更新2.没有记录点赞转发的记录。3.评论信息与用户之间没有建立关联 4.动态数据如宠物医院是否可以动态更新
A10:1.现在已经更新，以后会及时修改。2.不好意思我们漏掉了，现在已经在寻找解决方案中。3.在数据库表中评论的表里有用户名的属性...或者问题是什么意思。4。可以。
以下为修改的类图
3.针对前几次作业的不足的地方进行思考和总结
在之前所做的所有工作当中我们还是出现了一定的不足与问题。
①在之前的原型展示中有很多比较不完善的地方。这个问题我们已经在不断地完善当中。
②类图有一定的冗余，没有用专业的processon画，会有一些不专业。现在已经改正。
③在答辩PPT中，有些图的展示没有做到分部展示导致图很大大家看不清楚的情况。以后一定改正。
4.需要改进的团队分工
在团队刚组建的时候，我们给了两个同学“算法”这个位子。在现在我们即将进入冲刺阶段的时候，我们认为我们的项目用到算法的地方会比较少，所以将两位同学一位并入前端组，另一位并入后端组。两位都是各组的管理员，掌握着奖惩（贡献度）的权力。
以下为最新的分工
| 学号 | 姓名 | 预期分工安排 |
|---|---|---|
| 131700114 | 张辉 | 数据库设计 |
| 061700232 | 闫佳豪 | UI界面设计 |
| 031702612 | 陈志超 | 后端——个人信息，登录注册，管理员管理 |
| 031702632 | 林华伟 | 算法设计，前端负责人，测试 |
| 031702611 | 李斯文 | 前端——用户信息界面设计，宠物中心界面设计，宠物百科界面设计 |
| 031702338 | 郑学贵 | 算法实现图像处理，后端负责人，测试 |
| 031702509 | 李享 | 前端——宠物管理，寻宠启示，留言界面设计 |
| 031702326 | 胥鹏 | UI界面设计 |
| 031702601 | 罗爱玥 | 统筹规划，兼职UI，项目经理 |
| 031702536 | 伍裕荣 | 后端——寻宠启示，留言，聊天 |
5.团队的代码规范
(一) 命名风格
1.【强制】代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结 束。
反例:name / name / $name / name / name$ / name
2.【强制】代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
说明:正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼
音命名方式 也要避免采用。
反例:DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3
3.【强制】类名使用 UpperCamelCase 风格，但以下情形例外:DO / BO / DTO / VO / AO / PO / UID 等。
正例:MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例:macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
4.【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必 须遵从 驼峰形式。
正例: localValue / getHttpMessage() / inputUserId
5.【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名 字长。
正例:MAX_STOCK_COUNT 反例:MAX_COUNT
6.【强制】抽象类命名使用 Abstract 或 Base 开头;异常类命名使用 Exception 结尾; 测试类命名以它要测试的类的名称开始，以 Test 结尾。
7.【强制】类型与中括号紧挨相连来表示数组。
正例:定义整形数组 int[] arrayDemo; 在 main 参数中，使用 String[] args 来 定义
反例:在 main 参数中，使用 String args[]来定义。
8.【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统 一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
正例:应用工具类包名为 com.alibaba.ai.util、类名为 MessageUtils(此规则 参考 spring 的框架结构)
9.【强制】杜绝完全不规范的缩写，避免望文不知义。
反例:AbstractClass“缩写”命名成 AbsClass;condition“缩写”命名成 condi， 此类随意缩写严重降低了代码的可阅读性。
10.【推荐】为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的 单词组合来表达其意。
正例:在 JDK 中，表达原子更新的类名为:AtomicReferenceFieldUpdater。
反例:变量 int a 的随意命名方式。
(二) 代码格式
1.【强制】大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可， 不需要换行;如果是非空代码块则:
左大括号前不换行。
左大括号后换行。
右大括号前换行。
右大括号后还有 else 等代码则不换行;表示终止的右大括号后必须换行。
2.【强制】if/for/while/switch/do 等保留字与括号之间都必须加空格。
3.【强制】采用 4 个空格缩进，禁止使用 tab 字符。
说明:如果使用 tab 缩进，必须设置 1 个 tab 为 4 个空格。IDEA 设置 tab 为 4 个空格时， 请勿勾选 Use tab character;而在 eclipse 中，必须勾选 insert spaces for tabs
正例:涉及1-3点
(三) 注释规约
1.【强制】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/内容/格式，不得使用 // xxx 方式。
说明:在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注释;在 IDE 中，工程调用方法时，不进入方法即可
悬浮提示方法、参数、返回值的意义，提高阅读效率。
2.【强制】所有的抽象方法(包括接口中的方法)必须要用 Javadoc 注释、除 了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。
说明:对子类的实现要求，或者调用注意事项，请一并说明。
3.【强制】所有的类都必须添加创建者和创建日期。
4.【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法 内部多行注释 使用/* */注释，注意与代码对齐。
5.【强制】所有的枚举类型字段必须要有注释，说明每个数据项的用途。
6.【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名 词与关键字保持英文原文即可。
反例:“TCP连接超时”解释成“传输控制协议连接超时”，理解反而费 脑筋。
7.【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、 异常、核心逻辑等的修改。
说明:代码与注释更新不同步，就像路网与导航软件更新不同步一样， 如果导航软件严重滞后，就失去了导航的意义。
8.【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用， 则删除。
说明:代码被注释掉有两种可能性:(1)后续会恢复此段代码逻辑。(2) 永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接 删掉(代码仓库保存了历史代码)。
(四) 安全规约
1.【强制】隶属于用户个人的页面或者功能必须进行权限控制校验。
说明:防止没有做水平权限校验就可随意访问、修改、删除别人的数据，比如查看他人的私信内容。
