软件工程师都应该知道的10个定律

墨菲定律

案例

一个项目负责人,拿到一个项目,做好了方案。把开发人员、测试人员等相关方都叫到一起开会,对齐了方案和排期。如果大家各司其职,按照方案和排期进行,事情会很顺利。但是经常做项目的我们自然知道,事情很少像想象的那样顺利过。比如开发人员自己开发好了,却忘记了通知测试人员测试。测试人员有其他的项目要忙,没人通知他也没有自己主动问问是否需要测试了。这些都需要设置跟进和应对措施,不能想当然。

七、墨菲第二定律

内容

没有什么事情像看起来那么简单。

墨菲第二定律

案例

项目往往会比你预计的时间长,比如临时会插进去更紧急的事情;比如合作团队遇到问题;所以有经验的工程师往往会给自己留一些buffer。

八、康威定律

内容

组织设计的产品/设计等价于这个组织的沟通结构。

案例

如果你让 4 个小组开发编译器,那么你就会获得 4 个编译器。所以我们要用一切手段提升沟通效率,比如工作中常用的wiki、jira、github和即时通讯工具。

九、格雷欣法则

内容

简单来说就是坏的挤走好的。

也就是通常所说的“劣币驱逐良币”定律。周先生以西方公案的方式介绍其来龙去脉,也就是先生说的“以讹传讹”。十六世纪的英王伊丽莎白有位顾问,就是Sir Thomas Gresham(葛氏),他发现市场上流通的货币,由于在流通中磨损而重量不足,人们便把“足金”储存起来,熔化成金属块,甚至转运出口,只把“不足”的拿到市场上使用。

格雷欣法则

案例

很多用人单位招聘秉持着:新招聘的员工水平一定要高于目前员工的平均水平,宁缺毋滥的原则。就是要避免“劣币驱逐良币”定律。

十、泰斯勒定律

内容

泰思勒定律也被称为复杂度守恒定律。该定律指出每一个过程都有其固有的复杂性,存在一个临界点,超过了这个点过程就不能再简化了,你只能将固有的复杂性从一个地方移动到另外一个地方。

简单点来说:如果想让用户使用简单,那产品自身的实现复杂性就会增加。

案例

以下是一个通过产品自身增加处理,让用户行为变得简单的例子:

泰斯勒定律

上一页12下一页


留言