最近被问到对一些对技术的理解，虽说很多时候自己感觉对技术选择有自己的理解，知道背后的原因，但还是不大能说的上来。这儿就总结一下对所经历的一些技术的理解吧。谈到理解，总免不了介绍技术出现的原因，解决的问题，可能的方案以及未来的可能的形态。比如，不少人认为前端玩的一些概念是在后端存在很久的东西，这个现象也确实存在。虽然 web 技术诞生有一定的年头了，不过就前端而言，可能要在 2005 年之后 Ajax 出现之后以及 SPA 成为趋势之后，才算是真正的开始发展。JS 和 CSS 存在的问题也才逐渐的突出起来。
平常开发中，你花多少时间写测试？覆盖率有多少？除了单元测试，其它的整合测试以及 UI 测试有实践么？
以我个人经历来说，在国内工作时几乎不写任何测试，仅限于倒腾过测试。即使阿里这样的大公司，业务部门也几乎不写任何测试，基础研发部门或许很有节操，具体情况不得而知不好瞎猜。为什么不写测试，这跟整体的氛围有关，真有人在意你的代码质量吗？没有！大家在意的是业务结果。原来的负责人升职加薪之后项目交给后面的人维护，如果新需求不多，代码还过得去维护着就行。需求实在太多，维护不下去了，那只能重写了（自动化测试都没有，谈不上重构）。
国内开发节奏太快，着急于抢占市场，不断试错，计划赶不上变化，这周加的功能下周都可能就要废掉。这种情况下，写测试完全得不偿失，自然也就不会花时间在写测试上了。那如何保证代码质量呢？一般在上线截止日期前，集中时间手动测试，或许有些公司将这些任务外包给其它公司来做，毕竟大多数的开发可不屑于干这么枯燥无聊的活。
现在就职的公司在测试上做的可谓非常专业。我们的 QA 团队会支持各个业务团队，QA 是质量辅助而非质量保证。这儿有个文章介绍质量保证与质量辅助。QA 的职责更多的是监督，指导我们来完成测试任务，而非自己测试。他们会收集各种数据，建立指标来评估代码质量。另外，也会帮助新团队或新项目建立自动化测试，指导新人完成测试工作。
再说说我的发布模式，我们的发布周期是每日发布，也就是说当你的代码合并到 master 时必须保证它是正确的。因为第二天固定时间就会部署到线上，部署之后自动化测试通过就认为部署成功。除了单元测试，我们还需要用 UI 测试覆盖到所有的关键路径，也即冒烟测试。冒烟测试只会测试整体流程，允许存在 bug 但不是严重的，不影响正常的流程即可。
一个潜在的 bug 发现的越早所需的修复成本越低。单元测试并不能保证万无一失，模块与模块之间功能是否匹配还需要整合测试来保证。现在的问题是我们为什么而测试，于是，在开发前我们列出所有的需求点来，以保证我们会用适当的测试来覆盖这些需求点。
最后，在后端和前端之间，我们加入了合约测试以保证后端的 API 变动不会影响到前端代码。
现在的趋势是，开发将承担运维和测试的工作，而运维和测试只做些支撑性的工作。某些大厂强制测试转开发，就我之前见到后端写前端的经验来看，除非是内驱的并且公司给予足够的时间来转，否则只是添乱。口号喊的很好，全栈工程师，简单易上手，但是只要不让我接手维护他们的代码随便他们怎么折腾都行。
说说发布周期，每日发布就必须要求开发对代码有信心任何时候合并进去就要能够部署，避免开发将测试责任推卸。缺点是用户不能很好的利用缓存，用户重新加载新资源却并没有任何新的可用功能。将任务切分很细只会带来更多的工作量，而开发分支上本来就不是直接可交付给用户的。个人来看，除非必要的 bug 修复，完全可以等到 Sprint 结束一起发布。
关于测试，我并不是认为测试写多了，代码质量就会变好。测试只应该是辅助，不应该为测试而改动代码的可读性或使得代码变得复杂。真有一个极端的同事，几乎所有的代码都是依赖注入，一个功能函数的参数是一个接口。比如，fetchUser() 依赖的 request 只是一个接口，你需要一层一层往上查看，才知道这个是如何实现的。
我知道这会让我的代码非常容易测试，但毫无疑问它让代码变得更复杂了。如果说好的架构师懂得如何权衡各种技术做出取舍，好的程序员一样也需要懂得取舍。测试的增加必然会拖累产品迭代的速度，有时我常会想，我现在增加的一个 UI 测试，真的以后这儿会做改动吗？或许那时交互的需求早就变了。我同样好奇这些测试到底帮助我们揪出了多少个潜在的重大 bug，是否值得我们的投入。
关于是否应该面向需求点检查覆盖率，我们也有不同的意见。个人不太认同，因为我们做单元测试很多时候是知道这个模块会被复用，其它人在使用这个模块时，如果需要改动，单元测试可以很好的保证其不被破坏。这个可复用的模块即使已经被整合测试覆盖到，也应该有对应的单元测试。整合测试并不能够帮助我们迅速定位问题，只是确保某一个功能是否完好。
对于测试，总的来说，它带来好处，但是也不是免费的。对可复用的模块，基本的单元测试是必需的，写单元测试也可以帮助你发现代码异味。关键路径的冒烟测试也是有必要的，至少确实会减少人工成本。业务逻辑代码因情况而定，非关键功能且你认为是一次开发即可的，你老板也不会让你投入这么多时间写测试的。如果你没有写过测试，开始尝试用单元测试覆盖你的可复用模块，尝试写些 E2E 测试减少重复劳动吧（E2E 测试远并没有你所想的复杂）。
若说编程能力，涉及的方方面面太多，这儿只谈谈写代码。
你可能也有发现，有些课程优秀的同学代码写的并不优雅，甚至在大公司工作几年的人代码写的也可能不堪入目。或许不难理解，在学校的学习的计算机知识与编码能力没有太大关系。我们说代码写的好，往往说的是整洁，清晰，易于维护扩展。
如果不清楚自己编码的水平，可以尝试一下这个挑战：给你两个小时让你实现一个类似 1024 的游戏。要求不依赖任何库，当然可以使用工具和 IDE。
如果你没有尝试做过类似的事情，不妨现在试一下，回头再读这个文章。
在你做完之后与 Github-2048 上的实现比较一下，看看有哪些收获。
我经历的一些实际项目中，充斥着大量的反模式和代码异味。我们花了很多时间去清理那些技术债务。依据我的经验来看，里面的错误做法非常普遍。
React.js 简单，但是简单并不代表容易。某个框架上手容易，其实也意味着挖坑容易。在真正的将新技术在业务项目中铺开之前，一定要多调研，多参考优秀的实践。
当你用 React.js 堆业务时，思考一下创建的组件是否符合面向对象的基本原则，新手是否能够通过你暴露的属性猜出这个组件的功能。
在你写代码时，哪些原则是你一直遵循的？如果有人指出你的代码中违背了某一原则，你是否能够解释个所以然来。
个人以为提升编程能力的方法有：
推荐阅读《代码整洁之道》《代码大全》《重构》等经典书籍
大量阅读源码
Code Review（自己先 Review 一遍）
在刚毕业的时候，我也和大多数人一样，心想自己不擅长与人打交道，比较适合一心搞技术（当然也挺羡慕那时的 leader 管几个人分分任务不再需要写代码）。
最初也确实是这样子，花比较多的时间在技术上。现在看来，对于新人来说这依然是第一优先级的事情。
对于刚从学校出来的学生来说，最为推荐的书是《程序员修炼之道-从小工到专家》。不只是技术，这本书还会涉及到效率工具，保持学习，团结交流以及推动变化。因为并非每个人在刚毕业的时候都有一个靠谱的人领路，这本书可以让你少走一些弯路。
在之后工作中渐渐发现有些软实力要比技术更为重要，有时新技术的学习能给你带来的收益远不如这些能力的提升。下面只是个人想到的一些点：
效率
在你可以独立承担一个项目的时候，你会留意与其它人的差距，同样的项目交给你，你是否可以做的又快又好。这可能取决于你对工具使用的熟练程度以及是否有能力开发工具减少你的重复劳动。建议保持学习；最近才发现 ssh 到远程服务器使用 Iterm2 设置之后一个快捷键就可以开始工作了。
业务
在阿里巴巴，不是技术说的算，更多的是业务。技术也只有在创造了价值的时候才有用，不管是绩效评审还是晋升。每个人都会去思考业务中的痛点，尝试去解决这些问题。很多时候，这些痛点不是你一个人能够解决掉的，很可能涉及到各个方面。这又取决于你是否能够调动足够多资源以及推动其他人解决这个痛点。
有人说，在腾讯你能做成一件事要看你能够调动多少资源。
影响他人
现在让你说出你身边三个优秀的程序员，你会选谁？然后回想一下他们的共同点。你选他们是因为他们代码写的很溜吗？很可能不是。
勇于担当，照顾新人（乐意分享和帮助），谦逊（让你感受到被尊重）
你也想成为受欢迎的人？有本叫《How to make friends and influence people》我猜你早就读过中文版《人性的弱点》
管理
你有思考过，站在管理者的角度，他们对你的期望和你自己在做的事情是否匹配，当你有些新想法时，能否争取到他们的支持？或者站在公司角度思考，你在做的事情和公司的目标是否匹配？如果你和老大的关系很好，一切会好说，即使你不大欣赏你的管理者，保持一个定期的沟通以及定期的反馈也是必要的。我个人非常喜欢双周一次的与 Manager 的 1:1 会议。
所以，对有一定工作经验的人，我一定会推荐读几本管理类的书。比如《Make yourself indispensable》
企业文化
当你思考一家公司为什么能够成功时，你会发现可能有很多的因素，它可能在某些方面做的不是很好，但不足以致命。而公司失败一个致命的错误足矣。
公司大的时候价值观能够很好的发挥作用，比如阿里巴巴的人才观：聪明，皮实，乐观，自省。直接就筛选掉那些整日抱怨而不行动的人。
如果你发现什么做的不够好的地方，那不是正是你要努力推动的吗？
个人
你有没有发现身边一些人做了 1 可是却吹成了 10，而你做了 1 结果说成了 0.5。 在你往上走的过程中表达能力也是急需提升的，包括讲故事的能力。
之所以这么强调软实力，是因为像大多数程序员一样我在最开始对这些东西并没有给予足够的重视，而且也没有一个清晰的路径来培养这些能力。这些只是自己碎片化的吸收以及从跌打爬滚的经验中学习得到的，或许如同大多数道理一样，听起来觉得老生常谈，但只有在自己切身经历之后，才慢慢理解。
与诸君共勉！
在每个前端项目中，多多少少都会依赖一些第三方资源，比如Query，React，Angular，core-js，babel-runtime；如果我们能够尽最大程度的复用这些资源，那么我们就能够节约很大的首次请求成本，无需绞尽脑汁即可显著提升首屏首次加载速度。另外提升 webpack 构建速度，扯这么多构建优化方案，就设置 externals 效果最显著；
对框架的使用者来说，谈一个框架的思想，其实不如谈谈它的最佳实践。就是同一个框架，不同的人实现相同的功能，代码也是千差万别。不同风格的实现自然也有高低之分，而往往这些东西还没有成文的规定，不知道坑了多少前端。这些框架还有另一个特点—–非常容易上手（入坑），从而埋下更深的祸患。这么简单！其实往往是不明所以的时候就开始挖坑了。
