IETF的RFC文档是整个互联网的基石，在RFC1958中，对于其中的一些原则做了总结和讨论。我觉得非常有意思，因此做一下摘抄和讨论。

  1. 保证它可以工作。首先做出原型系统，并成功运行，再着手标准化，而不是相反。

  2. 尽可能使它简单。如果一项特性并非绝对本质的特性，那么就不应该考虑，尤其是通过组合其他特性也能够获得同样效果的前提下。

  3. 做出明确的选择。如果有几种方法可以完成同样的事情，选择其中一种。

  4. 尽可能做到模块化。每个协议独立于其他的协议。改变其中一个，其他不受影响。

  5. 期望具备异构性。

  6. 避免使用固定不变的选择和参数。如果需要使用参数，最好的方法是让发送和接收方协商一个值。

  7. 寻找一个好的设计，不必是最完美的。如果有一个好的设计，但是不能够处理一些特例。那么应当坚持这个设计，让怪异的特例自行解决问题。

  8. 对于发送一定要严格，对于接收有一定的容忍度。

  9. 要考虑伸缩性。尽量去中心化，必要时将负载尽量均匀的分布到所有可以利用的资源上。

  10. 要考虑性能和代价。

第二条听起来好像CISC和RICS之争，虽然现在最流行的处理器是一款CISC，但是这并不妨碍RISC成为优美和进化方向的象征。

第三条在两种不同的语言上，有不同体现。python认为Simple is better than complex，ruby认为Simple is boring。具体可以看这里（http://automation-excellence.com/blog/zens-python-and-ruby）。

模块化是一个非常好的主意，但是同样，非常难实现。

第七条在设计大型系统中非常重要，不要为了一点小小的瑕疵破坏整个系统。

joel on software中，提到了第八条。joel认为目前网页格式凌乱的根源有部分来源于此。第八条鼓励人们在建立浏览器的时候，尽量兼容各种格式变化，而不是对每个不符合标准的进行报错。这导致了各种兼容变化。

第九条所有架构师都应该看看。与其购买昂贵的机器和服务，不如在设计系统的时候，就假定系统中的部分会发生故障。使用设计将负载分布到所有可利用的资源上。此条的推论是，大部分设计良好的系统都具有级联失效的可能。因为一旦发生失效，压力会分布到其他资源上。如果这超出了他们的能力，就会导致他们一起失效。