事儿多.com

生活服务信息分类,python + tornado ...

↑我也要推荐

设计的一些原则

发布时间:2011-07-11 18:38:02, 关注:+6519, 赞美:+385, 不爽:+5

原始出处: shell's home

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

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

如果你觉得本站对你有帮助,欢迎向本站赞助 :P

使用支付宝捐赠

Copyright© Python4cn(news, jobs) simple-is-better.com, 技术驱动:powered by web.py 空间主机:Webfaction

版权申明:文章转载已注明出处,如有疑问请来信咨询。本站为 python 语言推广公益网站,与 python 官方没有任何关系。

联系/投搞/留言: en.simple.is.better@gmail.com 向本站捐赠