从前到后构建软件

2020-05-15 00:53:36

在过去的几年里,我已经(出于兴趣和需要的结合)转变为一名全栈开发人员。在这段时间里,我的前端功夫确实提高了很多。然而,我知道我不会因为对CSS技巧的创新贡献而获得任何奖项。我认为我甚至不会像现在从事后端更改那样感到舒服。

由于这种偏见,在实现完整堆栈更改时,我总是从后端开始。我将构建一个服务层,创建一个数据库模式,编写一系列测试,并最终围绕我的数据结构构建API。从我最强的那部分开始,以后再弄清楚其余的部分,感觉很好。

这一切都是倒退的,这会导致心痛。你甚至可以说这是从后到前(停顿以换取掌声)。

我经常以不太正确的API端点结束,这导致了在客户端聚合一些资源的诱惑。我不是视图层中聚合逻辑的狂热粉丝,所以我通常会在API达到黄金时间之前提交后续合并请求来更改API。这是浪费时间,对我和评论者来说都是相当令人沮丧的。

最近我在做一些有点不同的事情。我从前到后一直在工作。我一直在使用模拟数据在UI上预先创建我希望看到的用户体验。我通过将数据硬编码在客户端存储中用于单页面应用程序,或通过在控制器中硬编码模型用于多页应用程序来实现这一点。通过这种方式,我可以在投入太多时间之前尝试一些大小的东西,并从团队那里获得反馈。我甚至可以将其部署在功能切换之后,让一些alpha用户在开发周期的早期给出反馈。

我现在对我在整个工作中试图实现的目标有了一个更明确的想法。起初,我认为我的基于REST的API方法会转变为RPC over HTTP。我担心它会将UI功能与API紧密耦合,但事实并非如此。我的端点稍微重一些,但它们的结构要合理得多。

有趣的是,我意识到我现在对整个堆栈都很满意,以这种方式实现功能丰富/数据少的更改要快得多。我最近一直在使用StimulusJS(我在这里谈到了它),并一直将HTML表单视为我的应用程序的基本构建块。也许Visual Basic的以表单为中心的方法终究是针对某件事的呢?

我猜想,我之前从后端构建更改的倾向更多地是出于安全考虑,而不是任何明确的决定。我很想知道其他后端开发人员在过渡时是否会经历这个过程。前端开发人员最终会发生相反的事情吗?