2016

其实每年都会写总结,稀稀拉拉的可能写的不多,但大概元旦左右会写。今年事情太多,没来得及,但觉得还应该写一点东西。今年在(其实根本说不上)架构的地方做了一些事情,而且也和更多的人合作,有了很多新的东西,有不认同的,也有认同的,所以写一下总结和思考。

New

2016 年元旦之后,基本上就定了在 VIPKID 工作,然后着手重构约课。3 月份左右该项目不上线,停止了项目。在 4 月份左右着手开始搭建移动端的 Gateway,项目没有什么挑战。大概在 7 月份之后做了内部系统(管理端)的负责人,在架构、服务化方面进行了一些尝试。

虽然经过了一年的各种尝试,有成功的也有失败的,摸爬滚打也有一些感受。大概会从这些时间节点上来归纳。

Jedi

Jedi 是当时做约课重构的项目,那个时候主要是以主程序员的角色。负责产品项目的设计。主要工作是负责设计和评估算法、性能和程序结构方面的事情。这个阶段很难说和架构有什么关系,主要还是以写单元测试、产品逻辑、算法本身为主。目标也很明确,就是性能好。当然从今天来看,当时的性能可能依旧无法满足今天的要求,还是免不了迭代开发,会有些想得简单了。

大概在 3 月底的时候,团队讨论该项目改动面很大,于是结论是不上线。其实并没有什么心里波动,主要是一下子拼了很久一下子泄气了,需要调整。并且,当初进来的时候心气很高,也难免会反过来思考自身的问题。但那个时候很多人会想安慰我,不过很少有人知道我到底在想什么。砍项目不是很重要,重要的是如何做出改变。说来大概就是项目、组织和团队的问题。初次有了这种感觉,但是找不到头脑。

Gateway

在 Jedi 完成后,被调动做移动端的 Gateway。这个项目纯粹是小儿科,实在说不上有什么技术含量。当初还是以 Jedi 团队重建为主。最后发现这些人在该项目中产能过剩,能力是极大的浪费。从今天来看,当初这个团队去做更应急的事情也很正常。

我自己本身在这个团队中虽然说是 Leader 的定义,但这个时候已经逐渐将开发的事情交给别人。虽然我自己很想在一线编码,但是 Jedi 本身的事情让我学到了更多。可能我自己能比上几个人,但是要比上几十个人,是完全不可能的。并且还要让项目正常顺利的上线,代码质量也许是可以考虑妥协的。这一点和我之前想的和推崇的会有矛盾。但是哪里打折哪里不打折,很难一句话说明白。这时主要是自我的概念的重建。

所以这个时间段主要是读了大量的书,一方面由于接触代码的时间少了,由于程序员的危机感(大概是不学点什么东西就会落后),读了不少数学、计算机基础的书。从今天来看,也算是物有所值,确实学到了很多的东西,在今后做决定这件事情上,基础帮助了我很多东西。另一方面读了一些软技能方面的书,例如沟通、写作、管理等书。自己也去了一些公司学习,虽然说当时看不到有什么结果,但今天来说还算是有了很大的帮助。

Management

Gateway 团队产出很多,但是其实能看见的很少。其实想想看,这一年都在做技术团队的 Fireman。说实话,谁不是呢。大概在 6-7 月份的时候。管理端团队瓶颈凸显,临时被调到管理端负责技术。

说实话我自己当初是很拒绝带管理端的,一方面是自己还未从一个程序员真正的蜕变,思考方式还是代码质量、测试覆盖率、线上系统资源使用率等等。想到管理端项目的代码质量极差,前所未有,而测试难度又极高,业务的容忍率又很低,吃亏的肯定是技术,投入产出太低。后来没办法,实在是 找不到人选 只好让我硬顶着头皮来做。

一开始管理端主要的工作是接触业务,沟通和开会。虽然说会议效率极低,但是也让我学到了很多东西。7-8月份做了一次项目冲刺,有很多时候不回家。这个时候完全不接触代码,也不知道为什么选了我做项目经理。虽然从今天的结果来开,项目经理并不是很成功,但从个人角度还是学到了很多东西。

基本上,之前的时间管理和项目管理仅仅针对个人,而针对团队的很少。做了一些尝试,还挺成功。后来不做项目经理的时候,还能够运用到团队上。值得一提的是,团队现在已经完全能够自运行,再加上来了一些更好的人之后,团队本身的性格也逐步成型。

