編譯自： https://medium.com/ladies-storm-hackathons/how-we-built-our-first-full-stack-javascript-web-app-in-three-weeks-8a4668dbd67c

作者： Sophia Ciocca

應(yīng)用 Align 中，用戶主頁的控制面板

從構(gòu)思到部署應(yīng)用程序的簡單分步指南

我在 Grace Hopper Program 為期三個(gè)月的編碼訓(xùn)練營即將結(jié)束，實(shí)際上這篇文章的標(biāo)題有些紕漏 —— 現(xiàn)在我已經(jīng)構(gòu)建了 三個(gè) 全棧應(yīng)用： 從零開始的電子商店 、我個(gè)人的 私人黑客馬拉松項(xiàng)目 ，還有這個(gè)“三周的結(jié)業(yè)項(xiàng)目”。這個(gè)項(xiàng)目是迄今為止強(qiáng)度最大的 —— 我和另外兩名隊(duì)友共同花費(fèi)三周的時(shí)光 —— 而它也是我在訓(xùn)練營中最引以為豪的成就。這是我目前所構(gòu)建和涉及的第一款穩(wěn)定且復(fù)雜的應(yīng)用。

如大多數(shù)開發(fā)者所知，即使你“知道怎么編寫代碼”，但真正要制作第一款全棧的應(yīng)用卻是非常困難的。JavaScript 生態(tài)系統(tǒng)出奇的大：有包管理器、模塊、構(gòu)建工具、轉(zhuǎn)譯器、數(shù)據(jù)庫、庫文件，還要對(duì)上述所有東西進(jìn)行選擇，難怪如此多的編程新手除了 Codecademy 的教程外，做不了任何東西。這就是為什么我想讓你體驗(yàn)這個(gè)決策的分布教程，跟著我們隊(duì)伍的腳印，構(gòu)建可用的應(yīng)用。

首先，簡單的說兩句。Align 是一個(gè) web 應(yīng)用，它使用直觀的時(shí)間線界面幫助用戶管理時(shí)間、設(shè)定長期目標(biāo)。我們的技術(shù)棧有：用于后端服務(wù)的 Firebase 和用于前端的 React。我和我的隊(duì)友在這個(gè) 短視頻 中解釋的更詳細(xì)。

從第 1 天（我們組建團(tuán)隊(duì)的那天）開始，直到最終應(yīng)用的完成，我們是如何做的？這里是我們采取的步驟綱要：

第 1 步：構(gòu)思

第一步是弄清楚我們到底要構(gòu)建什么東西。過去我在 IBM 中當(dāng)咨詢師的時(shí)候，我和合作組長一同帶領(lǐng)著構(gòu)思工作組。從那之后，我一直建議小組使用經(jīng)典的頭腦風(fēng)暴策略，在會(huì)議中我們能夠提出盡可能多的想法 —— 即使是 “愚蠢的想法” —— 這樣每個(gè)人的大腦都在思考，沒有人因顧慮而不敢發(fā)表意見。

在產(chǎn)生了好幾個(gè)關(guān)于應(yīng)用的想法時(shí)，我們把這些想法分類記錄下來，以便更好的理解我們大家都感興趣的主題。在我們這個(gè)小組中，我們看到實(shí)現(xiàn)想法的清晰趨勢，需要自我改進(jìn)、設(shè)定目標(biāo)、情懷，還有個(gè)人發(fā)展。我們最后從中決定了具體的想法：做一個(gè)用于設(shè)置和管理長期目標(biāo)的控制面板，有保存記憶的元素，可以根據(jù)時(shí)間將數(shù)據(jù)可視化。

從此，我們創(chuàng)作出了一系列用戶故事（從一個(gè)終端用戶的視角，對(duì)我們想要擁有的功能進(jìn)行描述），闡明我們到底想要應(yīng)用實(shí)現(xiàn)什么功能。

第 2 步：UX/UI 示意圖

接下來，在一塊白板上，我們畫出了想象中應(yīng)用的基本視圖。結(jié)合了用戶故事，以便理解在應(yīng)用基本框架中這些視圖將會(huì)如何工作。

這些骨架確保我們意見統(tǒng)一，提供了可預(yù)見的藍(lán)圖，讓我們向著計(jì)劃的方向努力。

第 3 步：選好數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫類型

到了設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)的時(shí)候?；谖覀兊氖疽鈭D和用戶故事，我們在 Google doc 中制作了一個(gè)清單，它包含我們將會(huì)需要的模型和每個(gè)模型應(yīng)該包含的屬性。我們知道需要 “目標(biāo)（goal）” 模型、“用戶（user）”模型、“里程碑（milestone）”模型、“記錄（checkin）”模型還有最后的“資源（resource）”模型和“上傳（upload）”模型，

最初的數(shù)據(jù)模型結(jié)構(gòu)

在正式確定好這些模型后，我們需要選擇某種 類型 的數(shù)據(jù)庫：“關(guān)系型的”還是“非關(guān)系型的”（也就是“SQL”還是“NoSQL”）。由于基于表的 SQL 數(shù)據(jù)庫需要預(yù)定義的格式，而基于文檔的 NoSQL 數(shù)據(jù)庫卻可以用動(dòng)態(tài)格式描述非結(jié)構(gòu)化數(shù)據(jù)。

