jser

**需求描述** webpack-dev-server 服务启动成功后，直接唤起浏览器打开页面

*【前言】需求过来时，不要着急思考 “怎么做”。应先思考 “为什么要这么做”。* 事情背景是这样的： 我负责了公司某个公共的的 `npm`，该 `npm` 被公司所有的 web 应用使用（以下用 p 代替）。某天，A 业务线的小明跟我说： + 小明：“我们在一个复杂项目的场景下，需要 p 的 projectName 支持动态修改。即随着时间的推移，该 projectName 可能产生变化。” + 我：“先说说该项目复杂在哪里？” + 小明：“我们的项目里依赖了一个公共的业务模块，该公共业务模块里面使用了 p。而我们的项目里也依赖了 p，并且我们之间使用的 projectName 是不同的。而我们期望公共业务模块使用我们配置的 projectName。期望你能修改一下...

推动某项规范（标准、最佳实践）落地最快的方法是——制定的规范尽可能少的存在想象空间。因为团队中每个人都是富有想象力的，如果留有太多的想象空间那规范就无法落地（对于 “好” 的认识不一致）。因此制定的标准必须清晰明了，能够供大家 case by case 的匹配最佳实践。举一个例子最近项目中遇到的问题： 在最近的一个项目中，我与同事在项目开始前做了充分的设计（当时还算充分，后来发现还是不够），对于 “业务组件” 这一块的设计尤其，粒度、命名等都做了充分的讨论。但随着项目的迭代，逐渐的暴露了很多问题，其中最典型的一个是：“为什么我们在有业务组件库的情况下，还有那么多 case 没覆盖到？”。ok，围绕这个问题，我与同事展开了讨论： + 我：“我觉得我们做业务组件的思路有点偏了，有点做成了通用组件的味道。导致有比较多的业务场景没覆盖到” + 同事：“还是业务组件，只是业务组件应该分层。至于对 业务贴合度不够的问题，我觉得是我们对业务切入的角度还不足够精细导致的” + 我：“业务组件应该是针对特定的业务场景的抽象，将特定业务域的问题解决即可，不需要考虑太多的通用场景” + 同事：“应该有 基础 UI 组件 --> 抽象业务组件 --> 定制业务组件” ok，聊到这， 我陷入了一阵思考。这不是我想追寻的答案。我想追寻的更多是如何准确落地，解决特定问题的答案。于是我复盘了一下当初的设计过程：...