不知不觉自己从毕业已经从事了一年多的前端工作，当然如果加上实习期，那就更长了，一年中，有最初的兴奋和憧憬，也有迷茫和困惑，这里想要总结归纳一下这一年学到的一些程序的抽象层和思维和方法论上面的东西，谨以记录勉励自己前行。
这里首先致敬感谢老大乔总的鞭策和指导，如果说我在前几任老大学到怎么写代码，那么乔总教会的我是怎么从软件工程思维去思考一个问题，一种另类的学习方法和规划、设计思路的方法论。
模型层
在此前我一直待在一家996的公司，大家业务紧当然是能跑就行，最多加点"你看不看得懂没关系，反正老子写了"的注释，维护组件和数据异常蛋疼，上千行的组件非常常见。
当然呼应主题必须引入ts的故事
因为大佬强推Typescript接触到了Typescript，当然在一开始我是有点抵触的，"定义一个复杂些的东西好复杂啊，能不能不用啊"。但是后面发现确实加了这玩意之后，配合vscode各种类型提醒更有谱了，而且因为你定义好了所以你用a.b.c.d这种对象的时候不用反复比对这玩意之前是不是这么写的，并且线上确实很少发生"xxx underfunded，xxx is null"这种炸了的事情。"真香"
后来我发现大佬在处理一些复杂数据，例如多条件结算，多权限判断的时候使用了模型层的概念，我研究后发现这么干有如下好处
- 视图更加纯粹地渲染视图，不带复杂恶心逻辑
- 数据层处理好数据，接口变动无需去业务代码里面翻找修改，专心处理数据，这其实也是mvvm这类框架的灵魂。
- 调用者可以无需知道model内层复杂的判断逻辑，调用方法即可，避免每个开发者去“review”这个方法所在的项目业务代码的痛苦过程
- 可跨框架，跨项目使用这个model层，提高开发效率
先设计后实践
以前我拿到一个需求总是从图形入手再想这玩意大概用什么方法api可以搞定就动手了，这样子的思维存在一个缺陷，因为从图形入手我很容易在最后将他和view耦合过深， 抽离困难，或者卡住在某个地方没有思路继续不下去，后来我看到大佬在写一些程序的时候会在头部先写一些思维构想，譬如："主要思路，抽取空闲通道，将弹幕插入xxxx，需要考虑**问题"，然后再开始写代码，果真读他的代码结构清晰，和view耦合低，因为是原生js，所以甚至可以抽离出来给任何项目调用。
问题拆分组合分析能力
因为我们在做微信的一些业务，而微信生态里面发生了什么对于我们来说它就是一个黑盒，我们不能用常规的方式去排查它，而且网上也找不到任何确切相关的资料，而我们拿到一个问题的时候，总是觉得这个问题非常的庞大，很难拆分，不知道如何入手去排查他，而大佬通过自己一些经验告诉我们有时候一些问题不仅仅要靠常规经验，你必须动手用设置对照组，拆分条件，js不对拆css，拆加载顺序，模拟加载，多做实验，其实，软件工程也是跟科研一样，我们需要不停的实验不停的尝试，最终得到你自己的判断。
Service
你以为service只是后端的东西？前端也可以有，在项目中发现一些小工具可以开发出来公用，但是我们又不希望他只能在特定项目使用，具有通用性和容错性，譬如我们的前端授权服务，前端监控上报服务，我们都可以抽出sdk servide的概念，总结特点如下。
1，业务非耦合 - 不和业务耦合，即使跨项目也能使用能够通过npm，script直接引入，不依赖【业务依赖】
2，兼容 / 扩展性 - 可以通过独立发版进行拓展功能和升级，对不同项目没有js版本/依赖等要求
3，容错度 - 即使我们的服务炸了，也不会影响业务代码(搞出xxx is undefine等阻塞页面)，或者最低影响
深层思考
万变不离其宗，其实很多人都在担忧前端技术更新日新月异好害怕，但是大佬用他的实践告诉我们，先不要害怕一个东西，先观察，但是不要先去看源码，先看我们用最简单的方法看能不能造出来，譬如api表现怎么样的。我们的思维定势一直是出了个新东西，先疯狂追一下新，然后学会怎么用。再看看能不能看懂源码，而大佬每次都能在我们说会用的时候给我们以降维打击。后期我学着这种思路去看了express，react-router， vuex， redux的一些实现，体会很深，有时候我们真的就卡在一个点，如果告诉你，react-router是基于context实现的props跨级传递和history api的一些简单应用(当然redux也是基于context)，vuex的全局store数据驱动更新是因为它把store作为更高层级的"data"并利用了vue原本的数据对象观察的能力,我估计大部分人会说"哇，那这样我也知道啊",其实有时候就是这样的，我们的思维定势先设定我们很难去理解大神做的东西，所以我们缺了去思考"how it run"的动力。我们习惯于膜拜某些看源码的大佬，但是这种方式用大佬的说法是像高中解数学题，先看了答案再去想实现，这并不是最优的思维方式。
