霸榜GitHub！程序员必懂的15大定律和7大原则（github规则）

霸榜GitHub！程序员必懂的15大定律和7大原则（github规则）

综合自：

https://github.com/dwmkerr/hacker-laws

https://github.com/nusr/hacker-laws-zh

从小到大，我们学过很多定律，见过许多法则。近日，猿妹在GitHub上找到一个专属程序员的定律＆法则合集项目。

自从我知道这个项目后，已经连续一周霸榜GitHub Trending前三，如今已经在GitHub上获得4337 个Star，231 个Fork（GitHub地址：https://github.com/dwmkerr/hacker-laws）

这个仓库包含对一些定律、原则以及模式的解释，共有15大定律和7大原则，但不提倡其中任何一个。 它们的应用始终存在着争论，并且很大程度上取决于你正在做什么。

阿姆达尔定律 (Amdahl's Law)

阿姆达尔定律是一个显示计算任务潜在加速能力的公式。这种能力可以通过增加系统资源来实现，通常用于并行计算中。它可以预测增加处理器数量的实际好处，然而增加处理器数量会受到程序并行性的限制。

举例说明：如果程序由两部分组成，部分 A 必须由单个处理器执行，部分 B 可以并行运行。那么向执行程序的系统添加多个处理器只能获得有限的好处。它可以极大地提升部分 B 的运行速度，但部分 A 的运行速度将保持不变。

下图展示了运行速度的潜能：

可以看出，50％ 并行化的程序仅仅受益于 10 个处理单元，而 95％ 并行化的程序可以通过超过一千个处理单元显著提升速度。

随着摩尔定律减慢，单个处理器的速度增加缓慢，并行化是提高性能的关键。图形编程是一个极好的例子，现代着色器可以并行渲染单个像素或片段。这也是为什么现代显卡通常具有数千个处理核心（GPU 或着色器单元）的原因。

布鲁克斯法则 (Brooks's Law)

软件开发后期，添加人力只会使项目开发得更慢。

这个定律表明，在许多情况下，试图通过增加人力来加速延期项目的交付，将会使项目交付得更晚。布鲁克斯也明白，这是一种过度简化。但一般的推理是，新资源的增加时间和通信开销，会使开发速度减慢。而且，许多任务是不可分的，比如更多的资源容易分配，这也意味着潜在的速度增加也更低。

谚语九个女人不能在一个月内生一个孩子 与布鲁克斯法则同出一辙，特别是某些不可分割或者并行的工作。

康威定律 (Conway's Law)

系统的技术边界受制于组织的结构。改进组织时，通常会提到它。康威定律表明，如果一个组织被分散成许多小而无联系的单元，那么它开发的软件也是小而分散的。如果一个组织更多地垂直建立在特性或其服务周围，那么软件系统也会反映这一点。

侯世达定律 (Hofstadter's Law)

即使考虑到侯世达定律，它也总是比你预期的要长。

在估计需要多长时间开发时，你可能会听到此定律。软件开发似乎不言而喻，我们往往不能准确地估计需要多长时间才能完成。

技术成熟度曲线 (The Hype Cycle & Amara's Law)

我们倾向于过高估计技术在短期内的影响，并低估长期效应。

技术成熟度曲线是高德纳咨询公司对技术最初兴起和发展的视觉展现。一图顶千言：

简而言之，这个周期表明，新技术及其潜在影响通常会引发一阵浪潮。团队快速使用这些新技术，有时会对结果感到失望。这可能是因为该技术还不够成熟，或者现实应用还没有完全实现。经过一段时间后，技术的能力提高了，使用它的实际机会会增加，最终团队也可以提高工作效率。罗伊·阿马拉简洁地总结了这一点：我们倾向于高估技术短期内的影响，并低估长期效应。

查看其它的定律和法则，可以到GitHub详情页查看，如果你自我感觉英文水平不行还有中文版哦，最后附上中文地址：https://github.com/nusr/hacker-laws-zh

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。