在整个开发过程中，最重要的事情就是：不要将自己迷失！
应该时刻提醒自己注意以下几个问题：
(1) 对象是什么？（怎样将自己的项目分割成一系列单独的组件？）
(2) 它们的接口是什么？（需要将什么消息发给每一个对象？）
在确定了对象和它们的接口后，便可着手编写一个程序。出于对多方面原因的考虑，可能还需要比这更多的说明及文档，但要求掌握的资料绝对不能比这还少。
整个过程可划分为四个阶段，阶段 0 刚刚开始采用某些形式的结构。
阶段 0：拟出一个计划
第一步是决定在后面的过程中采取哪些步骤。这听起来似乎很简单，但很常见的一种情况是：有些人甚至没有进入阶段 1，便忙忙慌慌地开始编写代码。
如果你的计划本来就是“直接开始开始编码”，那样做当然也无可非议，但最低程度也应同意自己该有个计划。
因为在整个过程中设置几个标志，或者“路标”，将更有益于你集中注意力。这恐怕比单纯地为了“完成工作”而工作好得多。至少，在达到了一个又一个的目标，经过了一个接一个的路标以后，可对自己的进度有清晰的把握，干劲也会相应地提高，不会产生“路遥漫漫无期”的感觉。
阶段 1：要制作什么？
我们特别要注意将重点放在这一阶段的核心问题上，不要纠缠于细枝末节。这个核心问题就是：决定采用什么系统。
对这个问题，最有价值的工具就是一个名为“使用条件”的集合。对那些采用“假如……，系统该怎样做？”这类形式的问题，这便是最有说服力的回答。“使用条件”可以指示你在混乱的情况中做出正确的选择。
应尽可能总结出自己系统的一套完整的“使用条件”或者“应用场合”。一旦完成这个工作，就相当于摸清了想让系统完成的核心任务。由于将重点放在“使用条件”上，一个很好的效果就是它们总能让你放精力放在最关键的东西上，并防止自己分心于对完成任务关系不大的其他事情上面。
在这一阶段，最好用几个简单的段落对自己的系统作出描述，然后围绕它们再进行扩充，添加一些“名词”和“动词”。“名词”自然成为对象，而“动词”自然成为要整合到对象接口中的“方法”。
尽管仍处在初级阶段，但这时的一些日程安排也可能会非常管用。我们现在对自己要构建的东西应该有了一个较全面的认识，所以可能已经感觉到了它大概会花多长的时间来完成。
此时要考虑多方面的因素：如果估计出一个较长的日程，那么公司也许决定不再继续下去；或者一名主管已经估算出了这个项目要花多长的时间，并会试着影响你的估计。但无论如何，最好从一开始就草拟出一份“诚实”的时间表，以后再进行一些暂时难以作出的决策。
感觉一下大概需要花多长的时间，然后将这个时间加倍，再加上 10％。你的感觉可能是正确的；“也许”能在那个时间里完成。但“加倍”使那个时间更加充裕，“10％”的时间则用于进行最后的推敲和深化。但同时也要对此向上级主管作出适当的解释，无论对方有什么抱怨和修改，只要明确地告诉他们：这样的一个日程安排，只是我的一个估计！
阶段 2：如何构建？
在这一阶段，必须拿出一套设计方案，并解释其中包含的各类对象在外观上是什么样子，以及相互间是如何沟通的。
此时可考虑采用一种特殊的图表工具：“统一建模语言”（UML）。请到http://www.rational.com
去下载一份 UML 规格书。
作为第1 阶段中的描述工具，UML 也是很有帮助的。
此外，还可用它在第2 阶段中处理一些图表（如流程图）。
作出了对对象以及它们的接口的说明后，就完成了第 2 阶段的工作。当然，这些工作可能并不完全。有些工作可能要等到进入阶段 3 才能得知。但这已经足够了。我们真正需要关心的是最终找出所有的对象。
阶段 3：开始创建
在正式编码前掌握了正确的设计结构，会发现接下去的工作比一开始就埋头写程序要简单得多。
让代码做到我们想做的事情，这是所有程序项目最终的目标。但切不要急功冒进，否则只有得不偿失。作为真正的程序员，这并非可有可无的一种素质。全面的思考、周密的准备、良好的构造不仅使程序更易构建与调试，也使其更易理解和维护，而那正是一套软件赢利的必要条件。
构建好系统，并令其运行起来后，必须进行实际检验，以前做的那些需求分析和系统规格便可派上用场了。
全面地考察自己的程序，确定提出的所有要求均已满足，但这还远远不够。
阶段 4：校订
到此，整个开发周期还没有结束，现在进入的是传统意义上称为“维护”的一个阶段。有的人认为：凡是需要“维护”的东西，必定不是好的，或者是有缺陷的！因为这个词说明你实际构建的是一个非常“原始”的程序，以后需要频繁地作出改动、添加新的代码或者防止它的落后、退化等。因此，我们需要用一个更合理的词语来称呼以后需要继续的工作。
这个词便是“校订”。换言之，“你第一次做的东西并不完善，所以需为自己留下一个深入学习、认知的空间，再回过头去作一些改变”。
什么时候才叫“达到理想的状态”呢？这并不仅仅意味着程序必须按要求的那样工作，并能适应各种指定的“使用条件”，它也意味着代码的内部结构应当尽善尽美。至少，我们应能感觉出整个结构都能良好地协调运作。没有笨拙的语法，没有臃肿的对象，也没有一些华而不实的东西。
除此以外，必须保证程序结构有很强的生命力。由于多方面的原因，以后对程序的改动是必不可少，但必须确定改动能够方便和清楚地进行。
在最终得到一套恰当的方案之前，“校订”几乎是不可避免的。我们需要不断地对比自己的需求，了解系统是否自己实际所需要的。有时只有实际看到系统，才能意识到自己需要解决一个不同的问题。若认为这种形式的校订必然会发生，那么最好尽快拿出自己的第一个版本，检查它是否自己希望的，使自己的思想不断趋向成熟。
不管制订出的计划有多么小，但与完全没有计划相比，一些形式的计划会极大改善你的项目。最后请记住：根据估计，没有计划的50％以上的项目都会失败！
