您好,欢迎来到12图资源库!分享精神,快乐你我!我们只是素材的搬运工!!
  • 首 页
  • 当前位置:首页 > 开发 > WEB开发 >
    开发者必备!Github上1.6W星的「黑魔法」,早知道就不会秃头了
    时间:2020-10-20 21:06 来源:网络整理 作者:网络 浏览:收藏 挑错 推荐 打印

    当顺序员议论开发设计时,常常会聊到十分多的定律,而Github上的一个名为「hacker-laws」的仓库收录了一些最常见的定律、准绳等,取得了16.3k的Star。

    开发者必备!Github上1.6W星的「黑魔法」,早知道就不会秃头了

    还记得一切AI教程必提的「奥卡姆剃刀准绳」吗?即:如无必要,勿增实体。这条准绳也被收藏,还有一些不太常见的费茨规律、盖尔定律、康威定律等,都被逐一支出囊中。

    写代码累了困了?这些规律让任务事半功倍

    90-9-1规律(1%规律)

    90-9-1 规律表明,在诸如维基这样的互联网社区中,90% 的用户只看内容并不参与互动,9% 的用户会参与讨论,而只要 1% 的用户会发明内容。

    理想世界的例子:2014 年,对四个安康的数字社交网络停止的一项研讨发现,排名前 1% 的人发明了 73% 的帖子,紧随其后的 9% 平均占 25%,其他的 90% 的人平均占 2%。

    相似的,帕累托规律也指出:生活中大少数事情不是平均散布的。这个准绳也被称为二八规律,重要的少数规律和要素稀疏准绳。

    技术成熟度曲线规律

    技术成熟度曲线是高德纳咨询公司对技术最后兴起和开展的视觉展现。一图胜千言:

    简而言之,这个曲线表明,新技术及其潜在影响通常会引发一轮浪潮。团队快速运用这些新技术,但有时会对结果感到绝望,这能够是由于该技术还不够成熟,或许理想运用还没有完全完成。

    经过一段时间后,技术的才能提高了,运用它的实践时机会添加,最终团队也可以提高任务效率。

    罗伊·阿马拉繁复地总结了这一点:我们倾向于高估技术短期内的影响,并低估其长期效应。

    破窗效应

    在破窗实际中以为,一些清楚的立功迹象(或缺乏环保看法)会招致进一步的、更严重的立功(或环境的进一步好转)。

    破窗实际已运用于软件开发中,它表明劣质代码能够会影响后续优化的效率,从而进一步形成代码劣化;随着时间的推移,这种效应将会招致代码质量大幅下降。

    没那么常见的规律,但也暗藏任务秘诀

    阿姆达尔定律

    阿姆达尔定律是一个显示计算义务潜在减速才能的公式。这种才能可以经过添加系统资源来完成,通常用于并行计算中。

    它可以预测添加处置器数量的实践益处,但是添加处置器数量会遭到顺序并行性的限制。

    举例阐明:假设顺序由两部分组成,A部分必须由单个处置器执行,B部分可以并行运转。那么向执行顺序的系统添加多个处置器只能取得有限的益处。

    它可以极大地提升部分 B 的运转速度,但部分 A 的运转速度将保持不变。

    下图展现了一些运转速度的提升潜能的例子:

    开发者必备!Github上1.6W星的「黑魔法」,早知道就不会秃头了

    可以看出,50% 并行化的顺序在运用大于 10 个处置单元之后的速度提升收效甚微,而 95% 并行化的顺序在运用超过一千个处置单元之后依然可以清楚提升速度。

    随着摩尔定律逐渐失效,单个处置器的速度添加缓慢,并行化是提高功用的关键。

    图形编程是一个极好的例子,现代着色器可以并行渲染单个像素或片段。这也是现代显卡通常具有数千个处置中心(GPU 单元)的缘由。

    德墨忒尔定律

    得墨忒耳定律又称最少知识准绳,是一条与面向对象言语有关的软件设计准绳。

    该定律表明,软件的一个单元应该只与其直接协作者交谈。

    比如对象 A 援用了对象 B,对象 B 援用了对象 C,则 A 可以直接调用 B 的办法,但不应直接调用 C 的办法。所以假设 C 有一个 dothing() 的办法,A 不应该直接调用,而是用 B.getC().doThis()。

    遵照这一定律可以限制代码更改的范围,使其以后更容易维护、更安全。

    坎宁汉姆定律

    在网络上想失掉正确答案的最好办法不是提成绩,而是发布一个错误的答案。

    除了以上的这些规律,该仓库还给出了很多的准绳。

    职场相关准绳

    死海效应准绳:在任何一个组织中,工程师的技艺、才华和效能往往与他们在公司的时间呈正比。

    才能强的人更有能够分开,才能差的人反而会留下。

    呆伯特准绳:公司会倾向于系统地将任务才能差的员工提升到管理层,以使他们脱离任务流程。

    技术相关的准绳:

    单一功用准绳:每个模块或许类只应该有一项功用。

    开闭准绳:实体应开放扩展并封锁修正。

    里氏交流准绳:可以在不破坏系统的状况下,用子类型交流类型。

    接口隔离准绳:不应强迫任何客户端依赖于它不运用的办法。

    依赖翻转准绳:初级模块不应该依赖于低级完成。

    还有一些具有哲学意味的准绳:

    鲁棒性准绳:在本人所做的事情上要保守, 在接受别人的事情上要自在。

    你不需求它规律:只要当你需求某些东西的时分,才去完成它们,而不是在你预见的时分。

    KISS准绳:保持复杂和直白。

    还有很多的规律和准绳没有逐一指出,需求的小同伴请点击下面的链接翻开查看。

    参考链接:

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

    【编辑引荐】

    下个10年,Go能取代Python成为开发者的首选言语吗?

    (责任编辑:admin)