直接构建：我们如何设计 Streamlit 来引导您取得进步-Python教程-PHP中文网

最初由 Thiago Teixeira 在 Streamlit 博客上发布

如果您正在阅读本文，您可能已经熟悉 Streamlit。如果没有，这里有一个总结：Streamlit 是一个用于构建数据应用程序的 Python 框架。它固执己见，包含电池，并且与特定的设计系统紧密相连。

它专注于数据应用。我们所做的一切都源于此。我们的目标不是手机上的通用应用程序或您最喜欢的 SaaS，而是数据科学家和机器学习工程师需要使他们的工作对组织产生影响力的应用程序类型。
这是固执己见的，因为我们希望促进快速、迭代的工作流程，并坚持我们认为的工程最佳实践。
它包含电池所以您开始使用所需的大部分内容都在库本身中。
最后，它与设计系统相关，因此您无需花时间构建组件库、视觉语言或标识。您才刚刚开始，而且速度很快。

此时，我可以告诉您我们是如何开始 Streamlit 的。根据我们之前在工业界和学术界的经验，关于它是如何从良好的预感开始的。关于我们如何深入不同的公司并观察他们的数据科学家和机器学习工程师的工作方式以塑造 Streamlit。但 Adrien 在 5 年前就已经做得很好了，我认为我无法超越！

因此，我将讨论我们对数据应用程序的深度关注如何转化为我们每天做出的产品决策。为此，我将从一个故事开始......

10 名新员工

曾几何时，一个数据科学团队为公司最重要的指标构建了一个强大的预测模型。财务团队看到了它并且很喜欢它，然后要求提供一个可以在每周会议中使用的实时版本。因此，数据团队向工具团队提出了构建数据应用程序的请求，工具团队将其放入队列中。

三个月和多次会议后，应用程序交付了，它很漂亮。

但有一个问题：当财务部门尝试时，这并不是他们所需要的。因此，他们向数据团队提出了另一个请求，数据团队将其传递给工具团队，工具团队将其放入队列中。几个月过去了。

此时，一位毫无戒心的新员工加入了数据团队，并被分配了一个启动项目：在等待工具团队的真正的应用程序时，组装一个快速数据应用程序来解锁财务团队.

经过一番谷歌搜索后，新员工发现了 Streamlit，并在一天之内就能够与同事共享一个最小的应用程序。它并不完美，但她解决了一些反馈并更新了应用程序。第二天，她向财务团队的联系人展示了该应用程序，获得了更多反馈，并相应地改进了应用程序。

三天之内，财务团队在会议中定期使用该应用程序。他们收到了更多反馈，新员工很快在新版本中解决了这个问题。

一周之内，首席执行官就开始使用该应用程序，新员工被誉为英雄？

为什么会发生这种情况

我们已经无数次看到这个故事发生了。新员工的应用程序最终获胜的原因是今天的简单应用程序比晚了三个月的过度设计的应用程序要好。

事实上，这正是最好的初创公司构建产品的方式！他们发布最小可行产品（MVP），尽快将其交到客户手中，并不断迭代。

在此过程中，他们逐渐强化底层基础设施。因为新员工的故事有一个推论：随着团队继续使用该应用程序，他们逐渐将其生产化。

那套定制的 Pandas 转换速度超级慢？他们将其拉入单独的数据管道和一些物化表中。

其他应用想要使用的复杂计算？他们将其转移到 RESTful 服务中。随着应用程序的发展，他们将其重构为多个页面。他们编写测试，建立 CI。该应用程序变得防弹。

此流程的好处是显而易见的：

您可以构建更好的应用程序，因为在尝试之前您通常不知道自己需要什么。因此，通过构建和用户测试，然后再次构建和用户测试，你最终会得到一个更好的应用程序，而不是提前计划好整个事情，但后来才意识到这不是你想象的解决方案。
从第一天起您就获得了价值。当您构建和用户测试时，您已经拥有了一个有用的应用程序。而且它只会变得越来越有用。
您不会过度构建。您不必在构建应用程序的同时构建管道，只需将应用程序拿出来，然后在证明其有用性时对其进行强化。然而，并非所有应用程序都有用，也并非所有有用的应用程序都存在足够长的时间以需要强化。因此，您只会将宝贵的大脑周期花在既有用又持久的应用程序上。

