vlambda博客
学习文章列表

大家估计有个越来越深的感受，就是说只做写代码的码农太局限了，现在这个环境，大家都想往上走当领导，除了升职加薪，其实也是实现了阶层的跨越。

定律

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

布鲁克定律(Brooks's Law)

康威定律(Conway's Law)

侯世达定律(Hofstadter's Law)

阿玛拉定律的“炒作周期”(The Hype Cycle & Amara's Law)

海勒姆定律(Hyrum's Law)

摩尔定律(Moore's Law)

帕金森定律(Parkinson's Law)

普特定律(Putt's Law)

泰斯勒定律(复杂性守恒定律,Tesler's Law)

抽象化漏洞定律(The Law of Leaky Abstractions)

琐碎定律(The Law of Triviality)

Unix哲学(The Unix Philosophy)

Spotify模型(The Spotify Model)

Wadler定律(Wadler's Law)

原则

鲁棒性原则(The Robustness Principle,Postel's Law)

SOLID

单一职责原则(The Single Responsibility Principle)

开放封闭原则(The Open/Closed Principle)

李氏替换原则(The Liskov Substitution Principle)

接口分离原则(The Interface Segregation Principle)

依赖倒置原则(The Dependency Inversion Principle)

整体还是建议大家看一下的，对于思维的打开很有帮助，太多就不逐个分析了，我就展开讲一下布鲁克定律吧。

维基百科中对此定律的解读是：将人力资源添加到一个后期软件开发项目中会使它更晚。 

啥意思呢？通俗点说就是：更多的人反而会让项目延迟。这乍看可能是违背常理的，但它基本上是正确的且经过验证的。

毕竟有人的地方就有江湖，人多了就会存在划水摸鱼的情况，想想你盯3个人和30个人是啥区别？可能就是脱发和秃头的区别吧。

人一多必然会面临沟通和协作的复杂度呈指数型上升，简单的事情可能倒变得更复杂了。

我也是做了十来年的程序员了，举个我自己的例子吧：之前接手一个新项目，为了留点面子就隐去项目名字和背景了，就简单跟大家说一下这个定律是如何验证的。

当时恰巧我的领导（总监级别，大家懂的）又不懂技术，而那时又是大众创业的浮躁年代，凡事都要求很快要结果，我手底下兄弟没日没夜加班，领导还不满足，于是又调了一个兄弟团队来“帮忙”，其实我们虽然达不到领导的进度要求，但我们还是能按预期完成的。

原本2个月的项目，1个半月的时候突然杀进一批人，你不给他安排活也不行，中间涉及到重新分配、划分、沟通交流，你猜最后这个项目多久完成？

3个月！中间不少的推卸、扯皮、沟通。原本我们的团队之间是很熟悉的，配合度很高，但新团队加入后难免会有邀功请赏、挑肥拣瘦等问题存在，所以导致最终3个月才完成项目。

更狗血的是，对方来帮忙的团队啥也没干，反而成了救世主，拯救我们于水火之中，力挽狂澜。但其实这是我们本来2个月就可以完成的项目，所以你现在知道什么是狗血了吧？

从那之后我就明白了一个道理，也算一点干货吧：如果有在做管理或者即将走向管理岗位的朋友，记住职责一定要明确，你的东西就要你自己搞定，搞不定就延期，但绝对不要让外人插手！

一个颇具讽刺的中国版布鲁克定律，分享给大家。

往期精选：

来都来了，点个【好看】吧~