提问回顾与个人总结

问题回顾

问题一：单元测试是否只能由程序的作者进行编写？

• 诚然，没有比作者本人更了解代码的人，由作者写单元测试程序在效率上可能确实更高，但根据我的经验，单元测试的质量可能会有所下降。我自己在写代码时，常常会有一种思维定式，往往很难发现程序中的固有bug，而是要通过讨论以及与大家共同交流测试样例才能找出bug所在。如果完全由作者本人进行单元测试的书写，我认为很可能会陷入和我一样的困境，自己程序的正确样例会反复测试，而错误样例却一直很难发现，在这种情况下，由他人或者多人一起书写单元测试，集思广益，难道不是更高效且更具质量的做法吗?

• 原本我认为单元测试由专门的测试人员来编写质量应该会更高，但经过一学期软工课程的学习后我发现这个想法有些脱离实际。首先，他人编写单元测试的话必须要先花大量时间熟悉相应的代码，这不仅会对他人造成负担而且有可能耽误项目的进度，在团队项目的开发过程中，我们团队的单元测试也都是由本人来编写，交给专门的测试人员编写的话实在有些异想天开。其次，他人编写的单元测试很难随着项目的进展而一直维护，当原本的代码经过修改或优化后，原本的单元测试case也要进行一些针对性的更新，而作者之外的人书写的单元测试很难做到这一点，因此测试的质量可能会有所欠缺。
  单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。做好单元测试，尽早发现程序中的bug，对于整个项目的测试成本，测试效果以及产品质量都是很大的提升，因此开发人员必须认识到单元测试的重要性并由作者本人来编写测试代码。

问题二：只要助于程序逻辑的清晰体现，什么方法都可以使用，包括goto？

• goto语句一直是人们争论的焦点，1974年，D·E·克努斯对于goto语句争论作了全面公正的评述，其基本观点是：不加限制地使用goto语句，特别是使用往回跳的goto语句，会使程序结构难于理解，在这种情形，应尽量避免使用goto语句。我深以为然，goto语句虽然功能强大，但会使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。去掉goto语句后，可直接从程序结构上反映程序运行的过程。这样，不仅使程序结构清晰，便于理解，便于查错，而且也有利于程序的正确性证明。如果单纯为了书写时的逻辑体现而滥用goto，从而造成代码可阅读性的下降以及其他隐藏危害，我认为是得不偿失的。

• 我认为，这里并不是倡导我们使用goto，而是要根据实际情况灵活处理各种问题。任何事物都不能说它是绝对的好或是绝对的不好，其实只有最适合的才是最好的。不提倡使用goto语句的语言，大多是有自带的垃圾回收机制，例如java，它不要求程序员过多关心资源的释放问题，然而对于C++语言来说，程序员需要自己管理资源的分配和释放。倘若没有goto语句，那么我们在某个函数资源分配后的每个出错点需要释放资源并返回结果，这样的代码会显得非常冗杂，而这时使用goto可以方便的为资源释放设置统一出口，其实使程序的逻辑更加清晰了。因此，根据实际情况选择最适合的方法即可，就像我们开发的团队项目，往往是针对某一特定用户的，明确客户的需求做针对性开发才能最优化用户的体验，做出最适合典型用户的产品才是最好的。

问题三：关于结对编程方式的疑惑

• 结对编程自然有很多好处，两人相互鼓励，相互监督，不容易偷懒，但我认为其也并不是没有害处的。根据我的经验，一个水平高的程序员和一个水平低的程序员一起编程的话，往往水平高的程序员会做更多的工作，在这种情况下，水平低的程序员可能不但无法贡献出自己的思想精力，还可能会拖整个项目的后腿，更别提作者在书中所描述的这种方式了，两个人共用同一个鼠标，同一个显示器，我认为这种结对编程的方式实在是太过于理想化且不现实。在我的理解中，结对的两人分开工作，可以定期进行交流讨论，在自己的空间中最大限度的发挥自己的才智，这才是结对编程的正确打开方式。

• 结对的编程方式其实是有利有弊的，在结对项目中，我和队友互相帮助互相鼓励，有问题就一起协作解决，没有产生过什么大矛盾，出现小分歧也可以很快就解决掉。但由于本学期结对项目主要是以线上的方式进行的，感觉我对结对编程这一模式的理解还不够深，没有太多体验到结对编程消极的一面。但我认为队友的选择是至关重要的，不管是两人编程水平的差距，还是两人的性格沟通能力，都会对结对项目的进行产生影响。

问题四：关于程序员和项目经理的交流

• 在第九章中，作者论述到项目经理最大最独特的贡献是带领团队达成最重要的目标，并保持团队平衡，但根据我的经验，实际情况可能会更加复杂。作为程序员，如何清楚的向项目经理表述自己的想法与能力？尤其是意见遇到分歧时，应该以什么作为优先考虑目标？如果项目经理制定了错误的或者是不切实际的目标，我作为程序员除了只顾编写自己的代码还有更好的解决方式吗？

