您是否曾经想过,为什么像软件开发人员这样的聪明人会如此频繁地搞砸呢? 有些人做了。 在这篇文章中,我们回顾 一些描述专业人员行为的不成文法 计算。
我的第一台计算机是Commodore64。该系统将近30 kb的RAM用于系统,剩下的32 kb用于文字处理,游戏,家族企业会计,以及我现在拥有的6 gb计算机所做的几乎所有事情。 这使问题悬而未决 当今的设备是否可以满足软件的需求,或者该软件是否会使用更多的硬件资源(因为可用)?
公平地说,游戏不一样,图形也不一样,因此看电影和听音乐是不可能的。 但是,人们不禁会以为 有些程序会发布版本并消耗越来越多的资源,而没有真正贡献任何新东西。
原因如下。
扎温斯基定律
Netscape开发人员Jamie Zawinsky认为 每个程序都具有各种功能,直到能够阅读电子邮件为止。 如果他没有成功,他将被另一个有能力的人代替。
当他说这话时,开玩笑的是他指的是最初不打算用作电子邮件客户端的程序。 当发现Google Play上的许多应用程序正在请求访问不需要执行工作的电话组件和用户数据的许可时,它变得不那么有趣了。
一些人将此解释为试图监视用户的一部分。 但是仅仅因为可以完成某件事而做某事可能是人类的天性。
彼得原理适用于软件
劳伦斯·彼得(Lawrence Peter)之所以出名,是因为他指出,在一个等级制度中,一个人升任至他完全无能的位置。 但是他也有时间谈论复杂的项目:
“一个复杂的项目将变得过于复杂,即使是它自己的开发人员也无法理解。”
最小惊讶原则
该原则于1984年在IBM Systems Journal上发表,指出:
“如果所需的功能引起很大的惊喜,则可能需要重新设计该功能。”
换句话说, 如果部分或全部软件与用户习惯完全不同,则最好是重新设计。 理想情况下,力争实现 渐进式的改进,足以令人印象深刻,但又足够小以保持熟悉 为用户。
太糟糕了,沙特尔沃思在启动Unity时没有考虑到这一点。
控制论昆虫学法
计算机历史上的第一个错误是真实的。 蛾子飞入MARK II计算机上的一个继电器中,导致故障。
继续隐喻,控制论昆虫学定律认为: 总会有一个错误。
那是所有计算机用户都知道的东西。 不管测试了多少操作系统,总为时已晚会发现一个缺陷。
克尼根定律
Linux Adictos 安装了一个插件,以确保我们作者以搜索引擎友好的方式编写。从第一天起我就讨厌它。任何带有一点文学飞行的尝试都会立即被红圈谴责。随着时间的推移,我已经习惯了,很少需要修饰。
程序员也会遇到同样的事情,很多时候,他们比起编写更易于理解和维护的更简单的代码,他们更想证明自己的编码能力。
因此,克尼根定律认为:
调试的难度是一开始编写代码的两倍。 因此,如果您尽可能聪明地编写代码,就定义而言,您不够聪明,无法对其进行调试。
90/90规则
在现实生活中开始营利性项目的任何人都知道,每个项目将花费两倍的时间,成本是预算的两倍,以赚取预期利润的一半。
计算机世界对此法有其变体。 例如,一位汤姆·嘉吉(Tom Cargill)说:
“代码的前90%代表了开发时间的前90%。 代码的其余10%代表了开发时间的另外90%。”
不清楚吗? 霍夫施塔特定律也许会有所帮助:
“即使考虑到霍夫施塔特定律,它总是比您期望的花费更长的时间。”
我猜Ubuntu和Fedora开发人员必须知道。 或者至少每6个月记住一次。
布鲁克定律
开源软件项目通常有两个问题; 融资和缺乏合作者。 除非第二个没有问题。 根据布鲁克的说法:
“为进度落后的软件项目增加工作量将进一步延迟工作。”
可以理解,您不仅需要更新新的编码器。 需要记录更多内容,需要更多的官僚机构才能使每个人保持同步,并且可能会发生争执。
当然,我们不能忘记朋友帕金森氏症和他的主张 开始时有多少空白都没有关系。 您将永远需要更多。 他指的是办公空间,但RAM和磁盘空间也是如此。
优秀的文字。 可以理解,哲学和文学。 我从Linux服务器上读到的最好的书之一。 我祝贺你。
非常感谢您的评论
很真实,很多年前,我是一名程序员,并且生活在许多情况下。 恭喜你我从芝加哥出发,跟随您。
非常感谢
适用于几乎所有工作的原则