知鸦日报2022-10-15

平时我们会把业务需求分成日常需求和项目，一般而言，项目是有体系的，有顶设的，能够挂靠业务重要目标的，也有比较长的澄清与沟通周期，项目数量也是可管控的，虽然是PD投入精力的大头，但相对而言，投入的质量也是可预期的。

而日常需求则是无体系的、临时提出的、大量的，看似点都不大、难度也不高，但是产品经理无法放过每一个日常需求，都还是要投入大量的精力去了解背景、依赖、风险，然后确定方案、跟进需求上线全流程的。

正因为日常需求没有一个正儿八经的立项机制，各种业务方提日常需求的方式也是很难被规范化要求，过去我们虽然尝试过各种需求结构化的模板，提供给需求方，意图能够减少大量线下临时沟通，让他们找我们之前先好好思考、认真填写必要要素。

在主应用和子应用上分别使用 div 元素插入一段标题，两个 div 元素使用相同的 class 名 title，分别在 class 中设置文字颜色，主应用 color 值为 yellow，子应用为 red。

由于子应用的样式晚于主应用加载，所以主应用的样式会被覆盖。

以上问题在同时加载多个子应用时也会存在：各个应用之间也可能存在同名的 className 或者给相同条件的选择器添加了样式， 那么最终只有优先级最高的样式才会生效。要确保应用之间的样式不会互相影响，就需要对应用间的样式进行隔离。

中后台系统做为每家公司运营体系中的一环，小到内容管理系统，大到资产管理系统、财务系统等，一直都扮演着重要的角色。随着业务迭代升级，参与开发的人员增多，如果没有做好合理的规划，成为“巨石应用”似乎是一个逃不掉的宿命。