去年10月底受另一项目的号令，我马不停蹄的从SZ赶往NJ进行项目紧急支持。来到NJ后又立马投入到该项目的代码熟悉与环境搭建中。在熟悉差不多的时候被告知版本需求部分不是我目前了解的模块，而是另外的模块，并且立即进入需求规格澄清阶段。听完这些话，我知道前期的投入算白费了，并且还得立马熟悉新模块并进行该需求的开发。所以在得知该情况后，我做了如下的工作：
1.首先需要了解规格所涉及的模块或是部件，知道它们的应用场景，它们是干什么的，大概流程是怎么样的就可以了。这一步骤不是为了详细了解所涉及的部件，而是让你对该项目有个大概了解，从而有个高屋建瓴的感觉。就类似于SE需要知道整个框架而不一定要具体了解某行代码是干什么的一样。
2.了解了所涉及的部件的应用场景后，就得开始仔细熟悉需求规格了。对于大多数程序员来说(比如我-_-!!)，我会仔细一个一个字的阅读我负责的需求，有疑问的话就批注起来。看完之后可能有点晕，不知道需求讲的是什么，不用急，不要立马去找SE或是PM去确认问题，而是静下心来重新看遍需求规格，记得一定要思考，思考打的批注，思考SE写的规格。多想一想。这些规格的意图是什么。个人来说最起码需要把规格看个3，,4遍。这样确认思考下来，你对整体规格就比较清晰明了了。剩下的就直接找SE确认规格问题了。(这里对刚工作的同学有一个建议：就是对于向SE确认问题不要觉得不好意思也不要觉得问的问题很白痴，只要经过自己思考过滤的问题都可以明目张胆的去问，因为我最近接触的刚毕业工作的童鞋会不好意思向SE问问题的情况出现。)
3.规格了解清楚了，那就得开始理一下你所需要开发的逻辑流程了，这个时候没必要就火急火燎的去看代码，看了代码后反而会将注意力集中在代码上，而将本来应该要关注的开发的逻辑流程忽略了。你可以在一张纸上画画自己的逻辑流程。
4.逻辑流程清楚了，那就好办了。开始看代码了，代码很多我们没必要重头看起，而且时间也不允许我们这样做。这个时候那些老员工就有作用了。直接咨询他们入口函数在哪里，这个涉及的功能的代码在哪块。或是自己运行软件，根据日志信息看代码。重点推荐前一种方法。然后重点关注你负责开发代码的那一块。这个时候不要急于代码开发，而是将那附近的或是所涉及的代码反复看，仔细的看。你会发现整个思路会清晰出来。这个时候就可以进行编码了。最忌讳的就是拿起代码就进行开发的。代码的精髓之处在于将自己的思想反映到代码中。
5.代码完成之后一定要进行自测，自己发现的问题越多。后续转测的问题就会越少。你想象一下，旁边的同学一组在改问题单，而您老人家可以干自己想干的事，如熟悉代码加强业务知识。
-------------------------------------------------------
对于开发人员的项目经验，我觉得就是类似于学打篮球一样，会打球的人拿到球后知道是分球还是突破，会有这种意识(即经验)，但这些意识并不是看看篮球比赛就会的，而是需要多锻炼，多思考。
祝童鞋们更上一层楼(当然也包括我自己。-_-)