最近工作忙到键盘都快敲烂，出于原本团队中两位小伙伴都因为各种原因相继离职了，外企扁平化管理模式嘛，项目中前端事无巨细的东西都由我接盘了，最终还是一个人承担了所有。趁空闲下来，总结下这段时间工作上的想法吧。

角色转换

在以往的工作模式，有其他伙伴的分担，伙伴A负责页面表格，伙伴B复杂表格弹窗…只需要专注自己的任务内容就行了，有重复的东西直接import引用，其他人需要什么，我提供接口方式暴露给就行，然后愉快地敲代码，测试，交付…

现在所有编码工作压在自己身上后，需求的所有细节都要自己去完成，包括需求确定，组件设计，数据流设计（下面会详细说），UI Feedback（这玩意要精确到1px，哭了）等等。虽然这些工作在日常的前端开发工作来说，都会遇到，但是当自己负责整个模块时候，需要了解的东西就更加深刻和透切了。在开发过程中，意味着自己不仅要关注系统的核心实现，其他所有UI小细节，前端小交互都要由自己写了，在这个过程中，我觉得最困难的是对一天工作时间的管理，有时候真的会觉得分身乏术。所以我会安排一些核心业务进行集中处理，提高专注度，保证思维逻辑不被打断，这个比重可能会占开发时间的60%或以上，在完成大体框架后，在此基础上不断完善架构的设计，然后利用碎片化的时间去处理一些小细节任务，最后再给自己一些时间进行自测。

编码思维

虽然公司还有其他前端team，人马充足（流下了羡慕的目光），但是由于是不同产品线，也不好过来帮我，所以给到我最大的挑战就是面对复杂的新需求，如何设计给到一套有效的解决方案，并且成功落地。

需求沟通 => 细节化 => 对历史版本的影响 => 后端沟通接口 => 前端实现 => 设计数据流 => 完成UI => 写交互

常规的前端工作模式，基本都是上面这种打发，大同小异。

现在前端的开发模式基本偏向模块化，组件化，对于不同的业务有不同的实现，很多业务的细节展开说貌似没有过多的意义，这里提供一种编码思维，说得不对的地方，还望指正哈~

以一个后台导出csv文件为例，对于后端来说，接口只有一个，但对于前端条件导出来说，涉及的交互就非常多了，需要非常精确地通过控制参数，导出所需的文件内容，这里会有多个因子的影响，如权限，搜索条件，选中条件等等。

在我的实践中，建议在写业务的时候尽可能抽离共同的因子，把代码的粒度控制到最小，把它们的耦合度降到最低。一个funciton只干一件事情。这种编码方式的拓展性是很高的，可以随时应变需求的变更或者接口的变化，而且可读性增强了，对后期的维护友好，改动出错的几率也是非常低的。

再举个例子。

前端在写html模版渲染的时候，对于复杂的页面，往往会涉及嵌套的循环。在这个场景，提前和后台沟通好接口设计就显得尤为重要。 渲染模版的写法需要结合业务进行，如样式的变化，元素的展示等等，这些展现在用户面前的东西，都是由数据驱动的，需要前端通过接口拿到后台一份离散的数据，重新组合，制定一份符合渲染模版所需的数据结构。

简单来说，要做的就是两件事，一是重新组合数据，二是结合数据制定渲染模版接口。

细化一下，在写编写渲染模版时候，有变量控制的，要避免出现魔法判断，尽量抽离到function，语义化代码，试想一下，如果存在多个条件控制，没有抽离出来，这些代码慢慢自然而然会变成屎山。更关键的话，如上面提到的，把变量的粒度控制到最小，代码的插拔性必然会得到增强，有改动只需要调整function，做到1对多的效果。

最后一点，聊聊数据流的管理。

在review以前小伙伴的代码时候，发现存在主组件传到子组件的引用类型数据，属性被随意添加删除的情况。由于JavaScript是弱类型的语言嘛，这种随意修改反正让我觉得很不可靠，项目随时会崩的感觉，应用交互不是很复杂的时候，还能溯源修改的内容，当交互比较复杂的时候，这种处理方式真的分分钟有重构的想法。

在大多数情况下，并不需要vuex, redux这样集中式的状态管理方案。但是你可以参考这种方式。把需要修改数据的逻辑放到主组件，有修改后分发到子组件，这种写法能明确清晰数据的改动逻辑，子组件更多承担渲染工作，避免一份数据多次地方修改，造成耦合。

End.