再见2016，我在腾讯这一年
再过几天，就是入职腾讯一周年的日子了。现在想想，过去的这一年，我觉得自己是幸运的。
16年一月，将近过年的时候，义无反顾的离开了上一家公司。那是我个人整个动荡的15年的结束。这一年我在这里呆的安心，有收获、有成长。如果说之前的两年多时间我是在安心学技术，那么这一年更多的是学习如何做事情。
到深圳之前，我并没有接触过项目管理、开发周期这些概念；而到腾讯之前，我对每周迭代这件事情也是完全没有概念的，这真的很快，太快了，以至于需求从拿到手上到成型你都可能还没有时间好好消化它，一开始我很难相信这种迭代速度能打造出精品。刚入职的那段时间确实很慌乱，我挺害怕自己之前那种慢工出细活的那种做事方式没办法太好的展现出自己的优势。实际上这在上半年也确实成了掣肘的毛病。而我的另外一个问题是我始终不太愿意做重复的事情。所以在很长一段时间中，我一直抓住的是另外一条线：运维。我觉得这是能带我融入项目和环境的途径。
从我工作以来，一直都是 PHP 和运维双线发展的（也许我离开上一家公司也有一个原因是他们不愿意让我碰服务器吧）。从熟悉业务机器的部署到管理和调整，然后再去了解项目本身的模块和代码问题，也算是找到了自己的一个熟悉整个项目架构的途径。
下半年花了很大的力气去改变一些既有的结构，我把自己的想法和风格带入到了项目中。我们对服务器的结构做了很大的调整，从原来一致性的环境分割成按照不同模块划分独立运行的环境，对环境的配置也做了很大的调整。中间也不完全是一帆风顺的，也出过一些小的问题，但都及时调整，也算是安稳度过。业务代码上，随着 Composer 加入项目，一些组件和模块逐渐取代了原来的一些意大利面条式代码。虽然这一块儿改的不算彻底，但也比原来好多了。
过程不必一一细表，还是总结一下收获吧。
对项目和产品的理解：
- 一个需求投入时间的多少不是取决于把它做到完美需要多少时间，而是它会带来的收益值多少时间；
- 投入时间的性价比也是你可以拒绝某些需求的理由；
- 一个产品在市场的认可程度不是取决于用户看不见的技术实现是否优雅，用户只看表象，有时候还是因为出现的时间；
- 技术的最终都是服务于需求，不要用技术的理由来拒绝需求，如果两者有冲突，可以试着调整一下，尽管有时候你会有『f**k，这事儿还能这么干』的感叹；
- 技术的在某些时候对产品的意见未必没有产品专业，有的时候，技术能直击事情的本质；
- 不要拒绝沟通，解决问题永远是第一位的，哪怕不得不做出一些妥协。
技术上的一些进步：
- 花了一个月左右的时间掌握了下 docker 的基本用法，并且实践在了项目上（非我自己操作）；
- 花了一些时间在 PHP 源码调试的学习上，也能自己动手改造一下业务用的 PHP 扩展；
- 在公司环境限制的条件下对改善运维操作做了一些尝试，节省了一些体力；
- 丰富了自己的技术栈认识，包括 日志收集、ELK、自动化测试、持续集成等，但有些还没有应用到实践上；
- 从尝试中学会了将自己熟悉的技术栈带入项目中的方法；
- 对大公司（当然是腾讯）的技术栈有了一定的认知，解决了一些以往的困惑。
以上项目和产品上的理解未必完全正确，只是自己的认知，也有可能随着时间的推移而产生调整。而技术上的事情，我只能说：学习永不止步。以下是一些 2016 做的不好地方以及 2017 希望去了解的地方：
- 过去的一年看书太少，给自己的理由是私下的时间太少，2017 还是希望补足，多看书；
- 应该尝试写一些业务上成熟且有示范效应的代码；
- 尝试写一些成体系的文章，运营一个公众号试试？
- 也去跟风了解一下人工智能，从 TensorFlow 开始？
感谢过去的一年，从可见的成果上看，小小的升了级，并且有了一个继续升级的机会，摘下一颗四星。希望 2017 会更好。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
