边界-程序员的枷锁（前端视角）

最新推荐文章于 2024-07-03 09:21:02 发布

天元reborn

最新推荐文章于 2024-07-03 09:21:02 发布

阅读量705

点赞数 25

文章标签：前端状态模式

本文链接：https://blog.csdn.net/qq_23212225/article/details/136917089

版权

我是天元，立志做1000个有趣的项目的前端，公众号：cssandjs

如果你喜欢的话，请点赞，收藏，转发。

背景

在晋升的时候，被问到一个问题：如何界定边界？

当时回答的其实是业务边界的理解，或者说是自己做事的一个态度，但是后来回想回答的并不好。

所以想详细的阐述下自己对边界的理解,如有不对欢迎指正。

边界简而言就是负责的职责范围，单一职责做单一的事，系统通过明确的责任或者模块做为边界，相互之间用接口做连接。

例如商品模块和订单模块，两者之间在业务功能上是相互独立的。但是订单前端需要显示商品的信息，所以订单后端调用了商品后端的接口，通过商品给出的数据，交付给前端。

或者具有中台属性的组织架构，将所有的数据做整合，在中台中做统一交付给业务部门

一般由实线或者虚线leader负责自己下属人员的边界划分，多组业务由该业务的领导者划分。无论是自己要求，还是领导者指派，最终的决定权仍在领导者手里。所以边界的划分是由领导者决定的。

以具体职责作为边界，例如基建和业务。基建负责提供基础建设，例如脚手架，组件库，基础能力。而业务部门负责业务交付。在具体工作中，由各个业务小组对自己的业务负责。各业务小组再以模块做划分，一个人可能存在多个模块，或者一个模块由多个人负责。各自之间通过组织架构和责任分工组成实线及虚线团队。

在边界中可能存在冲突时，由领导者负责协调和监管，确定各自边界范围。

边界的划分有效的阻隔了相互之间的访问和干扰，可以使数据按照约定的形式互相访问，在隔离的基础上没有放弃连通性。

因为接口的约定，使数据变为可控的，可以提供系统更好的安全性和稳定性。尤其在敏感信息的访问上，可以做进一步约束。比如所有用户的手机号，在用户模块的接口中可以做脱敏处理，使接触到敏感数据的人限制在模块的维护和开发人员中，尽可能的避免泄露的风险。

充分解耦，可维护性大大增强。因为模块之间是相互独立的，降低了业务的耦合性，同时将复杂度降低。在此基础上，可以做更深层次的技术实现。例如将数据和业务分离，将模块抽象，公共的拦截层。这些大大降低了后续的业务接入成本，促进了系统的可维护性和扩展性。

因为边界的存在，领导者只需向该边界的负责人进行沟通即可，减少了管理的沟通成本。例如商品模块只需要找到对应的owner和一号位，直接向其进行沟通。。

在边界内，可以对整体技术统一明确，减少不必要的技术损耗。同时可剥离出更多的技术专职，将技术栈进一步缩小到模块的使用上。基于以上两点，使招聘目标更其清晰，可以更明确的指出需要什么样技术栈，经验技能的专职人员。在培训上也可只专注于模块的培训而弱化整体的培训，降低培训成本。

因为边界的存在，一般不允许跨模块的事情的发生。例如商品前端通过商品后端访问商品中台，不允许发生商品前端直接访问商品中台的情况发生。由此使整体系统链路变长。

又因为系统的充分解耦，所以为了降低单一模块对整体的影响，增加了更多的维护成本。在模块单独部署上，增加了运维和服务器成本。在非独立部署时，要考虑单一模块对整体的影响，需要测试对整体回归测试，增加了测试的成本。

每一个模块都可能需要一整套的公共模块的支持，如果公共模块更新不及时，可能造成各自造轮子的场景。在技术收敛上存在更多的成本，这时就需要边界的监管者及时收敛。

同时边界限制了人员相互之间的沟通，不利于发掘人员潜力,促进创新。更像是把人员限制在工作位置上，形成了一个萝卜一个坑的局面。多组人员之间相互不熟悉对方业务和工作内容，增加沟通成本。单一模块的人员，对整体业务缺乏足够了解，在调整职责的时候，需要更多的时间熟悉和梳理。

在一般情况下，不应该打破边界，边界的形成是具体的社会分工。目的是为了清晰的职责划分。
但是边界的存在遏制了开发者的创造力，使公司限于交付为目标的公司，不利于公司的创新性。

打破边界不是打破组织边界，业务边界，而是以一个更高的维度看待问题，从多方面发掘自己的潜力。

思维转变。将自己从单一职责中摘出来，本职工作是立命之本。但自己能跳出来才是向上的根本。
不断学习。打铁还需自身硬，自己本身能力的提高才能有助于自己打破枷锁。不断的学习新知识，使自己有打破枷锁的能力。横向的知识学习，根据自身的技术栈做扩展，了解其他同一层面技术的应用和资讯。纵向挖掘底层，深入技术原理与实现。跳出知识盲区，了解其他职能的技术，促进交叉技术应用。
关注非技术流程。例如业务流程的衔接，产品的理念，ui的规范等相关内容，从纵向了解研发流程，从横向了解其他团队的做法，打破技术边界，了解产品UI，项目经理的思考点。从更高的层面去看到问题，看待结果。