本文主要是介绍软件的“比尔定律”，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
软件的“比尔定律”
信息论的开山鼻祖香农的“香农定理”支撑了整个通信业半个世纪以来的繁荣，摩尔定律的引入则使得IC技术和产业获得了“黄金时代”的高速发展。而当今ICT融合发展的时代，大多数人也都认同进入了“软件时代”，软件会吃掉一切的时代，却没有太多这样的定理、定律来说明这个行业和时代，不是很让人费解的一个事情吗。
由于芯片是IT硬件工业的“皇冠上的明珠”，所以掌握芯片的规律就能引导IT行业的规律。而软件正是因为其“软”，最多出现一些“设计模式”，语言不断变迁，软件架构也不断演化，似乎毫无规则可言，很多软件工程、方法论和架构、设计搅和在一起，导致很多问题讨论最后不得不归结为，还是需要顶级“架构师”，一个工业或产业不得不回归到“工匠精神”或“工匠”自身。
机缘巧合，最近几年从事开源工作越来越久，似乎隐约感觉到了这个纷繁复杂的软件行业泥石流背后那股暗流涌动的“力量源泉”，也感受到了这个行业的“脉搏”和“呼吸”。虽说很难像芯片或IT技术那样以集成电路的数量或工艺来分级划代，但软件业似乎也有一条隐含的脉络走向“规模制造”。
为了归纳总结我们软件行业的规律，特地查询了一下，归纳起来，“摩尔定律”主要有以下3种“版本”：
1、集成电路芯片上所集成的电路的数目，每隔18个月就翻一番；
2、微处理器的性能每隔18个月提高一倍，而价格下降一半；
3、用一美元所能买到的计算机性能，每隔18个月翻两番。
鉴于本人英文名字叫Bill，所以也尝试总结一下软件行业的“比尔定律”：
1、 软件工程师编码效率，每隔18个月提升一倍；完成同样功能的代码量会下降一半，
2、 软件程序的性能每隔18个月会提高一倍，需要的程序员人数，则可以下降一半；
3、 整个社会创造出的软件总量，每隔18个月翻两番。
可以看出，模仿和斧凿的痕迹很重，而且大有可以“挑战”的空间。说实话，我原来也是不相信软件会有什么“规律”，就是个靠程序员个人天赋和勤奋的手艺活，虽说本人是科班出身，但也对“软件工程”的“科学性”产生了疑问，正所谓软件“没有银弹”，也不相信任何“人月神话”，上面虽然列举了很多人，很多月的数目，但不希望被误解成人月神话。
但是最近一个项目组在主流开源平台上的实践让我感受到了“产业规律”的魅力。前一天是产品线管理者和核心专家一天的闭门研讨，前前后后也付出了很多“材料”和“研讨”上的工作，其中研发专题部分提到的要通过半年到一年的努力把某平台或产品性能提升30%，持续打造“极致性能体验”，使得我们保持领先优势。当然，这中间需要大量研发工程师通过研究项目、技术项目和版本开发的辛苦付出。巧合的是，第二天，某开源小项目组，其实可能也就几个人，没有准备太多胶片，也没发起过过多研讨，通过自己摸索实践，把我们某个产品版本原来基于开源两年前的版本切换到了最新版本，当然因为中间不是持续与开源同步，也有很多代码冲突，架构冲突的细节问题需要去“攻关”，在获得了“节省工作量”这个缺省好处的同时，获得了意外惊喜。这个项目组并未去“专攻”性能，但我们的产品性能“意外”获得了50%以上提升。经过仔细询问，原来该社区近两三个版本，有几个云或互联网巨头致力于提升该版本的性能，贡献了一些代码，在同步完社区最新版本后，自然而然就获得了性能提升的“好处”。
前后对比，让我感慨万分，我们的确非常“艰苦奋斗”，但如果每一个技术和架构改进的代码都由我们自己程序员来写，和行业一些巨头善于驾驭“开源”和“产业”的力量，就像我们在岸上奔跑，最多骑上了马，而有的公司搭载上产业“大船”或“火车”上前行，改进效率的差距就显现出来了。
IC行业有28纳米，14纳米到7纳米、5纳米的制造工艺和集成度的产业代际，软件行业在开源逐步成为每个工程师，每个程序都会用到的能力之后，如何让自己的项目、程序能使用到最新的产业“工艺”，获得尽可能先进的软件“元器件”的支持，让自己的软件供应链尽可能安全、高效和连续，则是我们这一代人应该不断去践行和总结、归纳的。
比尔定律可能还很不“完美”，甚至充满“瑕疵”，但希望以此为启发与行业同仁共勉，激发我们的思考，如何让我们的软件工程师掌握更多驾驭开源技术、开源代码和项目的能力，如何让我们的产品的版本能搭载上软件产业的高速发展“生产力”，如何让我们自身努力是基于产业和行业共同成果的，而不是重复制造每一个“轮子”。
让我们更加开放拥抱产业，拥抱开源，提升自身软件技能，不断更新和学习，获得软件“比尔定律”红利。
这篇关于软件的“比尔定律”的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
