独立开发的最好和最糟糕之处都在于“独立”这一部分。独立工作有很大的自由度，这种自由可能会激发灵感，但也可能成为阻碍生产力和进步的严重障碍。维克多·阿约米波分享了他在独立开发以及构建“正确”应用程序方面的个人经验教训。
正如任何尝试过独自构建任何东西的人所预期的那样，我的目标不是构建一个应用程序，而是那个应用程序——那个非常好的应用程序，好到让你想知道没有它你是怎么活下来的。我把一切都准备好了：线框图、待办事项清单、项目结构——凡是你能想到的。然后我开始构建。但不是构建产品。我从它的登陆页面开始，这花了我四天时间，而我甚至还没有触及应用程序的核心功能。这个想法本身非常好，我必须马上开始推广它！
我发现自己把每一个细节都做得尽善尽美：每一种颜色、阴影、渐变、字体大小、边距和填充都必须恰到好处。我甚至不想说设计这个标志花了多长时间。
Spoiler:
No one cares about your logo.
为什么我会在一些甚至从来都不是我非常想构建的核心应用程序的一部分的事情上陷入如此困境？为什么当我明显需要继续前进的时候，我没有督促自己前进呢？
独立开发的现实情况是，没有人告诉你什么时候该停下来，或者简单地说：“哟，这已经足够好了！继续前进吧。”大多数用户并不关心登录按钮是黄色还是绿色。他们想要（并且需要）的是一个在点击时能够起作用并解决他们问题的按钮。
避免尽早且频繁地测试
不必要的调整、优柔寡断的用户界面决策以及完美主义是我在事情上花费比必要时间更多的核心原因。
和大多数独立开发者一样，我也怀着能以大规模团队的效率推出产品的希望开始。但说起来容易做起来难。
在独自构建项目时，你开始编写代码，然后可能会注意到一个设计缺陷，于是你转而修复它，接着又出现一个错误，你尝试修复那个错误，然后，瞧——一天就过去了。总有那么一个时刻，你会突然意识到，“你知道吗？是时候进行混乱构建了。”就在那时，项目和产品管理的良好意图被抛到了窗外，而我发现自己是在凭直觉工作，而不是按照基于良好的用户界面/用户体验原则（如故事板、用户角色和基本优先级排序）的明确目标和可操作任务向前推进。
这种认识是你必须亲身体验才能完全理解的。我学到的诀窍是专注于拿出一些东西让人们看到，然后根据实际反馈进行改进。换句话说。
与其一开始就追求完美，不如先把想法提出来并加以改进。
因为，你猜怎么着？即使你有世界上最棒的应用程序创意，在开始收到反馈之前，你永远也无法将其做到完美。你不是读心者——尽管我们都希望自己是——一些见解（通常是最相关的）只能通过真实的用户反馈和分析获得。当然，你早期的假设可能是正确的，但在你推出它们并开始评估之前，你怎么知道呢？
如今，我喜欢告诉别人（也告诉自己）从假设而非绝对中开展工作。提出一个主张，描述你打算如何检验它，然后付诸实践。这样，你可以收集相关的见解，用于更接近完美——无论完美是什么。
认识到弱点的力量
说实话：独立构建一个完整的应用程序并非易事。我想说，这就像独自建造一座房子；看起来可行，但实际情况是，要使其实现需要的人手远多于你所拥有的。而且不仅是要使其实现，还要使其良好地实现。
一个人的能力是有限的，预先承认自己的优势和劣势将对你大有裨益，因为这样可以避免陷入你可以独自完成所有事情的陷阱。
我曾经试图独自构建一个项目管理应用程序。我知道这可能很困难，但我很有信心。几天之内，这个“简单”的项目变得越来越复杂，增加了团队协作、分析、时间跟踪和自定义报告等新功能，其中很多功能我都非常兴奋地去制作。
开发一个完整的应用程序需要花费大量时间。想想看，你独自一人完成一个团队的工作，没有任何帮助。没有人给你提供设计资源、内容或后端开发。没有利益相关者对你的想法“横加指责”（这也许是件好事）。每一个决定、每一行代码和每一个设计元素都 100%由你独自承担。
从技术上讲，独自构建一个功能齐全的应用程序是可能的，但当你仔细想想，MVP（最小可行产品）的概念之所以存在是有原因的。以 Instagram 为例，它推出时并没有 Reels、Stories 和创作者洞察等功能。它始于一件简单的事情：照片分享。
我想说的是从小处着手，推出产品，让用户引导产品的发展。如果你能招募更多的人来帮忙，那就更好了。只要记住发挥自己的优势，并依靠他人的优势来弥补自己的不足。
是的，像一个最简化可实行产品一样思考
“最小可行产品（MVP）的概念一直让我着迷。在其最简单的形式中，它意味着构建你的想法的基本版本，这个版本在技术上可行，并将其展示在用户面前。是的，这是一个非常直接且广泛传播的建议，但它仍然是独立开发者最难遵循的原则之一，对我来说尤其如此。”
我之前提到过，我的“天才”应用创意开始有了发展。而且发展得非常迅速。我的创意多得不知道该如何处理，而我甚至还没有写出合理数量的代码！当然，这个应用可以进行增强，以支持面部识别、深色模式、高级安全、实时结果以及其他一系列功能。但是，对于一个你甚至不确定用户是否想要的应用来说，所有这些可能需要数月的开发时间。
我学会了问自己：“如果这个项目很容易构建，它会是什么样子？”。答案几乎总是与用户的需求一致，这真是太不可思议了。如果你能将你的宏大想法提炼成一个单一的不可或缺的想法，并且在一两个方面做得非常出色，我想你会像我一样发现，最终的结果会高度专注于解决真正的用户问题。
先推出最简单的版本。深色模式可以等等。你所需要的只是一个明确的想法、一个要测试的假设以及一个用于验证该假设的功能性原型；其他任何东西可能都是噪音。
优雅地处理不完美
你可能听说过“快速交付”的开发方法，并且能立即认识到它与我目前所讨论的内容之间的相似之处。从某种意义上说，“快速交付”最终是描述最小可行产品（MVP）的另一种方式：快速推出想法，并同样快速地对其进行迭代。
有些人可能不同意快速交付的方法，并认为它鲁莽和不专业，这是可以理解的，因为作为开发人员，我们非常关心我们工作的质量。然而。
“快速发布的心态不是忽视质量，而是尽快推出产品并从真实用户体验中学习。现在就发布——以后再完善。”
这就是为什么我喜欢告诉其他开发人员，推出最小可行产品是最安全、最专业的开发方式。它迫使你保持在范围之内并专注于任务，而不会屈服于你的突发奇想。我甚至在每个项目开始时都要立下“专注誓言”。
我，瓦约，在此庄严宣誓（一只手放在这份设计蓝图上），在这个应用以其最简化可行产品的全部荣耀完全建成之前，不做任何更改、不添加任何内容、也不增加任何额外功能。我承诺抵制无尽调整的诱惑以及“再增加一个功能”的想法。
只有当完成一个完整的原型时，我才会考虑任何新的功能、改进或调整。
签名， （请注意，单独的“signed”常见的翻译是“签署；签名；签字”等，这里结合语境给出“签名”的翻译表述，仅为一种参考。）
请记住，当你独立开发时，没有人在那里让你负责。花一点时间停下来，接受我的第一个版本不会是完美的，这有助于在项目早期让我处于正确的心态。
优先考虑重要的事情
我注意到，无论我构建什么，总是会有漏洞。总是如此。如果谷歌的谷歌笔记应用程序中仍然有漏洞，那么相信我，对于一个独立开发者来说，接受漏洞将永远是任何项目的一部分是没问题的。
看看不稳定的测试。例如，你可以运行一个测试一千次并得到全绿结果，然后第二天，你运行同样的测试，却出现了错误。这就是软件开发的本质。对于不断添加功能的情况，它也永远不会结束。总会有一个你感到兴奋的新功能。挑战在于“抑制一些这种热情，并在以后有意义的时候负责任地搁置它”。
我已经学会将错误和功能分为两种类型：侵入性的和非侵入性的。侵入性的是那些在修复之前会阻止项目正常运行的东西，比如崩溃和严重错误。非侵入性的项目是无声的。当然，它们应该被修复，但是如果不立即处理，产品也能正常工作，并且不会阻止用户获得价值。
你可能希望以其他方式对错误和功能进行分类，我也见过很多其他的例子，包括：
- 高价值，低价值；
- 高努力，低努力；
- 高成本，低成本；
- 必须有，最好有。
我甚至见过开发人员和团队使用这些分类来创建一些花哨的优先级“分数”，该分数会考虑每个类别。无论是什么能帮助你保持专注并完成任务，对你来说都将是正确的方法，而不是你使用的具体类别。
与你的技术栈共存
这里有一个发展领域的经典难题：
我应该使用 React 吗？还是 NextJS？或者等等，Vue 怎么样？我听说它更优化。但是等一下，我读到 React Redux 已经过时了，而 Zustand 是新的热门工具。
就这样，你花了一整天的时间只想着你用来构建那该死的东西的技术栈。
我们都知道，普通用户对底层技术栈并不关心。去问问你的妈妈，WhatsApp 是用什么技术栈构建的，然后告诉我她怎么说。大多数时候，只有我们会痴迷于技术栈，而且通常只有在我们被要求检查底层时才会这样。
我已经开始接受这样一个事实：每天都会有新的技术栈发布，承诺性能提高 50%且代码减少 10%。那个新工具可能扩展性更好，但对于我目前的零用户数量来说，我真的有扩展问题吗？可能没有。
我的建议：
选择最适合你的工具，并坚持使用这些工具，直到它们开始对你不利。
如果已经知道并且正在使用的东西能够完成工作，那么过早地与某些东西作斗争是没有用的。基本上，不要过早地进行优化或不断追逐最新的闪亮事物。
在编写第一行代码之前进行设计
我知道很多独立开发者在设计方面很糟糕，我可能也是其中排名前五十的。我的设计过程传统上是打开 VS Code，创建一个新项目，然后以任何想到的方式开始构建想法。没有设计资产、合成图或线框图可供使用——只有纯粹的、无结构的即兴创作。这不是一个好主意，这是我正在积极努力改掉的一个习惯。
如今，在开始编写代码之前，我一定会有一个我正在构建的东西的蓝图。一旦有了蓝图，我就一定会坚持到底，不做任何改变，以遵守我的“专注誓言”。
我喜欢很多团队将组件和线框图称为“项目制品”。它们是证据，为事物的外观和运作方式提供了真实来源。你可能是那种在有一系列需求时工作得更好的人，这完全没问题。但是在工作中有一些你可以参考的文档，就像在长途旅行中有逐向导航一样——对于到达你需要去的地方来说，它是不可或缺的。
如果你和我一样，并不以成为最好的设计师而自豪呢？那这又是一个提前承认自己弱点并从有这些优势的人那里寻求帮助的机会。这样，你就可以阐明目标，并专注于你擅长的事情。
为自己设定时间表
就个人而言，如果没有截止日期，我在拖延方面几乎是无法阻挡的。我在构建任何项目时都开始设定时间限制，因为这有助于克服拖延，并确保在特定时间推出一些成果。虽然没有责任感这一点就行不通，但我觉得这两者是相辅相成的。
我设定了一个 2 到 3 周的期限来完成一个项目。无论如何，一旦那个时间到了，我必须在我的社交媒体上发布或分享当前状态下的作品。正因为如此，我不再处于舒适区，因为我不想与公众分享一个未完成的项目；我习惯于更快地工作并把它全部完成。如果你能骗过你的大脑，看看你能坚持多长时间是很有趣的。
我意识到这是一个极端的限制，它可能对你不起作用。我只是那种需要知道自己的界限在哪里的人。设定最后期限并遵守它们会让我成为一个更自律的开发者。不仅如此，这还让我工作效率更高，因为当我知道自己有固定的时间量时，我就不再过度思考了，这会带来更快的成果。
总结
独立开发的最佳和最糟糕之处都在于“独立”这一部分。独立工作有很大的自由，而这种自由可能会激发灵感。然而，所有这些自由可能会令人陶醉，如果不加控制，就会成为生产力和进步的严重阻碍。这就是为什么独立开发并不适合每个人的一个很好的理由。有些人在团队环境中会表现得更好。
但是如果你是一个独立开发者，那么我希望我的个人经验对你有所帮助。很多天里，我都不得不认真审视自己，才意识到我不是一个能够独自构建出“完美”应用的完美开发者。要做出任何东西，尤其是做出完全正确且能做正确事情的应用，需要规划、自律和谦逊。
想法既廉价又容易产生，但走出我们的自由舒适区，并基于“进步重于完美”为自己增加约束，这是让我们不断前进并将时间花在那些重要事情上的秘诀。
