M1/M2阶段总结

• 以前提问的博客

问题解答

---

问题 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并进行维护。