认识达内从这里开始

在程序员的面试过程中，如何才能顺利通过面试官的问答呢?下面达内it培训老师给大家总结了程序猿面试问题五大定律，就和大家一一做个分享：

Conway定律

“系统设计的架构受限于生产设计，反映出公司组织的沟通架构”

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

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

举个例子，一个集中式的开发者团队会开发出各组件耦合的整体应用。另一方面，分布式的团队会开发出单独的(微)服务，每一部分关注点分离清晰。

这些设计没有好坏之分，但它们都是受到团队沟通方式的影响。在全球有大量独立开发者的开源项目，通常是模块化和可重用库，这就是很有说服力的例子。

墨菲定律

“凡是可能出错，就一定出错。”

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

这条定律很容易引入软件工程领域。当你将软件暴露给终端用户，他们会创造性地输入一些出人意料的内容，使系统宕机。所以你需要让你的软件足够健壮，能够检测并警告非预期行为。

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

Knuth定律

“在(至少大部分)编程中，过早优化是万恶之源。”

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

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

North定律

“每一个决定都是一次权衡”

好吧，我承认这是取自 Dan North 的演讲 Decisions,Decisions，它目前还不是公认的定律。 但这条语录影响了我做的每个决定，所以我把它放在这。

开发者日复一日的生活中，我们每天都做无数个大大小小的决定。从命名变量到自动化(手动)任务，再到定义平台架构。

这条语录强调无论你做的选择是什么，你总会放弃一个或多个选项

但这不是最重要的。 最重要的是理智地做出决定，了解其他选项，清楚你为什么不选择它们。你要始终根据当前你掌握的信息来权衡并做出决定。

琐碎定律(帕金森琐碎定律)

“组织成员投入大量精力到琐碎的事情上。”

这条定律论点是在会议中花费的时间与事情的价值成反比。的确是这样，人们更愿意把注意力和观点放在他们熟悉的事物上，而不是复杂的问题上。

帕金森给出一个例子，一场会议中，成员们讨论两件事：为公司建核反应堆和为员工建车棚。建反应堆是一件巨大而复杂的任务，没有人能完全掌控全局。他们完全信赖流程和系统专家，并很快接受了项目。

以上五大定律大家记住了吗?更多程序员面试试听解答尽在长沙达内培训网站了解!

0元课程试听报名进行中!