秃鸡队——凡事预则立
| 这个作业属于那个课程 | https://edu.cnblogs.com/campus/zswxy/computer-science-class1-2018 |
|---|---|
| 这个作业的要求在哪里 | https://edu.cnblogs.com/campus/zswxy/computer-science-class1-2018/homework/12064 |
| 这个作业的目标 | 项目冲刺，最后收尾阶段 |
| 小组的组号和组名 | 秃鸡队 |
| 小组组长名字 | 梁鹏飞 |
冲刺的时间计划安排
目前为止还是讨论怎样完成整个项目，按照之前的分工先自己各自完成自己的工作，到时候会进行整合。
针对前几次作业的不足的地方进行的思考和总结
第一次博客园团体作业：
内容：
加强团队合作意识，学会画用例图、顺序图、类图以及用例描述。
不足：
大家初次合作，在作业的想法上会出现不同的意见，公说公有理，婆说婆有理，对总体的分工和最终实现的工程上有不一样的想法。我们组是分工合作画的图，每个人负责一个部分，但是也是基于大家一起讨论协商之后再去化的图。但是由于基础的薄#弱，大家第一次画的各种图，顺序图，用例图，类图和用例描述都没有得到老师的认可，经过一次又一次的打回重改打回重改，基本上达到作业的要求。我们组首先用例图就画错了，用例图画的太过于复杂，用例过多的话，之后的顺序图就更多，会到一种近乎疯掉的结果，于是经过对我们工程的在思考，在此基础上增删，得到最终的用例图。然后是顺序图，顺序图我们组就是画少了，一般有有多少步过程就有多少个顺序图。用例描述是对我们的各个用例的一种简述。也是在大家的协作配合之下写的。类图也是这样的一个过程。
思考与总结：
首先上课要认真的听讲，在上课认真听讲的前提下，做作业就会轻松一些，我们组在老师的3次退回后，结合老师和我们组自己的思路，写出第一次团体作业。用例是参与者为达到某个目的而进行的一系列的交互，执行结果将为参与者提供可度量的价值，从参与者的角度来看，用例应该是一个完整的任务，在相对短的时间段内完成。概括而言，用例描述了系统的功能性需求。每个用例给出的是一个细化的系统行为需求，用例表示系统为参与者提供的服务与价值。顺序图是每一个用例的交互过程都对应一个顺序图，我们组就是没有认清这一点的含义才会只画了一个顺序图。顺序图能够很清楚的表达对象间是如何协作完成用例所描述的那些交互功能的。顺序图表示的是，为完成用例而在系统边界输入、输出的数据以及消息。用例描述是寻找用例的过程。寻找用力的最好的方式，就是把自己也当作参与者，与设想中的系统进行交互。要全面的认识和定义每一个用例。要点是用穷举的方式去考虑每个参与者与系统的交互情况。在类图建模的过程中，我们要识别类，定义类的名字，定于属性的名字，定义这个类的操作，并建立类和类之间的继承关系、组合关系和聚合关系，定义这些关联关系的多样性、方向的名字。这样就完成了一个基本的类图建模的过程。
第二次博客园团体作业：
内容：
学会写需求分析规格说明书。
不足：
这个阶段大家已经比较熟悉了，但我们组和别的组不一样，哪怕在熟悉，大家对于该争的地方还是争，或许是大家对作业的重视吧。对这次作业，大家也是在讨论的基础上分工合作，一些人写用户的原型设计，一些人写机构的额原型设计，一些人写说明书，然后上传git，一些人写博客园。分工很明确，大家的讨论也很激烈，对于我们过程的一些细节，会发表不同的意见，我觉得参与进去很不错，对自己各个方面都有学习。以前老师布置过个人作业就写过原型设计，所以大家再次做原型，就很得心应手，不难。然后大家一起协商要做什么，写出需求分析说明书。所以我觉得这次的作业没有什么很多的不足。
思考与总结：
到了这个阶段，大家就需要对自己的工程很了解了。对于自己要做的东西很了解。例如前端做什么，后端怎么做，分工需要很明确了。软件需求是指用户对目标系统在功能、行为、性能等方面的期望。需求分析是发现、求精、建模和产生规模说明的过程，软件开发人员需要对应用问题及环境进行理解和分析，为问题涉及的消息、功能及行为建立模型。需求分析实际上是对系统的理解和表达的过程。需求分析过程可以分为需求获取、需求分析、需求规划说明、需求评审四个过程。只有通过软件需求分析，才能把用户对软件功能性能的总体要求描述为具体的软件需求规划说明。
第三次博客园团体作业：
内容：
完善项目系统的设计和数据库的设计。
不足：
到这个阶段，已经快接近我们这个课程的尾端了，大家已经彼此熟悉，无论是对大家的性格，还是我们的工程。这次作业最大的不足是我们忘记提交了，写完了忘记提交也是一件很悲惨的事情。希望助教手下留情。我们组的作业都是在讨论的基础上然后分工合作写出来的，没有什么不足。
思考与总结：
作业要求是完善项目系统的设计和数据库的设计。我们组的分工如下：刘思怡：负责需求分析，原型设计，项目测试，以及对项目整体的构思，配合颜佳佳、汤云云完成前端设计。刘应军：承担项目的后端，数据库的搭建和编码。颜佳佳：负责前端页面编写，资料收集，美化细节。汤云云：负责前端页面编写，以及分配博客园编写任务，总结每周成果。梁鹏飞：承担项目的后端，数据库的搭建和编码。我们之后会慢慢在此前几次作业的基础上完成我们的工程。软件项目计划是对软件开发过程中的活动、资源、任务、进度等进行规划。软件项目的最大挑战是能否按时交付软件产品，所以合理地安排进度是软件项目计划的关键内容。
需要改进的团队分工
大家都是一起找个空教室，一起做，有什么不懂的也会在我们秃鸡队的群里面讨论，而且分工是在大家能力的基础上协商出来的，我们都认为比较满意这次的分工，所以到目前为止，没有什么不足和需要加强改进的地方。
团队代码规范：
一、命名风格
【强制】代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
反例：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章
软件测试。
按照测试设计的方法分类：黑箱和白箱。按照测试的目的分类：功能测试和非功能测试。按测试的时机和作用分类。
各种测试方法。各种测试工具。
质量保障。
软件的质量。质量的保障工作。
稳定和发布阶段。
从代码完成到发布。渐进发布和DevOps。发布之后——事后诸葛亮会议。
IT行业的创新。
创新的迷思。创新的时机。创新的招数。魔方的创新。创新和作坊。
人，绩效和职业道德。
领导力。知人善任。带领团队成长。绩效管理。软件工程师的职业道德。