對(duì)于我們這個(gè)情況，用 SQL 型還是 No-SQL 型的數(shù)據(jù)庫沒多大影響，由于下列原因，我們最終選擇了 Google 的 NoSQL 云數(shù)據(jù)庫 Firebase：

1. 它能夠把用戶上傳的圖片保存在云端并存儲(chǔ)起來
2. 它包含 WebSocket 功能，能夠?qū)崟r(shí)更新
3. 它能夠處理用戶驗(yàn)證，并且提供簡單的 OAuth 功能。

我們確定了數(shù)據(jù)庫后，就要理解數(shù)據(jù)模型之間的關(guān)系了。由于 Firebase 是 NoSQL 類型，我們無法創(chuàng)建聯(lián)合表或者設(shè)置像 “記錄 （Checkins）屬于目標(biāo)（Goals）” 的從屬關(guān)系。因此我們需要弄清楚 JSON 樹是什么樣的，對(duì)象是怎樣嵌套的（或者不是嵌套的關(guān)系）。最終，我們構(gòu)建了像這樣的模型：

我們最終為目標(biāo)（Goal）對(duì)象確定的 Firebase 數(shù)據(jù)格式。注意里程碑（Milestones）和記錄（Checkins）對(duì)象嵌套在 Goals 中。

（注意: 出于性能考慮，F(xiàn)irebase 更傾向于簡單、常規(guī)的數(shù)據(jù)結(jié)構(gòu), 但對(duì)于我們這種情況，需要在數(shù)據(jù)中進(jìn)行嵌套，因?yàn)槲覀儾粫?huì)從數(shù)據(jù)庫中獲取目標(biāo)（Goal）卻不獲取相應(yīng)的子對(duì)象里程碑（Milestones）和記錄（Checkins）。）

第 4 步：設(shè)置好 Github 和敏捷開發(fā)工作流

我們知道，從一開始就保持井然有序、執(zhí)行敏捷開發(fā)對(duì)我們有極大好處。我們設(shè)置好 Github 上的倉庫，我們無法直接將代碼合并到主（master）分支，這迫使我們互相審閱代碼。

我們還在 Waffle.io 網(wǎng)站上創(chuàng)建了敏捷開發(fā)的面板，它是免費(fèi)的，很容易集成到 Github。我們在 Waffle 面板上羅列出所有用戶故事以及需要我們?nèi)バ迯?fù)的 bug。之后當(dāng)我們開始編碼時(shí)，我們每個(gè)人會(huì)為自己正在研究的每一個(gè)用戶故事創(chuàng)建一個(gè) git 分支，在完成工作后合并這一條條的分支。

我們還開始保持晨會(huì)的習(xí)慣，討論前一天的工作和每一個(gè)人遇到的阻礙。會(huì)議常常決定了當(dāng)天的流程 —— 哪些人要結(jié)對(duì)編程，哪些人要獨(dú)自處理問題。

我認(rèn)為這種類型的工作流程非常好，因?yàn)樗屛覀兡軌蚯宄卣业阶约旱亩ㄎ?，不用顧慮人際矛盾地高效執(zhí)行工作。

第 5 步： 選擇、下載樣板文件

由于 JavaScript 的生態(tài)系統(tǒng)過于復(fù)雜，我們不打算從最底層開始構(gòu)建應(yīng)用。把寶貴的時(shí)間花在連通 Webpack 構(gòu)建腳本和加載器，把符號(hào)鏈接指向項(xiàng)目工程這些事情上感覺很沒必要。我的團(tuán)隊(duì)選擇了 Firebones 框架，因?yàn)樗『眠m用于我們這個(gè)情況，當(dāng)然還有很多可供選擇的開源框架。

第 6 步：編寫后端 API 路由（或者 Firebase 監(jiān)聽器）

如果我們沒有用基于云的數(shù)據(jù)庫，這時(shí)就應(yīng)該開始編寫執(zhí)行數(shù)據(jù)庫查詢的后端高速路由了。但是由于我們用的是 Firebase，它本身就是云端的，可以用不同的方式進(jìn)行代碼交互，因此我們只需要設(shè)置好一個(gè)可用的數(shù)據(jù)庫監(jiān)聽器。

為了確保監(jiān)聽器在工作，我們用代碼做出了用于創(chuàng)建目標(biāo)（Goal）的基本用戶表格，實(shí)際上當(dāng)我們完成表格時(shí)，就看到數(shù)據(jù)庫執(zhí)行可更新。數(shù)據(jù)庫就成功連接了！

第 7 步：構(gòu)建 “概念證明”

接下來是為應(yīng)用創(chuàng)建 “概念證明”，也可以說是實(shí)現(xiàn)起來最復(fù)雜的基本功能的原型，證明我們的應(yīng)用 可以 實(shí)現(xiàn)。對(duì)我們而言，這意味著要找個(gè)前端庫來實(shí)現(xiàn)時(shí)間線的渲染，成功連接到 Firebase，顯示數(shù)據(jù)庫中的一些種子數(shù)據(jù)。

