最近公司可算是赐予我一个CTO的头衔了，老实说这个名头，我是既得意又惶恐。得意之处在于，CXO这种头衔，总会自带某种光环。而惶恐之处就在于，万一被他们发现这CTO，名过于实，那丢脸的还是自己。要说是更得意还是更惶恐，我感觉是惶恐更甚，毕竟当不好被人赶下去应该也挺丢人的吧？

今天借着这个“东风”，我来谈谈回流的技术团队。我会从文化，技术栈等各个维度来介绍一下这只小团队。

对回流而言，他们是最好的

说这种话是有点不要脸了，貌似在歌颂自己的“丰功伟绩”，但要看你从哪个角度来评估最好这个词了。一家公司处于不同的阶段就会需要不同类型的人才，这个几乎是亘古不变的真理。要说专业水平的话，回流技术团队绝对算不上顶尖。也不是业界所推崇的特别年轻化的团队，团队里面80，90后都有（以后说不定也会有70后跟00后吧）。有些时候一群最顶尖的人不一定能把事情做成，但一群合适的人可以。“合适”也是我们对最好的定义。

虽说目前团队里面的人就没有从名校毕业的，不过这一年多两年来大家聚在一起确实完成了许多从0～1的突破，这对于刚起步的公司来说才是最重要的。当一家公司连掀锅都成问题的时候，就别谈什么先进技术了。Ruby On Rails能快速开发一个原型，我们就用Ruby写后端代码。Taro + React语法能够快速搭建一个可靠的小程序，我们就用它。用Dart + Flutter来开发App比写两套原生的App成本更低出活更快，那它会是我们的选择。换句话说，这是一个相对务实的团队，对于现阶段的回流就是最好的存在，而不是一个在各方面技术都特别顶尖的团队。

Ruby On Rails“死路”

老实说，我现在都还不太确定在中国用Ruby On Rails走不走得下去，不过选用这套技术栈在前期是有益的。对于“前途未卜”的创业公司来说，能够不断开发出原型，提前验证各种各样的想法，确实大有裨益，这也是我们前期选择开发小程序而不是一上来就App的原因之一。

不过老实说Rails在中国的生存空间真的不是很大，相关的人才是越来越少了。当然也有可能我们没开到足够高的工资，否则应该多少能从其他语言部落那里挖些人过来吧。我招聘了两个Rails后台工程师最后还是不欢而散（主要都是开发节奏难以适应）。如果招不到合适的Rails工程师，那么回流能不能走好下一个阶段就不好说了，这也是笔者稍微有些担忧的事情。

我不会忽悠新人Ruby有多好，更不会骗自己说其他语言有多差。Ruby不是特别好，但是它并不差，起码它带我们度过了相当关键的一段时期。当然也有很多优秀的语言跟对应的生态（Java，Elixir，Go，Rust都很好）。只不过项目刚启动的时候，出于Rails的优秀生态跟本人的私心（只懂Ruby也只想写Ruby），才用Ruby到了现在。

有小伙伴经常问我，以后会不会用别的语言把我们系统重写掉，回答都是永远不会。当然笔者并不是那种死都要坚守某种语言阵地的顽固派，之所以不重写也仅仅是成本角度考虑。如果考虑到招聘成本和难度（当然还有性能），把已有的一些功能抽取成微服务的形式，并用其他语言来实现，这种可能性还是很大的。

React + Taro + TypeScript有趣的组合

当笔者还是前端工程师的时候，对前端的大环境已经看不太懂了。现在跑去写后端，便更不懂了。我记得在上一家公司的时候，大家就到底是用Vue还是React都能争吵很长时间。回流的第一个产品是小程序，反正不可能写原生的小程序代码，笔者便让小伙伴自己去试试Vue系的uni-app，以及React系的Taro，在两者之间做出选择。

我隐约记得当时小伙伴是用Vue写了一个Demo，后来说还是喜欢React干脆重写了，所幸成本并不算太高。顺带地，当我们需要用前后端分离的架构重写我们的后台管理系统的时候，也是用的React。不过小伙伴考虑到维护成本，打算用TypeScript来编写整个项目。笔者是一个比较不喜欢束缚的人，天然对静态语言没有太多好感，不过事实证明，小伙伴的选择是对的。毕竟写代码的不是笔者本人，小伙伴开心就好。

至于为啥不用Rails的Hotwire？其实也是成本角度考虑，创业这些年很痛苦地发现，一个人能力再强，也不可能独自完成所有的事情，更何况笔者这辈子跟“能力强”这三个字应该是沾不上边了。如果用Hotwire来写整个后台管理系统（确实尝试过），后期的招聘维护会更难。可能你可以相对容易地招聘到一个前端工程师，招聘一个Rails工程师会有点难度，然而要招聘到一个懂Rails还愿意折腾前端页面，且还能把交互写利索的工程师，难度应该是地狱级别的吧。这种人凭啥来你回流呢？人生已经很艰难了，不要再给自己增加难度了。

编写App就用Dart + Flutter确实没啥好考虑的

