提问回顾和个人总结
| 内容 | |
|---|---|
| 这个作业属于哪个课程 | |
| 这个作业的要求在哪里 | |
| 我在这个课程的目标是 | 系统了解并参与软件开发过程，提升自身工程能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾学期初 |
阅读提问
问题1 学生与职业程序员的区别
显然从学生到职业程序员，并不是更加没完没了地写程序——花在写代码的时间反而少了很多
以前我的观点是：职业程序员的代码时间少，但测试时间多，可能是由于编码质量的不足导致测试期间的bug更多，测试时间延长。但经历了两个阶段的迭代开发之后，我对学生和职业程序员之间的差距有了更为清晰的了解。在整个开发过程中，就亲身体会而言，需求分析、测试等方面要远比写代码实现这一过程更加重要，清晰的功能定义，良好的代码规范，完整且有效的测试是写程序的基础条件，如果前期没有进行充分准备，那么写程序实现时就会很低效：不得不花费更多的时间对功能进行更加清晰的定义，不得不对代码进行反复重构，不得不做出很多无用功和无意义的事情。
关于职业程序员的测试时间多的表现，在Alpha和Beta的测试阶段我都深有体会：测试很难面面俱到 。每一种情况都考虑到，每一个细节都进行测试，每一个小功能都进行全面的测试，在真正的测试中需要花费很多时间和精力。测试是软件发布前的必须工作，否则若有一个功能性bug，可能会造成很差的用户体验和其他不可磨灭的影响。
问题2 goto是否应该在程序中使用
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
这个问题我仍然持有以前的看法，goto的使用会让程序一团糟。此外在团队开发中，往往会制定代码规范，在实际开发时，需要按照代码规范进行开发。
问题3 结对编程是否合理
以前的个人理解是水平近似的两个人在进行组队进行结对编程时，会由于能力的限制导致代码质量无法提高。
在进行两次结对编程后，我对这个问题有了新的理解。在结对编程中，我和我队友在开发时，采用了轮流开发的模式，每人开发1-2小时，完成某些特定功能后，换为另外一个人进行开发。总体而言代码的质量比个人开发的代码质量高很多，但由于两个人不是在开发就是在看队友开发，导致在3-4小时之后，两个人都处于一种大脑混沌的状态，效率也就会下降，但好在我们及时发现问题，并选择中场休息来保证有充足的精力。
这样的开发模式让我们的代码质量得到了保证，因为在个人开发时，我和我的队友两个人都属于那种容易出现手误的人，往往会出现一些低级但非常严重的错误。在避免了这样的低质量代码之后，我们的代码出现的bug很少。此外逻辑上的bug往往是对指导书的理解不准确导致的。
最终两周的结对编程，即便我和我的队友的水平相近，但最终我们依旧从对方那里学到了很多知识和技巧。
问题4 工作时是否应该带着个人、感情驱动的因素
在两次迭代开发过程中，我对这个问题理解很深刻。在整个开发阶段，我的代码被队友合并冲突时覆盖了三次，每次在我发现我的代码被覆盖时总是充满了气愤：为什么合并时不去询问和提出issue，而是直接覆盖最新版本代码？为什么有了一次覆盖两次覆盖还会在紧张的发布前一天再次覆盖？等等问题，充满了负面的情绪。在整个开发阶段我在初期对项目的热情让我在初期做出了很多莽撞的代码开发，比如最终被砍掉的拖拽功能，以及账单页面设计了几个小时的页面最终由于不实用而被砍掉。我相信在开发的过程中按部就班，持续的工作最终一定会有成果，但作为年轻人而言，带有激情往往会让自己更有动力和充实，带有负面情绪往往会对自己的项目、代码、团队心生反感而导致消极怠工。
但对于原文所提出的这个问题，我还是认为日复一日的工作可能会让人呆掉，人不是机器，生活也不仅仅只有工作和技术。
问题5 敏捷开发过程中对需求的变化
敏捷开发的原则是：
敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
第三步：冲刺。
......有任何需求的改变都留待冲刺后结束再讨论......
在敏捷流程中的冲刺阶段需求不应该再发生改变了。一旦发生改变整个冲刺阶段的进度安排便会受到影响，影响的不仅仅是改动需求的负责人，也会影响整个团队中的每一个人。特别的，一旦发生重大的需求变化，会打乱整个项目的开发进度和节奏，也即在冲刺阶段每一次的需求变动都需要非常谨慎。
做中学
需求
-
NABCD是非常有效的需求分析方法。
设计
在设计阶段的学到了：
-
如何根据典型用户场景和典型用户来抽象出软件所对应的具体的功能。
-
如何生动的将用户和场景结合到一起，并使用小故事的形式展示出来。（故事取材于生活
-
系统设计按照模块划分，每一模块完成模块内的任务，并提供对外调用的接口。
实现
-
在进行合作开发时，尽量避免和其他人在同一个文件内开发，既能减少冲突合并的风险也能保证代码之间的独立
-
在进行编写代码时要写尽可能详细的代码注释
-
要学会对代码进行封装和代码复用，减少冗余代码，否则在修改时非常复杂。
测试
-
测试既包括单元测试也包括测试阶段的全面测试。对于前端来说，单元测试就是在每次实现一个功能后，进行功能的基本测试，保证功能的局部正确。全面测试时，需要对于各个模块接口的调用和通信进行测试，保证模块整合后的功能正确和完整。
-
测试要全面，要从各个角度尽可能的对程序进行测试，以保证各个情况下程序都能正确的运行。
-
测试阶段就是在发现bug和修复bug阶段，仍要认真对待，不可草草了事。
发布
-
发布工作需要考虑小程序的审核时延问题
-
发布工作不仅仅是发布，宣传更加重要。我们Alpha版本阶段的宣传做的很好，通过一些基础物理实验的公众号以及朋友圈的宣传，让我们的软件在短时间内得到了很多人的使用，并提供了宝贵的经验。Beta阶段由于基础物理实验已经考试结束，我们的软件使用人群少了一半以上，此时宣传就面临了窘境。
维护
-
在出现问题时要及时修复，并尽量在最短时间内提交审核。
体会
一学期的软件工程落下帷幕，从个人阅读作业到结对编程到案例分析作业再到后面Alpha阶段和Beta阶段的项目开发，一整套下来个人整个学期都一直在软件工程开发工作，安排颇为紧凑和充实。
开始时的个人阅读作业回忆了很多以前的事情，也在那时候深深的感受到了人与人之间的差距。这样的回忆和长文的叙述，也只有在课程的安排下我才会去回忆和思考，所以即便当时看着别的软工班摸鱼写文档，我也并不觉得自己很痛苦，反而收获颇多。
在结对编程中很幸运能和以前的队友lpc组成小队，一起进行开发。在以往的开发过程中都是自己个人的单打独斗，所以往往会钻牛角尖或者在某些部分上很任性和随意，不喜欢深入思考。但在结对编程的过程中，我深深认识到自己的不足并学会了妥协与认错，坦然承认自己的不足，并接受队友的意见和建议，努力的将代码更加完善。这次结对编程，我想很大程度上提高了我团队协作的能力，并在一定程度上磨合了我的性格。感谢结对过程中lpc的包容和理解，希望他能够在实习和工作中事事如意，日进斗金。
团队项目Sunny图表是我参加的第一个比较大型的项目。从0实现一个微信小程序，在有以前HTML+CSS+JavaScript的基础上，我个人在技术栈上并没有遇到比较困难的地方，但在这个过程中对微信小程序的基本开发流程熟悉了很多，也真正见识到微信小程序的"真面目"：不完整的文档，低质量的社区，开发全靠前辈的博客和自己的探索。在开发过程中真心遇到了很多奇奇怪怪的问题，开发体验感并不是很好。
整Alpha的冲刺阶段在了解echarts画图时，每天都在不停的看echarts的文档，研究如何画图，如何对图形进行拖拽，由于echarts在小程序本身的拖拽支持度不高，在进行柱状图的拖拽时，一直都在尝试各种方法和办法来让拖拽更加的流畅，更加的方便，但经历了无数次的尝试后，最后还是失败了！Alpha阶段我很多的时间都花费在了这个拖拽功能上，导致浪费了很多很多的时间，而这个功能在Beta的初始阶段便被团队果断舍弃，这也是很无奈的事情：做一个不完整的功能不如不做，将精力放到更有效率的地方。虽然删除代码时很痛苦，但也不得不接受事实。
团队合作的最重要的团队的凝聚力。个人觉得，在整个开发过程中，我们的团队缺少一定的凝聚力，不如说缺乏积极性。整个团队在每次开会时给人的感觉往往只有2-3人，其他人基本沉默，线下开会也偶尔会出现这样的场景，但线上的会议往往多于线下的会议，导致了其实在很多的重要的讨论和决策中实际参与的成员只有两人或三人，那么效果肯定没有五个人集思广益讨论出的效果好。
我想如果团队有着可以一起奋斗的目标，并大家都愿意不计较的成本和利益去实现目标，那么结果的应该会更好。
