很多程序员误解了封装的用法。以为只要现阶段是相同的业务，就必须封装。
还有些没什么项目经验的更奇葩。看到一点相似的代码就想把他们提取出来进行封装。层层封装之后，他们自己都看不到这些封装程序在不同的业务情况，到底表达着怎样的语义，导致bug 错漏百出。
与nginx，mysql之类的软件不同。nginx，mysql 是面向机器编程的。所以他们的需求并不会太复杂。这里指的复杂不是算法不复杂。
而是，nginx，mysql，没有直接接触复杂的世界现象。这里的复杂是指业务需求的复杂。
特别是在7层模型，应用层做开发的程序员。分不清，什么是 program 跟 over program。他们不知道如何做到 合适的program。
举个例子，他们看到有两个按钮，都是下单，一个是前台的，一个是后台的，一个是第三方的下单接口。有一天，需求来了。一位新来的开发者A
改了前台的下单代码重新写了下。测试了下，觉得不错，没报错。就完成任务了。直到有一天，第三方下单出bug了，后台出bug了。
后来团队讨论，说这是封装的问题。因为这三个都是下单。没有良好的封装，所以改了一处地方，不知道还有没其他地方没改。
这就是被封装的思维误导的。这根本就不是封装问题。前台的下单代码，跟其他两个，有个函数公用了。不过这位开发者删了这个函数，重写，而没去找这个函数还在哪个业务系统（业务系统是指后台跟第三方下单接口）用到了。
看到了吗？这不是因为封装问题而导致的，是因为开发者没对业务系统进行充分了解导致的。如果一个开发者，连系统的业务都不能理解，不想去了解。你相信，这样一位应用层开发者。他能用代码为这个业务实现一个基本可行的解决方案？
业务层开发，字面上就已经说明，业务为主。业务系统是怎么产生的？是为了给这个复杂多变的世界现象给出一个解决方法。
很多写程序的，会为了技术而技术。他们忘了，程序语言当初是为了什么而发明出来的。其实这些都是知识面广度不够的问题。就好像PL领域。
能做出优美的语言设计的人，都是非常全面的人才。
单纯写代码的，总是想找到一个大一统的方法论 来给这个复杂多变的时间提供一个死板的解决方法。他们没发现一个现象，即使一个业务系统真的上线了。用这个系统的人，并不会只是在页面点几个按钮，特殊情况他们会改数据库，线下操作。所以你看，技术系统根本不能完全解决复杂的世界现象产生的问题。业务系统只是解决了一部分，或者加速了解决问题的速度。
这种大一统的方法论，我把他称之为“银弹”，就是万能的药，能治百病。其实这种东西，已经在软件工程领域，失败了无数次。例如，TDD，DRY原则，KISS。不过人们总是不吸取历史的教训。重复犯一样的错误。
最后，其实计算领域已经不缺牛人。缺的是脑科学领域的牛人。其实过去几十年，人们想在各种软件工程项目中找到一些方法论。只要他们了解人脑，他们足够尊重人的智慧。他们就会这样想，为什么在这种业务场景下，这个人的脑子会犯这种错误，是疲劳。还是业务系统过度臃肿，导致超出了他的脑子的计算范围，所以他考虑不到一些边边角角。当时他的脑子到底进行了何种运算。怎么来更高效的避免这个人犯这些错误？
