苦逼并快乐着——我的2017年总结

前阵子出去玩了一趟,回来思衬着年度总结还没写,就过来补了。

回看,在ZStack待了1年多,从30多人到团队到近百人团队,从A轮前到B轮展望——有好有坏,尽收眼里。一句话概括:我肥了,也变强了。

接下来说说今年我在工作中意识到的一些事情吧——可能说起来是有点平淡无奇。

来自工作的意识

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

今年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技术人员可能有总人数的一半。早期在人数较少的时候沟通成本极低,喊一声大家就全知道了。但在人数多起来以后是很能做到“全局一致性”的,比如:

  • 有些人并不知道这件事发生了、某些规则改变了,所以他还是用之前的方法在做这件事,可能会做错、或者相对很慢。
  • 如果通过开会来解决这种问题,一些团队的关键人物真正的产出时间可能会减少,都是在开会sync状态。

再者就是管理上的问题,人数多起来以后管理难度并不是线性增长的。这里面有很多需要细细思考的,介于篇幅,以后有机会的话我想详细讲一讲。

最后是效率——大公司的通病就是瞎忙活,大家看着很忙,其实产出都很少,最后就会变成一只行动缓慢的巨兽。而小公司的优势就体现在行动灵活上,然在流程及生产力、生产工具落后的情况下优先考虑堆人,如果收益是线性对数增长,恐怕成本(时间+金钱)就是线性增长了。

学习

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

就是这样。

相关文章
相关标签/搜索