开始的方式很简单：只需构建它。

用心设计

我们认为新员工的故事发生在这么多不同的公司绝非偶然。我们喜欢认为这个故事的发生是因为我们有意设计 Streamlit 来促进前进。

当您第一次开始编写应用程序时，前进进度意味着在 5 分钟内完成一份草稿，并且在某些方面已经有用。毫无疑问，让应用程序变得更有用的一件事就是交互性。因此，从一开始，我们就有一种强烈的感觉，那就是我们应该让交互性尽可能简单。

例如，您不必创建一个带有滑块的“视图”，然后创建一个带有回调函数的“控制器”来修改滑块使用的“模型”（换句话说，MVC 范例）。相反，我们想出了一个单行解决方案：

value = st.slider("选择一个数字", 0, 100)

您输入该内容并得到一个已经执行某些操作的应用程序。 前进！

然后，在两年后构建 Session State 时，我们很快了解到所提出的 API 很容易导致差一错误，而唯一有效的解决方案是回调。我们过去使用 MVC 和类似范例的经验给我们带来了创伤，我们花了相当多的时间来解决这个问题，想出了一个明确的“Streamlit-y”版本的回调，避免了所有的复杂性。而且 - 更重要的是 - 该解决方案不会强迫您从一开始就使用回调，而是允许您稍后根据需要对它们进行分层。 前进！

另一个对我们（当然还有社区）来说很亲近的例子是造型。一方面，我们要做的最简单的事情就是直接在 Streamlit 中添加对 CSS 的支持，例如 st.css(...) 或 st.write(..., style="css 位于此处”）。但当我们尝试它时，我们注意到不受限制的样式访问很快就会成为前进的障碍。人们并没有将第一个版本提供给利益相关者，而是陷入了梳理 MDN、对抗级联、调整选择器以及痴迷于单个像素的困境。而且，最糟糕的是，最终结果往往是不稳定且分散注意力的。

因此，我们通过问自己以下问题来解决这些请求：

“人们试图解决的根本问题是什么？”
“这个问题有多常见？”
“我们可以自己解决这个问题并帮助解放开发者吗？”

根据这些问题的答案，我们采用以下两种方法之一：

为问题提供单行、固执己见的解决方案

这件事发生在几个月前。我们注意到大量开发人员使用 CSS hacks 将徽标放置在应用程序的左上角，因此我们决定为他们提供 st.logo() 的单行解决方案。这个新命令绘制他们的自定义徽标，使其响应侧边栏的状态，确保它不重叠任何内容，并且默认情况下看起来不错。

这也是我们添加文本颜色、标题下的线条、容器周围的边框、垂直对齐、材质图标等的方式。它们在视觉和行为方面当然是固执己见的解决方案，但优点是您只需说出您想要的内容，Streamlit 就会做到，然后您就可以继续进行下一件事。 前进！
提供一组精选的旋钮……然后观看

当单行固执己见的解决方案无法解决问题时，我们会引入一组最小的“旋钮”，观察结果并进行迭代。由于我们不想破坏兼容性，因此我们的大多数功能都是单向门，这意味着我们必须谨慎行事。

一个例子是主题。每个人都希望他们的应用程序与公司的颜色相匹配，当然，确切的颜色因公司而异。但 Streamlit 的界面由几十种颜色组成，选择一种视觉上令人愉悦的组合可能会花费几个小时。因此，我们解决这个问题的第一个尝试是让您只选择 4 种颜色，Streamlit 会为您计算所有其他颜色。 前进！

我们现在正忙于在幕后思考针对这个问题的第二次尝试——一个扩展的解决方案，为您提供更多的旋钮（甚至超越颜色！）而不牺牲迭代速度。同样，我们也在考虑除列之外的新的、更灵活的布局选项。

我们现在没有什么要宣布的，但请务必留意？