前阵子出去玩了一趟，回来思衬着年度总结还没写，就过来补了。
回看，在ZStack待了1年多，从30多人到团队到近百人团队，从A轮前到B轮展望——有好有坏，尽收眼里。一句话概括：我肥了，也变强了。
今年在内部GitLab的Activity记录（六月的时候我们从GitHub上切到了GitLab）：
接下来说说今年我在工作中意识到的一些事情吧——可能说起来是有点平淡无奇。
自动化测试是最好的保证手段之一
今年2月的时候，ZStack的bug累积到了一定程度。之前的自动化测试框架并不完美，因难写、跑的慢等原因而坐着冷板凳。
然后便是老板写出了新的测试框架，之后一声令下，大家开始了没天没地fix bug。利用新的intergration test，有效的固化了战果。使原有代码处于较为稳定的状态，才开始快速的feature迭代。那是1.10的版本。
之后是2.0 UI，使用了新的框架vuejs。踩了很多坑，最可怕的是在写的时候没有考虑到怎么去测，致使后来前端一直是开发组的心头大患。测试团队的大量资源也耗损在上面。如果有自动化测试cover，完全可以省很多资源。
我之前的创业小伙伴也向我咨询过如何保证bug不regression。我的答案是：写自动化测试。
- 今天你写了A模块，并且手动测试了A模块的10个功能...
- 明天你写了B模块，并且手动测试了B模块的20个功能和A模块的10个功能...
- 明天你写了B模块，并且手动测试了C模块的40个功能和B模块的20个功能还有A模块的10个功能...
- ....
似乎听起来并不现实。这些活只能交给自动化测试——让机器来保证你的功能点是否出现了问题。
编写可扩展的代码——架构之美
小伙伴还和我提到过，项目的迭代速度到一定程度上会变得非常慢。要不就是改一点点就触发bug。
那个时候我就开始思考了，对比我现在所在的ZStack，为什么项目迭代可以这么快？
我翻了很多相关的书籍，也看了一些技术分享。最后还是回到了平时自己较为熟悉的ZStack中探索架构的秘密。故而，我写了一个系列的文章ZStack博文，其中ZStack源码剖析：如何在百万行代码中快速迭代有所提到，之后还会更新上来一些相关文章。不得不说，ZStack是我目前碰到过的大项目里代码质量较高的一个。
编写可维护的代码——Clean Code与重构
除了架构，还有代码整洁之道和敢于重构。
代码整洁有利于后面人的维护，减少潜在的人力成本，在此基础上产生的代码将会更加的稳定。
而ZStack本身是一个开源的软件项目，因此对代码质量要求是偏高的。每一行代码的输出都是经过Review的。
重构则是一门艺术，在测试覆盖率较高的情况下，我们可以尽情的重构，就像艺术家在他的画布上尽情创作一般。同样，这也是为了代码整洁。
再之就是面向接口编程，我在关于设计模式有略提到。
以上三点我在学生时代就有所耳闻，但却没有做过较为完全的实践。就现在看来，这些技巧在项目的快速迭代中蕴含着巨大的威力。
团队、管理与沟通还有效率
我之前工作待过的技术团队人数一般都是较少的，而目前在ZStack技术人员可能有总人数的一半。早期在人数较少的时候沟通成本极低，喊一声大家就全知道了。但在人数多起来以后是很能做到“全局一致性”的，比如：
- 有些人并不知道这件事发生了、某些规则改变了，所以他还是用之前的方法在做这件事，可能会做错、或者相对很慢。
- 如果通过开会来解决这种问题，一些团队的关键人物真正的产出时间可能会减少，都是在开会sync状态。
再者就是管理上的问题，人数多起来以后管理难度并不是线性增长的。这里面有很多需要细细思考的，介于篇幅，以后有机会的话我想详细讲一讲。
最后是效率——大公司的通病就是瞎忙活，大家看着很忙，其实产出都很少，最后就会变成一只行动缓慢的巨兽。而小公司的优势就体现在行动灵活上，然在流程及生产力、生产工具落后的情况下优先考虑堆人，如果收益是线性对数增长，恐怕成本（时间+金钱）就是线性增长了。
行业的重要性
之前提到了成本和收益。这和所在行业也有很大的关系，如果在2018乃至更后，作为一名程序员还从事在项目型公司（即外包公司），平均待遇相比别的行业肯定会低一些，这在相同的工作年限及大样本看来即是如此。同样，不同的类型的公司有不同高低的瓶颈。堆人堆到了一定程度，收益和成本便不再是正比成长。而且上面也提到了，人多了管理并不好做。
最后再说学习
我看了看去年的年度总结中定的学习目标，约有一半是完成的，然而额外也收获了很多——有些是应该被列入计划内的，有些则是性子来了顺便就上手开始了。这应了那句话——计划赶不上变化。我将不再制定一些详细的计划，不过，前进还是永恒的主题。
就是这样。
附上今年看到的一些好文（当然和文章主题相关）：
