每个程序员都该知道的5个定律

定律,或称法则,可以知道我们并让我们在同伴的错误中学习.这篇文章中,我将介绍我每次设计或实现软件时在我脑海中的五大定律.其中有些和开发有关,有些和系统组织有关,它们可以帮助你成为合格的软件工程师.


定律一 : 墨菲定律

凡事可能出错,就一定出错.


这条定律来源Edward Murphy  ---- 一名航天工程师在50年代初对火箭测试失败的回应.这条定律给我们的启示是永远在系统关键地方使用防御性设计,因为系统某些地方总会出错!


当你在机器上运行软件时,任何地方都有可能发生问题 --- 从硬盘上的系统到数据中心的电力供应,所以你必须确保你设计的架构在每个层级都可以应对故障.




定律二 : Knuth定律


在(至少大部分)编程中,过早优化是万恶之源.


这条定律是Donald Knuth的经典语录之一,它告诫我们不要过早优化应用程序中的代码,知道必须优化时再优化.


的确,简单易读的源码可以满足99%的性能需要,并能提高应用的可维护性,最开始使用简单的解决方案也让后期性能出现问题时更容易迭代和改进.


垃圾自动回收的编程语言中,字符串的链接常常是过早优化的例子.在Java或C#中,String对象是不可变的,我们学会使用其他结构动态创建字符串,比如StringBuilder.但事实上知道你分析完应用程序之前,你并不知道String对象创建了多少次并对性能的产生多大影响.所以首先编写皆可能整洁的代码,之后再必须的时候再优化,往往这样做更有意义.


然而,这条规则并不应该组织你去学习变成与样的性能权衡和正确的数据结构,并且,正如所有其他性能问题,你在优化前要测量开销.


定律三 : North定律
每一个决定都是一次权衡.


开发者日复一日的生活中,我们每天都做无数个大大小小的决定.从命名变量到自动化(手动)任务,再到定义平台架构.这条语录强调无论你做的选择是什么,你总会放弃一个或多个选项.星厨你为什么不选择他们.你要始终根据当前你掌握的信息来权衡并作出决定.
但是如果够来你了解到新的信息,并发现之前的决定是错误的,这也没有关系.关键是记清楚你为什么作出那个决定,重新评估新的选项之后再作出新的理智的决定.


所以,做出选择并对所有选项心智杜明.


定律四 : Conway定律


系统设计的架构受限于生产设计,反应出公司组织的沟通架构.


在60年代,一位名叫Melvin Conway的工程师注意到公司组织结构影响他们开发的系统的设计.他用一篇论文描述了这个观点.并命名为"Conway"定律.


这条定律很使用与软件开发领域,甚至体现到代码层面上,交付软件组建的各个团队组织结构直接影响到组件的设计.


举个栗子,一个集中式的开发者团队会开发出各组件耦合的整体应用.另一方面,分布式的团队会开发出单独的(微)服务,每一个部分关注点分离清晰.
这些设计没有好坏之分,但它们都是收到团队沟通方式的影响.在全球有大量独立开发者的开源项目,通常是模块化和可重用库,这就是很有说法力的栗子.


如今,将大的集成应用解耦成为服务已成趋势,这很棒,因为这可以加速支付使用项目,但你也应该牢记Conway定律,在公司组织构建中投入与技术开发同样多的gong'z