1.清楚项目的需求：
1.1.清楚此项目要做什么。

2.清楚项目使用的技术：
2.1.此项目使用的核心的技术是什么？自己对此技术是否了解？
2.1.如果了解继续向下，否则就需要补充此技术相关的东西，之后再继续。

3.清楚项目的架构：
3.1.此项目的组织架构是什么？这是此项目所有功能的共性所在，不了解可以先略过，但是最后你还是要了解才行。

4.根据需求搞清楚各个类的作用：
4.1.弄清楚各个类是做什么的。
4.2.弄清楚不同类之间是什么关系。
4.3.此时根本不必关注类里面的方法，还没有到关注细节的时候，不同阶段关注不同事情，否则就会陷入代码细节的泥潭而无法自拔。

5.根据功能搞清楚方法之间的关系和方法实现的细节：
5.1.根据功能去弄清楚各个方法之间的调用关系。
5.2.在清楚了方法之间调用关系的基础上，弄清楚那些实现起来较为简单的方法细节，把实现起来较为复杂的细节记录下来，暂时放下。
5.2.在5.2.的基础之上，把没有搞明白的细节重新的理解一下。

6.根据需求添加自己的东西：
以上步骤都清楚之后，在此基础上添加自己的东西就基本上不会有太大的困难了。

其实上面的这些还只是具体的手段，如果你认真考虑一下的话，你就会发现，它们的出现是遵循着一定的顺序的，这顺序就是我们要实现的目标，由模糊到清楚，由抽象的到具体，我们做的事情也是从无到有。

你有没有想过为什么顺序是这样而不是那样？你也许隐约的相信这样的过程是对的，但是你就是想知道为什么？我们为什么一定要遵循这样的过程呢？其实我也是这种想知道为什么的人。

我可以用最简单的一个问题来告诉你答案：是因为有了需求才产生的代码呢？还是有了代码才产生了我们的需求呢？
很明显，是需求推动了一系列的行动，最后才产生了我们编写的代码，所以是需求产生了代码，那么这个过程只不过是把需求到代码的实现过程更详细的分解了而已，之所以这么做为的是让我们的需求到代码实现的过程变得更加的可控、可行、可把握。

就像我们吃饭一样，是因为我们饿产生了要吃饭的需求（需求分析），而正是吃饭的需求产生了我们要吃什么的问题（概要设计），当我们确定了要吃什么之后我们便有了目标（详细设计），当我们有了要吃的目标之后我们就会去寻找哪里可以找到这些吃的（编码），当我们到了饭店吃完了之后，我们的需求就结束了（项目结项）。

其实不止是我们开发软件如此，做其他事情也都是这样，都是由需要产生需求、需求产生目标、目标产生行动。当然行动在很多时候也会进一步的影响我们的需求和目标，但只是影响目标，而不会改变目标的实现过程。