在团队成型的过程中,很多磨合和误会,虽然每天都想离职但最后还是扛下来了。不得不提的是,有很多时候大家以为我负责这个团队,其实这个团队也给了我很多能量。这个时候基本上不是完全从程序员的角度来思考,当然还有遗留很多扣细节的不好的习惯,只是更多的会从架构方面来思考。

架构这个词,大概是从这个时间点开始真正的理解。

Management Portal

我大概把 10 月份之后称作后管理端时代。10.1 我去拍婚纱照。海岛其实没什么可玩的,在酒店主要是在想团队管理方面的事情。那段时间和一些核心的团队成员聊的很多,主要是我们要做什么、技术上面有什么可扩展的、团队成员如何发展。那个时候没想好,其实最近回头看倒是可以看到当初的方向是对的,今天总结来看就是,学习型团队

这个阶段基本上我完全不参与写代码,主要在设计拆分管理端架构上,之前的项目代码很差,质量也很低,所有人包括开发和测试效率都很低,我主要解决开发效率的问题。第一步很难走,但是好在走出了第一步。Python 的服务化框架标准在那个时候基本上定好了,项目生成模板也同时完工。开发新项目变得越来越快,新项目效果也很好,例如 Followup。

第一个服务上线之后,很快就能够想象我们新面临的挑战。一个是业务项目时间紧迫,技术债太深,需要花时间和精力在业务无感知的情况下重写代码。这个时候很多决定很艰难,例如能不能重写,重写到什么地步,在服务架构体系下,这个服务在哪里,都是需要我们团队反复讨论的问题。与此同时,管理端团队 Gateway 的初步计划基本上已经确定,就差决心和开发。Java 这一块的服务也开始着手重构,leads dispatcher 在磨了两个月嘴皮之后,终于在业务的理解和踩坑之下着手启动,从今天来看,效果很好。当然,也有更多新的问题出现。

在这之后,新的项目开发的越来越快,代码质量提升得也非常高,于此同时,测试环境容器化也顺利使用。新人开发服务部署也更加顺利。自动化测试和持续集成在多次培训之后,在团队内部有了一些很好的风气,是个好的开始。之后,我们也尝试了更高效的工作流,为团队本身的自运行打下了很好的基础1

Business Portal

大概在 12 月份左右,我们改名叫业务端,虽然大家改口很难。但是在我心中这个端已经是一个更大的团队了。可以看到,从 Gateway 到 12 月之后,我自己本身基本上不参与代码的编写,只是偶尔还参与代码的设计和算法的设计。主要负责找到团队中薄弱的地方和未来可能的方向。效果的话,自我感觉还可以。薄弱的地方如信任(这是一个很大的问题),沟通,代码质量和标准都有了很大的提高。在未来可能的方向上,定了服务拆分,前端拆分以及 Gateway 的长远的技术方案。

这个时间段主要抓 Java 的标准相关的事情,团队内部经过反复讨论和 review,使用 Spring boot 开发框架,并且统一了 Java 和 Python 的 Rest 协议规范。另一方面,Java 也拥抱了新技术和变化(其实有些不是,如 Test)。在框架内部集成了单元测试和容器化基础组件,给未来创造了更多有利条件。

同一时期,这段时间新人入职的比较多,在学习成本上花费了大量的时间和精力。我们也内部定制了 Java 规范和 Python 规范,包括新人学习课程。最多有长达两周的学习时间,包括语言、技术、框架、团队风格以及业务等等。分享也非常的多,新人都能够学习到更多实用的东西,也可以了解团队之间都在学什么东西。

在这个阶段最让人满意的事情是,团队内部的架构演进基本上可以说我和个人没什么关系了。在之前的方向修改和反复讨论沟通上,我觉得团队内部的几个 Leader 已经完全可以撑得起这个项目组了。对于代码级、开发、测试环境的事情上,基本上团队内部就已经可以得到答案,大家方向一致,并且能够互相认同,更有甚很快就上线了。例如我们已经做好的 Staff Service 和 User Service,甚至是管理端拆分。而且从现在来看,相比写一个新的库来说,这个产出实在太大了。况且很快就要改客户系统和员工系统,到那个时候再来看我们今天的决定,会发现技术债已经改善了很多。

Performance

当然事情并不是一帆风顺,内部系统的复杂度要比面向用户的系统复杂度高很多。服务拆分之后,性能会是一个很大的问题。当然,由于复杂,而我们全部基于 MySQL 来做,数据库的性能基本上无法使用在我们现有的系统中。这个问题是我们这两个月最头疼的问题。好在今天来看,解决了一大部分,至少还能再扛一阵子。

