最近公司可算是赐予我一个 CTO 的头衔了,老实说这个名头,我是既得意又惶恐。得意之处在于,CXO 这种头衔,总会自带某种光环。而惶恐之处就在于,万一被他们发现这 CTO,名过于实,那丢脸的还是自己。要说是更得意还是更惶恐,我感觉是惶恐更甚,毕竟当不好被人赶下去应该也挺丢人的吧?
今天借着这个“东风”,我来谈谈回流的技术团队。我会从文化,技术栈等各个维度来介绍一下这只小团队。原文链接: https://step-by-step.tech/posts/huiliu-technology-team
说这种话是有点不要脸了,貌似在歌颂自己的“丰功伟绩”,但要看你从哪个角度来评估最好这个词了。一家公司处于不同的阶段就会需要不同类型的人才,这个几乎是亘古不变的真理。要说专业水平的话,回流技术团队绝对算不上顶尖。也不是业界所推崇的特别年轻化的团队,团队里面 80,90 后都有(以后说不定也会有 70 后跟 00 后吧)。有些时候一群最顶尖的人不一定能把事情做成,但一群合适的人可以。“合适”也是我们对最好的定义。
虽说目前团队里面的人就没有从名校毕业的,不过这一年多两年来大家聚在一起确实完成了许多从 0~1 的突破,这对于刚起步的公司来说才是最重要的。当一家公司连掀锅都成问题的时候,就别谈什么先进技术了。Ruby On Rails 能快速开发一个原型,我们就用 Ruby 写后端代码。Taro + React 语法能够快速搭建一个可靠的小程序,我们就用它。用 Dart + Flutter 来开发 App 比写两套原生的 App 成本更低出活更快,那它会是我们的选择。换句话说,这是一个相对务实的团队,对于现阶段的回流就是最好的存在,而不是一个在各方面技术都特别顶尖的团队。
老实说,我现在都还不太确定在中国用 Ruby On Rails 走不走得下去,不过选用这套技术栈在前期是有益的。对于“前途未卜”的创业公司来说,能够不断开发出原型,提前验证各种各样的想法,确实大有裨益,这也是我们前期选择开发小程序而不是一上来就 App 的原因之一。
不过老实说 Rails 在中国的生存空间真的不是很大,相关的人才是越来越少了。当然也有可能我们没开到足够高的工资,否则应该多少能从其他语言部落那里挖些人过来吧。我招聘了两个 Rails 后台工程师最后还是不欢而散(主要都是开发节奏难以适应)。如果招不到合适的 Rails 工程师,那么回流能不能走好下一个阶段就不好说了,这也是笔者稍微有些担忧的事情。
我不会忽悠新人 Ruby 有多好,更不会骗自己说其他语言有多差。Ruby 不是特别好,但是它并不差,起码它带我们度过了相当关键的一段时期。当然也有很多优秀的语言跟对应的生态(Java,Elixir,Go,Rust 都很好)。只不过项目刚启动的时候,出于 Rails 的优秀生态跟本人的私心(只懂 Ruby 也只想写 Ruby),才用 Ruby 到了现在。
有小伙伴经常问我,以后会不会用别的语言把我们系统重写掉,回答都是永远不会。当然笔者并不是那种死都要坚守某种语言阵地的顽固派,之所以不重写也仅仅是成本角度考虑。如果考虑到招聘成本和难度(当然还有性能),把已有的一些功能抽取成微服务的形式,并用其他语言来实现,这种可能性还是很大的。
当笔者还是前端工程师的时候,对前端的大环境已经看不太懂了。现在跑去写后端,便更不懂了。我记得在上一家公司的时候,大家就到底是用 Vue 还是 React 都能争吵很长时间。回流的第一个产品是小程序,反正不可能写原生的小程序代码,笔者便让小伙伴自己去试试 Vue 系的uni-app,以及 React 系的Taro,在两者之间做出选择。
我隐约记得当时小伙伴是用 Vue 写了一个 Demo,后来说还是喜欢 React 干脆重写了,所幸成本并不算太高。顺带地,当我们需要用前后端分离的架构重写我们的后台管理系统的时候,也是用的 React。不过小伙伴考虑到维护成本,打算用 TypeScript 来编写整个项目。笔者是一个比较不喜欢束缚的人,天然对静态语言没有太多好感,不过事实证明,小伙伴的选择是对的。毕竟写代码的不是笔者本人,小伙伴开心就好。
至于为啥不用 Rails 的Hotwire?其实也是成本角度考虑,创业这些年很痛苦地发现,一个人能力再强,也不可能独自完成所有的事情,更何况笔者这辈子跟“能力强”这三个字应该是沾不上边了。如果用 Hotwire 来写整个后台管理系统(确实尝试过),后期的招聘维护会更难。可能你可以相对容易地招聘到一个前端工程师,招聘一个 Rails 工程师会有点难度,然而要招聘到一个懂 Rails 还愿意折腾前端页面,且还能把交互写利索的工程师,难度应该是地狱级别的吧。这种人凭啥来你回流呢?人生已经很艰难了,不要再给自己增加难度了。
忘了是 2021 年的哪一天,老板突然心血来潮说要研发自己的 App,且不让笔者找外包公司(官大一级压死人)。鉴于笔者人格魅力不足(资金预算也是),无法把我亲同学的男朋友挖过来当 App 主管,只好跟前端小伙伴两人对 App 项目简单起个头。
虽然说在 App 原生领域,用Swift语言写 IOS,用Kotlin写 Android 的想法很诱人。但是考虑到研发成本以及“国库”不足的窘境,潜意识告诉我要克制。选择一个靠谱的跨平台方案才是明智之举。
当时比较流行的跨平台方案无非就是React Native还有Flutter。请教了好些朋友及前同事,最后敲定用 Flutter 来完成这个项目。事实证明,这个选择并不赖,招人也不太难招。目前的 App 小伙伴们都挺靠谱的,就是要难为他们一进来要接手两个门外汉写的 Dart 代码了,当然由于流程不够规范有时候还要加点班,在此深感抱歉。
无论对哪个公司来说,测试都是比较重要的一环。对回流来说又何尝不是?特别是随着项目越发庞大,需要测试的功能也越来越多,测试力量略显不足。Bug 经常出现,大家都说要对测试岗位进行扩招。从测试招聘贴发出去 5 分钟就有 60 个人来询问的情况来看,市场上并不缺测试人员。但招聘测试容易,优化流程难。
我粗粗排查了一下,导致测试力量不足的现象可能包含以下几个原因
以上列出的这些问题,回流都有。基本上都没能得到特别充分的解决,所以说测试的状态是“尚未完善”。自动化方面目前只在后端实施,前端着实很难推广。开发者一般都能自测一下自己的功能,因为不测的话会给别人带来不少麻烦,这点大家做得还算不错。不自测,经常给其他人带来麻烦的开发者已经被请走。流程方面感觉永远都不够完善,就算你把所有该做的事情一条条列出来也不可能用 AK74 去逼着每个人遵守。倒是希望大伙自觉养成大局思维,考虑一下怎么做才能更方便其他人的工作,如此一来效率才能从根上得到提高。
没啥好说主要是因为设计领域一直是笔者的弱项,着实不太了解。目前回流的产品运作良好,设计风格也不错,着实是没啥需要特别挑剔的。能在项目前期招聘到靠谱的设计师兼产品经理,算是挺幸运的。随着最近有新的 UI 设计师入职,产品经理总算能专心当产品经理了,只要公司不倒闭,产品形态应该还能更进一步,只是压力可能到开发这了。
对设计师用什么工具笔者其实也不算特别了解。只是听说,产品设计方面大家都比较倾向于用Sketch而不是PhotoShop。估计唯一让我不满的就是,大伙收入都不低了,且都已经用苹果电脑了,怎么还用盗版?
得益于网络时代的红利,除了那些当老板的之外,程序员是最容易享受到远程红利的一波人。本来远程这个东西是笔者为了自己去跟老板争取的福利,后来发现几乎所有小伙伴都不愿意坐班,加上疫情的加持,远程倒是成了常态了。
这里也说说我对团队远程的想法
要是当时跟老板没有说脑子一热,全体开放远程,需要解决的问题应该会少很多。只是“开弓没有回头箭”,见一步走一步了。遇到问题,就解决问题呗。毕竟 IT 工作者最核心的竞争力不应该是产品设计或代码编写,而是解决问题。
这篇文章简单对目前回流技术团队的现状做一个总结。现在看来运作得还算良好,偶尔有些小问题出现,基本都得到了解决。然而我感觉后面的问题会越来越多,其中有些问题是老板扔过来的(业务与招聘),有些问题是自找的(全面开放远程)。希望后面的路还足够长,我们有足够的时间把它们慢慢解决掉。
太久没写博客了,导致自己的个人博客被阿里云释放了都浑然不觉,等这篇文章写完尽快去恢复它,这就是懒惰的代价了吧。