应用程序后端：针对不能犯错误的小型团队的最佳实践

小团队拥有令人羡慕的优势和无声的风险。优点是速度：人员少，官僚主义少，决策快。风险在于，每一个错误的选择都会带来更大的影响，因为没有人留下来扑灭它引起的火灾。

在后端，尤其如此。它是产品逻辑、数据和可靠性所在的层。脆弱后端上的美丽前端就像沙上的城堡。当你有两个、三个、五个开发人员时，你就无法支持需要一个营才能运行的架构。

本文汇集了专为小型团队设计的良好后端实践。这里的标尺不是大公司所做的，而是当每个工程时间都很宝贵并且没有无谓的复杂性的空间时才有意义。

黄金法则：简单是竞争优势

在小团队中，复杂性是敌人。每增加一个架构，都需要在黎明时理解、维护、监控和修复。而你只有几个人来完成这一切。

因此，第一个好的做法是抵制模仿巨头建筑的诱惑。微服务、复杂的消息传递、容器编排，所有这些都为大公司解决了实际问题，也为小团队带来了新的问题。一个良好的、组织良好的整体架构可以让初创公司走得比大多数人承认的要远得多。

面对每一种技术选择时要问自己的问题是：这是否解决了我今天遇到的问题，或者我想象有一天会遇到的问题？小团队无法支付第二次的费用。

采用新的语言、流行的银行、处于巅峰的框架是有魅力的。在小团队中，这种魅力是一个陷阱。

整合技术拥有文档、社区、市场上可用的人员以及针对您将遇到的问题的现成答案。新技术几乎没有这种能力，当你崩溃时，它会自行崩溃。对于一个大团队来说，尝试是很便宜的。对于一个三人团队来说，每花一个小时与一个不成熟的工具作斗争，就相当于一个小时没有花在产品上。

选择您知道的[数据库0。选择团队高效的语言。你的初创公司的创新应该在于产品及其解决的问题，而不是技术堆栈。无聊的技术可以释放能量，去做重要的事情。

有些做法会带来不成比例的努力回报。这些是我会优先考虑的：

建模良好的数据库：大多数后端问题都是由结构不良的数据引起的。一开始在数据模型上投入时间可以节省几个月的时间。这是地基，在房子还矗立着的情况下重新打地基是很痛苦的。
代码外部的配置：秘密、密钥和环境参数永远不会在存储库内。这避免了经典的泄漏，并使在不同环境中运行相同的代码变得更容易。
体面的日志：您没有运营团队来调查问题，因此系统需要告诉您发生了什么。当出现问题时，精心制作的日志记录是您唯一的侦探。
版本化数据库迁移：数据结构更改必须可跟踪且可逆。直接在生产过程中手动更换座椅，就像不系安全带开车一样。
显式错误处理：决定出现故障时会发生什么。被默默吞没的错误是一种只有在客户抱怨时才会出现的错误。

这些实践都不需要昂贵的工具或外来知识。他们需要纪律，这同时也是最廉价和最稀缺的资源。

小团队在压力下工作，压力会导致人为错误。防御措施是将可以自动化的事情自动化，尤其是部署和测试。

它不必很复杂。自动化的部署过程，即使是一个简单的过程，也可以避免晚上十一点上传错误版本的错误。对关键路径、登录、支付、主要流程的一些[自动化测试1]可以防止快速修复在没有人注意到的情况下破坏重要的东西。

我们的目标不是完美的测试覆盖率，这对于大型团队来说是一种奢侈。它是在保护一旦发生故障就会损害现金流或客户信任的东西。这里的自动化并不意味着复杂，而是复杂。对于那些可能会犯错误的人来说，这是一张安全网，因为他们是人，而且他们在奔跑。

有一种纯粹主义言论谴责所有技术债务。在小团队中，这种言论是不现实的。你会走捷径，而且你走一些捷径是对的。问题不在于债务，而在于债务。这是看不见的、被遗忘的债务。

有意识的技术债务是一种商业工具。您决定现在做一些简单的事情，因为您知道稍后需要重新审视它，以便更快地交付价值。这是合法的。致命的是那些没有人登记、没有人记得、在最糟糕的时刻毫无征兆地爆发的债务。

成熟就是选择在哪里走捷径，在哪里不走捷径。辅助功能的快捷方式，很好。在数据安全、访问控制、[LGPD2?下的个人数据处理中的捷径，那么捷径就是炸弹。知道如何区分一个团队是幸存的小团队与崩溃的团队的区别。

对于小团队来说，后端是一项重点练习。这不是要做最复杂的事情，而是在重要的事情上做得足够好，并抵制其他一切。

简单、已知的技术、坚实的基础、基本要素的自动化和有意识的技术债务。这五个想法让一个小团队取得了惊人的成就。我看到的大多数问题不是来自于技术能力的缺乏，而是来自于架构野心太大太早。

如果您领导着一个精益团队，并且正在制定的后端决策将在未来几年给您带来压力，那么在考虑复杂性之前值得仔细考虑。博客上还有其他有关架构、可扩展性和产品的文本与此相关。