《构建之法》——个⼈总结
这个作业属于哪个课程
这个作业要求在哪⾥
团队名称Golden Express
这个作业的⽬标回⾸、展望
Github地址
⼀、请回望第⼀次博客作业，你对于软件⼯程课程的想象和提出的问题
在我的中，我把软件⼯程的东西概括为就是搞软件的，但是现在来看的话，事情并不像我曾经想象的那样就是单纯的编代码。经过我⼀学期的学习我现在对软件⼯程这个概念的理解是⼀个⼯程，⼀个类似于修建⾼楼⼤厦⼀样的⼯程，软件在准备开发以及开发完成的时候，它包含了很多的流程，⽐如：需求分析、概要设计、详细设计、编码、测试、软件交付、验收、维护等。并不是单纯的像我当初那样⼀个⼈写了些⼩程序就认为理解了软件⼯程的全部，实际上那只是属于软件⼯程中编码实现的⼀点点部分，这完全是就是在坐井观天，我曾经提出了⼏个问题，现在我准备在后⾯的内容中来回答⼀下，学习了⼀学期之后的我现在的理解。
⼆、链接到以前的博客链接
（现在看到就很呆，哈哈哈）
三、尝试对⾃⼰提出的问题进⾏解答，并阐明，是如何通过看书，实践，或者讨论弄明⽩的
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）通过⼀系列⼯具，流程，团队合作，能够在预计的时间内发布 “⾜够好” 的软件
通过⼀些列的⼯具、流程、团队合作
团队alpha、beta冲刺，⼩组有序的完成了整个项⽬的基础开发
3）并且通过数据展现软件是可以维护和继续发展的。
⽽不是不到源代码，代码⽆⽂档，代码不能编译，没有task/bug 等项⽬的发展资料，项⽬的完整源码以及开发⽂档技术⼿册已经上传到了git中
⼋、个性发挥：团队合照
九、最后想说⼏句：
项⽬终于是完了，讲道理，我感觉这种项⽬如果重头到尾都按着步骤⼀步⼀步完成的话，这对理解个⼈的⼯作、团队成员的⼯作会有很⼤的好处，对于这个项⽬在开发的过程中我也遇到过很多问题，有些地⽅也是⽐较⽔的，有的时候甚⾄会存在瞎编的时候，这个时候我也明⽩了，⼀定要切切实实的去完成项⽬的开发，才会真正的有所收获，⽽不因该完全依赖队友，这样对个⼈的技术成长以及理解软件开发流程是有问题的，在遇到很多问题时，经常都会查阅很多的博客，这也是技术太⽋缺了，整个开发下来，我才发现⾃⼰的技术确实是很菜的，在很多地⽅都不懂，这让⾃⼰说话都变得不硬⽓了，所以说技术还是要掌握在⾃⼰的⼿上⽐较好，⽽且不能光是嘴上说说就完了，⼀定要花费时间去完成这些任务，技术不是想来的，也不是说来的，⽽是练来的，这让我想起之前⽼师说过，在课堂上学习的是理论⽅法，⽽要成为⼀个⾼⼿，是要慢慢的练成的。但是总的来说在这个课堂上虽然实际的技术没有学到很多，但是在⼀些软件项⽬开发过程⽂档的编写，还有完整的项⽬流程有着⽐较清楚地了解，⽽且在课堂⼭给我还学会了UML，类图，实例图，E-R图，还有流程图，这是之前在编写⼩程序的时候所不清楚的，未来的⽣涯也不是打算就做个普通程序员，也是想过有更多的发展，所以学到的这些知识对我之后的开发项⽬的过程中会有很多的帮助，但是这个课程开的时间⽐较晚，对于我们⼤三来说，时间是不够的，⽽且在要求写博客上，更是严格，有的时候会多耽误很多时间来写⼀些没有必要的东西，如果在学这门课程之前，⼤家统⼀上过某个课的话这样是⽐较好的，不会出现同学之间差距太⼤的情况，⽐如我感觉我就是来打酱油的，技术太菜。
对⾃⼰寄予的希望：考研上岸，技术⼤佬，管理⾼层，成为⼤佬。
认真去做，剩下的交给时间，量变终将引起质变（最近马原学的有点⼊迷啊，道理太多了，哈哈哈）

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。