分享 Ruby 程序员该何去何从，33 岁程序员失业后的创业分享
关于我
我是覃明圆，非科班出身（中医针灸专业），2011 年毕业，2014 年 1 月 1 日在上海找到第一份 Ruby 程序员工作，2015 年从上海回到武汉，在武汉历经 5 个公司，其中：
- 2 家公司不再使用 Ruby 作为团队主力语言，仅维护老项目；
- 1 家公司在武汉不再招聘 ruby；
- 1 家公司倒闭；
- 上家公司远程，受疫情影响，我所在的项目甲方资金链断裂；
2020 年 3 月 19 日，我正式失业。
走访了一圈在武汉的 Ruby 小伙伴们，一半转了其他语言（Go / Nodejs / 大前端 / Elixir），一半继续出走北上广。
怎么办？
出走北上广肯定是不现实，33 岁了，不想再漂泊。
转其他语言，代价很大。由于自己非科班出身，不能分摊自己有限的技术精力投入，我早已决定在 Rails 技术栈上尽可能成为专家。加上自己有 2 年产品经理经验，1 年创业经历。我给自己的定位是成为一名“懂产品”的技术人员。
于是被迫创业。
怎么做？
在创业这个事情上，我是早有心理准备的，这些年我做了以下准备：
- 技术深入：Rails 擅长的领域是快速开发，我的目标是让 Rails 的特长得到充分发挥，深入挖掘 Rails 技术栈快速开发的潜力，通过对 Rails 框架的一些简单改造，相对于常规 Rails 开发，我的代码量减少了 50% 以上（更少的代码大概率等于更高的效率）。
- 积累组件：程序员的积累有个原则，即尽量避免重复性的工作，我开发过的功能我会尽量避免再写一遍，于是我将相关功能抽出为 engine，这些年来我总共剥离了约 30 几个通用性的业务组件，engine 列表
- 确定创业大概方向，提前准备品牌，注册域名，注册商标。特别是注册商标，不要怕麻烦，我有个商标因为与一个早我 3 个月注册的商标近似被驳回，多花了 2000 多块钱进行驳回复审，特别后悔。
- 找合伙人。尽可能的找更多人聊自己创业的想法，一是别人会给你提意见，这会促进你修正你的商业模式。这个期间很可能会有小伙伴非常认可你的理念，把他放进你的候选合伙人里。我有两个合伙人是女的，我女朋友有些不太喜欢，我说实在是没有办法，我跟很多人聊过我的创业想法，目前为止就这俩女的对我的创业想法比较感兴趣。
- 验证商业模式。正式创业之前，先找你的准客户聊聊，要聊到他们出钱的环节，我找了 4 个准客户进行了验证，效果还可以，有 1 个拒绝了，3 个表示可以合作。
介绍我的项目
简单来说，Work Design 是一个开源的由众多组件组成的快速开发体系，Work Design 核心团队负责底层搭建，对 Ruby 程序员进行培训和技术管理。这名 Ruby 程序员我们将提供给我们的甲方，由甲方给 Ruby 程序员发工资。根据甲方使用的 Work Design 的组件，我们按年进行收费，这部分收入用于支持 Work Design 的持续开发以及对合作的甲方所雇佣的 Ruby 程序员进行技术输出和培训。
目前 Work Design 还处于快速成长中，文档和测试还不太完善，我也正在借助甲方的项目打磨这个体系。在此也邀请对 Work Design 感兴趣的 Ruby 小伙伴加入进来，大家可以基于 Work Design 多年的积累去接自己的项目，同时参与到 Work Design 生态的完善中来。也可以加入我们的技术人员储备中来，当我们有新项目进来的时候，一起合作新项目。
我相信 Work Design 是一个扩大 Rails 影响力到 Ruby 社区之外的事情，目前采用 Rails 的公司越来越少，工作机会越来越少，ruby 程序员也就越来越少。所以我们要利用 Work Design 先做甲方的市场增量，形成良性循环，让 Rails 爆发第二春。
官网 有我的微信二维码，欢迎同道中人添加。
mingyuan0715
回复
我现在干的是 JAVA 方面的活。
用 Ruby on Rails 做开发的公司这边基本是所谓的互联网企业，然而这些企业不太熟。而且受到新冠疫情影响在经济方面立马就显现出疲软态势，只能看 8 月后能有没有好转吧。。。
xiaoronglv
回复
常规医学项目不好盈利，要么就是卖广告要么就是卖保健品。薄荷的商业模式倒是很值得参考的，不过我觉得创业成本相对较高。我目前这个模式我认为相对比较稳妥，且容易切入
huacnlee
回复
感谢大佬抬爱，我也一直有关注长桥和你们的 rails-engine。我目前家人都在武汉，长时间去外地阻力有点大。谢谢好意了
mingyuan0715
回复
另外，我看了一下你的 Gem，太多了
时间精力有限，你这样拉太长战线难以把细节做好。可以考虑把精力放在重点的几个（5 个以内），专注先做好他们。
huacnlee
回复
我能理解你的意思。我是这样考量的：
- 重点的确实只有几个，就是每个系统都会使用到的几个 engine，这几个是优先级更高的；
- 其他业务 engine 的核心实际就是模型设计，View 层和 Controller 大都是通过生成器生成的，我也不准备每个单独给文档了。就一个统一的文档。
- 不专门花时间写 engine，只在做相关业务的时候才会去完善某个 engine。这么操作有一部分商业考虑，就是知识产权。我每个 engine 是 LGPL-3.0 协议，先给出简单的“占位”，然后合作的甲方或者公司启动项目的时候，我会提及为了加快开发进度，我会使用一些现有的 engine，但是这部分是不能闭源的。所以目前我所有的 engine 都不涉及知识产权纠纷。
@mingyuan0715 企业信息化（或者数字化）有广阔的市场，个人更看好低代码平台解决方案，供你参考。业务信息化一定需要使用某种信息技术系统，通常有两种方法获得技术系统，一种是自主开发（也包括外包开发），这种方式的优点是可以完全自主灵活定制，缺点是开发周期较长，成本很高；另外一种是使用外部通用的产品方案（包括自主部署系统和由厂家部署的 SAAS 服务），这种方式的优点是非常快速便捷，功能全面强大，通常成本较低，缺点是难以找到特别适合的产品，难以定制扩展。低代码平台方案是介于两者之间的一种方案，使用它可以让业务人员/产品经理或者少量技术人员就可以快速定制开发出适合的应用，开发速度可以是自主开发的好几倍，成本低很多，还能消除多个子系统造成的数据孤岛问题。
mingyuan0715
回复
低代码 也有两种倾向，一种是往自主开发靠，偏快速开发工具，还是需要专职的技术人员；另外一种是往通用产品靠，偏灵活定制产品，已经不需要专职的技术人员，靠产品经理/项目经理，甚至业务人员自己动手就可以搞定。 我认为从企业的角度考虑，肯定更希望选择后者，只有后者不能搞定的时候，才不得不选择前者。
我判断未来一半以上的软件可以通过“低代码平台”快速生成，它特别适用于企业业务信息化的各种系统，比如进销存、CRM、资产管理 ...... 目前它还在发展的早期，这是一个巨大机会，如果我现在再创业，我估计也会选择“低代码平台”，哈哈，加油！
vincent
回复
Shopify / Salesforce 里的定制模块还是不得已引入了代码方案，比如 shopfiy 的 liquid。我认为专职的技术人员不属于不得不的选择，而属于需求方面的选择。也就是说，光靠灵活定制产品已经满不足了需求的时候，这个时候让技术人员参与进来不见得是成本就一定很高。
vincent
回复
最近观察了一下，国外的低代码生态相对来说比较成熟，像 webflow + zapier + airtable/coda + firebase + auth0 这一套东西可以做很多事情了，用户一般是没有编程能力的创业者，有了 idea 无需编程经验，再简单的定制一下就可以做一个 MVP 出来。
国内的低代码生态还不太成熟，还停留在表单和工作流这个阶段，主要面向小程序，并且国内用户对云接受度更低，动不动就想私有部署...
hooopo
回复
2019 年最火的技术词是“中台”，2020 年最火的技术词是“低代码”。我觉得正是国内不成熟才意味着机会，如果都成熟了就没多少机会了。
