Buy Database

对我们的技术堆栈、内部流程和工程原理感到好奇吗？

作为一个以产品为中心的小型团队，我们发现有一个指导原则对于简化技术决策很有用。

我们中没有人痴迷于特定的技术或编程语言。与采用最新的框架相比，我们更关心如何提供用户价值。

我们喜欢经得起时间考验的林迪工具，并且自豪地成为新工程趋势的晚期采用者。

大多数技术决策都可以追溯到久经考验的原则：

保持简单
为什么我们要让事情变得简单
简单是可靠性的先决条件。

优秀的程序员构建可靠的系统。因此优秀的程 mint 数据库 序员专注于理解和寻求简单性。

简单是一个迷人的词。这个词的词源是sim和plex，意思是一次折叠或一次扭曲。而这种关于一次扭曲的特性意味着它不能被扭曲。

简单的反义词是复杂，即折叠在一起。

如果我们想要开发可靠的软件，就需要保持其简单性。这意味着我们需要确保它不会像耳机一样折叠在一起并缠结在一起。

我们如何让事情变得简单合作
我们重视个人贡献，而不是合作。

当n个人需要相互交流时，随着n 的增加，产出会减少。

协作会增加输出的复杂性，遵循以下公式：n ( n − 1)/2

我们目前有 6 个人。因此 6 × (6 - 1)/2 = 15 个沟通渠道。

每位团队成员都会影响我们的执行效率。由于创业公司都讲究速度，因此我们需要谨慎处理这个问题。

因此，我们早期的团队仅由经验丰富的个人贡献者组成。

就像手术过程中的手术团队由一名外科医生领导，执行最关键的工作，同时指挥团队协助处理不太重要的部分一样，我们让项目所有者开发关键的系统组件，而团队的其他成员则在适当的时间为他们提供所需的东西。

每个项目都有一个明确的问题需要为我们的最终用户解决。

每个项目都有一个负责人，负责了解、确定范围、设计和指导工作，直到问题得到解决。

这是我们用来跟踪项目进度的 Google 文档模板：


工具
以无聊的方式构建

我们以最无聊和最武断的方式使用久经考验的技术。

这意味着我们试图尽可能地坚持快乐路径并以最标准的方式做事。

因此，我们选择编程语言和框架变得非常容易。我们使用 Rails 作为后端，使用 React 和 Typescript 作为前端。

即使使用 React，我们也以无聊的方式进行，例如使用 Redux 进行全局状态管理。

购买而非建造

SaaS 工具不会增加沟通负担，也不会分散我们的目标。

因此，根据经验法则，对于所有不是我们试图解决的核心问题的问题，我们都会购买最好的现成解决方案。

即使解决方案比内部构建和维护某些东西更昂贵，但如果我们从意外的复杂性中释放出一些精力，我们就可以将更多的注意力集中在我们的目标上。

送货
发货由两部分组成：编写代码并将其发布给用户。

添加新功能需要软件进行更改。同时发生的更改越多，两个版本之间的转换就越复杂。

因此，我们对软件进行更改的方式是添加和部署小的增量更改，然后将其部署给我们的用户。

我们不发布产品，也不进行准备。我们始终直接向客户发布产品。

我们所构建的所有内容都会被分解为每周的任务，并在我们的每周更新日志中分享。

我们发送的每一行代码都会在 2 分钟内部署到所有最终用户的生产环境中。

当功能处于开发阶段时，我们会在功能标志下发布它们，并首先为我们的测试帐户启用它们，然后慢慢地向所有用户启用。这意味着如果我们发布了一个有缺陷的功能，我们不需要回滚一个大的更改，但我们可以直接为受影响的用户关闭该功能。