• PM可以说是整个团队的大脑。程序员也不可避免的要和PM打交道。在项目进展的过程中，我认为保持与PM的有效沟通是十分重要的。PM毕竟不是直接写代码的人，有些设计和要求跟实际情况可能会有所偏差，或是工作安排超出了程序员的个人能力，或是安排工作上比较冗余。这时就需要立即与PM进行沟通交流，且需要掌握适当的沟通技巧。在我的团队项目中，PM提出需求后也会跟我们相互讨论，共同完成整个项目的设计，不会出现代码编写人员和PM脱节的情况，总的来说我觉得是合作比较融洽的。

问题五：作为软件开发公司如何平衡所谓的bug与改进空间

• 在第16章中，作者有这样的论述：当一个产品要发布的时候，通常都留有一些已知的bug而不去改。一方面原因是产品要即时发布才能有盈利，另一个原因是为下一阶段的产品迭代留有余地，团队会更有干劲。但是如何保证自己的bug不会对用户的体验造成影响呢？留什么bug才能最大限度的留住用户同时激励团队的开发干劲呢？

• 安全性的bug肯定不能留，我觉得在不影响用户体验的情况下，留有一些bug或者尚未完成的功能对于团队未来的迭代开发是有一定好处的，也可以让团队在每个阶段明确自己的工作重点。但是在实际情境下，这个想法可能会因测试人员而无法实现，在我的团队项目开发过程中，我们也没有刻意的去留一些这种bug，我觉得平衡发布产品的质量和未来的开发空间是很有意思的一点。

产生的新问题

• 如何正确实现前后端分离？在我的团队项目开发过程中，一般是前端提出并设计API交由后端实现，但有很多事务其实前后端都可以实现，例如对用户错误操作的处理，这部分功能应该交由前端实现还是后端实现更好呢？在真正的开发过程中，前后端是否应该有明确的责任分工？

学习到的知识点

需求

以前我认为需求分析只是一个很简单的步骤，但学完本课程并在团队项目中实践后，我认识到软件需求分析是整个项目中至关重要的一环。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础，其实很多项目的失败，最后都可以归结到需求分析的失败。在我们的社团项目中，我们主要与社联的人员进行交流，充分了解了他们的需求后才开始设计。在具体实践中，可以采用NABCD的需求分析法。

设计

设计是软件开发的基础，也直接决定了项目代码的质量。在设计阶段需要考虑使用什么框架，团队成员对于不同框架的学习成本等诸多问题。同时，功能规格文档，技术文档，代码规范文档也是必不可少的。有了规范的设计文档，在项目实际进展时才能做到有条不紊，随着项目规模的不断增大，这一方面也显得越发重要。

实现

首先，良好的分工是项目正常实现的基础。我们团队将主要工作划分为前端和后端两部分，每个人负责某一具体的功能。其次，良好的沟通是项目实现的催化剂，会使得工作变得更加容易，我们团队会在每天一次的例会上交流个人进展，遇到困难也可以互相讨论帮助。我个人在团队项目中主要负责前端代码的编写，学习了react.js框架，并熟悉了antd组件库的使用，对网页端代码的编写实现有了更为深入的理解。

测试

在开发的过程中，每个开发人员都需要编写自己负责部分的单元测试，优秀的测试可以及时发现程序中的问题，让程序在发布之前尽可能多的去除bug，使产品的稳定性，实用性，可靠性都得到提高。除此之外，随着项目规模的增大，仅靠人工测试已经不足以满足要求，学习使用一些成熟的测试工具也是必不可少的。

发布

发布阶段体会到的至关重要的一点就是一定要提前了解相关平台的规则并预留出足够的时间以保证发布阶段的顺利进行，且发布阶段的工作不仅仅是简单的上传代码，对产品进行适当的宣传推广也很重要，要尽可能让更多人使用我们的产品，这有助于收集用户反馈，对后续的版本进行更好的维护。

维护

产品发布并不是软件工程的终点，对产品持久的维护与优化也是必不可少的，这是决定产品寿命的关键。在维护阶段，一方面要根据收集到的用户反馈进行针对性优化，修复bug并完善相关功能。另一方面，维护工作不应该总是被动地等待用户提出要求后才进行，应进行主动的预防性维护，不断提高测试的质量，重点关注未来将要发生变化或调整的部分，通过预防性维护为未来的修改与调整奠定更好的基础。

理解和心得

一学期的软工课已经到了尾声，感觉收获还是很多的，主要有以下几点：

• 首先是单元测试的重要性。在个人项目中每个人都进行了单元测试的编写，

• 在结对项目中，

• 在团队项目中

我相信在软工课上学到的知识今后能够得到进一步的实践，成为一份宝贵的财富。

原文：https://www.cnblogs.com/KSMLighter/p/13152753.html