全职半年记
身份的转变
想起半年前入职时的心情，困惑而诚惶诚恐。
为什么，一个感觉根本就不需要前端的创业公司愿意招什么也不会的我去做前端呢？
我不知道，现在也不知道。日子向前，江河西去，我也不在乎原因。
半年前在机房里面试，ztrix翻看我的博客：神经网络，微信机器人，blackhat javascript，web输入法…
“你为什么要做前端呢？我是说，感觉花花世界都看过了，真的能静下心来写前端么？”
“……”
“我们确实需要一个人全职做前端方面的工作。”
我忽然很恍惚，因为我觉得贵司根本就不需要多余一个我来做前端。
“希望你能静下心来，在前端领域有所精进。”
时光再往前推几个月，第二次去768外二楼的狭小会议室里，我去讲了讲node实现的微信机器人。 接着ztrix, pandada8, 萌神开始讨论贵司准备 做的某统一认证。我去讲的不是前端，作为面试内容讨论的也不是前端。
模糊而迷乱，恍惚而平静。
“你哪方面比较擅长呢，如果让你写python也能写是吧”
“…”
时间再回推两个月，zt师兄微信问我愿不愿意去长亭，我说
“吼啊”
然后，给一家不到二十人的安全公司发了一份前端简历。
“我们都是朋友，你也多和zt交流交流。你想想为什么你面试这么多地方都被拒绝了。”
“你工作之后和自己玩不一样…”
“…”
时间再回推一个月，再linkedin，我不知道进门面试我的是何方神圣，因为名字没听清。
面试官带着眼镜，有一种温文尔雅的气质，很客气
“你最擅长什么呢？”
“…”
“你有听说过一些新技术吗？为什么没有尝试呢？”
“…”
“谢谢你来面试”
时间再回推两个月，在美团，面试官说，
“你这样让我很为难啊？工作中，交代一件事，你得把它按基本法走啊。”
复试的时候和面试官谈笑风声了半个小时美团面试的科学性和必然性。
耐心的面试官最后还是说，
“你基础挺好，还需要多练习，但我们以后再聊吧，我得赶紧写评语面下一个人了”
时间再回推几天，360手机助手的HR面试官语速很快。
“能不能来实习啊，学校什么时候发三方啊，你对薪资的企望是什么啊？”
“不能实习，不知道…”
“…你们北邮的同学应该消息很灵通吧”
“…”
时间再回退几天，被HR姐姐请到公司外的座椅处，隔着窗子能看到公司里忙碌的人群。
HR姐姐气场很强，咄咄逼人
“你是说你要请假几周做毕业论文喽？”
“…”
“你还有什么问题吗？”
我当时不知道为什么会说那样的话，之前的话，之后的话，话里的话，话外的话。
面试的人，被面试的人，所有人。
后来ztrix带着我面试时，我回想起从去年3月份，和各路面试官，HR和其它人谈笑风生的往事。
有一种豁然开朗的感觉。
原来如此。
人真是可怜的动物,
人真是可爱的动物。
黑客与画家
你问我每天的工作？我不是黑客，也不是画家，我就是工人。
工作在世界上最庞大最活跃的开放平台上。
没有什么比这个更简单，你想实现，需要实现的功能，你都能找到可参考、挺不错实现。
没有什么比这个更困难，你需要的，需要稳定的功能，你都找不到可靠的、标准的方法。
没有什么比这个更幸福，
也没有什么比这个更痛苦。
但问题的关键在于，企业需要你真的提供可靠的产品，还是仅仅需要:
不可维护，难以扩展，无法调试，充满问题的,用来忽悠的
不在乎质量的一次性代码
我希望长亭能选择维护产品质量，虽然无法保证这许多选择是明智的，长期的，巨大成本的。 但却是一个公司长远发展的基石，提供可靠、有效的产品。
这半年以来，长亭给了我稳定的环境、付出大量的成本培养一个入职时候什么都 不会的人成为一名熟悉业务的熟练前端工人。
但对公司来说，他的收益何在呢？
我们在构建产品UI的过程中付出了高昂的成本，时间，金钱。
长期的付出没有预期收益，是否还会相信一切都是值得的？
不会！
我始终在想这个问题，我不是艺术家，不是黑客，不是画家。
我只能试图在提高生产效率、节约时间、把控质量上做些努力。
而不是希望，一整天假装忙碌着不科学的事情，比如像某些傻逼996公司。
不过呢，今天被告知过一段要安排我去做前端之外的其它事情。
我表面上很淡定，心里却有了八成。
我在产品前端所付出的努力，看样子对公司确实没有太大意义。
真是可惜。
最起码，ztrix需要的前端和我在成为的前端，不太一样吧。
前端工程化
有几个概念我还想说一下，虽然也许对我自己、对公司没什么卵用。但也许对别人不是。
我还有很多想写的文章：如何写一个时间日期选择器，一个日期选择器，一个日期范围选择器，纯CSS语义友好的时间轴， 如何用webpack实现一个静态博客生成器，如何在webpack中结构化样式做主题切换效果等等。
ztrix当初说可能会有内部分享，然而…大家都很忙，大家也不是前端。
就前端开发的一些问题，来阐述我的观点。
显式优于隐式。
vue中，模板解析错误什么错误都不会抛出，只会给你留下一片空白。开发者作为人类，很可怜，总是会写错。 如果你觉得是开发者的问题。你知道table里能用的标签有限制，所以不能直接用template做子元素吗？ 你有过在属性中一不小心使用了双引号parse过程就莫名出错然而并没有任何错误信息吗？你把标签写错了，把标签的嵌套关系写错了，或者忘记闭合了 或者什么的。你总可以说这些都是傻逼才会犯的错误，可以说用无数工具可以做lint，然而我暂时没有特别好用的检查工具。 但如果不是模板，而是一种优秀的DSL，不仅拥有dom的全部表达能力，还更不容易出错， 因为语法错误会更容易被抛出。html可不是什么严格的语言。
另外，你知道vue的transition怎么工作的吗？你知道v-model怎么绑定的吗？大概只有踩过坑才知道。
样式组件化问题重重
vue的样式组件化设计追求简单，但是有缺陷。我这里仅仅针对webpack template来讲。 style中如果使用=scope=local=会是局部属性。按理说这个设计很好。
vue用一种聪明的方法实现了这个特性，=vue-loader=会对=template=和=scope=部分进行重写，给所有template标签加上一个哈希属性，然后在css规则也加上这个属性。 这样属性就是局部的了。然而，问题是，并不能确保你不会用某些第三方库比如d3动态生成DOM，虽然在MVVM框架中应该尽量避免操作DOM。
这不算什么问题，问题在于，所有现有的css工具，都不是为这个设计的。
比如当生产模式压缩css时候，比如按media-query打包规则，需要同时对所有样式进行打包，但是，vue-loader对postcss的调用是针对单个vue文件的…
再比如less-loader，less有一套自己的继承方式，根本不对webpack对js打包那套理论胃口。虽然有了webpack什么都可以用js打包，但是，css的层叠性就失去了。
所以，更好的生产环境样式处理方式可能是，用webpack-extract-plugin抽取样式之后在进行css优化。
另一方面，我看到css-module，elm-css等作出的一些尝试，终于我几乎放弃了vue的样式组件化方法。
关于长亭某产品的样式组织么。
当公司业务需要支持多主题皮肤的时候，我开始尝试学习semantic ui的方式分层次和主题组织bootstrap的样式文件。结果发现，less的build真慢，不过样式可以单独构建。
一个没有安全感的语言
在vue中计算属性会悄无声息吞下任何异常。这也许是可以接受的，因为计算属性异常并不会整个页面的js彻底挂掉。
但一言不合就让页面彻底挂掉的js并非天方夜谭。事实上，经常发生。
在undefined上取值的时候，使用了非标准的方法的时候，一不小心除0的时候，引用消失的DOM节点的时候等等等等。 问题在于这些问题，你根本 无法完全 避免运行时错误。而你也很难在最外层=try catch=或者在哪里都先判断一下数据类型。
在js日趋工程化的今天，终于有越来越多的企业认识到强类型的必要性。typescript、flow等开始介入javascript生态， elm，bucklescript，ghcjs，purescript等开始带来新的可能带来新的可能带来新的可能。
但，作为一个最大的社区，一个出处run time error的javascript真是惨
不过vue中你爱用啥用啥，但vue是偏爱纯js的。
我写了一点elm后，几乎再也无法面对js了, coffee哪种满天语法糖的语言更不能…
程序内依赖关系
我们可以用webpack处理模块间的依赖关系。
可以用组件模型，事件模型，vuex什么的处理组件间的依赖关系
那组件内呢？JS流行面向对象编程，一定程度上确实有好处，但是。。。
方法和状态间复杂的依赖关系缺乏有效的管理，结果就是，vue的方法并不接受任何参数而是 疯狂地对this进行操作，一大堆方法、计算属性、props、事件传来的、请求请来的东西强烈耦合在一起。 这种软件质量无从保证。
目前来看，redux/vuex那一套或者更进一步说elm那一套，应该是UI编程更科学的实践。 避免组件内冗杂的依赖关系非常必要，是保证可扩展性、可维护性，也就是维护产品质量的关键。
权衡
最大的问题，实际上却在于权衡。我渐渐发现没有完美的解决方案，却很难辨认一个方案是否真的适合业务。
我所做的努力是否真的是必要的吗？
在开发样式切换功能的时候，我一开始想到的是直接用webpack的style-loader实现。将css嵌入到js中。
但这样一来，js文件变得快2M了都。
pandada8说我们是内网环境，那么并不在乎js文件大小。
但我终于还是花了大量时间和精力去理解所有用到的库，理解webpack如何打包，样式如何分离，如何做异步加载。
将首次js压缩到了570k左右，并且可以和样式并行下载
这一切是值得的吗？说不值得，确实没啥用。说值得，项目组织更好更易扩展和修改了。
然而这一切，对整个公司的业务，有大的影响吗。我是否会因为项目组织不好而在修改时花更多精力呢？
谁他妈知道。
我觉得这不是一次性项目就值得不断的重构重构…
我引入一个库的时候会想很多，我们项目引入了d3，算上前期先见之明的学习和绘图确实花了很大精力。
图表有很多bug，界面不尽如人意等等
ztrix说过，我们现在需要快速的时候，你选用d3自己画图就比较失误。
然而我不认同，我说，我可以直接用echarts什么的，但做出同样的效果，估计根本就做不出来。
后来，另一个项目，p8大概也是对我徒手造轮效果还不好的情况害怕了，专门还提醒另一个前端不要自己造轮子，用一些现成的库。
随着业务和需求的变化，我渐渐意识到，d3对我是一个可以控制的，也许比较明智的选择。
可视化是个复杂的领域。
你要做得权衡是，究竟是选择看似困难，但通过显式的、广泛使用的程序(DSL)来构建这个可视化界面。 还是使用看似简单，通过大量冗杂配置来达到同样的效果？
我并无法说哪种更合适，这真是权衡。不是所有坚持都能换来结果，你也不一定能做到同样的效果。
我以前写代码求快，常常不想太多，有点头绪就开始做。
这样很对啊，不然也不会写出这么多有意思的垃圾。
但现在更多在想如何维护整个工程的质量，
经常会有些莫名奇妙的需求，大家都不知道怎么设计才好。但需求看起来挺别扭。
找你的人说，先这样上线吧。你是先管他三七二十一就先上线，还是，所以你会怎么做呢，你也不知道情况下？
实际工作挺蛋疼的，天天感慨。有次萌神在我旁边抱怨了两句，我幸灾乐祸，我还以为就我一个这么蛋疼。
ztrix说，大家都很蛋疼。
我觉得也是，看看代码的注释就明白了。
结语
在公司半年，默默看着它追寻、扩大，作出各种决定和取舍。
看着它。
所面临的压力是飞升的弹力，也是束缚的重力。
权衡取舍间，你的眼光会望向哪里呢。
我都将看见。
愿接纳我的贵司，用心看穿未来，幸运地继续前进吧。
不知不觉已经深夜，明天上班还有好多坑要填，MD。
历史总是惊人的相似。
