在书中，我们经常能够看到这样那样的法则、定律。然而真正经历过这些事，回过头来进行深度思考的时候，才越来越觉的这些定律、法则的道理之处。下边简述了一些自己感悟比较深刻的定律，当然还有很多，不断学习，不断经历，不断感悟，不断成长吧。
一，在系统设计时，应该多思考“墨菲定律”：
1，任何事都没有表面看起来那么简单；
2，所有的事都会比你预计的时间长；
3，可能出错的事总会出错；
4，如果你担心某种情况发生，那么他就更有可能发生。
二，在系统划分时，也要思考“康威定律”：
1，系统架构是公司组织架构的反映；
2，应该按照业务闭环进行系统拆分/组织机构划分，实现闭环/高内聚/低耦合，减少沟通成本。
3，如果沟通出现问题，那么就应该考虑进行系统和组织架构的调整；
4，在合适时机进行系统拆分，不要一开始就把系统/服务拆分得非常细，虽然闭环，但是每个人维护的系统多，维护成本高。
三，在工期估算时考虑“霍夫斯塔特定律”：
实际花费的时间总是比预期的要长，即便你考虑到了本条定律。
四，在功能设计时考虑“伯斯塔尔定律”：
又称健壮性法则：发送是要保守，接收时要大方。
类似于一个社交原则“对自己严格，对他人宽容”。
发送是保守：告诉我们编写代码尽可能符合规范标准，让别人很容易接收、解析、理解……
接收时大方：告诉我们编写代码尽可能兼容更多的版本、更多的可能性……
五，在变动项目安排时，考虑一下“布鲁克法则”：
追加人员到延迟的项目更会影响项目的进度。
新员工的引入往往会带来的问题：
1，新员工不可能马上投入项目，他们需要经历一些培训。
2，需要在原本的员工中挑选几人脱离生产，用于对新员工进行培训
3，团队内部的沟通将会消耗更多的时间
4，团队的管理将会更加困难
5，新员工对于工作的不熟悉极有可能拖累项目进度
6，更多人参与设计导致概念的一致性遭到破坏，将会导致项目的缺陷增多
7，由于工作的先后顺序问题，所有的员工不一定能投入工作，“十个孕妇不可能在一个月内产下孩子”
更建议采取的方式（视情况而定）：
1，向项目中追加时间，但这带来的二次商业成本将会非常高昂
2，带着问题发布新版本
3，减小目标，发布更精简的版本，并增添更多的后续版本计划
六，在分析问题时考虑“帕累托法则”，又称80/20法则：
1，对于许多现象来说，80%的后果都是 20%的原因造成；
2，在软件开发中，代码中80%的错误是由20%的代码造成；
3，还有，公司80%的工作是由20%的员工完成的。问题是你并不总是清楚谁是那20%。
七，在控制代码质量时，多考虑“林纳斯定律”：
足够多的眼睛，就可让所有问题浮现”（given enough eyeballs, all bugs are shallow）。
换句话说：只要有足够的测试人员及共同开发者，所有问题都会在很短时间内发现，而且能够很容易被解决。
当然，还有很多，多积累，多思考，善于站在巨人简单上……