忘了是2021年的哪一天，老板突然心血来潮说要研发自己的App，且不让笔者找外包公司（官大一级压死人）。鉴于笔者人格魅力不足（资金预算也是），无法把我亲同学的男朋友挖过来当App主管，只好跟前端小伙伴两人对App项目简单起个头。

虽然说在App原生领域，用Swift语言写IOS，用Kotlin写Android的想法很诱人。但是考虑到研发成本以及“国库”不足的窘境，潜意识告诉我要克制。选择一个靠谱的跨平台方案才是明智之举。

当时比较流行的跨平台方案无非就是React Native还有Flutter。请教了好些朋友及前同事，最后敲定用Flutter来完成这个项目。事实证明，这个选择并不赖，招人也不太难招。目前的App小伙伴们都挺靠谱的，就是要难为他们一进来要接手两个门外汉写的Dart代码了，当然由于流程不够规范有时候还要加点班，在此深感抱歉。

尚未完善的测试

无论对哪个公司来说，测试都是比较重要的一环。对回流来说又何尝不是？特别是随着项目越发庞大，需要测试的功能也越来越多，测试力量略显不足。Bug经常出现，大家都说要对测试岗位进行扩招。从测试招聘贴发出去5分钟就有60个人来询问的情况来看，市场上并不缺测试人员。但招聘测试容易，优化流程难。

我粗粗排查了一下，导致测试力量不足的现象可能包含以下几个原因

自动化程度不够，我始终相信有不少流程应该要避免掉人工测试的窘境。
开发者并没有自测，很多开发者自己写完的功能，甚至没有跑一遍就直接扔给测试，返工的情况就很多了。
流程不够完善，许多开发者只顾自己手上的功能是否能够完成，完全不给测试留下充足的时间。往往把功能放在上线之前最后一天才给到测试，导致发版当天每个人都加班到身心俱疲。

以上列出的这些问题，回流都有。基本上都没能得到特别充分的解决，所以说测试的状态是“尚未完善”。自动化方面目前只在后端实施，前端着实很难推广。开发者一般都能自测一下自己的功能，因为不测的话会给别人带来不少麻烦，这点大家做得还算不错。不自测，经常给其他人带来麻烦的开发者已经被请走。流程方面感觉永远都不够完善，就算你把所有该做的事情一条条列出来也不可能用AK74去逼着每个人遵守。倒是希望大伙自觉养成大局思维，考虑一下怎么做才能更方便其他人的工作，如此一来效率才能从根上得到提高。

产品设计-其实没啥好说的

没啥好说主要是因为设计领域一直是笔者的弱项，着实不太了解。目前回流的产品运作良好，设计风格也不错，着实是没啥需要特别挑剔的。能在项目前期招聘到靠谱的设计师兼产品经理，算是挺幸运的。随着最近有新的UI设计师入职，产品经理总算能专心当产品经理了，只要公司不倒闭，产品形态应该还能更进一步，只是压力可能到开发这了。

对设计师用什么工具笔者其实也不算特别了解。只是听说，产品设计方面大家都比较倾向于用Sketch而不是PhotoShop。估计唯一让我不满的就是，大伙收入都不低了，且都已经用苹果电脑了，怎么还用盗版？

生死未卜的远程机制

得益于网络时代的红利，除了那些当老板的之外，程序员是最容易享受到远程红利的一波人。本来远程这个东西是笔者为了自己去跟老板争取的福利，后来发现几乎所有小伙伴都不愿意坐班，加上疫情的加持，远程倒是成了常态了。

这里也说说我对团队远程的想法

技术团队可能会越发趋向年轻化，年轻人的自制力，责任心，对产品理解的深度一般比不上有一定经验的“老人”，一旦把控不好会影响团队效率。这方面其实笔者稍微有些担忧。
一旦习惯了远程，便很难适应外界的其他工作了。由俭入奢易，由奢入俭难。说句不好听就是，万一哪天云长科技倒了，要重新去打卡的企业上班，估计会很痛苦吧。
团队一旦壮大，远程沟通问题会越来越明显。沟通问题，工作流程需要长期不断审视优化，才能使远程这艘轮船持续运转下去。
薪资不好界定。假设你跑到小县城生活手里还拿着一线城市的工资，公司肯定有不少红眼之人，以后每到涨薪时刻杂七杂八的事情会越来越多。

要是当时跟老板没有说脑子一热，全体开放远程，需要解决的问题应该会少很多。只是“开弓没有回头箭”，见一步走一步了。遇到问题，就解决问题呗。毕竟IT工作者最核心的竞争力不应该是产品设计或代码编写，而是解决问题。

最后

这篇文章简单对目前回流技术团队的现状做一个总结。现在看来运作得还算良好，偶尔有些小问题出现，基本都得到了解决。然而我感觉后面的问题会越来越多，其中有些问题是老板扔过来的（业务与招聘），有些问题是自找的（全面开放远程）。希望后面的路还足够长，我们有足够的时间把它们慢慢解决掉。

太久没写博客了，导致自己的个人博客被阿里云释放了都浑然不觉，等这篇文章写完尽快去恢复它，这就是懒惰的代价了吧。