当你是初创公司或成长型项目的开发人员时，掌握大量技术并知道如何构建复杂、高负载的服务显然是不够的。在我的职业生涯中，我参与过许多成长型项目，并从零开始创建了两家初创公司。在本文中，我将分享我的经验，关于在开发过程中应该关注什么，以及为什么完美主义会毁掉最好的想法。 工具是手段，不是目的 对于每个开发人员来说，独自启动一个项目都是一项艰巨的挑战。感觉你需要把每件事都做得完美是很自然的。我花了一段时间才意识到，对完美的渴望往往是担心同事会因为我多出的“打印件”或不使用模式或工具而评判我的反映；情况就是这样：生产服务器会崩溃，客户会抱怨，我会被解雇，世界会走向末日。 任何工具、模式或编程语言都 ，而不是目标。更常见的问题是：为什么我现在需要它？它能提供什么？它会改善哪些指标？例如：为什么现在配置 linter？为什么现在定制 CI/CD？如果您每天部署 10 次，那么您可能需要它。如果您每周或每月部署一次版本，则很可能不需要它。如果 CI/CD 定制需要花费大量时间，但不会加快开发速度或为项目和客户带来价值，那么现在就应该实施吗？ 只是一种工具 在宠物项目中，尝试新事物是有意义的：不断改进存储库和代码的结构，试验模式等等。 。生产项目的主要目标是为客户提供价值。客户永远不会知道我们使用双引号而不是单引号和单例，并且没有硬编码。 在这种情况下，我们实施的工具就是目标 只有当重构能够提高开发速度和性能、减少错误或解决积压问题时，重构才是必要的。 对质量的承诺应该追求产品的目标，而不是追求完美主义。因此，重要的是要记住：成长型项目中的开发人员永远不是完美主义者。 商业价值至上 对于一个处于成长阶段的项目的开发人员来说，了解业务价值至关重要。当你习惯于成为一名仅按照现成规范编写代码的普通开发人员时，一开始可能会很有挑战性。 当产品刚刚诞生时，它对用户的价值尚未得到证实，但需要证实的价值存在于利益相关者的心中。在这个阶段，你可能会犯一个错误，即用不必要的逻辑重载代码库。例如，你需要编写一个订单处理程序。你在数据库中创建一个包含订单的表，并创建一个包含订单类型的表，尽管目前只有一种类型。 假设您这样做是因为利益相关者坚持认为将来有一天可能需要这种逻辑。实际上，可能永远都不需要。如果现在没有价值，就不要生成不必要的实体，更重要的是，不要浪费业务时间和金钱。 你可能会问一个合理的问题：“我会和利益相关者争论吗？”嗯，有时你会的。利益相关者希望得到详细的分析。项目发展的具体细节通常是缺乏资源，因此开发人员必须具备分析技能。你需要不断验证产品功能的价值，因为产品的可行性实际上取决于它。 如果您分散精力，企业就会耗尽资源，并且您将会存档存储库。 多问问题：“为什么现在实现这个功能？我们现在应该解决这个问题吗？这个问题真的存在吗？”这与上面描述的技术完全一样。能够提出正确的问题表明你的专业性。 你只需要把你的时间和业务资源花在真正能为客户带来价值的事情上。 黑客马拉松是一个很好的例子，展示了理解商业价值如何影响结果。在有限的时间内，必须针对明确定义的问题提出一个非理想但可行的解决方案。当开发人员受到项目的启发并清楚地了解他们为什么要这样做时，即使在 2 天内也会有很好的结果。 计划取决于风险 想象一款策略游戏：你有一个伐木工和一个新兵。目标是培养一名战士。首先，伐木工必须收集木材并建造兵营，新兵可以在那里接受军事训练。为了采伐木材，伐木工需要通过地图上未开发的部分到达森林。从地图上看，一个游戏日就可以到达森林，砍伐木材大约需要半天时间，建造兵营需要一周时间。所以兵营大约十天后就会出现。 伐木工花了将近一天的时间才到达森林，但突然一条河挡住了路。目标发生了变化：我们必须建造水坝、桥梁或船只才能到达对岸，或者最好在其他地方寻找森林。过早评估会导致战略失败。如果侦察兵先探索地图上未被发现的部分，这种风险就可以避免。 经验丰富的开发人员能够识别利益相关者不明显的风险：与第三方服务的集成、扩展代码库的复杂性等等。评估风险并发出警告是您的责任。利益相关者通常不知道这些风险，但它们会影响评估，这对他们来说很重要。 将您的服务与支付服务集成。首先，设置支付服务，获取访问权限，并调查可能出错的地方。在集成之前，了解如何集成。最好花一天时间进行研究，而不是在开发两三周后才发现该功能无法按时完成或集成失败，因为支付服务更改了条款或禁用了对所需功能的支持。 示例任务： 确定风险后，您需要规划工作并为任务提供时间估算。这是我使用的框架： 写下场景或在黑板上将其形象化：例如，用户点击按钮，文档就被下载。选择您理解的方法。 从更技术的角度分析脚本如何工作。选项越多越好。我会评估这些选项，然后选择一个具有最大风险且可以最快解决问题的潜在可扩展解决方案。 将场景分解为需要编码的逻辑部分。 用天数估算每个部分，然后乘以 1.11 系数。这是我的个人魔法系数，也就是我的生日 10 月 11 日。当然，这是个玩笑（或不是）。我的建议是，根据项目范围，在估算中多加几天甚至几周。虽然我们试图预见尽可能多的风险，但有些风险是无法预见的。最好尽快完成任务，而不是失败。 不要害怕给出更大的估计：当利益相关者问“你不能做得更快吗？”时，不要只回答“不行”，而要解释原因。讲述风险、演示场景并举例说明。利益相关者需要明白，你已经分析了问题，而不是随意评估。 重要一点：你的精神状态也是一种风险。规划你的假期，关注你的心理健康，保持积极性，避免倦怠：这是你的责任。 MVP 不是宇宙飞船 这个问题困扰了我整个职业生涯。听起来很简单 - 最小可行产品。 “如何创建 MVP？” 维基百科定义： 最小可行产品 (MVP) 是产品的一个版本，仅具有足够的功能供早期客户使用，然后他们可以为未来的产品开发提供反馈。 我经常发现，当你需要构建 MVP 时，有时它最终更像是建造一艘耗时极长的宇宙飞船。MVP 阶段的主要目标是从客户那里获得快速反馈，并根据此反馈与利益相关者达成一致，我们是“直行”还是“右转”。收集反馈的最佳方式是指标。如果没有指标，他们也能成功，这很好，但如果没有，至少你会知道原因。 我来介绍一下我的第一个 MVP。我找到了很多工具和框架： 。我决定使用所有这些，因为这些框架在大型公司内部使用，而且我在会议、讲座和 YouTube 上听说过它们。 UML、设计模式、路线图、故事点、系统需求规范、ADR、UI 测试等等 该服务的目的是存储有关测试运行的数据。我花了一年时间制定了路线图，用 绘制了详细的架构，花了很长时间选择后端框架，在 Sentry 中设置了测试和日志系统，并计算了许多用户的负载，而不是预期的 10-15 个。我想做一个完美的项目。 UML 第一个版本花了 6 个月才完成。你可以查看所有的发布和图表并下载报告，但数据收集存在问题。每周会出现两三次损坏的报告，导致服务无法使用，但我还是坚持按照计划行事。 在接下来的几年里，我接手了许多不同的项目，并尝试创办自己的初创公司。我了解了营销、销售和客户痛点。这段经历改变了我的思维方式，让我能够开发出我在本文中分享的方法。我将描述最近的一项任务，以展示它们在实践中是如何运作的。 我需要加快 API 方法的速度，因为它的速度太慢，让用户很恼火。计划是将其从整体式架构中移出，成为一个单独的服务，但由于与内部服务和数据结构的大量集成，这带来了困难。这个项目是实验性的——没有人知道是否可以加速。 当然，我可以继续建议重写所有内容并使其完美。我首先研究了整体和内部服务，并调查了集成的风险。然后，我使用 Miro 中的简单图表创建了一个策略，将所有内容分解为迭代，然后才开始工作。 有时，集成中会出现问题，利益相关者是第一个知道的。首先，我们解决了这些问题。是的，项目中仍然存在技术债务：linters、不完整的测试、数据库中的旧模式 - 但客户的问题已经解决了。 在每次迭代中，我都会收集有关 API 方法执行情况的指标： 缓慢、有错误、无法发布。 速度快 2 倍且有错误，无需发布。 5x，所有请求均有 1% 的错误。 速度快 6 倍，且无错误。 所有迭代都达到了目标，第四次尝试时，我们达到了 100%。从头开始重写所有内容需要 10 次迭代，但即使在更短的时间内，我们也获得了一个可扩展的服务来解决问题。唯一的问题是方法。 正在成长的项目开发人员的守则 放弃完美主义。虽然这个世界充满了解决问题的技术，但你不需要了解一切才能让项目对人们有用。 尽可能使用现成的解决方案。 商业价值是第一位的。用户来这里不是为了产品，而是为了解决问题。 从一开始就评估风险，并以清晰的方式将其传达给利益相关者。 制定短期计划。如果该任务已经积压两年，则很可能用户不需要它。 用各种可能的方式收集反馈和指标。指标是找到增长点的可靠方法。 即使一开始没有使用“正确”的工程模式，也可以实现可扩展的解决方案。
