《构建之法》——个人总结
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/xnsy/2019autumnsystemanalysisanddesign |
| 这个作业要求在哪里 | https://www.cnblogs.com/harry240/p/11524252.html |
| 团队名称 | Golden Express |
| 这个作业的目标 | 回首、展望 |
| Github地址 | https://github.com/isliudong/eyoo2 |
一、请回望第一次博客作业，你对于软件工程课程的想象和提出的问题
在我的第一次博客作业中，我把软件工程的东西概括为就是搞软件的，但是现在来看的话，事情并不像我曾经想象的那样就是单纯的编代码。经过我一学期的学习我现在对软件工程这个概念的理解是一个工程，一个类似于修建高楼大厦一样的工程，软件在准备开发以及开发完成的时候，它包含了很多的流程，比如：需求分析、概要设计、详细设计、编码、测试、软件交付、验收、维护等。并不是单纯的像我当初那样一个人写了些小程序就认为理解了软件工程的全部，实际上那只是属于软件工程中编码实现的一点点部分，这完全是就是在坐井观天，我曾经提出了几个问题，现在我准备在后面的内容中来回答一下，学习了一学期之后的我现在的理解。
二、链接到以前的博客链接
第一次的博客链接（现在看到就很呆，哈哈哈）
三、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄明白的
1.如果在代码长期维护过程中会有更新升级，这个时候就会有新的单元测试，但是如果每个都去重写，那么维护的代价就会变得很大，而且工作量也会变多，到底该怎样去解决这个问题呢？
如果在项目一开始的时候就采用了一些合理的设计模式的话，代码的重写就不会很难，况且在本次实验中我还学会了Idea的一个JUnit4的插件，他可以对我们的类方法进行一键生成测试框架，只需要写出具体的测试逻辑代码就行了，还有在开发的时候对一些可能会发生变更的东西进行封装或者定义，这样在之后修改的过程中对于这一类的数据就会很好的进行修改，通过查阅资料我了解到了一个叫做测试自动化这样一个概念，有很多工具可以提供帮助，比如Parasoft Jtest，有些第三方库甚至还提供内置参数化的功能，这大大减小了测试的难度与复杂度，更重要的当然还是写代码的时候就要注意代码的可维护性和可读性，并且一般来说，使用mock（模拟）作为依赖项使我们作为测试人员的生活更容易，因为我们可以为社会化代码生成“单独的测试”。对复杂代码的社交测试可能需要大量设置，并且可能违反被隔离和可重复的原则。但是由于模拟是在测试中创建和配置的，因此它是自包含的，我们可以更好地控制依赖项的行为。另外，我们可以测试更多代码路径。例如，我可以返回自定义值或从模拟中抛出异常，以覆盖边界或错误条件。
2.结对编程
对于结对编程这个我提出了一些疑问，而且我当时认为结对编程在现实中可能并不是一个比较好实现的编程方法，但是现在我能说在一般情况下确实比较难实现，因为你需要考虑到很多地方
1）对于有不同习惯的编程人员，可以在起工作会产生麻烦，甚至矛盾。
2）有时候，程序员们会对一个问题各执己见（代码风格可能会是引发技术人员口水战的地方），争吵不休，反而产生重大内耗。
3）两个人在一起工作可能会出现工作精力不能集中的情况。程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。
4）结对编程可能让程序员们相互学习得更快。有些时候，学习对方的长外，可能会和程序员们在起滋生不良气氛一样快。比如，合伙应付工作，敷衍项目。
5）面对新手，有经验的老手可能会觉得非常的烦躁。不合适的沟通会导到团队的不和谐
6)有经验的人更喜欢单兵作战，找个人来站在他背后看着他可能会让他感到非常的不爽，最终导致编程时受到情绪影响，反而出现反作用。
因此就我目前来说，我还是不太看好这种方法，可能对于一些特定项目实现的时候可能会用到，但是就目前在学习实际体验的情况来说我不太看好
3.敏捷的开发原则怎么来实现一个动态平衡，我现在体会也不是特别多，但是我还是愿意用我粗略的知识来谈一谈我的看法，在实施敏捷的过程中，我发现有些东西是比较理想化的，但是实际也有很多办法可以解决这类问题，比如一些有经验的PM就会运用以往项目开发的经验来应对这样一些问题，敏捷的开发模式不是代表一种特定固有的模式，他会有很多根据实际项目变化的地方，并且在敏捷开发的过程中，对于很多问题都已经有了办法解决，有些甚至可以用到一些计算公式来解决，因此实现一个动态平衡的时候，是需要一些项目经验的，而不是空口说怎么实现，应该具体的问题用具体的办法来解决。
4.产品经理(PM，Project Manager)，对于这个可以直接参看现成的博客，这是一些比较成功的产品经理的总结，其中那个包含了我的问题甚至还有一些更多的我没能涉及到或者想到的问题。
参见博客：
5.关于对做中学的看法或者说新阶段的理解，值得一提的是目前大部分人都是采用这种方法的，并且这也是效率最高的用来学习一个技术的地方，但是注意如果你是一个小白，请不要使用这种做法，在打基础的阶段也就是学习基本指示操作的时候不能使用这种方法，对于基础薄弱的同学，我建议还是要一步一步扎实基础比较好，对于如果能清楚知道原理，并且懂得如何进行简单操作的人，可以采用这种方法，不然的话你就会发现，每个地方你都不知道该干嘛，也不知道下一步怎么做，对于自己的基础没有把握或者基础不好，没有思路的同学，我不建议采用这种方法，当然如果你已经基础很扎实了，那么这种方法还是非常值得推荐的，毕竟这是最有效率的最快的方法。
四、是否产生了新的问题？请提出。
产生的新的问题：
1.在测试web项目中对于一些传值，不像传统的一些数据，而是一些其他通过一些方式封装的，该如何对此类方法或者类进行测试，对于这种是不是没有办法测试，对传入的数据该如何找到。
2.在软件开发过程中没有遇到过这样一个问题，假设成员技术水平不高，则到最后完成的项目就会延期甚至完不成，在对团队使用敏捷方法的时候，有没有看滤过每个人的技术水平，各自技术水平不够的话，该如何处理这种情况，（假设都是学生，学习知识的熟练度各不相同，而团队成员中没有能够挑大梁的成员存在），这样的团队就会完不成任务，有没有考虑过这样的情况。
五、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。
包括以下内容：
1）哪一次作业让你印象最深刻？为什么？
Alpha版本这是第一次在这我的电脑上进行团队项目的开发，从克隆开发提交都是花了很大的功夫，每一步我感觉基本上都查了互联网（这纯属我比较菜），而且在搭建项目环境的时候也遇到很多的问题，不过好在在团队成员的帮助下，我成功完成了项目环境的搭建，并成功运行了一个demo
2）累计花了多少个小时在软工实践上？
在实际开发过程中我编码的时候比较少，项目找过来的时候是个半成品，但是在一些原理探究或者说基础上我还是花 了一些时间，特别是在实践写博客这样一个事上我是比较认真的，基本上都是一到两个时，每天在学习基础技术上基本在1小 时左右的样子
3）学习和使用的新软件；
git、码云（强烈推荐这个软件很好地解决了git慢的问题）、idea
4)学习和使用的新工具；
墨刀、Axure、
5）学习和掌握的新语言、新平台；
Java，SQL server，IDEA
6) 学习和掌握的新方法；
简单项目管理，敏捷的开发原理、结对编程，软件项目开发过程
7) 其他方面的提升。
团队协作能力、文档编写能力,
项目开发过程中可能会写到的文档：
1、可行性分析报告
说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。
2、项目开发计划
为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。
3、软件需求说明书（软件规格说明书）
对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。
4、概要设计说明书
该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。
5、详细设计说明书
着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。
6、用户操作手册
本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。
7、测试计划
为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
8、测试分析报告
测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。
9、开发进度月报
该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。
10、项目开发总结报告
软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。
11、软件维护手册
主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。
12、软件问题报告
指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。
13、软件修改报告
软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。
六、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？
-
萌芽阶段
团队初期，我可以感受到，组员比较依赖我发布任务，那个时候，我队每个组员的能力也尚处于了解之中，任务的安排有些不是很合理，并且很多地方是通过传统的丢骰子的办法来分配任务的 -
磨合阶段
团队的组员都比较负责，基本没出现什么冲突，会议还是再开，不过比较随意并不是特别严谨（不过这种氛围很好）
-
规范阶段
经历过alpha阶段，我们小组在beta阶段冲刺时就更加合作无间，组员各自从teambition上领取任务完成。测试同学在teambition反馈bug，开发同学领取bug任务修复，整个beta阶段的工作有条不紊的进行着。
七、怎样证明你学会了软件工程？软件工程的有些什么内容
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件；
第一天注册用户达到4人
第二天注册用户达到9人
第三天注册用户达到14人
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
通过一些列的工具、流程、团队合作
《构建之法》——GitHub和Visual Studio的基础使用
团队alpha、beta冲刺，小组有序的完成了整个项目的基础开发
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料，项目的完整源码以及开发文档技术手册已经上传到了git中
八、个性发挥：团队合照
九、最后想说几句：
项目终于是完了，讲道理，我感觉这种项目如果重头到尾都按着步骤一步一步完成的话，这对理解个人的工作、团队成员的工作会有很大的好处，对于这个项目在开发的过程中我也遇到过很多问题，有些地方也是比较水的，有的时候甚至会存在瞎编的时候，这个时候我也明白了，一定要切切实实的去完成项目的开发，才会真正的有所收获，而不因该完全依赖队友，这样对个人的技术成长以及理解软件开发流程是有问题的，在遇到很多问题时，经常都会查阅很多的博客，这也是技术太欠缺了，整个开发下来，我才发现自己的技术确实是很菜的，在很多地方都不懂，这让自己说话都变得不硬气了，所以说技术还是要掌握在自己的手上比较好，而且不能光是嘴上说说就完了，一定要花费时间去完成这些任务，技术不是想来的，也不是说来的，而是练来的，这让我想起之前老师说过，在课堂上学习的是理论方法，而要成为一个高手，是要慢慢的练成的。但是总的来说在这个课堂上虽然实际的技术没有学到很多，但是在一些软件项目开发过程文档的编写，还有完整的项目流程有着比较清楚地了解，而且在课堂山给我还学会了UML，类图，实例图，E-R图，还有流程图，这是之前在编写小程序的时候所不清楚的，未来的生涯也不是打算就做个普通程序员，也是想过有更多的发展，所以学到的这些知识对我之后的开发项目的过程中会有很多的帮助，但是这个课程开的时间比较晚，对于我们大三来说，时间是不够的，而且在要求写博客上，更是严格，有的时候会多耽误很多时间来写一些没有必要的东西，如果在学这门课程之前，大家统一上过某个课的话这样是比较好的，不会出现同学之间差距太大的情况，比如我感觉我就是来打酱油的，技术太菜。
对自己寄予的希望：考研上岸，技术大佬，管理高层，成为大佬。
认真去做，剩下的交给时间，量变终将引起质变（最近马原学的有点入迷啊，道理太多了，哈哈哈）
