最近碰到个问题，在五个工作日内阅读一个百万行左右代码量的新项目集合，如何解决呢？
第一个工作日，环境观察。待在那个项目组，看项目成员们在做些什么事情，开发，测试，聊天，或多或少可以收集到一些项目相关的零散信息，这是看和听了。适当向项目成员咨询一下平时项目的一些基本情况，这就是问了。第一个工作日对项目开发环境有一定了解就好，比如开发的方式，是一步步的瀑布法，还是一个个功能的敏捷法；比如数据权限，是有测试环境和生产环境之分的；比如项目组成员情况，每个人的做事风格是有区别的，如果留心观察和思考，会发现他们写的代码往往带有一些个人习惯，或缜密，或条件繁琐，或简单快速，或者套路化，或者千篇一律一个样，这就是个人，团队和项目三者的大致关系了，他们是如何在一个环境中存在的。代码是人写的，是团队合作出来的，是在一种生产环境运行的，最开始了解代码产生的环境，在脑子里面有个大概思维形状是个好的开始。
第二个工作日，文档收集。每个项目或多或少都有一些相关文档，比如项目是用什么框架实现的，各个项目是通过什么协议传输数据的，包名类名规范，基础类继承要求等。最开始因为不熟悉项目，文档看着是有点头疼的，因为感觉多散乱，从简单的自己熟悉的方面开始看就好。可以按照自己喜欢的类型，将文档进行分类，方便形成结构化的文档集。就象数据库建模，最开始收集到数据是没有数据库表和对象的，把一类物质归纳到一起，抽取他们共同的属性和方法，可以反复调用他们，就产生了数据库表和对象了。文档分类类似，习惯把文档按照什么类型分类，然后归纳为一类，一类文档解答一类问题，把没有关系的信息因为可以解答一类问题这个关系而归纳为一类有关系的信息。阿拉伯数字和中文汉字是一个非常好的组合，01+几个简明扼要的中文汉字，就可以明白阐述一类文档了。OK，有特例怎么办，可以看用途，有的特例有使用条件，有的特例可以多处使用，有的特例就是例外，我们可以写个带参方法（条件即参数），可以写个工具类（可以反复调用），可以写个异常和日志记录（触发例外则按异常处理）。
第三个工作日，结构整理。理清技术相关信息，了解基本运行原理。人们往往毫无头绪或者思绪混乱，是因为未知，理解未知的常用方法是用已知的知识结构去解析。
1，jdk1.6，jdk1.6中文API文档。
2，运行java的网络服务器，tomcat7。
3，IDE，Eclipse。
4，数据库，Oracle；数据库操作，PlsqlDeveloper。
5，数据访问框架，Mybatis，数据访问层dao。
6，业务逻辑和控制框架，SpringMVC，基于方法复用service。
7，界面，jQuery EasyUI。
8，系统间数据交互，spring HttpInvoke。
9，分布式缓存框架，EhCache。
10，sql优化方案...
第四个工作日，业务逻辑。一个常用的方法，就是把自己当成用户，操作用户界面，看看实现了哪些功能模块，然后结合代码看看这些功能模块是如何实现的。从哪里收集的数据，如何加工数据到界面上的，用户需要这些数据有什么价值，系统额外做了什么，与其他系统产生了什么交互。然后用笔纸大致画画业务逻辑图。可以对照数据库表，想想这些表是如何抽象出来的，如何让一些没有关系的数据建立起数据模型的。可以从核心功能，常用功能看起。
第五个工作日，方法抽象。整合前面收集的信息，对方法和步骤进行一定的结构化归纳。
1，细节。日志记录要清晰，sql语句效率要高，数据流通清晰明白，等。
2，流程。需求分析，设计文档，业务逻辑，结构清晰，沟通顺畅，等。
3，复用。某个功能模块，类，方法适用于大量业务场景，抽取这些逻辑组织复用性高的代码。
4，合作。涉及到多系统交互，数据访问调用接口这些必然存在问题，事先考虑时效等相关问题，运用一些数学统筹方法，调整事务顺序，是有好处的。
5，学习。若没有网络，我们如何解决未知问题？尝试，排除，类比都是可以的。学习基础知识快速开发的同时，学习一些反复使用的经典方法是有益的。
我们没有思路，是因为我们还没有看懂，还没有想明白，多看，多听，多写，多画，多想，多动手。求快就快点写，写好了实现功能出现问题再改；求稳就按照步骤做，边做边检查边测试，按部就班即可；求复用，就要多动脑子模拟场景，把东西挖出来形成一个功能齐全的独立整体就好了；求收益好，就多想想实用性，逆向思考就好...年轻的我们一天天成长，每天都有进步就好了；图书馆和运动场多去逛逛，是有好处的，这是一件重要不紧急的事情。