- 尽最大的可能利用好每天的pair（结对编程）的机会，向他们学习，了解我们的代码的框架。
- 工作之余基本上都用来学习这些对我来说全新的技术，如果有问题google之，如果无解，则在上班时间提出，总有人能够给我答案。
- 阅读已有代码。希望从其中找出关于某些知识点的实际应用，并与我所学的相互验证。
- 团队内部定期不定期的开展关于技术的session，每一节我都不会拉些来。
所有的这些action，无一不显示出我对这些技术迫切掌握的热情。每当解决一个问题，掌握一个知识点，看懂已有系统框架中的一处设计，或者发现code base中的一些可重构的代码，都是满怀欣喜的。当然这就更加的激励了我，看更多的代码，学习的更深入。一切都朝着我们的目标顺利前进。
开起来很美！
但是当我的注意力全部被学习这些技术的热情夺走的时候，我就忘记了思考。
思考我做这件事的目的是什么？
有没有更好的方式完成我的目标？
- 目的已经清楚了，我想为团队做更大的贡献。是的，当我冷静下来的时候，我还是能够把握我们的目标的。掌握这些技术，无疑能使我给团队带来更多的贡献。看来我做的还可以。
- 好吧。那为了完成这个目的有没有更好的方式呢。那就的从我的目标说起，什么是对团队的贡献，多些代码？多修一些defect？这样当然是贡献了，但是当我在写代码的时候，我并没有考虑为什么要实现这样的功能，我们为客户提供这样的特性，能给他们带来什么样的价值。或者说我假想一个系统最终用户，在使用这些功能时到底会是一个什么情况。只知道写代码，而不知道为什么写，是一件很可怕的事情！！
冷静下来之后，我再想，如果我在加入一个新团队的时候，这样做，情况有可能会大不一样：
- 了解客户的业务，他们是怎么挣钱的？
只有了解到我们的可用的业务，才能有可能为他们提供有商业价值的软件，否则，一切都是未知。即便我们的客户已经对我们非常清晰的指出了他们所需要的功能，这样也是无法保证我们的交付是有价值的。如果说，我们没有能力了解客户所处的领域的业务，我们是否就可以让客户指挥我们给他们提供所想的功能呢。当然，此时的我们仅仅是一个提供商的角色，而不是一个合作伙伴。这两的区别就在于，后者能够为客户提供具有价值的咨询服务。
- 做一个星期的QA，（当然时间是灵活的）。
在这前两个项目中，我遇到了相同的问题，我不知道如何使用我们的系统？我不知道我们到底提供哪些功能？谁将使用我们的系统？是否觉得有些好笑呢。事实是有这样感觉的团队成员不在少数。在新加入一个项目之后，不应该是急于写代码，而是首先熟悉如何使用这个系统，了解这个系统到底为客户提供了什么服务。在了解了这些context之后，编写代码才会有一个正确的方向。甚至我们在编写代码过程中，能够提出更好的业务领域的方案。
- 跟BA/QA多多交流？
为什么没有说跟DEV多多交流呢，难道就不重要吗？当然不是，因为Dev间的交流从来都不容易被人忽视。我们公司提倡的是结对编程，Dev们每天都会有很多的交流。同时交换结对，也是我们的知识在所有的Dev中快速的分享。但是跟BA或者QA的交流可能在无意识间就有可能被忽视。这样的忽视不少见，结果可想而知，开发的代码有可能就无法满足业务需求。