每个程序员的第一课——你的代码像一坨翔，甩锅呗！

正文

请到「今天看啥」查看全文

无论怎么拆分，都会比合在一起要好。这里"好”，指的是少出故障。实际上是怎么切的，反而不是那么重要的事情，只要能切得开，哪怕你是复制一份代码呢？

甩锅宝典

我的判断是，90%的一坨翔不是因为业务自身有多么多么复杂。而是因为不懂得拒绝，总是做老好人，什么事情都干。就是因为你总是做劳模，替所有人干所有的事，屎盆子才会扣在你的头上。要想避免一坨翔，要从学会甩锅开始做起。传你五条甩锅心法，保平安

• 立字据

• 透传

• 让他们来取

• 如果还是要我推，我就和你们同归于尽

• 相信队友

所有这些招数，和上篇里列举的那些架构模式没有本质区别，不过是换了一个说法。但是我们这次很明白自己的需求是什么。提高团队的自主性，不要被周边系统连累。一个需求，尽量一个团队搞定。减少跨团队沟通的需要，提高所有人的效率。如果开的药方可以做到这一点，就是一个好药方。

你给我立字据

甩锅心法第一则，立字据

哪怕是亲兄弟，也要明算账。坚决不要和其他的服务共用db。我的是我的，你的是你的。

各做各的业务，你要存什么，你自己存去。别挤到一个庞大的Order表里。让你和其他的服务之间，有明确的起止边界，是甩锅最重要的事情。当出了问题的时候，你的责任非常清楚，看看输入，看看输出，一目了然。要不然某个Order上的字段错了，到底是谁写错了都搞不清楚，大家都有读写权限。最极端的情况，流程的每一个步骤都可以切出一个独立的服务出来。

让每个服务有自己的存储，自己独立去面对最终客户，目的是为了让有需求来的时候，每个服务的团队可以更快响应。他们上可接客户，下可接存储，拥有了最大的自主性。而与其他的团队之间也有很清晰的接口（连产品经理都可以说得出来的），从而最小化了沟通成本。

其实所有在数据库里有 1:1 关系的表都有类似的问题。我们可以选择一个表n个字段。也可以选择把表分为两个，然后1:1对应。从快速试错，满足业务需求的角度，拆分出独立的表是更优的做法。也就可以表达为，如果要加一个功能，优先选择建一个新的模块，把这个特例的需求搞定。而不是去修改现有的表，把功能写到现有代码里。

代码重用，从来就不是老板们关心的事情。快速实现需求才是。从90年代的OO理论，到现代的微服务。我觉得最大的进步就是大家觉醒了，快速实现 != 代码重用。与其给场景A加两个字段，给场景B加三个字段。不如连同代码和数据，一切都切分出去好了。

透传

甩锅心法第二招，透传

在查询接口上最恶心的事情是要把一堆杂七杂八的东西都放在一起返回。甚至很多数据都不属于你，是别的团队提供的。要想减少你替别人做嫁衣（想一想，对方年终奖会分给你多少？），最佳的办法是甩锅。与其让别人返回一个enum给你，然后你吭哧吭哧地翻译成中文，拼装出其他需要的数据。直接开一个map透传的接口，你要给用户什么数据，你自己搞，爷不伺候了。因为你提供的是透传的接口，后端的系统有什么字段要加，也不会再来找你了。

请到「今天看啥」查看全文