架构师需要知道的10条设计原则

函数是程序员的工具中最重要的抽象形式。它们能更多地被重复使用，你需要编写的代码就越少，代码也因此变得更可靠。较小的函数遵循单一职责原则更有可能被重复使用。

你应该尽量减少函数之间的隐式共享状态，无论它是文件作用域的变量还是对象的成员字段，这有利于明确要求把值作为参数。当能明确地显示函数需要什么才可以产生所需的结果时，代码会变得更容易理解和重用。

对此的一个推论是，在一个对象中，相对于成员变量，你更应该优先选择静态的无状态变量 (static stateless variables)。

理想的副作用（例如：打印到控制台、日志记录、更改全局状态、文件系统操作等）应该被放置到单独的模块中，而不是散布在整个代码里面。函数中的一些“副作用”功能往往违反了单一职责原则。

如果一个对象的状态在其构造函数中仅被设置一次，并且从不再次更改，则调试会变得更加容易，因为只要构造正确就能保持有效。这也是降低软件项目复杂性的最简单方法之一。

接收接口的函数（或 C++ 中的模板参数和概念）比在类上运行的函数更具可重用性。

寻找机会将软件项目分解成更小的模块（例如库和应用程序），以促进模块级别的重用。对于模块，应该遵循的一些关键原则是：

　　1.尽可能减少依赖

　　2.每个项目应该有一个明确的职责

　　3.不要重复自身

你应该努力使你的项目保持小巧和明确。

在面向对象编程中，继承 —— 特别是和虚拟函数结合使用时，在可重用性方面往往是一条死胡同。我很少有成功的使用或编写重载类的库的经历。

我不是测试驱动开发的坚定分子，但开始编码时先编写测试代码会使得代码十分自然地遵循许多指导原则。这也有助于尽早发现错误。不过要注意避免编写无用的测试，良好的编码实践意味着更高级别的测试（例如单元测试中的集成测试或特征测试）在揭示缺陷方面更有效。

我经常看到更好版本的 std::vector或 std::string ，但这几乎总是浪费时间和精力。一个明显的事实是 —— 你正在为一个新的地方引入 bug，其他开发者也不太可能重用你的代码，因为没有被广泛理解、支持和测试。

这是每个程序员都应遵循的最重要的教诲：最好的代码就是还没写的代码。你写的代码越多，你将遇到的问题就越多，查找和修复错误就越困难。

在写一行代码之前先问一问自己，有没有一个工具、函数或者库已经实现了你所需要的功能？你真的需要自己实现这个功能，而不是调用一个已经存在的功能吗？