公众号菜单栏点击“入群交流”，和大家共同进步
大家估计有个越来越深的感受，就是说只做写代码的码农太局限了，现在这个环境，大家都想往上走当领导，除了升职加薪，其实也是实现了阶层的跨越。
这其中最重要的是一些基本原则和顶定律你得知道，对于后续做管理会有帮助。GitHub最近就有一个项目总结了与开发人员相关的15大定律和7大原则（项目地址：https://github.com/dwmkerr/hacker-laws）。
定律
阿姆达尔定律(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个月就可以完成的项目，所以你现在知道什么是狗血了吧？
从那之后我就明白了一个道理，也算一点干货吧：如果有在做管理或者即将走向管理岗位的朋友，记住职责一定要明确，你的东西就要你自己搞定，搞不定就延期，但绝对不要让外人插手！
一个颇具讽刺的中国版布鲁克定律，分享给大家。
往期精选：
程序猩球
一个深度的技术号
