记录一些简短的东西，这些东西作为单独的一篇内容太单薄，但是放弃又太可惜，收录在这里。
前端圈子，甚至是码农圈子里，有个怪现象：一个项目成功，就总会有一群人追着问/宣传“用XXX（语言/框架/库）做的”。仿佛一个项目的成功并不是它自身的成功，而是XXX（语言/框架/库）的成功似的。
---- 司徒正美(2015.10.08 10:16)
model: 模型，MVC 的数据部分
module: 模块，一个项目的拆分单元
三种职位的人工作中会有重叠。高工与上下都有重叠，努力与上面的重合多一点，这会带来两个好处：更快的进入上一层，更好的完成本层工作。高工用最少的时间进入上一层不一定是好事，大公司的 CTO 和小公司的 CTO 在职责和收益上会差很多，而且小公司的 CTO 或 项目 Leader 进入大公司甚至会降为高工，如果在做管理的时候把技术放下了(至少管理会占用你一部分研究技术的时间)那么回头再来写代码与一直代码为主相比就有点走弯路了，更可悲的是小公司 CTO 想要升级为大公司 CTO，降级再升级基本是一条必经之路。如果你的目标不太高，没有年薪百万的梦想，或者想投机，没有打算在技术这条路上走很长久，高工直接转总监收入上会有很大的提升。
再说说码农，码农是在高工的工作成果上完成总监下达的任务。大多数小公司没有高工，比新手做东西干活儿快一点靠谱一点大部分时间在写业务相关代码的人我认为不能称之为高工。对成本和收益的权衡成为多数小公司和大公司的很多部门放弃独立拥有高工的决策。但是码农工作需要在高工的成果上进行，否则回到刀耕火种的开发模式效率和质量实在太低。其实码工用的高工成果很大程度上是相同的，从 IDE 和 SVN 这些基础工具 到 Gulp 和 Webpack 这些工程化工具 再到 Angular 和 Bootstrap 这些好用的框架和库。这些通用技术能满足企业发展初期的大部分需求，当企业发展到一定程度和规模，就要逼迫码农升级为高工了，将社会上其他高工的东西进行定制化的整合，工具自身的业务需求可能还需要一些创造。所以码农在使用这些高工成果时要研究的透彻一些，任何一个工具都有优缺点，学会那些有点能让你事半功倍，记住那些缺点能减少你的掉坑次数。多积累一些东西，观千剑而后识器，然匠者造器。
至于总监，我还没做到那个位置，这里不敢妄言...
想到一些词句对应这三个职位：
总监的收入在别人看来已经很不菲了，但是毕竟公司不是自己的，招人管人选技术方向，一切的所作所为都是为了别人的目标而努力。与老板和股东比起来，总监的收入真是太微不足道了，但是就是这点与整个公司的收益相比微不足道的这一部分足以支撑很多家庭的富足生活。所以还是乐观一点吧，虽然你成就了别人，但别人也不是成就了你吗，生活还得向上蹦跶，加油！
---- 清明节加班有感(2016.04.03 23:50)
呆伯特法则（Dilbert's Law）意指 1990 年代一个讽刺意味的观察，认为公司都倾向有系统地把工作能力最差的员工提升到管理层，以把他们能对公司造成的损害减至最低。
is 开头，表示布尔设置on 开头，表示事件的回调函数before 和 after 表示事件执行前后，这时你有可能需要覆写默认事件，注意提供默认事件本身和参数其实相对于规范、脚手架、公共组件落地后对团队开发效率的提升，我更关注这些事情一步一步落地的过程，并且团队的每个人都能参与其中，以此了解为什么要做这些事情！为什么最终如此制定！了解如何参与大团队协作开发中的版本管理、开发流程和 review 机制！另外，架构师绝不是闷头帮你把基础设施建设完毕的人，而应该是提供思路制定规范推动大家一起做技术演进的那群人，想好一个角色的定位很重要。
---- 芋头微博(2016.08.01)
反对无条件无限度加班，反对用加班粉饰决策流程上出的问题。
按时上线就万事大吉，产生加班的原因是不是应该事后总结一下，是工时估的有问题，是开发者上班看新闻了，还是某位开发者工作没做到位影响了其他人的进度，还是领导拍的上线时间不加班就不可能完成。
没人愿意被动加班，被动加班也是一种意外，影响工程质量，影响团队稳定。
每次出现被动加班我都希望项目的所有参与者自审一下，造成加班的原因究竟是什么，下次能否不加班顺利完成项目。
在职业发展中不管是公司晋升还是提高江湖地位，选择一个好的项目 --- 给要做的项目一个好的定位实在是太重要了，这几年做残过几个项目，总结几点吧：
大众产品：分清人和机器擅长的部分，用程序把它们分开；
辅助产品：分清程序和程序员擅长的部分，给程序员留出的空间宁多勿少；
---- 有感于多模版 ipage 报表平台(2016.08.01)
主动给排期可以掌握主动优势，自己先有一份 todo 清单自己心理上会自信不焦虑，给别人也是一种靠谱的感觉。
---- 有感于多模版迭代总结会(2016.11.24)
留出 20% 的时间做一些探索性的事情，经理支持找一些项目来作为新技术的探索，这可能是百度的技术还被外面认可的原因。百度这家公司的技术基因表现出的外在作用让行业得到了认可。
---- 有感于前端技术分享会(2016.11.24)
世间存在这么一种轮子：“我实现你一个子集，我比你小，我厉害”，“更轻量级，某某库核心功能定制版”。早先年网络环境不太好没有包管理工具的年代这种轮子确实有一定的存在价值，现在的一种比较好的设计是只提供核心功能，周边功能通过插件来实现，这是一种减法。如果我只有核心，那么新轮子不可能比这个更小(或者做到比当前库小很多比较困难)。也是一种加法，通过插件的形式拥有无限多的功能，从而形成一种生态很难被颠覆。
---- 2017.05.16
为什么要撕逼？首先现在的工作方式是合作，不是员工给老板打工。如果老板对技术不太看重很可能会做出错误的决策，作为技术人员有必要从专业角度提一些意见。因为公司的成败与我们自己相关，技术方案的使用与我们的职业发展相关，在一家公司待 3 年的收获不能只是 36 个月的工资，要做出能拿的出手的产品，要获得能够升职加薪的技能。如果老板阻碍了我们的目标，那只能愤而开撕了，下面是自己总结的几点经验，撕逼要有大局观才能撕的赢：
用户整体体验：为了一小部分用户降低整体体验是不明智的，点：浏览器统计数据，动画流畅度，CSS3等；
公司战略：产品是想原地不动还是想越来越好，支持IE7会对产品产生局限，现在竞争这么激烈你给我们发放大刀长矛怎么和人家的机关枪干仗；
技术团队：如果我们用老技术，技术团队招不到牛人，留不下优秀的人，一堆烂人还能指望做出什么好产品；
开发成本：开发效率低，开源界不再提供技术支持，框架层面的 bug 都要自己修。
---- 面对微信群的抱怨给出的反击策略(2017.10.11)
最近接手了一个比较复杂的项目，项目的复杂点在于之前是各部门分别开发的，现在要做统一的战略调整，但是其他团队人员不足，需要我们出人在其他团队的基础上开发，而他们用的前端技术框架各不相同。然后苏先生就抛出这么个话题 -- “你说说前端框架为什么越来越复杂”。直接来复述苏先生的话：软件最开始是 CS 架构模式，这种模式的弱势是 UI 控制比较弱，当然也发展出一些解决方案(Swing/SWT)，但是还没发展成熟就被 BS 架构模式颠覆了，Java Web 大行其道，JSP 拼页面可是当时最盛行的技术，然后是 Web 2.0 的出现主要是为了解决操作的时候不断刷页面的不友好体验，但是有一个问题依然没有很好的解决，那就是“前端组件组件化”，尤其面临前后端耦合太重的问题，于是随着以 V8 和 NodeJS 为根基的一批框架和工具的出现，前端进入组件化时代，但是现在还不成熟，不成熟主要表现在两个方面，第一整个基础设施还不完善，需要很多工具来弥合这些缺陷(比如有的浏览器不支持ES6需要babel，不支持模块化需要 webpack)，第二是没有一个有明显优势的方案胜出来一统天下。
--- 来自和互联网10多年从业老兵苏威的早餐聊天(2017.12.27)
苏先生的Hi上有一句签名：实施必须敏捷，方案不能敏捷。
软件构建的核心就是控制复杂度。
--- 代码大全(2018.01.11)
联调就是后端不好好写单元测试与集成测试，让前端发请求调用以达到测试的目的；前端不好好写Mock和测试，让后端输出数据以达到测试的目的。
联调是前后端一起见证靠谱的测试结果，尽早暴露前后端实现的问题。