| 项目 | 内容 |
|---|---|
| 本作业属于北航软件工程课程 | 博客园班级链接 |
| 作业要求请点击链接查看 | 作业要求 |
| 我在这门课程的目标是 | 成为一个具有一定经验的开发人员,熟悉公司开发模式和学校作业模式的区别 |
| 这个作业在哪个具体方面帮助我实现目标 | 让我总结了从学期初开始到现在自己的成长和变化 |
一、学期初问题回顾
在学期初老师要求我们快速阅读构建之法，并在快速阅读的基础之上提出一些自己的问题，具体之前的问题见原博客。
二、对问题的找到的答案
1. 单元测试要求覆盖所有的代码路径，是需要在完成基本的代码调试以及性能优化之后进行还是说从完成程序编码就进行？书的后文提到单元测试需要与代码一起维护，如果每次做修改都需要覆盖所有的代码路径带来的维护成本是否会过大？
这个问题提出的背景当时实在是没有过正式开发经验(虽然OO课上也写过单元测试，但是现在回顾下真的是为了应付作业当时)，所幸这学期遇到了一位开发经验十分丰富的同学，在他的指导下真的把开发的正确流程顺利走了一遍。由于我们组没有分出正式的测试人员，所以都是前后端每个人要对自己的代码进行编写单元测试，我现在认为比较好的单元测试甚至是要早于完成程序编码就进行，在编写程序的时候边写大部分单元测试并实时运行能避免后期很多因为前面代码错误导致后面也要修改的无用功。从软件安全性角度来看，维护代码覆盖率是非常有必要的，这直接关系着软件的质量和漏洞数目。
2.计算机专业考级真的有用吗
现在我对这个问题有了自己的答案，这个证书并不是特别重要，重要的是自己在考级过程中对新知识的掌握，不断考级的过程更是一种不断学习的积极心态以及不断提高自我的过程。
3-6.有关对书中不太理解的编码上的约定
经过这一个学期的代码训练，我现在认为其实这些都不是问题，编程本身就不是像数学物理科学那种自然科学有绝对的真理和答案。更多的时候是靠的约定俗成，不同的人对不同的规则和约定有不同的看法是正常的。我认为只要在coding的过程中一个团队甚至一个人遵从一个规范即可。比如我个人喜欢同类型变量定义放在一行，即使写JS变量命名会适当简化但不会只用一个字母，编码过程中基本不使用goto语句，c++中更习惯使用class。
7.结对编程中适合什么场景下使用？
现在认为结对编程其实适合开发代码需求不大的情况下使用，而且对代码的正确性要求越高，就越适合使用结对编程。
8.敏捷流程是否太过于依赖scrum master的个人能力？
在这学期的实际开发过程中，我也逐渐体会到了master的个人能力是非常重要的，因为真的是PM和我们的前后端负责人一起推动并决定了整个项目的进度和完成质量，他们相当于开发人员的引路人和通讯器，不断带领整个团队按时高质量完成相关工作。
10.程序的性能代价和开发代价如何找打合适的平衡点
这个在我们团队开发过程中也有遇到，尤其是在beta版，因为后端新加了三十多个接口，所以开发和测试任务十分重。在最后的确有点时间不充足的情况，我们最后采取的策略是先保证完成度，然后在完成基本要求之后可以在beta和gamma的过渡期对代码进行优化重构。所以我觉得其实二者在长时间线上来看是不冲突的。在工期要求比较紧的情况下可以先采用最小开发代价进行快速开发，在后期可以再对性能进行优化。
三、还未理解的问题和新问题
所幸在这个过程中没有出现新问题，但是对之前提出的一个问题，因为没有相关经历还没有确认答案。
9.一个领域的创新和这个领域的专家关系不大吗？
虽然没有准确答案，但是我可以说一下自己这个问题的看法。我对这个观点整体上持肯定态度，诚然，万事万物都不绝对，并非成为一个领域的专家才能创新。但是我对书上所说“70%的创新者说他们最成功的创新是在他们的拿手领域之外发现的”这个70%的比例有些存疑，我认为领域外的创新是存在的，但是在整个领域的创新所占的比例是较小的。大部分创新点的提出是基于对该领域有着深刻的理解与知识储备的，除此之外还有运气和灵光的成分。某领域内如果一个外行可以提出一个创新点，我认为后者是主要的因素，但是对于这个领域与行业的长久发展以及推进作用往往还是这个领域的专家所完成的。
四、做中学--各个阶段中学到的知识点
-
需求分析
需求分析的时候PM一定要和开发人员进行充分的沟通，避免出现没有沟通就认为“这个很简单呀，很容易就实现了”的情况，这样会对工期的判断出现较大的偏差。针对课程来看，PM要根据大家的时间合理和用户进行沟通需求，要适当砍掉一些不太必要的需求。
-
代码设计
无论是前后端，代码都不能上来就写，至少要想好基本的设计再开始编码。
-
代码实现
遇到比较棘手的实现问题时要多向别人请教，多查资料。在写代码的过程中首先要考虑如何快速实现，但是也应该思考如何提高代码的性能。
-
代码测试
开始阶段单元测试做的充分，后面debug就越轻松。
-
代码发布
用户状态下的环境跟我们开发时的环境一般会有很大的差异，所以最好能在正式发布之前找一些内测用户进行先测试，避免发布之后进行太多的修改。
-
代码维护
维护阶段要强调敏捷性，对用户提出的反馈最好能及时响应，这样可以最大化减小对用户的体验影响。
五、学期心得
在这个学期的开发过程中，我的身份一直是后端的开发和测试人员。刚上来就体验到了什么是短时间速成一门全新的语言和框架，利用清明节假期速成ruby on rails。
我的直观体验是，我们组的项目听上去虽然不是很难但是各个方面的技术都要涉及，而且对比大部分组的逻辑关系以及实体都比较复杂。开发过程中对于后端来说有很大一部分的时间都花在了从需求抽象出实现接口，并且设计前后端交互的接口上。许多代码不难写，但就是要写很多很多控制逻辑。
在这个学期软工开发过程中，我也逐渐养成了一种在写代码的时候多考虑的习惯。印象最深刻的是在alpha阶段快结束的时候，有着丰富开发经验的张少昂同学在review我的代码时告诉我虽然代码实现上问题不大，但是需要我去查一下一个经典的1+N问题并进行改正。经过查阅资料，我发现这是一个典型的查询性能陷阱。场景为：需要根据某一列的值查询表中该值出现的行数，如果分别count的时候每次对一个不同的元素count的时候会对表全体进行一次扫描，代价是N。这是一个比价大的性能瓶颈，但是如果我们第一次就先按照不同值进行group，然后count的时候就只需要数每组的值，相当于只需再扫描一次表。之前写代码的时候根本没有想到这个问题，经过这个问题之后我每次写代码的时候都会多想一下，思考有没有更好或者更高效的实现方式。
最后，我还是很感谢我的团队，这学期的软工开发是非常愉快的一次学习过程。虽然中间也因为太菜被reviewer疯狂diss，但是也正是在一次次被批评后不断改进的过程中不断提高了自身的能力。