发布于 2026-01-06 0 阅读
0

咱们别再放弃另一个副业项目了

咱们别再放弃另一个副业项目了

作者:多尔·杜楚尼

又到了一年中的这个时候。

你灵光一闪,想到一个千载难逢的点子,然后立刻开始写代码,因为,说实话,我们都热爱编程。
但没过多久,项目就开始变得一团糟/你没时间继续/你开始觉得无聊……然后,砰!你又多了一个可以引以为傲的未完成项目。

我叫Dor,今年29岁,是一名前端开发人员,我的GitHub账户里有6个未完成的副业项目(“我们爱你,Dor”)。几天前,我和朋友们又冒出了一个千载难逢的想法。我们想开发一款应用,用来追踪你家里的所有植物,并在需要浇水时提醒你浇多少水。

我兴冲冲地回到家,准备开始这个令人兴奋的新项目,突然意识到,这又会是一个半途而废的副业。于是我停了下来,深吸一口气,决定这次要改变策略。我必须合理安排我并不充裕的空闲时间,才能推进项目进展,享受其中的乐趣,并最终完成它。

所以我决定为自己(也希望对你)编写一份循序渐进的副业项目生存指南。那么,我们开始吧:

别急着开始写代码!千万别急着开始写代码!

首先要定义MVP(最小可行产品),它将是项目的初始版本。顾名思义,MVP是包含最少功能以满足早期用户需求的应用程序版本。换句话说,它是一个完全可用且可交付的应用程序版本,仅包含其核心功能。

从最小可行产品(MVP)入手有很多好处,但对我们来说最重要的一点正如乔治·克拉萨达基斯所言:
“它能帮助你最大限度地降低开发和运营成本,因为可以降低那些不太重要的功能在未来迭代中的优先级。”
我们时间、人力(和资金)都不多,所以,MVP 才是王道!

为了方便这篇博文的讨论,我们暂且把我们的应用程序称为 Groot,这是一个 MVP 应用程序,它将允许用户设置他们的植物,并获取有关如何以及何时浇水的说明。

确定你的技术栈——对于业余项目,你可能需要使用你已经熟悉的语言和框架,以及使用第三方服务来提高开发效率。决定你的产品是移动应用、Web 应用,还是完全没有用户界面的应用。此外,尽量列出你可能需要的所有服务。一些常见的服务包括数据库、身份验证、通知和分析。

最后,看看你的应用是否需要使用任何外部 API(例如,从某个天气 API 服务获取天气信息)。
我经常在 free-for.dev 上寻找更多可以帮助我的服务。

就我而言,使用 Expo 的 React Native 是 Groot 客户端最简单的解决方案(相比 Flutter、Ionic 或原生 iOS 和 Android,因为我对它们都不熟悉),我们将使用 Google Firebase 进行身份验证和数据库,并使用 Trefle 进行植物信息 API 的开发。

流程图——绘制主要流程的流程图。仔细思考流程中的每一个逻辑步骤。这有助于在系统设计初期发现问题。为什么呢?因为在绘制流程图的过程中,你会思考功能的各个方面,例如:“如何确保用户已通过身份验证?”、“数据库模式应该是什么样的?”、“我应该只在数据库中保存植物ID,然后通过API获取植物详细信息吗?还是应该将所有植物详细信息都保存在数据库中?”

当你回答这类问题时,实际上是在解决那些如果不使用流程图就可能遇到的问题。就我们而言,为了避免数据重复,最好的办法可能是只将植物 ID 保存到数据库中,并使用外部 API 作为我们的“数据源”。

针对特定功能的流程图还可以帮助描述该功能所需的不同接口。

例如:
图表

从这张图表中,我们开始了解应用程序的总体结构。
用户界面:
“搜索植物”屏幕
、“搜索结果”屏幕、
“植物详情”屏幕。
与 Firebase 数据库的交互:
获取 API 密钥
、将植物 ID 保存到数据库中用户的集合中。
与 Trefle.io 外部 API 的交互:
搜索植物、
通过 ID 获取植物详情。

拆分并交付

将工作拆分成若干个可交付的小任务。由于你的空闲时间不多,因此你用于这个项目的时间有限。你需要争取一次性完成所有任务。

最令人沮丧的事情莫过于重新开始一个副业项目,却发现自己只完成了一半就已经忘记的事情,而且甚至不知道还剩下什么要做。

您可以使用 Trello 来管理您的任务(最简单的列是“待办”、“进行中”和“已完成”)。

以下是格鲁特目前的棋盘:
木板

展示与分享:
把你的项目介绍给一些朋友,和他们分享你已经完成的任务。炫耀一下你的项目有多棒,然后“开始推销”。甚至可以写一篇博客文章,和完全陌生的人分享你的作品。

这样一来,你就会全身心投入到项目中,朋友们会主动询问,你也会更想展示更多的进展。此外,你或许还能在此过程中获得一些有益的启发。

概括

我们来简单回顾一下。

我们有很多项目想法,但空闲时间却不够,我们也不想放弃任何一个副业项目。
在急于开始编码之前,我们应该先明确最终目标(最小可行产品,MVP),然后制定一系列小任务来实现这个目标。

我们还需要确定技术栈,选择我们用起来顺手的语言和框架。我们需要确保任务足够小,可以一次性完成,并且内容足够丰富,以便能向朋友(以及一些感兴趣的陌生人)展示成果。

这部分就到这里啦(正如我承诺的——暂时不写代码)。我会随时更新我的​​进展。因为,嗯,既然我已经告诉你们了,那就没有回头路了!😈

文章来源:https://dev.to/dorduch/let-s-not-ditch-another-side-project-e28