瞎扯淡 回流技术团队现状

lanzhiheng · 2022年12月08日 · 最后由 3316872395 回复于 2023年03月14日 · 1510 次阅读

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

今天借着这个“东风”,我来谈谈回流的技术团队。我会从文化,技术栈等各个维度来介绍一下这只小团队。原文链接: https://step-by-step.tech/posts/huiliu-technology-team

DSCF0609.jpg

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

说这种话是有点不要脸了,貌似在歌颂自己的“丰功伟绩”,但要看你从哪个角度来评估最好这个词了。一家公司处于不同的阶段就会需要不同类型的人才,这个几乎是亘古不变的真理。要说专业水平的话,回流技术团队绝对算不上顶尖。也不是业界所推崇的特别年轻化的团队,团队里面 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 个人来询问的情况来看,市场上并不缺测试人员。但招聘测试容易,优化流程难。

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

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

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

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

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

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

生死未卜的远程机制

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

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

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

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

最后

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

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

流批,CTO 都有时间写博客,我等楷模

对于小白的我,Hotwire 维护起来真的有点难受

spike76 回复

😬 招人进来写代码,自己就可以喝茶了。

bill997603 回复

把“有点“ => “非常”吧,我也放弃维护了。

lanzhiheng 回复

不好维护的地方能展开说说么?

apexy 回复

顾不过来啦。又要做设计还原,又要写业务逻辑。公司项目来说会比较难搞。当然我自己的项目倒还是用 Hotwire。

  1. 阶段性地思考是很多技术工作者缺失的,写东西是一种不错的思考方式,CTO 应该需要有时间思考;

  2. 对 Web 应用、服务来说,Rails 提供的方案能较快地构建出不错的应用,且成本可控,不倦,只是生存空间确实尴尬;

写得挺好,值得学习,加油!👍

wikimo 回复

😬 感谢,后面还需要找你取取经。

一直没太懂回流是啥意思?

BenX 回复

我司产品。

“招聘一个 Rails 工程师会有点难度,然而要招聘到一个懂 Rails 还愿意折腾前端页面,且还能把交互写利索的工程师,难度应该是地狱级别的吧。这种人凭啥来你回流呢?人生已经很艰难了,不要再给自己增加难度了。”

前几个月有幸得到了一份 Rails 远程兼职的 offer,三个月后,有一批遗留系统的需求,“义不容辞”地独自接了下来,前端 AngularJS 1.4 以及 Vue,后端 Spring Framework。也是这时才知晓,遗留系统的业务承载规模,比 Rails 项目大挺多的。

雇主目前没有除 Bootstrap 之外的前端开发资源,也没有 Rails 之外的后端开发资源,同时又谋划着未来用 Rails 和 Bootstrap 重写所有遗留系统,所以现在和将来都没打算增加这些资源。

这时我才意识到,自己在 Rails 上的 0 年工程经验,是如何帮助自己获得这份 offer 的。一切都是意外😂

sinlight 回复

你能搞定 AngularJS 1.4 以及 Vue,后端 Spring Framework, 搞定 Rails 也不会有多大难度. 本质上 Rails 应该比 AngularJS 和 Spring 简单比较多。

其实我一直在找寻类似的远程团队,无奈一直没有找到。。。

我现在都还学着 hotwire, 对 Ruby on Rails 只能说算是入门那种,自己靠前端吃饭😭 😭 ,学习 Ruby on Rails 是热爱,是它带我走入了编程这个行业,最近一直在焦虑 学习了有用吗,我在地方就没有 Ruby on rails 的工作,找远程能力达不到 (在国外也有很多人在讨论对于 ROR,很多公司都在找 senior 的开发者,对 junior 找的少,特别是远程),我最终还是选择继续学习它,利用好自己的多年前端经验结合 ROR,最近自己在学用 inertia_rails(gem)+inertiajs(js)+ ror 可以很好的把前端加进去,比如一些框架(React、Vue)代码地址: https://github.com/jisuanjixue/pingcrm_react 欢迎指导,inertiajs 的介绍是: https://inertiajs.com/Inertia.js( lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers)

今天看到的一个统计,每个国家的 Ruby 职位空缺数量,来自: https://workhunty.com

nuanshuidai 回复

要来份简历看看吗?

lanzhiheng 回复

你们还招人吗?

nuanshuidai 回复

招啊。有合适的话

lanzhiheng 回复

怎么联系?

sinlight 回复

听你说完,我咋感觉是我以前做的项目啊,不会是北京一家搞医疗的吧

#老哥真的收应届吗 大专,前端, 会 vue 能手写响应式 reactive、effect 部分的源码和其他一些小 api,有项目,能互相了解一下吗

前端卷麻了今年,想试试 ruby,了解 java、c,能用 php 和 node 构建服务端接口,github 上还有我用 node 写的 css 预处理器,在 npm 上第一周三百下载量

需要 登录 后方可回复, 如果你还没有账号请 注册新账号