初步看了推荐的文章以后，我选择了最后一篇文章来阅读，原因是“软件工程的方法论到底有多少用处”这个问题也是我目前很大的一个疑问，于是我决定首先看看这篇文章怎么说。

       文章在开头举了一个离我们很近的例子：结对编程到底是解决了代码评审的问题还是无谓地增加了沟通成本？作者提出增加沟通成本的意思很清楚：结对编程非但没有逃避代码评审的繁复，却增加了额外的工作量：沟通，并且这些沟通并没有起到期望的作用：使一段代码由两个人看过以后更加完美。

我在结对编程中便遇到了这样的问题，当一个人在写代码时，他的思维运转是比较快的，而且带有个人的特色，这样坐在一旁的partner并不能很好地跟上节奏，导致其并不能专注在审查代码上，更坏一点的情况是partner完全不能理解某段代码，这时候还需要写代码的人来解释一番，随后便是恍然大悟，并不能及时地发现bug。最后仍然需要用测试用例去跑了，才能发现bug，并没有明显地减少bug的实现。

       当然这个问题有可能是因为我们并没有完全进入结对编程的状态导致的，但是，不得不说，结对编程对于我现在的软工实践经验来讲，并没有他的倡导者所讲的那么好，在上一篇读书笔记中我提到《移山之石》中作者对结对编程的赞赏，真实体验并不完全如此。

       本文引用Michael Feathers的话讲到软工实践中最倚重的还是开发者的能力，同时我们又没有一套行之有效的衡量的方法。日后没有意外我应该会从事it行业，至少是与其相关的职业吧。那么我应该用什么办法展示自己的能力呢？既然没有一套很好的衡量方法，那么对于从业者来讲，便应该用更好的方法去向他人证明自己的能力，这应该是我需要思考的，扯远了，这只是我的一点思考。

       说回软件工程方法论的东西，正如作者提到的，有两大原则可以大体上指引我们进行好的软件工程实践：化小开发周期和提升反馈效率。

       化小开发周期，我觉得就是说不让一个项目进行的时间过长，可能时间的急迫感有利于提供生产效率吧，但是作者没有给出严密的说明，“如此多的创新被发现，只要你真正理解了你在做什么，你就能发现任何事物”，这句话被作者用来说明在大型项目开发中缩短周期是非常重要的，就这一两个星期的团队项目时间来说，“不能真正了解自己在做什么”意味着没有明确的目标，对于项目需求的理解也是模棱两可的，这样确实不能有效率地工作，确实是不利于项目的推进的。

      作者引述了另一篇论文讲功能型团队对于缩短周期的作用，我把这篇论文也看了，然而这篇文章涉及了很多让人不明白的概念，我把文中关于跨功能性团队的内容做一些简述吧。

       所谓跨功能团队，要能够实现持续交互，一个办法是让开发人员、测试人员以及数据库管理员等等在一起进行开发，即时地沟通双方的意见，这样能够减少发布成本。

仅是一个大概意思，这篇文章我是没有怎么读懂。

       我们团队现在是把开发和测试分开的，开发者在提交代码审核以前，不会考虑测试者的需求，而测试者也只有在拿到程序以后，才能根据自己对需求的理解进行测试，再反馈给开发人员，如果我们能够把交流的过程提前到开发过程中，会不会减少商议沟通成本？（现学现卖的一个词）

当然，对于筒仓的瓶颈，作者也提出了另外的解决办法，比如说让团队成员的角色轮换等等。

       这篇文章的评论里面有一个人提出了与开发者的个人能力很重要不一致的观点。他认为对于开发者来讲最重要的应该是主动性和责任感。这两者如果都被一个开发者所有的话，就算他当时能力有限，同样也能够进行高质量的工作。同时他也提供最好的开发者们往往能够起到减少代码行数的作用。

       主动性和责任感已是老生常谈了，而这对于在大学中进行软工的简单实践者来讲尤其重要：我们目前的项目并不需要个人能力特别突出，更加强调团队的协作，好让每个人都能体验到一个软件的生命周期的全过程。保持热情，主动地承担工作，对自己的工作负责，就能比较好的完成软工的实践，可能最后也得不到一个特别出彩的分数（算是吐槽吧），但是这个过程是完整了，毕竟，日后我们大多数人都要在某个团队里面，完成产品的开发，这也是作为it行业从业者的生活常态吧。