Shell's Home

Jul 11, 2011 - 1 minute read - Comments

设计的一些原则

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认为目前网页格式凌乱的根源有部分来源于此。第八条鼓励人们在建立浏览器的时候,尽量兼容各种格式变化,而不是对每个不符合标准的进行报错。这导致了各种兼容变化。

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

Tags: thinking

讨论时的态度 初创公司的九句傻话

comments powered by Disqus