读书有感——专注于本质复杂业务才会有较高的职业发展

1. 简介

        我先做一下自我业务的介绍。我所在的小组主要是开发web的，给运营团队进行数据配置和可视化，还有校验运营团队配置的内容是否正确。

        我在工作的过程中，感受非常糟糕。

        其中最困扰我的问题，是一旦有bug暴露，就会挨批。同时我们没有测试团队支持，所有需求都是自己开发+自测完成。软件开发不能有任何错误，所有错误都是能自测找到的，这是我最不理解的。

        我之前认为是领导的风格、部门的KPI导致的。直到最近读到 David Farley 的著作《现代软件工程——如何高效构建软件》中的“分离本质复杂性和偶然复杂性”内容时，才有所感悟——是工作的业务内容决定的！

2. 本性复杂业务和偶然负责业务

        David Farley 在《现代软件工程——如何高效构建软件》中提出了软件系统的“本质复杂性”和“偶然复杂性”的概念。

        本质复杂性是指你正试图解决的问题所固有的复杂性。比如如何计算一个银行账户的值，如何计算购物系统中购物车的商品总数，如何计算宇宙飞船的轨迹等等。解决这种复杂性是我们系统提供的真正价值所在。

        偶然复杂性是指其他的一切——我们被迫解决的问题，这些问题是软件开发做一些有用的事情的副作用。比如数据的持久化、在屏幕上显示内容、安全等等。是与解决手头问题没有直接关系的事情。

        我在这一概念的基础上，提出了在业务领域的名词——本质复杂业务和偶然复杂业务。这个概念和上述的内容是一致的，只是从软件开发领域扩展到了公司业务领域。并发现它能完美适配我的当前业务场景，并解决了伴随我2年多的最大的困惑。

        下面是我对公司业务复杂性的分析，以及最终分离的业务是如果分到我的业务小组中来的：

        1. 首先我们公司的本质复杂业务是做一款客户愿意使用的产品，这派生出了“策划部门”。

        2. 策划的偶然复杂业务是落实其策划内容，策划当然只想专注于设计“让客户愿意”的本质复杂业务，不想自己落实内容（偶然复杂业务），于是派生了“运营部门”。

        3. 运营部门在落实内容的过程中，有配置内容错误的风险（偶然复杂业务），于是将其剥离出来成为其他部门的本质复杂业务——这就是我所在小组的业务。

        所以我所在的小组的本质复杂业务就是——不能出错（不能导致运营部门配置内容错误）。

        综上所述，困扰我的问题的根因找到了，就算换了领导，换了组员，这个问题依然不会改变，它是业务决定的。

3. 要专注于本质复杂业务，不要专注偶然复杂业务。

        注意这里说的是公司需求上的内容，不是软件开发的内容。

        要分析自己所做的业务，是公司主题业务被分离多少次后的业务内容（本质--偶然）。如果自身的业务是被分离多次的，那无论是对自身在公司的发展，还是对自身技术的发展，都是非常低的。就像笔者一样，上级部门最大的期望就是不要出错，而不是像贴近公司本质业务的小组那样，需要更多的创新和思考。

        我们的业务只服务于十几个人，不用考虑QPS，不用考虑数据存储、不用考虑容器化和微服务等等。不要考虑技术迭代。也不用考虑大规模的代码重构。这对软件开发人员来说，是会逐渐丧失自身能力和价值的。

        我所在的小组，一直没有出过绩效为A的员工。但是策划部门、运营部分、客户端、后台和测试都出过A级员工。真的是因为他们技术拉胯吗？在我看到主要是因为其业务是多层分离后的不能出错的偶然业务，然后编程又不可避免出错（也没测试团队）导致的罢了。

4. 感悟

        作为一名程序员，要学会分析公司的本质复杂业务，同时尽可能专注这样的本质复杂业务，才会对自己的技术提升和岗位提升有非常大的效果。

最后我想问下各位程序员，你们开发的过程中，是否达到没有一个bug的情况。另外你们认为低级的错误是否可以完全避免呢。