自动化测试是最好的保证手段之一

今年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乃至更后，作为一名程序员还从事在项目型公司（即外包公司），平均待遇相比别的行业肯定会低一些，这在相同的工作年限及大样本看来即是如此。同样，不同的类型的公司有不同高低的瓶颈。堆人堆到了一定程度，收益和成本便不再是正比成长。而且上面也提到了，人多了管理并不好做。

最后再说学习

我看了看去年的年度总结中定的学习目标，约有一半是完成的，然而额外也收获了很多——有些是应该被列入计划内的，有些则是性子来了顺便就上手开始了。这应了那句话——计划赶不上变化。我将不再制定一些详细的计划，不过，前进还是永恒的主题。

苦逼并思考着——我的2017年总结

就是这样。

附上今年看到的一些好文（当然和文章主题相关）：