我从没有规划过 Web 应用的经历中学到的东西（从开始到结束）

前端与后端分离。

先搞定基本功能。一次调试一件事。

我无法遵循自己的冲刺计划。

设计 API 时要考虑逻辑视觉效果

在进入计划的该部分之前，请先确定您的工具并阅读其文档。

不要浪费时间尝试学习新的框架

始终在本地进行测试

付费玩游戏很糟糕，但坚持下去可能是值得的。

给自己足够的时间来解决问题。

在申请工作之前，要确保你的项目和作品集万无一失。

我最近推出了《重要人物》，这是我拍摄了两年的一个艺术项目。

我十月份就部署好了，但维护和调试拖了一个多月。一部分原因是经验不足，另一部分原因是多个截止日期拖得太长了。

该网站以风格化的照片库为特色，展现了那些在我生活中扮演重要角色的男士的个人资料。前端使用 Tachyons 静态库；后端使用 Node/Express，使用 Sendgrid API 进行表单输入并发送嵌入表单的邮件。所有记录都收集在 MLab 上的 MongoDB 中，后端托管在 Heroku 上。

在与设计师进行了一些批评之后，我在 InVision 中制作了模型，但最后我的时间非常紧迫，我花了更多的时间来处理 api 响应和使项目适应 Heroku，而不是检查错误。

回想起来，我当时太专注于匹配我的设计，并希望网站比我之前的任何作品都更美观。但我完全忽略了http://www.importantmen.com/matt/ 上问答表单 API 行为的规划。
希望这篇文章能帮助大家避免我的错误。

前端与后端分离。

只要数据以 JSON 格式返回，我就可以随心所欲地操作它，无论我在哪个 URL 端点引用了 js 文件并发起了 fetch 请求。
一年多前，在一个 Angular 沉浸式课程中，我学到了路由应该在端点上服务特定的部分或文件（例如，“/”应该返回 index.html 等）。路由的作用是来回发送数据。路由的作用是来回发送数据。我一直得记住这一点。

先搞定基本功能。一次调试一件事。

与其用 StackOverflow 上的解决方案拼凑代码块（我压力大的时候会这么做），不如开发一些小型测试应用，逐行检查代码，最终实现一个功能，这比写十行乱七八糟、到处都出错的代码要好得多。我一度想添加更多功能，比如时间戳和用于评论的 Oauth 登录（在我看来，对于这么小的项目来说，这反而更麻烦），但我必须对自己的能力有清醒的认识。

我无法遵循自己的冲刺计划。

……所以我不如选择一个最高效、最吸引人的任务列表，我绝对会反复查看。对我来说，这个列表就是 trello。因为我有多个项目要收尾，所以把所有事情都放到 trello 的几个栏目里，把已经完成的都放到“已完成”栏目里，这样更现实。

设计 API 时要考虑逻辑视觉效果

我想如果不详细说明我的视觉导向思维如何只解释一组结果，我就无法解释这一点，但实际上要实现这些结果需要在后端代码中包含更多的条件和查询。

在显示已回答的问题的情况下，我没有想到：

1. 当问题回复发布时通过电子邮件通知用户
2. 仅显示包含问题和答案的记录，这样看起来问题就不会像没有答案或获取请求不起作用
3. 页面上有这么多向下切换标签来显示重要信息是不必要的（极简主义——实际上对功能的痴迷）
4. 在获取响应加载时包含加载器或某种视觉提示，但这也可能是过度的

必须弄清楚这些“未定义”的含义

在进入计划的该部分之前，请先确定您的工具并阅读其文档。

我没有考虑过部署，只对 AWS buckets 有一些基本的了解。在发布前夕学习如何配置服务器风险太大，所以 Heroku 看起来是个不错的选择，因为我已经熟悉 git 了。

不要浪费时间尝试学习新的框架

（特别是在最后期限前），如果您还没有准备好在生产中使用它。

对于页面数量少于 10 页的网站，它可能只是额外的膨胀，并引入不必要的耗时的学习梯度。

上图：部署几周后发生的众多恐怖事件之一。

始终在本地进行测试

如果部署到 Heroku 后出现问题，请恢复到本地测试，并创建一个虚拟页面（“我们正在处理”）。冲动的测试导致我在 Heroku 上测试了太多版本，以至于我忘记了对后端代码做了哪些更改。这样 MongoDB 的 Console.logs 也会更清晰易读。（如果我错了，请纠正我）

付费玩游戏很糟糕，但坚持下去可能是值得的。

我不知道我的一个获取请求的查看时间长达 15 秒！

如果你需要它以闪电般的速度运行，那么购买 Heroku Hobby 套餐或许值得。我听说过很多关于在 Heroku 上免费托管小型项目的好处，但如果预期的行为停滞不前，服务器会在半小时不活动后进入睡眠状态，需要通过请求“唤醒”，那么这毫无意义。我听说有人编写脚本，每半小时唤醒一次服务器，这样它就不会进入睡眠状态。对于压力很大的人来说，这似乎需要做很多额外的工作。

给自己足够的时间来解决问题。

...就像最后冲刺的 1.5 倍。

我没有，所以最终我启动了一个功能只有 80% 的项目，然后在接下来的一个月里推迟了推广，直到整个问答功能都运行起来。事后看来，我应该制定一个部署前的检查清单，以便完成以下收尾工作：

• 创建 robots.txt 以允许网页抓取和索引
• 测试 Facebook 和 Twitter 的 Open Graph 元标签，以确保链接共享的图片和标题预览功能
• 让多个用户测试网站链接
• 使用 chrome devTools 检查性能时间
• 确保人们能够通过链接和输入字段进行切换
• 检查页面在不同设备上的显示效果
• 确保我可以通过输入或按钮来获得焦点（可访问性）

这个清单还可以继续列下去，但这些是我真的希望做的事情。

在申请工作之前，要确保你的项目和作品集万无一失。

上线后就公开了，任何失败的体验都可能对我这个开发者和中期数字艺术家的形象造成负面影响。我当时真的不得不克制住自己对职业的渴望。

感谢阅读我的新手心得。请问您部署前的检查清单和工作流程是怎样的？