- 之前提问的博客
问题解答
问题 1
关于代码复审，复审者是否应该参与编码？如果复审者也参与编码的话，那么难免任务量较多，但如果不参与编码的话，工作分配的似乎不太均衡。
我们的团队项目在M1和M2阶段没有刻意去做Code Review，只有在发现bug后才会由大家一起来进行debug。这个过程中我们也发现了不严格按照代码规范来写代码会给调试bug带来诸多不便。有时一段代码连当时写代码的人都已经要花好长时间才能重新看懂，更不要说其他人了。
根据我的了解，一些大公司对Code Review的要求很严。每个程序员除了写代码，还要对相应的一段Code进行复审。据我的学长说他的代码第一次Code Review的反馈结果中绝大多数都是针对代码注释的，甚至连英文注释中的语法错误都指了出来。听起来很恐怖。
问题2.
关于敏捷开发，敏捷开发的过程似乎很混乱，它的需求似乎经常会改变，这样不就是没有设计好就开始写代码？那么难免遇到很大块的代码需要修改。
我们在M2阶段的开发中就遇到了这样的问题。之前原定的开发计划，由于学校服务器的原因而泡汤，只能放弃之前已经做了一半的讨论区开发的工作。
但是在开始写代码之前还是要有一个总体的设计，如果之后有改动，则要对相应的设计进行修改。
问题3
敏捷开发的过程在我看来仅适合一些小型的项目，大型项目中如果想应用的话会搞得一团糟，是不是呢？
通过询问一些正在实习的同学、学长，我发现目前的小型创业公司似乎都采用了敏捷开发的项目，一些大公司其实也把工作分为了一个个相对较小的项目组，每个项目组或多或少的都会应用到敏捷开发的一些思路。
问题4
单元测试要求对一切输入都有正确的输出，不能依赖自己的其他模块的代码，那么这难免会使我们倾向于把每一个模块都设计的很大，从而减少单元测试的压力……该如何避免这种情况？
这个问题现在看来似乎没有什么意义。因为在写代码的时候根本不会考虑到单元测试的问题……所以大家在写代码的时候基本都是按照应有的逻辑来写。做单元测试时也就只能正常做了。
问题5
结对编程，仅是指两个人共用一台电脑，一个人写，一个人看吗？两个人进行任务分配，每人完成自己的任务，也是一种互补的编程形式，这算不算结对编程呢？
对于结对编程的定义，书上已经说得很清楚，两个人进行任务分配，只能叫做“协作编程”，结对编程的重点在于两个人同时完成一份code，从而使得代码具有较高的正确率，减少一些不必要的错误。
新的问题
产生了一个新问题就是：在团队的开发效率开始变低时，作为PM应如何激励团队成员来保持开发热情？是否应制定一系列的奖惩措施？这个问题在企业中或许很容易解决，但是作为学生，同学间似乎很难去强行要求他人。
论文回顾
如今重新去阅读那些文档，我终于明白了，作为一个项目的开发者，你首先要对自己的项目感兴趣，之后才能做出漂亮的、有用的项目。如果自己都感到无聊，那么项目的质量也可想而知。
此外，开发者应该经常与用户进行交流，确切的知道用户需要什么，我们才能针对用户的需求进行改进。
当然，程序的健壮性更好有切实的保障。
我还从中看到了一句感觉很有意思的话：保持项目的简单性。设计达到完美的时候，不是无法再增加东西了，而是无法再减少东西了。
我觉得目前的很多产品都能从这句话中学到很多。
知识点
- 需求： 在进行需求分析的过程中，我学会了分析目标用户、以及进行场景分析。通过问卷调查、投票等方式找到项目所要解决的核心问题。
- 设计： 在设计阶段，我明白了API的重要性。
- 实现： 在项目的实现阶段，我第一次通过github配置了milestonw、issues以及燃尽图
- 测试： 在测试阶段，我对场景测试、测试矩阵有了大体的了解。
- 发布： 在发布阶段，我了解了产品发布的流程。以及版本号的管理
- 维护： 通过用户反馈，可以让我们了解到产品存在的bug并进行维护。