业务总结
# 业务总结
业务最核心的要素是业务本身的价值
# 业务自问
能不能 5 分钟说明白，你负责的业务是什么？（学会发现问题）
例子：假设你在开发一个营销活动页，这个页面能够给公司带来 3000 人的新用户，这些人有可能会购买公司的产品，从而带来收入。
- 营销页每天换内容，怎么快速替换？
- 营销部门人越来越多了，页面每天要 10 个，一个人怎么做得完？
- 前端的人也越来越多了，改个组件不能只靠复制黏贴，怎么管理？
- 拉新回流效率具体有多高？新人真的有买我们的商品吗？这么多人投入，都是要工资的，卖出去的商品能够发我们的工资吗？
- 转化率低了，怎么才能提升？
- 这个按钮写错个样式到了右边，居然点的人特别多？那下次是不是都应该放右边？
这些事情是你想做的，还是产品让你做的？
可以开始写代码了？(学会思考的方式)
请先做好技术方案设计，而设计的第一步，就是做一个 ppt 工程师，画图。
图，是思想的结晶
几个最典型的问题是：
- 思路混乱： 下面几个框在写业务的系统，上面画了一个 vue 或者 webpack 的框。
- 层级混乱： 底层写的是 native 容器，上层画了个 api gateway。
- 答非所问： 要求画业务大图，结果画了一堆前端脚手架的关键字，或者画成了流程图。
知道原理有什么用？(技术如何赋能) 知其然，而后使其然
任务的拆解
要不要造轮子？
我们经常会发现好像什么都能做，比如：你有的，我改改也能实现；社区有个差不多能用的，要不要直接用；好像大图上都有差不多的，那是不是拼拼凑凑就可以了，这个方案是不是没什么好做的了。
从我个人来说，每次画图我都会陷入这样的思考，还常常会钻牛角尖，为了整点差异化，故意换一些思路去做，这样能保证这个饼是我的。但最后我都会绕出来，这得益于上面画图的第三步，每次画完我都会重新回顾一下我真正想做的事情是什么。我认为这也是是否造轮子的一个评判标准：从业务的价值出发，思考真正核心的目标，并且为之努力，如果有现成的轮子，能满足业务核心诉求，那就放手去用。
首先，现实往往是这样的，当我们放手去用的时候，会发现这个轮子好像不那么好用，或者这个轮子没人维护了，又或者业务变化太快，轮子自己觉得顶不住了。机会自然会来到身边，而触发这些机会的，是我们不断的站在业务的视角去思考问题，业务的变化一定比一个平台化的轮子要来得快。
其次，真正核心的系统一定是紧贴业务，而且很难大范围复用的，好的技术架构在设计的时候，讲究的是够用即可，过度设计大部分就是没用的设计。在之后的迭代中，会随着业务的不断变化，被带动着自我进化，那最终的产物也自然是和业务形态非常贴合。所以，我个人在选择的时候，一些核心的轮子，该造就造起来，但这些轮子一定是带有业务特色的，比如我会去造一个业务组件库，但是我绝不会去造一个 antd。
业务/技术思考 => 发现痛点 => 产出方案 => 拆解实现
参考：前端简历中的项目经历怎么突出亮点？https://zhuanlan.zhihu.com/p/179284623 (opens new window)