一,在系统设计时,应该多思考“墨菲定律”:
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)。
换句话说:只要有足够的测试人员及共同开发者,所有问题都会在很短时间内发现,而且能够很容易被解决。
作者:刘佳翰
来源:CSDN
原文:https://blog.csdn.net/liujiahan629629/article/details/88547172
版权声明:本文为博主原创文章,转载请附上博文链接!