國外前端開發(fā)的一周工作日程（擁有五年經(jīng)驗）
譯文作者：核子可樂譯
我是一名前端開發(fā)者，所在公司: 一家物聯(lián)網(wǎng)連接與云廠商，坐標(biāo)：美國。
【51CTO.com快譯】我是一名前端開發(fā)者，所在公司: 一家物聯(lián)網(wǎng)連接與云廠商，坐標(biāo)：美國。
提要：
1.堆棧:
1. 前端：React、Redux與Webpack等。
2. 后端：Apache、PHP與SQL（所有前端內(nèi)容皆靜態(tài)提供，不過API來自PHP）。
3. 后后端（云系統(tǒng)）：PHP、Python及C等。
2.主要工具:
IntelliJ、Slack、Phabricator(類似于JIRA與GitHub二合一)、Sketch (用于設(shè)計)。
3.需要解決的項目：
先來介紹背景，我們提供一項長期運行功能，允許用戶免費向物聯(lián)網(wǎng)設(shè)備直接發(fā)送短信。很多用戶喜歡這項功能，遺憾的是，有些人找不到原來的短信箱了，因為它被隱藏在一套下拉框當(dāng)中。為了解決這個問題，我需要創(chuàng)建幾項標(biāo)簽，讓大家在“云”或“短信”間做出選擇。
如果用戶看不到，那么功能將毫無意義。
***步是建立設(shè)計。我們的團隊使用Sketch。在初稿完成后，我交給UX負(fù)責(zé)人Kevin進行審查。他讓我調(diào)整一下顏色與頁邊空白，其實這項工作相當(dāng)微不足道——只是進行了樣式與標(biāo)記的輕微調(diào)整。經(jīng)過一個小時的React JSX與.scss文件調(diào)整，再加上一不小心出現(xiàn)的瀏覽器死循環(huán)問題，我最終完成了任務(wù)。
這項成果將在下一次發(fā)布時推送，不過我需要確保其順利通過e2e測試。
解決任務(wù)的***天：
進行了e2e Selenium測試，但因為一些原因而不得不推遲（因為我必須構(gòu)建一套Chrome擴展來進行測試記錄）。
那么今天就來搞定這些任務(wù)吧。前端開發(fā)面臨的一大挑戰(zhàn)在于，我們往往需要認(rèn)真考慮工作的優(yōu)先級。理想情況下，這個問題應(yīng)該由項目經(jīng)理在規(guī)劃會議上解決，但我們是一家初創(chuàng)企業(yè)且沒有多余的資源。因此，我決定通過以下問題進行考量：
哪項任務(wù)能夠為客戶創(chuàng)造***價值？
接下來就是選擇其中最簡單的任務(wù)。所以我挑了一項有意義且輕松的任務(wù)：
***步: 我們提供一項組織功能，用于創(chuàng)建能夠在物聯(lián)網(wǎng)設(shè)備上同他人協(xié)作的新“用戶”類型（類似于GitHub組織形式）。在組織環(huán)境中（由用戶切換至該組織），其中包含大量需要訪問的重要賬戶數(shù)據(jù)——特別是用于調(diào)用服務(wù)器API的“訪問令牌”，即個人API密鑰。我需要讓用戶看得到這些密鑰。
我做的其實就是為設(shè)置頁面的邊欄添加了一份列表。由于該目標(biāo)頁已經(jīng)存在，所以進度很快。
完成！用的時間比預(yù)期稍長……我被迫把兩個Submenu組件合并將結(jié)果提交至更高的“common component”文件夾中。如下所示：
解決任務(wù)的第二天：
我們打算在硬件/云服務(wù)中搞定大動靜。我目前正在進行“團隊百葉窗”項目，就是利用短信讓辦公室的百葉窗打開與關(guān)閉。此前我們曾經(jīng)利用同樣的原理控制過臺燈，但這次需要引入一臺高扭電機。無論如何，這類活動只是為了證明前端開發(fā)者的生活也是豐富多彩的！
我今天的貢獻還包括構(gòu)建了一款小型Web應(yīng)用，允許大家隨時了解“百葉窗”項目的進展。這其實就是一套小型節(jié)點服務(wù)器，能夠調(diào)用我們的公共API。如此一來，我就有借口繼續(xù)鼓搗公共hologram-node npm軟件包了。從本質(zhì)上講，這屬于一套基于我上周建立的原始HTTP端點的“小甜點”。
此前:
// annoying to have to build the url yourself... also you have to keep track of the apikey and orgid, which are essential for a call to succeed. request('https://dashboard.hologram.io/api/1/devices?limit=50&orgid=XXX&apikey=XXX', function(error, response) { if (!error && response.statusCode == 200) { cb() } else { cb(error, null); } });
此后: (非終版)
var HologramAPI = require('hologram-node')("APIKEY", { orgid: 123 }); returnHologramAPI.getDevices({limit: 1000}) .then((devices) => { return res.json(devices); }) .catch((e) => { return res.json(e); });
不錯吧？再來看看內(nèi)部構(gòu)造：
HoloClient.prototype.getDevices = function(options = {}) {returnnewPromise(function(resolve, reject) { options = _.pick(options, 'limit', 'startafter'); var path = `/devices`; var querystring = this.getQueryString(_.extend({}, options)); if (this.config.showDebug) console.log(`GET ${this.getBaseUrl()}${path}${querystring}`); needle.get(`${this.getBaseUrl()}${path}${querystring}`,this.responseHandler(resolve, reject)); }.bind(this)); };
以下是我們在測試當(dāng)中發(fā)現(xiàn)的mocha測試集成錯誤：
給大家的小問題：
1.我們在哪套環(huán)境下進行測試？
2.我們該如何輕松對SQL服務(wù)器進行預(yù)測試與后測試？
3.這一切值得嗎（就人力投入而言）？
解決任務(wù)的第三天：
繼續(xù)處理Hologram NPM。昨天，我在代碼中發(fā)現(xiàn)了很多模式，我決定嘗試另一種架構(gòu)策略，希望這能夠增加API功能并有助于維護。
今天的新策略是配置源代碼以支持Introspection。我首先建立了一套包含全部API方法及其HTTP屬性的JSON數(shù)組。而后，我編寫了一項“bootstrapping”方法，其能夠利用該JSON建立實際代碼。例如：
從這里開始：
{ name:"getAll", definition:"Get all devices in your account.", example:"https://hologram.io/api/i/devices?orgid=123&apikey=123123", path:"/devices", category:"Device", method:"get", params: [ { name:"limit", type:"string", required: false, location:"querystring" }, { name:"startafter", type:"string", required: false, location:"querystring" } ] }
...而后: buildAPIWithConfig(json)
...實現(xiàn)以下能力:
HologramAPI.Device.getAll({ limit: 0 }) .then((devices) => { assert(devices.length === 0, "No devices returned"); done(); })
該JSON可用于生成文檔、方法參數(shù)類型反饋、測試以及測試模擬。例如，我可以這樣運行：
generateDocs(json)
獲得的結(jié)果為：
METHODHologram.Device.getAll({options}): Get all devices in your account andreturns a Promise. Makes a raw GET request to /devices Example: https://hologram.io/api/i/devices?orgid=123&apikey=123123
為什么？構(gòu)建良好的README.md而后再配置！
面向用戶的功能:
1. 用戶能夠獲得全部API文檔
2. 用戶能夠獲得***API文檔
3. 維護人員無需更新JSDoc等標(biāo)簽
4. 維護人員能夠立足該JSON生成測試并模擬數(shù)據(jù)
弊端：犧牲了靈活性……因為代碼已經(jīng)生成，因此當(dāng)API返回的內(nèi)容與標(biāo)準(zhǔn)模式不符時，很難再進行定制。
解決任務(wù)的第四天：
回顧路徑選擇流程的感覺不錯，至少比編寫代碼和說明文檔好多了。
這一天中的大部分時間用在添加JSON條目、為其編寫Mocha測試、構(gòu)建README.md生成模板、編寫端點描述以及將README文檔鏈入正式文檔頁面當(dāng)中。節(jié)奏不錯，再有一、兩天就能將其正式開放了。
展示回顧結(jié)果！
接著，編寫文檔……
運行測試……
解決任務(wù)的第五天：
我打算弄點快速見效的東西。
***步-在路由部分添加一些文檔鏈接。我已經(jīng)在其它位置放置有文檔鏈接，所以直接粘貼即可。有些人將此稱為樣式優(yōu)先級，我們應(yīng)當(dāng)將實現(xiàn)方式記錄在uikit/kitchen-sink項目中。
第二步-將一個圖標(biāo)的源url配置為來自數(shù)據(jù)庫而非硬編碼。后端團隊承諾在API調(diào)用響應(yīng)中提供url字符串，所以我需要將其納入現(xiàn)有配置。
完成！出人意料，這項工作挺費勁……我花了2個小時才搞定。剛開始基礎(chǔ)變更并未起效。我開始比較理論與實際顯示效果間的區(qū)別，快快速加以修復(fù)。另外，我們的CSS代碼形式非常靈活，這讓我相當(dāng)頭痛——可能我們稍后需要進行重寫。暫時把這個加進待辦清單吧，還有更重要的功能等著完成呢。
終于能在Phabricator的Done列中加入幾項了。
接著，我在這里檢查代碼區(qū)別并進行提交。
好了，這就是我一周的工作日程，希望對大家有幫助~
【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】
責(zé)任編輯：關(guān)崇
來源：
51CTO
