提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 通过这门课锻炼软件开发能力和经验，强化与他人合作的能力 |
| 这个作业在那个具体方面帮我实现目标 | 在本课程即将结束的时候回顾过去提出的问题，并总结课程收获 |
一、第一次作业链接
二、对过去问题的解答
- 问题一：
单元测试代码的编写该只由作者完成吗？
当时我的想法是确实应该只由作者完成。之所以会提出这个疑问，是因为在之前的课程中，我们同学之间都会互相交换自己构造的测试用例来验证各自程序的正确性，也就是说两个人看一份代码查出错误的概率一定比一个人单独编写的要高。而在经历过团队项目以后，我更加坚定了单元测试的代码就是应该由作者完成。因为各个模块之间的开发是独立的，要强求别人阅读你的代码并编写单元测试，既费时又费力，成本上不合算，而且如果对方没有能很好地理解你的代码，单元测试覆盖可能会不完善，导致bug数目的增加。
- 问题二：
学生和职业程序员的区别
书中2.3节写到：
软件工程师比大四学生多读了3年书，多工作了3年，两类人任务的质量要求也不一样。我们可以看到，工程师在“需求分析”和“测试”这两方面明显地要花更多的时间（多60%以上）；
但是在具体编码上，工程师比学生要少花1/3强的时间。显然.从学生到职业程序员，并不是
更加没完没了地写程序 —— 花在写代码上的时间反而少了许多。
当时我的感觉是学生和职业程序员其实区别不大，因为现在的课程要求对于正确性非常地严格，代码稍有疏忽就会丢掉非常多的分数，而需求分析方面，如果能多花一些时间阅读题目要求的话，可以少走一些弯路。基于这些原因，我认为学生和职业程序员其实区别不是很大。在经历过个人项目、团队项目之后，我发现了我自己之前想法的问题。真正接触了软件工程之后，才知道需求分析这部分做起来其实比想象中要花的时间还多得多。就以我们团队为例，在确定选题方向的时候，我们就花了一整天来确定项目方向；然后又花了两天时间调研用户需求，最终才决定下来项目要开发的功能和实现方式。完全不像以前理解题意就可以直接上手写。而测试部分，可能由于我们的软件功能并不是很复杂，因此花在测试上的时间也比较有限，如果开发了一个比较功能完善的项目，花在测试上的时间肯定会多得多。学生和程序员的区别，确实就如书中所写，“需求分析”和“测试”这两方面花的时间有明显的不同。
- 问题三：
如何正确的使用goto语句？
这个问题书中的想法是：“只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto”，而当时我并不认同，因为它会使代码结构变得复杂的可能性大大增加，并且完全有不影响程序逻辑、可以等价替代的语句。现在我也不认同这个观点，因为团队项目让我认识到了代码质量的重要性，如果团队的代码风格越是统一，那么阅读其他模块的代码就会越容易，goto语句实际上对程序的逻辑性是有反效果的，不使用goto语句已经成为了大家的共识，因此，我依然保持我的观点，goto语句尽量不要使用。
- 问题四：
对于结对编程的模式的疑问：
书中4.5.2节写到：
在结对编程模式下,一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电
前,面对局一个显示使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计,
一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等。我并不认可这种做法，在现在代码管理软件如此发达的情况下，结对编程应该更适合于书中下文所说的（有可能是由于我没有尝试过这种模式）：
编程从来就是一个人的活动。学校里是这么教的，我们一直以来也是这么做的。两个
人本来可以去做两个模块，现在一个模块两个人写是不是一种浪费（这可是两份工资
哦）？
当时的我并不认可这种做法，自己经历了结对项目以后才对这种做法开始认可。而且助教也对我的疑问发表了自己的看法：
对于书中的“结对编程”模式的概念，我的第一想法就是类似于小组作业那样的各自完成自己的模块，而书中的概念却是两个人一起编程。但我觉得结对编程是有一个前提条件的，即老手和新手结对编程效果会更好，也如助教所说的，对两者的提升都很大，新员工向老员工学习编程知识，新员工帮助老员工发现bug；角色互换以后，老员工的指导对新员工也会有很大的帮助。当然，如果两个人水平差不多的话，互相学习编程风格其实对两个人的提升都很大。在经历了结对编程以后，我也很认可结对编程的模式，用一定的时间换取了两个人编码能力和质量的提升。
- 问题五：
对于开发阶段的疑问
在15.1.5节中写到：
团队要有把Bug都搞定的执行力。ZBB - Zero Bug Build,即这一版本的构建把所有已知的
Bug都解决掉了。为了实现这一点，就应该尽量在开发阶段减少bug，但开发人员在开发阶段是写完一个模块马上进行测试好，还是写完所有模块再进行测试好？在我编程的经验中，如果等所有模块都写完后在进行测试，会发现bug难定位、不知道错误的代码在何处等问题，如果写完一个模块马上测试，又会显得效率过低，采用哪一种模式会更好？
当时的疑问，简单点说就是对于测试，开发人员在开发阶段是写完一个模块马上进行测试好，还是写完所有模块再进行测试好？经历了团队项目后，我觉得这个问题的答案已经很明显了，就是写完一个模块马上进行测试会更好。因为就拿错误处理的思想举例，错误处理尽可能都会要求局部化，这样在发现错误的时候可以尽快地定位所在，而如果错误处理的范围过大，那就显得没有意义了。测试也是这样，测试的目的本身就是为了提高软件质量，写完一个模块马上测试也并不会让效率变低，反而可能会省下许多定位bug的时间，因此，在开发完一个模块尽可能马上做相应的测试会更好。
三、产生的新问题
-
关于项目代码重构的问题
在发现项目代码使用的框架有更好的上位替代品，比如我们团队项目后端使用的是django原生框架，但是如果drf使用框架实际上可以有更好的效果。发现这个问题的时候已经是项目开发中期了，由于两者效率上的差别并不是很大，而且所剩开发时间不多，我们就没有选择代码重构，但是从可维护性的角度来讲，是否需要在发现问题时候就马上进行重构呢？
四、软工过程中学到的知识点
-
需求阶段
这一阶段是很经典的对项目的NABCD进行分析，即如何分析需求(Need)、做法(Approach)、好处(Benefit)、竞争(Competitors)、推广(Delivery)，而结合我自己的经历，推广是最重要的一部分，而需求分析则是为推广奠定基础，只有解决了用户的痛点需求，才会愿意去使用，甚至推广你的软件。
-
设计阶段
设计阶段对应于博客作业即任务拆解、功能和技术规格说明书。任务拆解帮助我们在开发过程中明确目标，并有机会量化进度，个人认为也是开发过程中最重要的部分之一。而技术、功能规格说明书则是帮助完成任务拆解的辅助材料，确定整体目标。
-
实现阶段
这一阶段其实学习到的东西挺多的，主要是一些编程思想，例如错误处理的局部化、完善化，数据库设计的基本思想以及架构设计的可扩展性。同时文档和代码注释也非常重要，一方面可以方便前后端、爬虫沟通数据格式，知道接口的使用方法，另一方面也可以让项目的可维护性大大提高，有助于下一届迭代开发。
-
测试阶段
这一阶段主要是单元测试，单元测试不仅可以验证模块功能的正确性，而且也对回归测试有很大的帮助。而在这个阶段，我们也发现了错误处理的重要性，错误处理做的好，那么在发现bug时候就可以很快地定位到bug，否则可能就得找很长时间。
-
发布阶段
在发布阶段最重要的就是推广的手段和方式了，尽量向不同系的人推广，可以让用户数目增加更多。
-
维护阶段
每天查阅服务器上的log，看看有没有异常行为以及代码运行错误，如果有则及时修改。
五、结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
-
个人项目
个人项目题目的难度其实并不算大，就是数学公式的计算，而算法上我并没有找到一个速度很快的算法。其实比较担心的是精度的问题，使用不同的算法，中间结果的精度也会不一样，导致最后算出来坐标数目的不同，当时应该规定一个eps，减少精度的影响程度。最关键的一点就是要仔细阅读题意，在编写代码的时候要对可能出现的问题有敏锐的意识。
在测试方面，自动化测试的手段很重要，这是检验项目正确性效率最高的方式。
-
结对编程
第一次接触结对编程，本以为是和之前的小组作业类似，但其实大有不同，两个人合作，可以互相学习编程能力，而且借着这个作业也结对伙伴的交流也比较频繁，任务进展比较顺利，两个人都学到了很多。同时也学会了使用github管理两人的代码，提高开发效率。
在测试方面，回归测试很重要，在开发新功能的同时也要保证之前功能的正确性。
-
团队项目
我在我们团队中担任的是后端开发岗位，在这个过程中也学习了Django框架的基本实现、数据库交互逻辑代码的编写、数据库的管理、drf接口的使用。这相当于是一个学以致用的过程，和另一位后端开发伙伴之间的交流也学到了很多，同时，PM之前担任过计组助教的Django后端开发，也经常给我们的代码提出批评与建议，学到了很多django和drf框架的特性。
在团队项目中收获最大的，就是我上面经常提到的，如何写出高质量的代码，其中错误处理、代码注释、代码风格都很重要。正确性不再是评判代码质量的唯一因素，可扩展性、可维护性以及效率才是软件工程项目代码最重要的几个方面。
六、总结
经过一学期的软件工程的课程，其中付出了很多，也收获了很多，最开心的莫过于和团队一起做出了一款类似于“同袍”的软件，大大方便了其他同学的校园生活。总之，有付出就一定会有收获，感谢团队成员的辛苦付出，也感谢老师和助教的付出！