作为技术人，每半年都应该进行一次自我反思或者总结，回过头来看看这半年自己成长了多少和自己有哪些需要改进的。因为才来公司三个月时间，我就直接总结一下我这半年自己技术能力的发展经历和在工作上的经历，教训。
一.技术的成长
2018年上半年的技术浪潮中给我最大体会就是大前端的真正到来，事实上大前端在2016年的时候已经有这个概念了，从RN，weex 这些前端框架来开发移动应用直到小程序的大放异彩，身边一部分 iOS 开发也逐渐开发转写 JavaScript 了，让我觉得大前端真正的来了，很难再单纯的抱着一门iOS技术能够坚信未来不会被淘汰，周围的一些朋友也有出现焦虑的，说实话，我也焦虑过，担心自己的技术会在浪潮中像当年的诺基亚塞班系统一样被淘汰。后来一位前端大神跟我说到，“技术就需要时刻的跟着，前端如果几个月不跟新技术，看到新技术可能会陌生。如果守着老技术几年不变，可能再了解新技术的时候，前端框架已经换了新天地了。” 后来想想语气这样不断的担心焦虑 ，不如多去了解多去学习。但是毕竟很少有人能保证每天有大块的时间都在学习新技术，除去完成公司的工作以外，加上可能的加班时间，人回家也会疲劳，也需要休息。每天都有大块的时间用来学习新技术的时间也就不是很多。
于是，我一直思考着如何能在工作之外的业余时间能够高效的学习，以下是我的总结
在技术的不断更迭变化过程中，如果一味的跟新技术，那是否想过，追随新技术的到底是为了什么？以我个人的经验总结需要注意的一点就是不要盲目追随新技术，一味地盲目追随不去自己独立思考什么样的技术适合当前的工作和自己，无法转化自己成果的技术，只会导致最终沦为技术的奴隶， 学习永远没有错，错的是选择了低效耗时耗精力的前进方向。我的总结还是优先学习公司项目里面用到的知识，深挖业务上技术痛点。有多余的时间再去横向了解其他的。和 T 型人才一样，先专一门，再扩宽广度。为何高效？利用公司真实的项目锻炼自己，真的学习特别高效。每天项目中遇到的问题，上下班在地铁上都会很有目的的在网上查询解决办法。学习目的非常明确。 但是如果没有公司实际的项目让你练手，怎么办？可以在业余时间制定一份计划，每天结合着开源的框架和demo直接开始做，以学习小程序 为例子，我自己加了一些小程序开发群，发现很多常问的问题是：“我想上手小程序，需要先学啥语言，先学习html css js吗？小程序是用js开发吗？那我是不是要去先学js？想上手学小程序，需要什么知识储备吗？”我的看法是，直接开干啊!遇到啥问题再具体查啥问题。我个人觉得为了打算学个新东西（注意是’新’东西），然后就问一下有啥经典书籍么？先抱着一本16开，三四厘米厚的一本大厚书，（我习惯叫砖书，很厚很大砸人很疼），看个好几天一个礼拜的，然后还没上手。或者听到个新东西技术是html，然后美名其曰技术储备，俩仨礼拜略微看明白点html，css，但也毫无实战经验，俩仨礼拜，连小程序的边都没摸到。直接上手网上的demo项目是最快的，虽然刚开始不是很懂，但是有源码，官方文档，博客，官方论坛下，这些是最好的指导方案，遇到不大懂的直接上网查，网上及时阅读最新的碎片化博客文章，这些绝对是最快的学习和了解’新’东西的手段。我个人感觉光读光看是绝对没用的，最有效最有效的手段是，直接上手，上项目，哪怕是仿写一些开放API接口的app（知乎日报，豆瓣电影，有太多开放提供服务器api，让广大客户端开发者练手的）。
二 .工作上的经历和反思
在公司经历一个完整小版本的迭代，反思一下自身，首先没有做Code Review，之前在51的时候基本上一个模块其实是两个人负责，一个是主工程，一个Code Review 的，在他正式提测之前，Review者需要花点时间看他的代码，一个帮忙找出他代码的错误和优化代码互相学习，还有一个是通过验证程序设计了解她的业务模块。但是在这边直接放松要求了，沉浸在舒适区里，团队意识薄弱了，以后需要改正，加强Code Review习惯。还有觉得沟通层面自己的不足，一定需要面对badcase，唱黑脸，提要求，对产品一定要严格要求按照文档上来，新增需求一定要写在文档上，不然后期沟通成本太大。经历了一个小版本的迭代，自身的成长也是有很多的，因为业务的性质，bug reopen 没有作为考核的一部分，对自身的代码要求更高了，感觉到有个合理的kpi考核标准，对自身也能成长很多。
