| 软件工程 | |
|---|---|
| 作业要求 | |
| 团队名称 | |
| 作业目标 | |
| 作业正文 | |
| 参考文献 | 作业要求-代码规范、构建之法 |
一、冲刺的时间计划安排（冲刺时间为期七天，安排在2020-6-17——2020-7-2之间）
| 时间 | 安排 |
|---|---|
| 6.25 | 讨论并实现各自负责的前端设计并测试 |
| 6.26 | 讨论并实现各自负责的前端设计并测试 |
| 6.27 | 整理、合并所有的前端设计，并根据整体测试来调整、改进前端设计 |
| 6.28 | 实现各自负责的后端部分 |
| 6.29 | 实现各自负责的后端部分 |
| 6.30 | 整理、合并前后端，并进行测试，根据测试结果来进行调整、改进 |
| 7.1 | 软件测试，继续完善 |
二、针对前几次作业的不足的地方进行思考和总结
- 思考
- 以往作业中，在某些问题上考虑不全，导致需要反复修改已经完成的作业
- 以往作业中，队员间交流时间不充分，导致设计得不到每个人的赞同
- 总结
- 冲刺阶段，我们会更全面的考虑问题，避免多余的反复修改
- 冲刺阶段，我们会加强团队交流，避免想法不一致导致的项目部分冲突
三、需要改进的团队分工（针对之前的不足，需要加强和改进团队协作和分工的地方）
改进：
- 根据每个成员的能力和特长分配最适合的工作，尽最大程度的激发每个成员的潜力
- 多交流、讨论，队员积极互相帮助
四、团队的代码规范
一、命名风格
- 【强制】代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
- 反例：_name / __name / $name / name_ / name$ / name__
- 【强制】代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
- 说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼音命名方式也要避免采用。国际通用的名称，可视同英文。
- 反例：DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3
- 【强制】类名使用 UpperCamelCase 风格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。
- 正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
- 反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
- 【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从驼峰形式。
- 正例： localValue / getHttpMessage() / inputUserId
- 【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
- 正例：MAX_STOCK_COUNT
- 反例：MAX_COUNT
- 【强制】抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类 命名以它要测试的类的名称开始，以 Test 结尾。
- 【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
- 正例：应用工具类包名为 com.alibaba.ai.core.util、类名为 MessageUtils（此规则参考 spring 的框架结构）
- 【强制】杜绝完全不规范的缩写，避免望文不知义。
- 反例：AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成 condi，此类随 意缩写严重降低了代码的可阅读性。
- 【推荐】为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合来表达其意。
- 正例：在 JDK 中，表达原子更新的类名为：AtomicReferenceFieldUpdater。
- 反例：变量 int a 的随意命名方式。
二、代码格式
- 【强制】大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：
- 左大括号前不换行。
- 左大括号后换行。
- 右大括号前换行。
- 右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。
- 【强制】if/for/while/switch/do 等保留字与括号之间都必须加空格。
- 【强制】采用 4 个空格缩进，禁止使用 tab 字符。
三、注释规约
- 【强制】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容*/格式，不得使用 // xxx 方式。
- 说明：在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注释；在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。
- 【强制】所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。
- 说明：对子类的实现要求，或者调用注意事项，请一并说明。
- 【强制】所有的类都必须添加创建者和创建日期。
- 【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐。
- 【强制】所有的枚举类型字段必须要有注释，说明每个数据项的用途。
- 【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
- 反例：“TCP连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。
- 【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
- 说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。
- 【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。
- 说明：代码被注释掉有两种可能性：
- 后续会恢复此段代码逻辑。
- 永久不用。
- 前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。
- 说明：代码被注释掉有两种可能性：
五、阅读构建之法13-17章
第13章 软件测试
- 按测试设计的方法分类
- 黑箱测试
- 白箱测试
- 按测试目的分类
- 功能测试
- 非功能测试
- 测试方法
- 单元测试
- 代码覆盖率测试
- 构建验证测试
- 验收测试“探索式”的测试
- 回归测试场景、集成、系统测试、
- 伙伴测试
- 效能测试
- 压力测试
- 内部/外部公开测试
- 易用性测试
- 总结
- 了解每种测试的优缺点，选择合适的测试
- 记录好每一次出现的错误，方便日后做维护
第14章 质量保障
-
软件质量公式：软件质量=程序质量+软件工程质量
-
分工是社会和行业进化的结果。开发和测试其实是软件工程的两个分支。不同的软件和服务需要不同方式和程度的测试。独立专业的测试角色等同于第三方代表对产品质量进行检测和认证
第15章 稳定和发布阶段
- 思考、总结：团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才?
- 团队成员之间有互相帮助么?
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
第16章 IT行业的创新
- 创新的迷思
- 灵光一闪现，伟大的创新就紧随其后
- 大家都喜欢创新
- 好的想法会赢
- 创新者都是一马当先
- 要成为领域的专家，才能创新
- 技术的创新是关键
- 成功的团队更能创新
- 创新者就是冒险家
- 总结：对我们这些新手来说，创新还太遥远，我们需要扎实的走好每一步，为未来的创新打下基础
第17章 人，效绩和职业道德
- 从软件工程起源中可以看出，软件工程是产生的主要目的是为了解决大规模软件开发周期长的问题，而解决问题最核心的思想就是“团队合作”
- 如何才能实现高效的团队合作？
- 软件开发模型的选择：做任何事情都不应该本末倒置，应该一切从目的出发。世界上不存在两个完全相同的项目，项目规模的大小、复杂度、难度千差万别，就像组装自行车的过程和生产飞机的过程之间的差别。笔者并不是哪一种过程模型的支持者，而是提倡“软件过程选择的敏捷性”，根据不同项目的特点，对现有的过程模型进行裁剪，形成每一个项目独有的过程
- 开发团队的组建：团队是由人组成的，人的问题才是根本问题
- 工作任务的分配：任务的拆分需要尽量降低子任务之间的耦合度，耦合度高会增加沟通成本。 必须尽量准确的评估工作量，最好团队一起评估，工作量分配不合理，对项目的完成时间而言会造成“水桶效应”，虽然可以调配人员，但会增加沟通、学习成本
- 感悟：明白了同学之间合作的重要性以及团队合作的重要。一个人不可能独立的存在，无论是在学习工作还是生活中，都需要与他人的合作才能完成每项任务。通过这种形式的合作，事半功倍，同时还能学到不同的东西，让我们的生活更加的丰富多彩