技术瓶颈的根源
目前自己的工作，渐渐有维护开发组件转变到和外界的第三方库进行代码整合，集成。
之前开发组件方面，常常是后端说你提供一个这样的配置项，或者根据有这样一个业务需求，希望能新加一个配置项。一个组件设计者对组件的设置项能考虑得多周、多全详尽，体现了这个开发者的老道程度。
做集成就更少了，经验积累的也不够。和后端通讯大多只停留在接口调用方面，后端暴露出API，我来请求数据，进行相应的增删改查。但是对于后端模型、字段思维还是没有很好的熟悉了解，没能提前做好前端接口的规划，很多时候都是被提需求。
现在做的整合第三方库，其实是有挑战性的，不过也非常有意思。因为你能看到别人的代码组织思路，和有趣的命名方式，很多地方可以学到新东西，但是更多的是发现了自身存在的问题——对后端知识的匮乏，比如：http/https。
有一定的服务端知识对于前端来说无疑是加分项，而http/https对于前端应该是最需要掌握的后端知识，毕竟大部分web前后端通讯走得都是http/https协议。其实搞懂了一个协议，协议也就算了入门了。从http状态码、编码（曾经面试被问到gbk和utf-8分别的适用场景）到认证（数字证书、cookie、session）再到web 安全方面的知识（加解密通讯机制、XSS、CSRF）自己了解得太少了。其实主要是因为，公司的产品研发平时不需要接触这些，因为这些东西基本上已经为你封装好了，你只需要用他们就可以了。我也明白这个现状，于是就对自己说：“ysq,你要靠自己了~”。
有一段时间我非常严厉的批评自己，你以为你会了ajax就算懂http了，其实没有系统的学习，没有投入时间去钻研，你是永远不可能懂的。现在服务端已经可以用js来写了，为什么你不自己去尝试写写服务呢，自己搭一个服务，看看请求头、响应头这些字段都是什么意思。公司没有这个机会，你就要靠你自己去深入下去。
简而言之，缺哪补哪，在哪里跌倒，就要在哪里站起来。
参与开源
刚才说到自己目前的工作，主要是和第三方库进行代码整合。在这个过程中，逐渐开始参与到Open Source Project中去。人家说了声感谢，我还是非常开心滴_
技术人员并非不用和人打交道
相反，技术人员需要用有效的方式方法去和别人进行高效沟通。比如了解需求，比如反馈需求中的技术实现难点以及需求中不合理的地方，比如沟通协调研发周期时间和研发进度，比如讨论团队内部的人员分工等等。这一切都需要研发人员具备很强的沟通能力，理解能力。
无论在大公司和小公司，其实技术人员多多少少都要设计到管理层面上的事，想两耳不闻窗外事、一门心思搞研发，这种纯粹的技术专家其实还是少数的。尤其是级别越高，越会更多地承担起管理方面的事务。而研发的管理其实主要就是对人的管理。而这离不开良好的沟通。
深度 VS 广度
在知乎曾经有人问了这样一个问题：如何平衡知识结构广度与深度？
其中有一张图片非常有意思：
它的结论是：深度和广度并非矛盾的，反而知识的深度需要用知识的广度来支撑。
举个例子，比如前端同样是做css垂直居中。
一开始可能用line-height等于height觉得很好，后来发现这东西有局限性，对于单行文字还ok，对于多行文字就显得非常不方便。
于是遇到多行文字就给个容器设个定高，再使负边距的知识将margin-top设为定高的一般的相反数。
后来过了一段时间他用遇到了新需求，就是这段文字是从服务器抛过来的，并非定死的。所以定高有可能会因为文字撑不满导致底部留白问题。于是他就开始尝试其他的解决方案，比如transform和top相结合的方法。
在不断的面对处理新需求的同时，技术领域得到更广的探索，于是渐渐敢说我成为了垂直居中领域的小行家~做到了有一定深度。
当我面临压力的时候，我在想些什么
压力来自何方？
时间交付期限压力（很有名的书叫《最后期限》，推荐阅读），技术瓶颈压力，社交压力等等，重复引起的身心疲倦带来的压力等等。
理性思考得出结论
有压力就更应该感到高兴，以色列文化中有这样一句话：苦难是化了妆的幸福（Afflictions are Blessings in Disguise）。因为这正是可以提升自己的时候。
压力暴露出来的是问题，而问题越早暴露越好。就像发烧实际上是对身体的保护一样。越早暴露出问题，越早面对问题，就会越早得到提升。一味的为了面子，为了荣誉，为了身段，隐藏，遮蔽，逃避，对自己没有任何好处。
也谈工程师文化
我从不把自己叫做码农，我更喜欢称自己为工程师。因为我不是光完成任务就完了，我认为自己有更大的价值，我也希望能给团队，给企业，给社会带来更多的价值。这也是我喜欢计算机的原因，它给了我价值感。就像我写过的那句话：用技术驱动变革，用善心拥抱未来。
工程师要有工匠精神
一开始要想能不能做出来。能做出来之后要继续想能不能做好。做好之后要想还存在哪些漏洞及潜在隐患。不断地思索，不断地去打磨自己的产品，不断地在这个过程中提升自己。
平常由于交付期限的限制，很多东西做完就完了。但其实能够沉淀、能够吸取出来的精华的东西往往也在“做完就完了”这种思维中流失掉了。所以我喜欢总结，喜欢去看自己做过的旧项目，带着新的思维去审视过去的项目，往往能触发思考。而这种思考反过来让我接下来的项目越做越好。
工程师的使命是解决问题
衡量一个工程师的价值的很重要的一方面就是看他能否解决问题。我们平常出页面，做交互，做集成同样也有产出，但这是对一个程序开发者最最基础的要求，说白了就是you deserve it。做好了也没什么可以骄傲的地方，因为这是本职工作，但是做不好就是没有称职，要自己反思（我一直是这么要求自己的）。
一个非常有意思的真实案例。
一次，某产品在测试过程中发现页面交互出现性能问题，当数据量大的时候单机鼠标会出现一段时间假死，数据量越大，假死现象越严重。该产品前端并非我负责，但反馈到了我这里。但我又暂时没有产品的源码，因为我的工作是底层组件支撑，我只能通过firebug在火狐上进行调试，来发现问题。于是我就想办法分析。
当然一开始的时候我怀疑是它的业务js代码有问题。后来我发现我右键菜单(contextmenu)和左键(click)都会造成此问题，于是就猜想二者的相同之处应该就是问题所在。于是去对比发现他们都调用了B组件的clearSelect()方法，于是我在firebug做测试，手动执行此方法，重现了问题。重现问题是解决问题的第一步。而B组件是底层组件在我的管辖范畴内，于是我就可以进一步缩小范围调试了~
在没有得到项目源码的情况下，我利用firebug进行远程调试，发现了问题所在，缩小了debug范围，节约了返工成本。
工程师要把基础打好
大部分的流行的框架我都不会，但我并不觉得这是什么很严重的问题。很多互联网公司，应用现在流行的angular、react、vue等等，甚至面试上来就会问你会使用它们吗？
说说自己的观点。框架每年都在变，你看angular现在已经到了4.0，很多API也发生了变化，那些一直跟着框架走的人，有一部分人是疲惫地在往前学，出了新的API就要去跟进，个人觉得这样好累啊。这些人在准求的是那些一直在变化的东西，让自己的学习成本一直非常高。但他们忽视了哪些不变的东西，以不变应万变才是王道。这个不变的东西就叫做基础。
实际上每个框架都是为了解决一个特定的问题而生的，每个框架也都是有其局限性的，不存在一个框架是能管所有的。所以我认为在学框架前更重要是了解它背后的设计初衷，即为什么要设计这个框架，当时设计者面对的是怎样的需求，他希望这个框架能够解决什么应用场景下的问题，他针对这个问题为框架注入了怎样的精神活力，融入了怎样的思想？在搞清楚这些问题的时候，我想学习框架就不会太盲目了，而是有针对性和目的性。而不再是单纯地傻傻地为了找到好工作而学框架了。
如果能把框架的思想融入到自己的思想中去，那么平时在写代码，处理问题的时候，实际上就是带着这样的思维去做事情，就像图灵书上写的“站在巨人的肩膀上”。
一个值得期待的项目
团队内部近期发起了一个代号为AND的项目,该项目希望通过可视化拖拽组件的方式快速搭建已集成后端的app。
我在这方面看到了几个亮点：
- RESTFul API的引入。RESTful可以通过一套统一的接口为 Web，iOS和Android提供服务。这为公司迎接开源引进新的前端框架以及前后端分离做了准备。前端对于页面将有更多话语权，页面渲染的东西将完全交由前端处理。也提高了html的可维护性，杂糅后端代码的页面看上去总会是恶心的。
- 深入了解组件化，为组件定规范。暂不展开。
- 后端模型基于可视化的方式自动生成。合并重复，提升效率。
- 前后端分离的契机。之前我们只能叫做前后端分工，远远达不到前后端分离。而且经常会造成后端和前端一起改js或是velocity，导致相互之间总得交流沟通，浪费大量时间成本。所谓前后端分离主要是指：后台只需提供API接口，前端调用AJAX实现数据呈现。前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码。我期待以后的工作流程变成：1.大家伙一起开会了解产品及其需求。2. 前后端根据产品先沟通数据结构。3.前后端按照约定好的数据结构同步开发，前端专注于页面及交互，后端利用RESTFul API提供接口为前端提供数据。4.让集成工作交由前端处理，后端专注于底层服务。感兴趣的小伙伴可以看看这个：我们为什么要尝试前后端分离
我给AND的定位是:
减少重复、提供定制，让前端人员专注于组件开发，让后端人员专注在底层服务。
彩蛋
最后po一个今年的小作品(支持手机端)： 公司38节活动暖场
