U（省去真名）是我进公司以来的第一个交付项目，与他相遇也应该用巧来形容，因为原本我们应该去另外一个项目的。当听到我马上要做的项目是五马时，还是很高兴，毕竟我马上就可以上我的第一个项目了。不过心里面也有些疑惑，因为这个项目基本上是处理偏向前端的项目，去调用后台提供的服务，我们本身不提供任何数据的持久化操作或者对外提供服务。不过的确这个项目相比与公司内部的其他项目真的算小的了。我们团队总共4个人，外加澳洲share的两位同事吧。时间也只有3个月左右。不过由于这个项目是从0开始做，而且是大牛@Jeff带着我开发，我学到了很多东西，不仅仅是编程，更是如何去进行敏捷项目的开发，如何推动敏捷项目的正常的进行，如何在团队之中发挥作用。
我们的团队成员：大熊、弘、梦秋、以及在项目shadow过一段时间的青。
- 大熊，技术大牛，不仅仅教会我们了如何写好代码，他在很多时候，还把一些事情放给我让我去track、去push，并告诉我怎么样去和澳洲的同事、同事沟通、合作才能把这些事做好。在他的丰富的经验的熏陶和潜移默化之下，我感受和体会颇多。
- 弘，我们项目的QA兼职BA，看吧，从这点就可以看出我们项目的之小了吧。不过这也辛苦了孙弘了，感觉在我们团队里面又当爹又当妈的。感谢孙弘教我怎么样写测试用例才是最好的。
- 梦秋，从我们的Drupal Team过来的孩纸，比我早一年的公司，我们项目的大部分前端的架子都是她搭起来的，在她身上我也学到了很多前端方面的知识，我想我再也不会胡乱的写css selector了。梦秋童鞋有一股很较真的劲。
青，在项目中途进来的孩纸，谢谢你免费帮我们项目做了这么多Story，也恭喜你马上就Billable了。
在项目中要求的几点，从项目开始到现在，我觉得是很有感触的：
代码测试覆盖率100%。的确，如果我们是真正严格按照测试驱动开发，先写测试代码，再实现，基本上是不会遇到测试覆盖率不过的（基本上>=90%）。你也许会说，如果遇到某些方法不能测试怎么办，在项目中我遇到过两三次觉得代码不能测试的情况。但是由于我们的测试覆盖率要求100%，所以我不得不去寻找测试代码的方法，所以即使经过多次尝试最后发现代码的确不太好测试，那么我对那段代码也是相当熟悉了，也基本上保证了代码的正确性。当然最后面对那个我认为不能测试的方法，我写了一个很屎的代码去通过覆盖率要求。但绝大多数最初我认为不能测试的代码，最终都表明是可以测试的。比如Spring中的 HandlerInterceptorAdaptor。
大熊的三层设计：如何测试系统的外部服务，同时还要保证外部服务挂掉的时候，不影响我们正常的开发。用Integration Test保证外部服务的真实、正常、可用性，用本地的缓存的真实的服务器相应数据来进行一般的本地代码的测试。用Mockito来进行controller级别的测试。为了保证我们本地的应用可以正常跑起来运行，我们还用了校长@dreamhead开发的Moco,保证我们本地的应用可以正常运行和测试的。更详细的文档可以看大熊写的两篇文档《都是为了半夜能提交》1,2。我也希望后面可以另外写博客用自己的话讲述我们在项目中怎么做这些测试的。
在这个项目中，当大熊不在的两周，我们剩下的人需要负责更多的事，以前可能很多问题需要找大熊才能解决的，现在也许就需要我自己来处理了。不过所幸的是，经过和澳洲的同事打电话，聊天，两天下班以后加了点小班，问题都被一一搞定。这两周也是我最独立、主动的两周。承担了应该承担的Responsibility。
在这个项目期间，我看了《Rework》和《程序员职业素养》这两本书，也对程序员的身份有了更多的认识。让我明白，一个程序员需要对自己写的代码负责，而不是写一坨自己都不认识的屎。
当前天得知自己马上就要离开小组时，刹那间突然很舍不得，舍不得这个团队，舍不得自己写的那些代码。不过，从一个项目到另一个项目是很正常的，项目总有自己的生命周期，把他当作是一个学期的大学课程就好了。这学期快结束了，下学期也不远了。
下周星期一就到新项目了。加油！恨自己，写得那么烂的文字。