最近，我把大部分时间都用在了研究和处理复杂软件上面。这里的复杂并不是指代码如何复杂（尽管有时候也会发生这样的情况）而更多的是指软件本身要处 理多少问题。例如，Twitter就不那么复杂，而Facebook就相对复杂，它不仅包括共享，还包括消息、应用、网页等等。
      经过反复的跟踪与错误调试，处理复杂的系统和清理复杂的代码，我提出了几条准则，通过这些准则能够确保软件工作并且能够处理无数的功能，更重要的是，它们维护起来也很简单。
代码泄漏
      我遇到的最大问题之一就是代码泄漏，下面是一个代码泄漏的例子：       这段应该从这个类里面分离出来。在这个例子中，消息传递被泄漏到数据库代码中，而这两个泄漏到一个类中并没有什么实际的作用。
      在一个理想的处理环境下，你应该把访问数据库的代码包裹在一个类里面，创建一个简单的接口并且远离上面这样的程序。
      如果你一直沿着上面代码的那种思路走下去，你就得改变你的数据库，或者改变类库，或者仅仅是存储一些不同的数据库数据。在这一点上面，为了使程序能够跑通，你可能会需要修改成百上千的文件，当然也会带来成百上千个错误，而且还浪费大量的时间。
      API：内部和外部
      API并不仅仅对Web很有好处，对一切开发都很有好处。本质上讲，你代码中的每一段都有其重要的任务，并不需要把所有的都暴露出来，下面这是一个很糟糕的类：       你可能会认为，哇，棒级了，在我软件的任何地方我都可以直接访问users对象，不需要考虑并发，问题来了，如果你想在数据库里面存储user list而不仅仅是list？两者之间你会如何去过渡？
下面给了一个例子，对上面的代码稍微改动了一下。       注意了，你不能直接访问Users list，相反，你有一个对与它相互紧密的方法，如果我们改变一下，通过数据库去访问，而不是list，我们可以这样做：       如果我们用API模块化的方式去构建软件，我们只需要改变一个文件就行了。理想情况下，我们会给Users创建一个接口用来测试，在这里我们就不深入讨论了。
最好每一个类都应该有自己的API（就像Java里面的get，set函数，而不是直接获取数据）。
      使用一个模块架构，即使你只有一个开发模块
      这样做的好处是减少你编写应用程序的时间，并且可以根据需求进行功能的添加，而不是一次编写一次运行。当你以这种方式去开发的时候，以上两点都是不可避免的。
当你使用一个基于架构的模块时，如果其中的一个出现问题时，那么它可能会使整个系统都会有潜在的下降。
      总结
      把这些东西写下来是很重要的，上面的内容并不适合所有的开发策略，我们必须与所有的开发策略进行工作，因为有很多种类型的语言和许多不同的方法。但是在做完一个项目后，你会发现，带领团队使用OOP思想效果是最好的。