有些著名的定理在互联网世界同样适用，下面为大家介绍的定理有些和开发相关，有些和系统相关，可以帮你成为合格的软件工程师。
01、墨菲定律
凡事可能出错，就一定出错
这条定律来自一名航天工程师在50年代初对火箭测试失败作出的回应，给我们的启示是，永远在系统关键地方使用防御性设计，因为系统某些地方总会出错。
这就好像是你把软件暴露给终端用户，他们会创造性的输入一些意料之外的内容，导致系统宕机。因此你需要让你的软件足够健壮，检测并警告非预期行为，确保设计的架构在每个层面上都可以应对故障。
02、Kunth定律
在大部分编程中，优化过早是万恶之源。
这条定律是Donald Knuth的经典语录之一，告诫我们不要过早的优化系统程序代码，直到必须优化时再优化。
简单易读的源码实现99%性能需要的同时，可以提高应用的可维护性。开始时，使用简单的解决方案可以让后期出现问题更容易迭代和改进。
在Java或者C#语言中，String对象是不可变的，我们要学会使用其他结构动态创建字符串，比如StringBuilder。
现实是，直到分析应用程序前，我们并不知道String创建了多少次，并对性能产生了多大影响。因此在编写代码时，要尽量保持整洁，必要的时候再做优化。
03、Conway定律
系统设计的架构受限于生产设计，反映出公司组织的沟通架构
Conway定律由一名Melvin Conway的工程师提出，他注意到公司组织结构影响开发系统设计后，在一篇论文中描述了这个观点。
举一个例子，一个集中式的开发者团队会开发各种组件耦合的整体应用，而分布式的团队会开发单独的（微）服务，每一部分关注点分离清晰。
设计本身没有好坏之分，但是都受团队沟通方式的影响。现今，将大的集成应用解耦成微服务已成趋势。但也应该牢记Conway定律，在公司组织架构中投入与技术开发同样多的工作。
04、琐碎定律
组织成员投入精力到琐碎的事情上
琐碎定律又称为帕金森琐碎定律。这条定律的论点是：时间与事情的价值成反比。
对此，帕金森给出了一个例子，一场会议中，成员们讨论两件事情：为公司建核反应堆和为员工建车棚。建反应堆是复杂而又巨大的任务，没有人可以掌控全局，于是成员完全信赖流程和系统专家，很快就接受了项目。但建车棚的讨论时间远远超过建核反应堆的讨论时间。这条定律在软件行业非常出名，之后被称为车棚效应。
随着软件开发经验的积累，我们会学到更多东西，虽然这些定律看起来是常识，但却可以帮助我们识别这些模式并作出反应，提升工作效率的同时，对自己的职业生涯也有很大帮助。
#软件#
