提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 作业属于哪个课程 | 2020春季计算机学院软件工程 |
| 作业的要求 | 提问回顾与个人总结 |
| 课程的目标 | 经过了一学期的学习，总结自己的收获，解决自己在曾经的疑问。 |
一.第一次作业链接
二.问题解答
问题1
原问题如下：
在原书第85页，有如下描述：
在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。两人合作，还有互相激励的作用，工程师看到别人的思路和技能，得到实时的讲解，收到激励，从而牡蛎提高自己的水平，提出更多创意。
我的疑问在于，考虑工作和学习中的结对编程，我们需要考虑到合理的分配两个人的任务，如果只是将工程分解为数个模块分给两个人做，那结对编程和团队编程有什么区别呢？
其次，编程并不是做数学题，我们还要考虑到代码风格等等问题，我觉得两人合作解决问题的能力更强这句简单的描述缺乏说服力，强行结对可能并不能有文中事半功倍的效果，在后文我们也能发现，作者所指的结对编程需要大量的磨合，这种高投入的方法真的适合高强度的现代开发吗？
最后，看别人的思路与技能来启发自己，为什么我们一定要在工作中做而不是在其他时间阅读他人代码和文档来起到相同的作用。
在本学期课程中我们也尝试了一次结对编程，与我结对的同学也是我比较了解的朋友。在我们结对编程中，我们遇到了一些问题：
- 代码风格不统一。
- 各人课程时间，往往不能一起编程，而是依赖于文档等进行汇报交流。
- 效率比较低下。当一个人阶段性完成任务后可能需要等待另一人完成其任务并一起进行测试。
考虑到在实际工作中，公司内部应该有统一的代码规范以及一致的工作时间安排，前两点并不是太大的问题，但仍然存在着效率低下的问题：
- 每个人的编码速度可能不一致，debug的需求也不一致，可能造成一方等待另一方的情况。
- 对于前端与后端的结对，两者的工作范围差距很大，不存在所谓互相学习的情况；若是同种工作的结对编程，则会增加大量的文档与说明，而这些文档对于本模块与其它模块的接洽可能是无用的。
综上，我认为结对编程在实际工作中或许必要性不大，作为团队新人融入时，让新人与一位前辈结对，熟悉团队开发流程等或许更加符合结对编程的定位。
问题2
原问题如下：
书中对于"写了再改"模型是持批判角度的，但是我的疑问是，有的时候哪怕我们花了很多时间预先进行思考与规划，也有可能在编码过程中出现问题，毕竟编码是一个细节很多的工作，在真实开发软件时，会不会出现临时增加需求的情况呢(在一些论坛里看见过这类吐槽)，也就是说，程序员可能不得不陷入写了再改的境地。那么当我们陷入这种情况时，有没有什么方法可以让我们能够减少改动？
在我们团队的实际开发中，我们采用了敏捷开发的流程，然而尽管我们预先做了大量的分工、讨论以及文档工作，依然无法完全避免"边写边改"的问题，这是因为许多问题只有在代码写出来了后才能表现出来，尤其是我们负责的前端部分用到了不熟悉的框架，事先的许多规划在最后才发现不甚合理。我认为，"边写边改"是无法避免的，只能通过一个团队对于其频繁使用的语言、框架等的熟悉来更好的进行规划，减少"边写边改"。
但这不代表"写了再改"这个模型在实践中是有效的。在我们项目的后期，因为一些课程的考试与大作业，我们负责的前端有同学有几天并未大量参与开发，在之后他们补自己负责模块的进度时因为与以及完成任务的同学缺乏接洽，导致几个人的代码无法直接组合，这使得我们有耗费了一些时间调整。"写了再改"的思路是不可取的，虽然"边写边改"无法避免，我们也要尽量做好规划，尽量减小后期不必要的花销。
问题3
原问题如下：
书中说“很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。”
在这里，可以自由组织的形式可能使得代码风格等接近的同事组队，如果这种组队固化后，每次项目的功能模块实现应该如何分配呢，每个组的工程能力会不会两极分化？
这个问题在我们团队并没有遇到，因为我们都是使用了新工具，大家都是从零学起。在实际工作中，我认为组队并不代表互不相干，各个队伍之间也要互帮互助，共同进步，否则这样的组队有害无益。
问题4
原问题如下：
观察、理解和快速学习能力PM要能够在一个新的领域中很快上手。PM要能理解用户，能站在用户的角度上考虑问题，观察发现用户不善于表达的需求，体察团队成员的言外之意，倾听老板/客户/利益相关人的弦外之音。要有能够理解别人的处境、心理、动机的能力——同理心。一个PM平时或许能玩转很多高技术的工具，但是当工作需要时，他/她能突然把自己变成一个完全不懂技术的菜鸟用户，从用户的角度来看问题。
PM是离用户最近的人，负责把用户的声音传达给开发者和策划人员，但是他同样也应该是将开发者的声音传达给用户的人。就我个人看到的吐槽，很多PM反而是外行人员，他们只能做到前者，却因为缺乏专业素养，往往不能分辨出用户的非合理需求，这时开发人员应该如何与之进行技术层面的协调呢？
PM必须要懂技术，因为很多技术问题，如果PM不懂得相关技术是无法工作的，譬如某一个模块解决的问题理论算法复杂度是$O(n^2)$，若PM不懂得技术，面对客户要求继续降低时间消耗的需求，或许会答应下来而带来许多麻烦。
此外，PM也需要进行很多的相关调研，譬如我们的PM对于后端使用的OCR-API进行了调研，若是对于软件、编程技术一窍不通的PM，这样的调研是无法完成的。
对于实际公司中的那些缺乏技术认知的PM，开发人员与他们的交流依赖于这些PM自发的去了解技术，而这样的PM最终也会脱离"缺乏技术认知"这个标签。一个极端例子是某个讽刺视频里一名PM提出了要实现一个三角形内角和大于180°的需求，这样的PM或许开发人员要考虑的不是怎么和他交流而是反映换一个PM。
问题5
在书中239页提到，一些科学家一直在努力，希望用无歧义的、形式化的语言描述我们要解决的问题，然后用严密的数学推理和变换一步一步把软件实现出来，或者证明我们的实现的确完整和正确地解决了问题。
我联想到了oo时的JML，这是一种对于规格的描述，对于每个class都会有这样的JML描述来约束输入和输出，但我觉得其描述太过详尽，又是甚至将内部的算法也描述了一遍，这样显得有些画蛇添足，为什么我们不直接写一份清晰的代码呢？但是如果不这样详尽的描述，又怎么形式化地进行正确性验证？
在我们的实际编程中，对于规格、接口等主要还是通过写文档、规定好功能、传入传出参数来进行规范，更加严格的如JML的要求我们并没有采用，或许对于更加复杂的项目，这种详尽的规范是有必要的。
三.新的问题
- 强制转会是否合理？因为我们团队是真的没人摸鱼，磨合的也不错，而对于一些团队，可能使用了新框架等，这些框架的学习时间成本不低，强制转会会带来不必要的麻烦，毕竟我们是软件工程课而非真正的开发，人员有限，时间有限。
四.课程知识收获
-
需求阶段
在这一阶段，我学习到了作为一个开发者，需要去调查了解消费者的需求，而不能仅仅通过自己的臆测来决定需求，此外还要去调查市场上是否有相关产品，从而在需求设计上推陈出新，避免同质化。
-
设计阶段
我们做的项目是OCR表格，我参与了后端API部分以及前端实现。当需要使用到其它工具或框架时，需要去对各种可能用到的工具进行调研测试，选取出效果最好、调用最方便的工具；在前端实现时，我们先采用一些UI设计工具做好了效果图，将不同页面实现做好了分配，此外还要预先做好模块划分与互相之间的规格约定，方便后续整合。
-
实现阶段
实现阶段，我认为和我之前的编程最大的不同在于多人协作，个人认为最重要的是做好协调，不重复开发，写好规格文档，同时也要互相帮助，不能分好工后就完全各干各的，只有这样才能避免短板效应，增加开发效率。
-
测试阶段
我们在前端使用了flutter框架，flutter也有单元测试系统，做好单元测试是很重要的。因为flutter是我们不熟悉的框架，在编码过程中有大量的debug，通过单元测试不仅能够快速找到、定位bug，还能对于修改后的代码的正确性进行测试。
-
发布阶段
发布并不只是写几句话就可以的，特别是对于非学校成员的人推荐软件，如何吸引他们的注意力，如何体现我们软件的优势，如何让更多人看到我们的发布，如何提供一个更好的、让大家愿意尝试的发布平台，这些都是值得琢磨的事。
-
维护阶段
用户的反馈对于我们更新维护软件很重要，我们在最开始只能通过用户在我们项目的git上留言以及通过我们提供的联系方式联系我们反馈软件的缺点以及问题，这些反馈帮助我们解决了部分bug，我们也正在开发软件自身的反馈功能来方便用户反馈。
五.课程心得
-
个人项目
这次个人项目我认为最重要的是学习了单元测试，这是我之前从没有使用过的。有了单元测试，才能够在足够复杂的项目中保证正确性，这是与之前更接近算法题的程序所不一样的。
-
结对编程
结对编程主要学习了结对合作以及dll库，dll库可以分离后端核心与前端界面，只要做好接口规格设计就可以方便的将项目分离为前后端两部分，而在体验结对合作时，我们学会了如何协调双方时间，如何写出规范的文档来帮助对方理解，提高开发效率，如何做好接口设计。
-
团队项目
在团队项目中，我主要参与了前端开发，学习了flutter框架，在开发过程中，不仅需要与其他前端同学分工协作，也需要与后端同学接洽，在这过程中，我进一步明白了写好文档、注释的意义，只有这样才能完成与其他分工的同学的交互，此外，在后续的发布、维护阶段，我们也明白了软件工程不仅仅是编程，更是一个工程管理，需要的还有一些计算机外的知识。