三周内构建 JavaScript 全栈 web 应用
|
我们还在 Waffle.io 网站上创建了敏捷开发的面板，它是免费的，很容易集成到 Github。我们在 Waffle 面板上罗列出所有用户故事以及需要我们去修复的 bug。之后当我们开始编码时，我们每个人会为自己正在研究的每一个用户故事创建一个 git 分支，在完成工作后合并这一条条的分支。 我们还开始保持晨会的习惯，讨论前一天的工作和每一个人遇到的阻碍。会议常常决定了当天的流程 —— 哪些人要结对编程，哪些人要独自处理问题。 我认为这种类型的工作流程非常好，因为它让我们能够清楚地找到自己的定位，不用顾虑人际矛盾地高效执行工作。 第 5 步： 选择、下载样板文件由于 JavaScript 的生态系统过于复杂，我们不打算从最底层开始构建应用。把宝贵的时间花在连通 Webpack 构建脚本和加载器，把符号链接指向项目工程这些事情上感觉很没必要。我的团队选择了 Firebones 框架，因为它恰好适用于我们这个情况，当然还有很多可供选择的开源框架。 第 6 步：编写后端 API 路由（或者 Firebase 监听器）如果我们没有用基于云的数据库，这时就应该开始编写执行数据库查询的后端高速路由了。但是由于我们用的是 Firebase，它本身就是云端的，可以用不同的方式进行代码交互，因此我们只需要设置好一个可用的数据库监听器。 为了确保监听器在工作，我们用代码做出了用于创建目标（Goal）的基本用户表格，实际上当我们完成表格时，就看到数据库执行可更新。数据库就成功连接了！ 第 7 步：构建 “概念证明”接下来是为应用创建 “概念证明”，也可以说是实现起来最复杂的基本功能的原型，证明我们的应用 可以 实现。对我们而言，这意味着要找个前端库来实现时间线的渲染，成功连接到 Firebase，显示数据库中的一些种子数据。 
Victory.JS 绘制的简单时间线 我们找到了基于 D3 构建的响应式库 Victory.JS，花了一天时间阅读文档，用 VictoryLine 和 VictoryScatter 组件实现了非常基础的示例，能够可视化地显示数据库中的数据。实际上，这很有用！我们可以开始构建了。 第 8 步：用代码实现功能最后，是时候构建出应用中那些令人期待的功能了。取决于你要构建的应用，这一重要步骤会有些明显差异。我们根据所用的框架，编码出不同的用户故事并保存在 Waffle 上。常常需要同时接触前端和后端代码（比如，创建一个前端表格同时要连接到数据库）。我们实现了包含以下这些大大小小的功能：
有各种原因，这一步花了我们很多时间 —— 这一阶段是产生最多优质代码的阶段，每当我们实现了一个功能，就会有更多的事情要完善。 第 9 步： 选择并实现设计方案当我们使用 MVP 架构实现了想要的功能，就可以开始清理，对它进行美化了。像表单，菜单和登陆栏等组件，我的团队用的是 Material-UI，不需要很多深层次的设计知识，它也能确保每个组件看上去都很圆润光滑。 
这是我制作的最喜爱功能之一了。它美得令人心旷神怡。 我们花了一点时间来选择颜色方案和编写 CSS ，这让我们在编程中休息了一段美妙的时间。期间我们还设计了 logo 图标，还上传了网站图标。 第 10 步： 找出并减少 bug我们一开始就应该使用测试驱动开发的模式，但时间有限，我们那点时间只够用来实现功能。这意味着最后的两天时间我们花在了模拟我们能够想到的每一种用户流，并从应用中找出 bug。 
这一步是最不具系统性的，但是我们发现了一堆够我们忙乎的 bug，其中一个是在某些情况下加载动画不会结束的 bug，还有一个是资源组件会完全停止运行的 bug。修复 bug 是件令人恼火的事情，但当软件可以运行时，又特别令人满足。 第 11 步：应用上线最后一步是上线应用，这样才可以让用户使用它！由于我们使用 Firebase 存储数据，因此我们使用了 Firebase Hosting，它很直观也很简单。如果你要选择其它的数据库，你可以使用 Heroku 或者 DigitalOcean。一般来讲，可以在主机网站中查看使用说明。 我们还在 Namecheap.com 上购买了一个便宜的域名，这让我们的应用更加完善，很容易被找到。 
好了，这就是全部的过程 —— 我们都是这款实用的全栈应用的合作开发者。如果要继续讲，那么第 12 步将会是对用户进行 A/B 测试，这样我们才能更好地理解：实际用户与这款应用交互的方式和他们想在 V2 版本中看到的新功能。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
