如何较快熟悉一个项目？

最近换了环境，开始接触一些新的代码和项目．人总是会迎接一些新的项目，拥抱变化，时间成本往往在成本中成为了最大的成本，于是我也记录一下自己摸索的过程．

 

如标题所说，快速和熟悉是两个重点．快速，自然是在很短的时间内完成更多的事儿．

１．工欲善其事必先利其器．

我第一步就是挑一些好用的工具作为工作前奏．ide自然可以选自己顺手的或者偏爱的，我个人喜欢phpstorm+vim.小文件vim,大的组织结构的project用phpstorm.数据库ｇｕｉ工具在linux下我是用workbench,windows下的选择更多，比如navicat．当然少不了终端工具，即使是在win下也有cygwin来模拟．

 

2.生活不止眼前的苟且，还有诗与远方．

拿到一个项目先根据功能切分成小的任务，做好deadline的设置，给自己排好期，每一步都有计划．不要拿着什么就开始玩命搞，超反方向跑得越用力，偏离目标就越远，不是吗？

 

3.不做盲人摸象的事儿．

代码是业务的实现，业务是代码的具象化．有些人拿着代码就开始看，一个一个controller跳转去看，一个一个function去读里面逻辑，其实走了很多弯路甚至会迷路．我个人认为应该先从功能业务上梳洗，先理解业务，然后看对应的代码，进行操作，chrome下追踪http request,在web page和代码之间一一对应去理解逻辑，然后每个功能点去看数据库的设计，字段含义，特殊的枚举值等等．这个操作和分析的过程中得有记录，方便日后回顾和思考．有不清楚的也得记下来，独立思考后不得解即可问相关更熟悉的同事或pm.

 

4.多询问多沟通．

以前就有人告诉我：能力是一定的前提下，沟通往往比能力重要得多．

一切的功能业务，往往都是来自于人的设计．除非你是在做自己独立设计开发的项目，否则你都得理清需求本质，因为产品不是你一个人能决定怎么build.在自己结合功能业务和代码分析思考后还不能解决，必须和其他熟悉业务的工程师沟通，你得理解整个逻辑，才能在这个基础上进行合理的开发．就算是新的功能，也得多和ｐｍ确认流程和细节，沟通得越多，未来花在沟通上的成本就越少．沟通的成本是唯一一个不能避免的成本，但是也是很有价值的．

 

往往我们看到一些工程师做了很久的一个项目或功能，被推翻重做，或者反复改动，往往都是前期或者开发过程中和ｐｍ或者客户沟通少了，反馈少了．我们一直在强调迭代开发和快速集成，其实沟通和反馈也是遵循这个原则的，不断地快速集成你的反馈．人最喜欢的干的事情就是自动脑补，当你做一个东西判断条件或者做法产生了两条不同的路，你得小心，也许你的脑补就是和pm背道而驰的做法．

 

５．一切皆可成书．

在你熟悉的过程中，记得做好笔记，或者能成文档是最好的．总会有后来人去接手你的项目，你的总结不止是帮你梳理了整个项目的业务代码，更是加速了整个项目的良心发展．我的原则是：多截图，关键性代码，关键性sql语句．甚至一些重要和复杂的功能模块或业务流程我会画出uml图．别担心写了这些没用，说没用的大多数都会后悔的．

 

欢迎有看到此文的朋友留言讨论，毕竟我的能力有限，肯定有不足之处，请不吝赐教．