工程师都应该了解的10个定律

golcm
发布于 2023-1-17 11:21
浏览
0收藏

 一、海勒姆法则

内容

当一个 API 有足够多的用户,你在契约中承诺了什么并不重要:系统中所有看得见的行为都会有某个人依赖……

案例

现在有两个系统A和B,B的一个接口返回一个列表。A系统的开发人员发现返回的列表都是按照ID正向排序的。本身A系统正好需要其按照正序排序,于是直接自己没有做排序就直接使用了。

工程师都应该了解的10个定律-鸿蒙开发者社区

实际B返回的列表是直接从数据库取出来的,自身没有做排序,并不知道自己的返回列表顺序被依赖了。有一天,B系统有个新需求,需要在返回列表数据前对数据先做个处理。因为B本身没有意识到自己提供了有序的列表,处理时就可能产生问题。

二、切斯特顿栅栏

内容

简单来说是:存在即合理。

在某种情况下存在某种制度或法律,为了简单起见,我们可以把它当做道路上竖立一道栅栏或大门。后来的改革者会欢欣鼓舞地说:“我没有看到这东西有什么用处,让我们把它清除掉吧。”
而更聪明的改革者则会说:“如果你没有看到它的用处,我当然不会让你们清除它。离远点动脑子想想。然后,当你可以回来告诉我你确实看到了它的用途时,我才可能让你毁掉它。”
做出重大决策的核心部分是理解先前决策背后的理由。如果我们不了解是如何形成当前状态,我们就有使事情变得更糟的风险。

工程师都应该了解的10个定律-鸿蒙开发者社区

案例

有很多人接手一个前人做的项目时,会发现一些代码写的不对或者不好。有想马上动手改一改的冲动。但是有经验的前辈就会说这个代码运行了这么多长时间,不能随便改。有段逻辑看起来是错的,那很有可能是因为负负得正,其他地方也有问题正好一起合成了正确的结果。在理清楚所有脉络前,最好什么都不要动。

三、二阶思维

内容

简单来说:更深层次的考虑问题

把问题思考到二阶、三阶和n阶的能力,或者简称为二阶思维——是增强你思维的强大工具。

案例

工程师都应该了解的10个定律-鸿蒙开发者社区

在上面切斯特顿栅栏的案例中,就可以使用二阶思维多想一层,把整个系统的原本思路原因分析清楚。大家在做故障回顾和案例分析时常用的5why分析法也是二阶思维的经典应用。

四、街灯效应

内容

简单来说就是:拿着锤头找钉子

出自下面这则寓言:

一天晚上,一个警察看到一个醉汉在路灯下的地面上找东西,问他在找什么。醉汉回答说他钥匙丢了。警察看了看也找不到,就问他:“你确定你钥匙是在这儿丢的,就在路灯下?”醉汉说:“不,但是这儿的光是最亮的”。

工程师都应该了解的10个定律-鸿蒙开发者社区

案例

在排查生产问题的时候,特别是不能复现的问题。很多人的排查方法取决于自己知道哪些方法而不是问题本身需要什么方法。要解这个问题需要大量的积累,有更多的方法、思路,才能根据问题找到合适的方法。

五、虚荣指标

内容

虚荣指标是指无法真正反映情况的数字。

案例

工程师都应该了解的10个定律-鸿蒙开发者社区

有些反馈表面数据的指标,它们让效果看起来很好但却不能告诉我们具体价值,典型的虚荣指标如点击量、下载量和曝光量,数据量级很大,让人印象深刻,但这样的数据用于广告宣传还行,用于指导公司行动就意义不大。举例如下:

1. 点击量。这是互联网洪荒年代所使用的指标,随便什么网站,只要上面可点 的东西多,这个数字都会很高。相比之下,你更应统计点击的人数。

2. 页面浏览量(PV值)。这个指标只比点击量稍好一点点,因其统计的是网页被访客请求的次数。除非你的商业模式直接与PV值挂钩(即展示广 告),你还是更应统计(访问的)人数。

3. 访问量。你的100访问量究竟来自于1个访问了 100次的用户,还是100 个访问了 1次的用户?它无法指导行动。

4. 独立访客数。只能显示有多少人访问了网页,却不能告诉你这些人在页面上做了什么。他们为什么停留?是否离开了?如果是一款内容型产品,更应该关注单个用户的阅读文章数量、用户的使用频次、有点击行为的浏览时长 和点击位置。以这些指标反馈到具体的用户行为和用户喜好,来优化内容运 营行为。

5. 粉丝/好友/赞的数量。计算粉丝/好友的数量只是一场毫无意义的人气比 赛,除非你能让他们做对你有利的事。你在社交平台上振臂一呼时,有多少 粉丝会响应?只有知道了这个数字,他们才对你有意义。实际上,更应该观察用户对产品核心 功能的使用情况,资讯类产品公司要关注用户浏览了几篇文章,电商类产品 公司要看用户浏览了哪些商品且有没有购买,在线教育类产品公司要关注用 户是否参与了课程并按课程进度听课。

6. 网站停留时间(time on site ) /浏览页数(number of pages )。用户停留时间是指用户在某个页面停留了多久,而不是浏览了多久。用 户停留时间并不能反映用户对内容的喜好程度,我们更应该使用用户的阅读 速度、阅读完成度和内容跳出率等数据判断用户对某个页面内容的喜好程度。用这 两个指标来替代客户参与度或活跃度并非明智之举,除非你的商业模式与这两个指标相绑定。而且,它们并非一定能说明问题。比如,客户在客服或投 诉页面上停留了很长时间,不见得是什么好事。

7. 收集到的用户邮件地址数量。有很多人对你的创业项目感兴趣,这很好。但是,如果不知道他们中有多少人会真正打开你的邮件(并为你邮件中的内容 买单),纵使有再多人在你的邮件列表上也是枉然。更好的做法是:向一部 分注册用户发送测试邮件,看他们是否会按照邮件中的提示去做。

8. 下载量。尽管有时会影响你在应用商店中的排名,但下载量本身并不带来价值。你需要衡量的是:应用下载后的激活量、账号创建量等等。但是没有免费功能的付费应用除外。

六、墨菲定律

内容

凡事只要可能出错,那就一定会出错。

工程师都应该了解的10个定律-鸿蒙开发者社区

案例

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

七、墨菲第二定律

内容

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

工程师都应该了解的10个定律-鸿蒙开发者社区

案例

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

八、康威定律

内容

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

案例

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

九、格雷欣法则

内容

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

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

工程师都应该了解的10个定律-鸿蒙开发者社区

案例

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

十、泰斯勒定律

内容

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

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

案例

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

工程师都应该了解的10个定律-鸿蒙开发者社区



文章转载自公众号:编程一生

分类
已于2023-1-17 11:21:51修改
收藏
回复
举报
回复
    相关推荐