来自alexkrupp的这篇文章虽然是基于Django/Python编写,但是实践原则是通用的。
大多数现有的软件架构建议都是为 100 亿美元以上的公司编写的,因此往往侧重于最大化性能、可扩展性、可用性、可靠性等。
这实际上造成了一个巨大的问题。问题是,由于在大学学习计算机科学,大多数在初创公司工作的工程师没有接受过大量的业务培训。因此,经常发生的情况是,这些开发人员通过复制 Google 或 Stack Overflow 中出现的第一个建议来决定如何实现功能,而没有首先从业务角度评估该建议,而且由于这些建议中的大部分都是针对财富 500 强公司(在一个极端)或黑客马拉松类型的爱好项目(在另一个极端),这不可避免地会导致巨大的看不见的成本。
我编写本指南是为了解释如何以一种方式编写软件,以最大限度地增加您的初创公司成功的机会——无论团队规模、开发人员能力和未来不可避免但不可知的变化如何,都可以轻松保持开发速度。经验、产品功能等。这个想法是,考虑到固有的不确定性,初创公司可以通过放置一些基本系统来帮助最大化他们可以测试的想法、功能和假设的数量,从而大大增加成功的几率。
以下是构建 REST API 的一系列模式和最佳实践,专为满足 SaaS 初创公司和消费者应用程序的需求而设计。
哪些工具对初创公司最有价值?根据我的经验,答案是:可预测性、可读性、简单性和可升级性。
1. 可预测性
- 规则#1:每个端点都应该讲述一个故事
- 规则 2:将业务逻辑保留在服务中(banq注:复杂业务放入服务会膨胀它 变成面向过程)
- 规则 3:使服务成为可重用的场所 (banq注:可重用的服务就不是微服务,微服务需要替换,不注重重用)
- 规则 4:始终清理用户输入,有时保存原始输入,始终转义输出
- 规则 #5:默认情况下不要拆分文件,也不要拆分您的 URL 文件
2. 可读性
- 规则 #6:每个变量的类型或种类应该从其名称中显而易见
- 规则 #7:为文件、类和函数分配唯一的名称
- 规则 #8:避免在用户代码中使用 *args 和 **kwargs
- 规则 9:使用函数,而不是类
- 规则 #10:正好有 4 种类型的错误
3. 简单
- 规则 #11:URL 参数是一个骗局
- 规则#12:编写测试。不是很多。主要是集成。
- 规则 #13:将单元测试视为一种专业工具
- 规则 #14:负责任地使用序列化程序,或者根本不使用
- 规则 #15:将管理功能编写为 API 端点
4. 可升级性
本指南中的代码片段是使用 Python、Django 和DRF编写的,但它们有意设计为即使您不太了解 Python 或 Django 也易于理解。我已经使用这些代码片段创建了一个完整的应用程序,以确保它们可以正常工作,并在此处发布。选择 Python 的原因是它通常是 ARR 低于 1 亿美元的初创公司的最佳语言;作为所谓的第二好的语言,Python 为初创公司提供了最大的选择余地来试验不同的产品功能和货币化模型。但是无论您使用什么语言和 Web 框架,这些建议的大部分都是适用的。