认识达内从这里开始

佛山java培训：作为我们软件开发工程师来说，要想成为一名合格并优秀的工程师并没有那么简单，我们不妨试试下面的五大定律，看看能不能把这五个定律应用到我们的工作中去。

墨菲定律：“凡事可能出错，就一定出错”

这条定律给我们的启示是永远在系统关键地方使用防御性设计，因为系统某些地方总会出错!这条定律很容易引入软件工程领域。当你将软件暴露给终端用户，他们会创造性地输入一些出人意料的内容，使系统宕机。所以你需要让你的软件足够健壮，能够检测并警告非预期行为。当你在机器上运行软件时，任何地方都有可能发生问题 —— 从硬盘上的系统到数据中心的电力供应。所以你必须确保你设计的架构在每个层级都可以应对故障。

Knuth定律：“在(至少大部分)编程中，过早优化是万恶之源。”这个定律告诫我们不要过早优化应用程序中的代码，直到必须优化时再优化。的确，简单易读的源码可以满足 99% 的性能需要，并能提高应用的可维护性。最开始使用简单的解决方案也让后期性能出现问题时更容易迭代和改进。

垃圾自动回收的编程语言中，字符串的连接常常是过早优化的例子。在 Java 或 C# 中，String 对象是不可变的，我们学会使用其他结构动态创建字符串，比如 StringBuilder。但事实上直到你分析完个应用程序前，你并不知道 String 对象创建了多少次并对性能的产生多大影响。所以首先编写尽可能整洁的代码，之后在必须的时候再优化，往往这样做更有意义。然而，这条规则并不应该阻止你去学习编程语言的性能权衡和正确的数据结构。并且，正如所有其他性能问题，你在优化前要测量开销。

Conway定律：“系统设计的架构受限于生产设计，反映出公司组织的沟通架构”，适用于软件开发领域，甚至体现到代码层面上。交付软件组件的各个团队组织结构直接影响到组件的设计。

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

佛山java培训：将大的集成应用解耦成微服务已成趋势。这很棒，因为这可以加速交付使用项目。但你也应该牢记 Conway定律，在公司组织构建中投入与技术开发同样多的工作。

琐碎定律(帕金森琐碎定律)：“组织成员投入大量精力到琐碎的事情上。”这条定律论点是在会议中花费的时间与事情的价值成反比。的确是这样，人们更愿意把注意力和观点放在他们熟悉的事物上，而不是复杂的问题上。

如果你了解这种规律，你将在会议和交流中发觉这种行为。这并不是让你在每次讨论中避免“小”问题，而是提高你的意识，从而帮助你关注真正的问题，并为这些会议做好准备。

North定律：“每一个决定都是一次权衡”，开发者日复一日的生活中，我们每天都做无数个大大小小的决定。从命名变量到自动化(手动)任务，再到定义平台架构。如果后来你了解到新的信息，并发现之前的决定是错误的，这也没关系。关键是记清楚你为什么做出那个决定，重新评估新的选项之后再做出新的理智的决定。

定律是为实践和事实所证明，反映事物在一定条件下发展变化的客观规律的论断。定律是一种理论模型，它用以描述特定情况、特定尺度下的现实世界，在其它尺度下可能会失效或者不准确。佛山java培训：随着软件开发经验的增长，我们将会学会更多。尽管其中某些定律现在看起来是常识，我始终坚信了解这些原则可以帮助你识别这些模式并做出反应。