Victory.JS 繪制的簡單時(shí)間線

我們找到了基于 D3 構(gòu)建的響應(yīng)式庫 Victory.JS，花了一天時(shí)間閱讀文檔，用 VictoryLine 和 VictoryScatter 組件實(shí)現(xiàn)了非常基礎(chǔ)的示例，能夠可視化地顯示數(shù)據(jù)庫中的數(shù)據(jù)。實(shí)際上，這很有用！我們可以開始構(gòu)建了。

第 8 步：用代碼實(shí)現(xiàn)功能

最后，是時(shí)候構(gòu)建出應(yīng)用中那些令人期待的功能了。取決于你要構(gòu)建的應(yīng)用，這一重要步驟會(huì)有些明顯差異。我們根據(jù)所用的框架，編碼出不同的用戶故事并保存在 Waffle 上。常常需要同時(shí)接觸前端和后端代碼（比如，創(chuàng)建一個(gè)前端表格同時(shí)要連接到數(shù)據(jù)庫）。我們實(shí)現(xiàn)了包含以下這些大大小小的功能：

• 能夠創(chuàng)建新目標(biāo)、里程碑和記錄
• 能夠刪除目標(biāo)，里程碑和記錄
• 能夠更改時(shí)間線的名稱，顏色和詳細(xì)內(nèi)容
• 能夠縮放時(shí)間線
• 能夠?yàn)橘Y源添加鏈接
• 能夠上傳視頻
• 在達(dá)到相關(guān)目標(biāo)的里程碑和記錄時(shí)彈出資源和視頻
• 集成富文本編輯器
• 用戶注冊、驗(yàn)證、OAuth 驗(yàn)證
• 彈出查看時(shí)間線選項(xiàng)
• 加載畫面

有各種原因，這一步花了我們很多時(shí)間 —— 這一階段是產(chǎn)生最多優(yōu)質(zhì)代碼的階段，每當(dāng)我們實(shí)現(xiàn)了一個(gè)功能，就會(huì)有更多的事情要完善。

第 9 步： 選擇并實(shí)現(xiàn)設(shè)計(jì)方案

當(dāng)我們使用 MVP 架構(gòu)實(shí)現(xiàn)了想要的功能，就可以開始清理，對(duì)它進(jìn)行美化了。像表單，菜單和登陸欄等組件，我的團(tuán)隊(duì)用的是 Material-UI，不需要很多深層次的設(shè)計(jì)知識(shí)，它也能確保每個(gè)組件看上去都很圓潤光滑。

這是我制作的最喜愛功能之一了。它美得令人心曠神怡。

我們花了一點(diǎn)時(shí)間來選擇顏色方案和編寫 CSS ，這讓我們在編程中休息了一段美妙的時(shí)間。期間我們還設(shè)計(jì)了 logo 圖標(biāo)，還上傳了網(wǎng)站圖標(biāo)。

第 10 步： 找出并減少 bug

我們一開始就應(yīng)該使用測試驅(qū)動(dòng)開發(fā)的模式，但時(shí)間有限，我們那點(diǎn)時(shí)間只夠用來實(shí)現(xiàn)功能。這意味著最后的兩天時(shí)間我們花在了模擬我們能夠想到的每一種用戶流，并從應(yīng)用中找出 bug。

這一步是最不具系統(tǒng)性的，但是我們發(fā)現(xiàn)了一堆夠我們忙乎的 bug，其中一個(gè)是在某些情況下加載動(dòng)畫不會(huì)結(jié)束的 bug，還有一個(gè)是資源組件會(huì)完全停止運(yùn)行的 bug。修復(fù) bug 是件令人惱火的事情，但當(dāng)軟件可以運(yùn)行時(shí)，又特別令人滿足。

第 11 步：應(yīng)用上線

最后一步是上線應(yīng)用，這樣才可以讓用戶使用它！由于我們使用 Firebase 存儲(chǔ)數(shù)據(jù)，因此我們使用了 Firebase Hosting，它很直觀也很簡單。如果你要選擇其它的數(shù)據(jù)庫，你可以使用 Heroku 或者 DigitalOcean。一般來講，可以在主機(jī)網(wǎng)站中查看使用說明。

我們還在 Namecheap.com 上購買了一個(gè)便宜的域名，這讓我們的應(yīng)用更加完善，很容易被找到。

好了，這就是全部的過程 —— 我們都是這款實(shí)用的全棧應(yīng)用的合作開發(fā)者。如果要繼續(xù)講，那么第 12 步將會(huì)是對(duì)用戶進(jìn)行 A/B 測試，這樣我們才能更好地理解：實(shí)際用戶與這款應(yīng)用交互的方式和他們想在 V2 版本中看到的新功能。

但是，現(xiàn)在我們感到非常開心，不僅是因?yàn)槌善罚€因?yàn)槲覀儚倪@個(gè)過程中獲得了難以估量的知識(shí)和理解。點(diǎn)擊 這里 查看 Align 應(yīng)用！

Align 團(tuán)隊(duì)：Sara Kladky（左），Melanie Mohn（中），還有我自己。