| 项目 | 内容 |
|---|---|
| 本作业属于北航软件工程课程 | 博客园班级链接 |
| 作业要求请点击链接查看 | 作业要求 |
| 我在这门课程的目标是 | 成为一个具有一定经验的软件开发人员 |
| 这个作业在哪个具体方面帮助我实现目标 | 让我对自己目前的状况有一个更加清醒的认识 |
一、之前的提问博客
请点此链接查看
二、对博客中问题的解答
1. 类型继承是被提倡使用的吗？
对于这个问题，我认为针对不同的项目有不同的做法。有些项目从一诞生起就注定了将成为一个中大型项目，仅靠个人的力量无法独立完成，必须经过多名程序员的共同配合才有可能编写出来。而另一些项目则是典型的小型项目，两三个人甚至一个有经验的程序员就可以轻松完成，不需要有太多的人员配合。对于前者而言，有必要在需要对开发人员进行约束的地方使用类型继承，这样可以将模块的功能限制在一个确定的范围之内，有利于程序整体结构的一致性；而对于后者，可以仅在必要的地方使用类型继承，例如把一系列相似的对象视为同一种对象在不同切面上的投影。以上是我在实践中确定的思想，我们组的项目后端框架选择了Ruby on Rails，一种非常纯粹的面向对象语言，而中间件则是选择了Python。Rails项目相对来说要庞大一些，且这个框架本身就包含了非常多的类型继承，因此我们也顺水推舟地使用了很多类型继承；Python写的中间件则是几个小品模块的杂糅，为了求快并没有使用过多的面向对象技术，反而短平快的解决了问题。
2. 角色互换是否是一个合理的选择？
我后来发现，结对编程与我预先设想的目的并不相同。我原本以为，结对编程是为了直接提高编程效率而诞生的，但经过一次实践之后发现并非如此。结对编程本质上是牺牲了两份时间，换取一份几乎没有bug的代码，从而间接提高软件开发的效率（因为后期复审变得容易了）。在这种情况下，由一个人长时间驾驶而另一个人长时间领航就势必会带来疲劳驾驶的问题，因此经常进行角色互换实际上是一个合理的选择。
3. 该怎么权衡用户对UI的相反评价？
实践告诉了我两个真相：1. 用户从来都是站着说话不腰疼的白嫖党，如果真按他们的意见来是会出大事的；2. “真香”才是人类的本质。无论是从我们这学期做的小程序项目，还是我个人在使用各类App时的亲身经验，都发现想要让所有人都满意是一件不可能完成的任务。用户基数一上去，之前所以为的真理都会被各种各样奇葩的意见所打破，如果真要去挨个满足用户的需求，恐怕得等到共产主义到来的那一天。更明智的做法是，从一开始就设立好一种UI风格倾向，并坚定不移地执行下去，只要软件做得好，用户迟早会说一声“真香”。
4. 如何针对具有复杂副作用的方法设计测试用例？
Ruby on Rails这个框架教会了我一个道理：没有什么是一个测试文件解决不了的，如果有，那就上一个集成测试。之前我过于拘泥在单元测试的泥潭里无法自拔了，后来在实践的过程中我发现，单元测试只是测试的一种手段，在实际的软件测试中，集成测试才是更好用、性价比更高的测试方法。集成测试把软件当成一个黑箱，关心软件的运行状态是否达到预期，其测试粒度相比单元测试要大上不少，可以将许多方法及其副作用包络起来，从接近用户的角度去做测试。因此，设计测试用例的时候，遇到那些不好做单元测试的方法，索性就把它们放在集成测试中，一次性全部测完。
5. 如何做好后端项目的可见性？
我现在觉得，这个问题可能有些自私了。之前我的想法是，一个软件项目后端团队和前端团队是完全分离独立的，后端只需要做好所有接口就可以完事走人，前端只需要做好所有界面展示工作就可以回家睡觉，其它地方出了问题都可以甩给别人，自己不接这口锅。但后来我发现，一个团队是荣辱与共的，不存在前端和后端可以真正独立的情况。无论是在项目经理还是投资者视角中，前端和后端都是不存在的，唯一存在的就只有这个项目本身，后端出了问题是整个项目的问题，前端出了问题也还是整个项目的问题，前端后端福祸相依，也唇亡齿寒。因此，后端没有必要去过多考虑怎样做好后端模块的可见性，应该把更多的精力放在完善功能和测试上，不成为前端的瓶颈。这样，当前端完工时，后端的工作也就自然而然地被展示出来了。
三、是否原来的问题还不明白
所幸，现在没有了。
四、是否产生了新的问题
我的问题是：怎样持续控制软件质量。
一个团队中，技术差距是一定会存在的，这个时候往往技术最强的人会挑起大梁，负责他所在部分的代码质量审核。但一个人的能力越强责任就越大，负责的事情也会越多，往往抽不出身去对代码做特别细致的审核。我们组的代码质量在一开始是比较高的，但后期下滑严重，代码量的快速攀升给审核代码的技术人员带来了很大的压力，有时为了项目能够快速部署上线看到效果，往往会有囫囵吞枣式的审核，代码质量控制也就成为了一个流于形式的东西。但代码质量又是十分重要的，当几个人共同向一个代码库中推送代码时，个人糟糕的代码风格很快就会如雪崩般放大，进而影响到整个项目。对于小型团队而言，当代码量逐渐变大（大至一万行左右）时，有什么更好的控制代码质量的方法吗？
五、各个阶段学到的知识点
1. 需求分析阶段
如何分辨哪些需求是重要的、哪些需求是不重要的：只需要将自己代入进用户，并结合市面上相似产品的功能，就可以大致做出判断。
2. 设计阶段
前端不是上来就莽的，如果没有设计图就直接开工的话，会死得很难看。
3. 实现阶段
熟悉一个项目的最好方式，就是去亲自为其实现一个新的功能。
4. 测试阶段
集成测试往往比单元测试性价比更高。
5. 发布阶段
用户所处的环境千奇百怪，许多Bug真的是在上线之后才能发现的。
6. 维护阶段
学到了Rails项目和React项目在服务器上的部署方法，以及腾讯云对象存储的使用方式。
六、理解与心得
在这学期的软件工程课程中，我的身份一直在发生改变。最开始，我负责小程序的开发，写了几个简单的页面和微信授权登录的逻辑，封装了几个API；后来，我转去后端，学习了Ruby on Rails框架，开始研究后端各种功能的实现；再后来，我去做了网页端开发，从零开始自学React，完成了一个小型的3000行代码左右的网页端社团管理App；最后，我转职为了半个运维+半个后台开发人员，学习了各种项目和各种工具在服务器上的部署，在生产环境中操纵生产数据库上的数据，在作死的边缘大鹏展翅。这期间，我几乎是从技术角度遍历了整个项目的所有环节，也因而得以窥得了项目的全貌。
我的感受是，我们组的项目麻雀虽小但五脏俱全，在各个方面都有所涉及。我之前以为的软件工程（此处暂且特指一下App开发，包括但不限于小程序），就只是一个前端+一个后端，没有什么特别复杂的技术，按部就班行事而已。但后来我发现，为了更好地完成这个项目，需要很多附加的周边知识。例如，为了给小程序以更好地图片I/O性能，我们使用了腾讯云的对象存储服务，这就需要我们去额外学习腾讯云SDK的使用方式，并把SDK和Rails项目有机地结合起来。这期间，我学习到了中间件的设计方式，理解了微服务架构存在的意义；还有，为了做好微信模板消息推送，前端和后端需要共同配合，还需要在服务器上设置一个定时任务，这指引我进入了运维的大门；在运维过程中，我还需要学习前端后端项目在服务器上的部署，对于一个新人来说，把项目部署上去和实现它们几乎是同样的困难。在Ruby on Rails教程中，有一句很经典的话说，“技术是复杂的”。现在我对这句话有了非常深刻的体会。
也因此我意识到，现代软件工程已经成为了一个很难靠单枪匹马就可以完成的任务，只有团队合作才能给软件项目注以源源不断的生命力。我很感谢我的队友们，和他们在一起的这个学期，我度过得非常愉快。