其实在解决性能问题这件事上,大家都很迷茫,也付出了很多。在调研、测试、试错上遇到了很多的问题,也抓住了不少机会。当然业务在这期间是不理解的,我也很理解为什么不理解。技术应该有自己的生命周期,就像一台电脑,你不可能指望它工作一百年,技术的更新迭代是非常重要的。我们基本上是花了两个月才找到根本问题,但这两个月的付出是非常值得的。至少从技术和人文上(比如沟通和尝试),有了更多的成长。

同时,服务注册和服务发现,在我们团队内部还没有这样的意识,还需要更多的培养。在开发测试环境上,解决问题的思路还很老,一台机器很快跑不了所有的服务,可以预见的是,过几个月,很快会成为技术团队的瓶颈,在这方面,还需要发更多的力。

Teamwork

这一年来总的来说,自己从单打独斗逐渐演变到团队协作。身边的团队也有很多的改变,从一开始说实话不太行,随着时间和架构的调整,变得越来越好,整个研发团队也积累了很多。无论是好是坏。我相信未来会积累更多。团队之间的磨合和沟通必不可少,有时候,大家互相不理解也很正常。做架构和设计,不可能快乐,但肩负的使命很多,压力很大,常常压得喘不过气来,但必须得抗住。

每个人的性格不同,怎么样打造一个好的团队,理想的团队,不是靠说的。我自己比较理想化,相信团队,从来不指责个人。团队也给了我很好的回报,没有辜负我们团队这一性格。因为不指摘,大家会更往一个方向努力,如果每个人都不愿意承担责任,那么团队也如同散沙。

团队从 2、3 个人 到 7、8 个人 就已经完全不一样了。再从 7、8 个人到 20 个人左右,整个执行力和理解力就会下降很多。我们自己也常常会思考如何面对团队未来的挑战,光靠信任和自觉已经无法构建团队的时候。我们能否在不忘初心的情况下做得更好,会是一个更难的问题。从这点来看,写代码这个能力确实占比不大,但也不要忘了上层建筑永远是由基础决定的。

EOF

最后,这半个月内,主要开始回归开发。个人感觉做技术(架构)不能脱离技术(业务)太多,不深入一线,是不知道一线会有什么问题的。这个过程中,也解决了不少难题,学了很多新的东西。例如最近在看的 TCP 实现的源码分析部分,让人感受很深。于此同时,也开始进行新项目的冲刺,当然,这也得益于团队本身没有更多技术上需要我操心的了。

这一年来总的来说,实在太忙了,开心的时间不多,但也算做了一点事情,可以看到的不多2,相信我和团队都会觉得我们变化很多很快。但我自己也知道还没有到达那个奇点。一旦到达了奇点,相信整个团队会有更多的改善。

最后想到,年初面试(其他公司)有人问我做架构应该是什么样的,当时答得很模糊,如果现在来看,我大概这么说:

  1. 基础能力:没有基础能力就没有办法进行架构设计,最后对导致设计都是从他人那边剽窃过来的
  2. 技术识别:对于新技术能够给我们自己提高效率需要有眼光能够识别,并且有胆量落地,有能力解决技术问题
  3. 沟通能力:技术更多是实现项目的方法,推进无论是技术项目还是业务项目,都需要沟通,需要更多的锻炼
  4. 团队管理:对团队内薄弱的地方要考虑优化,不要局限于代码本身,站起来看整个团队,优化整个团队的效率
  5. 业务扛压:压力很大,无论是做得好的事情还是做得不好的事情,都会有很多人看着你,抗住压力,保护团队
  6. 技术抗压:技术选型和架构方向不是所有人都能看到价值的,需要抗住压力用结果和数据说话,这又需要很多基础能力

关于架构能力的思考和讨论(吐槽)不再说更多,也许哪天可以再起一篇文章说明。

Looking forward

2017,我们团队对未来有很多猜想,也有很多预期。但未来不是靠一个人,而是靠团队来达成,在这一点上,相信 2017 能有更多的改变。当然,最有压力的是我自己,有很多时候,我站起来看到整个团队,大家都能够往更好的方向去走,我会深深的感受到自己在退步。

关于我自己,关于团队,会不会更好,只能靠时间去证明。

  1. 从今天来开,Python 部分做得更好,主要是基础服务和基础组件很完善。Java 部分相对较差,主要还是历史包袱太多。 

  2. 做得好是应该的。