创业公司技术选型实录：从Egg.js到团队解散的踩坑记

2022年6月，我加入了一家很小的创业公司。老板对技术和管理的了解都不深，凭着一腔热血和对实体运输行业的认知，加上一点盲目的自信就开始了创业。后来的故事大家可能猜到了，公司经营困难，最终散伙，连最后几个月的工资都没能结清。

加入时，老板的核心要求很明确：极力控制人力成本，快速开发出能在Android和iOS上运行的App，他要尽快让业务跑起来。当时，技术团队只有我、一个刚毕业的前端和一个UI，连人事和测试岗位都是空缺的。

结合公司“快”的需求和我个人的技术背景（主要是前端和Node.js），我主导了初期的技术选型：

1. 使用 uni-app 开发App。主要考虑它能一套代码多端覆盖，开发速度快，先解决“从无到有”的问题，也为后续可能的小程序开发预留方案。
2. 使用 Egg.js + MySQL 作为后端。基于Node.js的框架开发速度快，考虑到业务比较小众，短期内不太可能遇到巨大的性能瓶颈，足够应付初期的需求。未来如果需要，过渡到Midway.js也方便。
3. 使用 antd-vue 开发运营后台。主要是为了与 uni-app 的技术栈（Vue）保持一致，降低团队成员在技术上下文切换上的成本。

总结下来，初期方案就是 Egg.js + MySQL + uni-app + antd-vue，目标是用这套组合拳快速完成两个App和一个运营后台的开发，实现从0到1的突破。

关于App开发技术方案的选择

当时我们也评估过其他方案：

1. 纯原生开发：需要分别招聘iOS和Android开发，两端并行开发测试，时间和资金成本老板都无法接受。
2. Flutter：要么我自己从头学，要么招人，虽然比纯原生方案好一点，但也不是最优选。
3. React Native/Taro：这类方案与 uni-app 类似，但综合考虑团队的熟练度、技术上手难度和开发效率，最终还是选择了 uni-app。

为什么选择Egg.js做后端

很多时候，技术选型不能只从技术角度考虑，成本是决定性因素。在当时的情况下，Egg.js 完全能满足需求。

1. 使用Java、Go或PHP等成熟的后端方案，从技术角度看可能更“稳妥”，但对老板来说不是经济的方案。
2. Egg.js 基于Node.js，我比较熟悉，开发简单快捷。对于有一定JavaScript基础的新成员来说，学习成本也很低，能快速上手后端开发。

前期开发进行得还算顺利，我们如期完成了开发、测试和上线。然而，老板承诺的“快速运营、快速盈利”并没有实现，业务推进异常缓慢。更让人头疼的是，中间经历了各种折腾：

1. 老板在运营上遇到困难，就开始四处寻找“专家”（往往和我们的业务毫不相干）提意见，导致产品和UI反复修改。
2. 中途新来的产品经理甚至想全盘推翻原有设计，要求重做。
3. 还有位兼职的领导，没有任何依据，就坚持要招聘原生开发和Java开发来重写项目。

那段时间，不断有人提出要修改产品、设计甚至推翻代码。经过大量的沟通和争取，总算保住了最初的技术方案，前期的开发成果没有被浪费。但后续还是增加了很多需求：系统1.1版本升级、UI 2.0改版、开发微信小程序版本、开发新的配套系统及其后台、集成即时通讯、以及各种小功能的迭代。

老板的想法也经常反复，一会说要加快进度让招人，一会又无缘无故想开人。最核心的运营问题始终没有进展，明明症结不在产品和技术，却总在这个层面折腾团队，让人非常无奈。你已经很努力地协调、站在公司角度思考、拼命写代码了，但感觉一切努力都像打在了棉花上。

后期技术方案的调整

在后续的迭代中，我们也对技术方案做了一些优化：

1. 优化了App的打包流程和性能。
2. 在新的配套系统中，尝试使用 midway.js 来开发新业务。这是基于团队已熟练掌握 Egg.js 的基础，为了进一步提升开发规范和可维护性所做的升级。
3. 搭建内网私有npm仓库，用于管理公共组件和工具包。
4. 制定了团队的代码规范和开发流程。

人员招聘与团队管理

人员招聘

小公司招聘本就困难，更何况薪资不具竞争力。好在我们选择的技术栈（JavaScript全栈）降低了一些门槛，对JS掌握较好的人，可以兼顾前后端开发，这样也方便根据任务灵活调配人力，避免资源闲置。

团队管理

对于小团队的管理，我积累了一些心得：

1. 业务导向：小公司起步，必须实事求是，一切以推动业务为核心。
2. 倡导全栈：在小团队中，全栈开发模式能最大化利用人力资源，避免因前后端任务不均衡造成的浪费。
3. 代码规范：制定一份大家都能接受的代码规范（可以参考主流规范并结合团队习惯），目标是让代码风格相对统一，易于维护。
4. 流程简约但明确：建立并执行简单的开发流程，例如：产品评审 -> 任务分配 -> 技术方案设计 -> 开发 -> 测试 -> 代码评审 -> 上线 -> 线上监控。这能避免管理混乱和不必要的损失。
5. 可量化的考核：建立简单有效的考核点，如：任务按时完成率、核心模块是否有技术文档、线上Bug数量、是否遵守数据库操作规范（严禁手动改生产库）等。
6. 鼓励分享：营造相互学习的氛围，让团队成员觉得这段工作经历有成长、有收获。
7. 保持沟通：及时了解团队成员的想法、工作进展和遇到的难点，主动沟通反馈。

最后的总结与避坑建议

这段经历让我对加入创业公司有了更清醒的认识，以下是一些避坑建议：

1. 考察创始人：这是最重要的一点。老板是否靠谱、务实，是否有清晰的商业逻辑和决断力，而不是只会画饼或优柔寡断。跟对人，哪怕当前项目不成，未来也可能在其他地方做成事。
2. 关注盈利模式：在当下的融资环境里，自身不具备造血能力的公司很难存活。必须搞清楚公司打算怎么赚钱，以及这个路径是否现实。
3. 抓住核心矛盾：业务永远是第一位。在生存问题面前，技术选型是否“高大上”、代码是否绝对规范，都可以适当让步。
4. 保持向上沟通：及时向管理层同步你的工作进度和遇到的困难。老板站在更高层面，掌握的信息不同，其决策可能有你未能考虑到的因素，不要闭门造车。
5. 确保自我成长：无论公司成败，尽量让每一段经历都成为你职业发展的垫脚石，在技术或软技能上有所收获。

这段在小公司的“技术开发心酸事”，虽然结局不尽如人意，但其中的技术决策思考、团队管理实践和踩过的坑，对于许多面临类似场景的开发者或技术负责人而言，或许能提供一些真实的参考。技术的价值最终需要服务于业务生存，而清晰的业务思考和坚定的执行，往往比单纯追求技术最优解更重要。如果你对全栈开发、面试求职或团队管理有更多想法，欢迎到云栈社区与其他开发者交流探讨。