FEer到全棧開發

JrayZhang發表於2019-02-16
全棧

前言

從前，一個類B/S架構的應用裡，FEer，或者叫切圖仔，切圖+表單驗證就是工作的全部。無奈我所做的全部，只是整個應用的冰山一角…責任小了，邊緣感就強了，owner意識自然差，視野自然受限。

感謝V8引擎的極速體驗&chrome瀏覽器的緊隨規範，js執行速度快的飛起，w3c規範愈加豐滿，FEer終於可以翻身農奴把歌唱了。推倒了切圖仔的定位並不斷擴充套件js的責任田。

  • 其實前端可以有模組化

  • 其實前端可以滿足除老本行表單驗證外更多的業務邏輯

  • 其實前端可以有路由層

  • 其實前端可以有資料層

  • …

看吧，這種趨勢已經勢不可擋，js從單檔案指令碼開始有模組化概念，有前端主義特色的MVC，有更高大上、業務層實現更easy的MVVM，react,vue,angular.js (姑且叫美中三強？)越來越多的WEB應用開始變為SPA。

什麼？你在質疑JS，你說SEO？我們FEer來加一個服務端渲染，順帶白屏時間長問題一同解決送你，還吹毛求疵？請UEmm做一張精美的loading圖附加給你，無話可說了吧~

野心越來越強，client已經無法滿足FEer，感謝酷酷的高效能伺服器專家Ryan Dahl和他的node.js，不僅貢獻了一個基於事件的高效能的WEB伺服器，還帶來了javascript的大繁榮。FEer終於可以有機會低成本觸及server端開發了，因為遙遠的對岸將不止有json”炮彈”，還會有我們熟悉的js大兄弟，你懂得這意味著什麼，海峽兩岸是一家！未來的溝通，一切將變得更加簡單方便稱心如意，未來對岸的大兄弟（可能就是你自己）將給你更舒心更懂你的json”禮包”。事件驅動，非同步I/O，順帶手FEer就可以自信高效的將VIEW渲染、路由分發等之前可望不可及的工作包攬實現。

也就是這樣，FEer腿也不疼了，腰也不困了，一口氣完成前後端開發，不費勁。好像title都可以變了，把自己稱為全棧工程師，責任大了，owner意識強了，曾經的後端RD被我們親切的成為服務端RD，FEer可以豪爽的說：『提供給我服務就好，頁面渲染、路由分發這些小事兒，小的做就行了，您去專心開發更復雜的服務端介面吧』。不過就算這樣，我們還是很開心，因為我們是FEer，我們也是Full Stack developer，沒錯，我們是更懂前端的後端！

新職責

工作流

我們已經不是游擊隊了，我們有自己的作戰部隊，需要自己獨立指揮。雖然FEer在飽受折磨，強烈抗議，爭得前後端分離開發的榮譽後，已經在工作流上有質的優化了（主要體現在有了寫build.sh，養成了編譯的好習慣）。現在作為全棧，還需要重新梳理下工作流。在社群有社群的方案，在百度，我們這樣做。icafe + icode + agile ，一條龍服務標準、周到、包滿意。

需求管理

icafe是百度內部的工作平臺，在我理解，就是需求管理平臺。PM等需求方在icafe上釋出需求，開發小哥肢解聖意，將一個Aplication級別的需求不斷拆分，拆分成story，逐個開發滿足。PM、RD、QA在icafe平臺瞭解PM所需，測驗RD所得，清楚QA所測。

程式碼開發

記得曾經聽開發icode平臺的同學驕傲的講，BAT中只有百度有全公司級別的統一程式碼倉庫，並且使用git管理程式碼，不明覺厲，我也很驕傲。icode平臺程式碼的提交可以通過issue號與icafe裡的需求store連線起來。通過git進行版本控制是業界及開源社群主流的選擇。包括百度EFE的大神們編纂了公司級別統一的各種語言的編碼規範，程式碼提交會觸發編碼規範校驗，保證了入庫程式碼的規範，review後准入的限制基本保證了程式碼的質量。

持續整合

百度的持續整合解決方案是依託於agile平臺實現。還記得樸大的廣告，整合的，好喝的!。每個icode專案都會要求開發者編寫一個BCLOUD指令碼，類似travis ci的.travis.yml的檔案，程式碼提交會觸發線上雲編譯機叢集完成編譯，並記錄編譯狀態，協助開發者保證線上程式碼分支的持續可用。agile另一個主要功能是完成程式碼釋出，釋出後，程式碼即進入公司級程式碼倉庫。

域名

什麼，你在說域名？我真的可以包辦域名了！在你要包辦域名的前，首先需要判斷你心儀的希望使用的域名是否已被佔用。dig、nslookup是我使用的判別方法。

nslookup baidu.com //只是做示範，提醒自己小夥子野心不要太大

在確認你心儀且該域名尚未被佔用的後，你就應該瞭解下A記錄、CNAME了。簡言之，一個域名的A記錄是域名指向ip的對映，而CNAME是域名指向其他域名的別名對映。在百度，有shifen系統，shifen系統的域名是A記錄，但它其實指向的是vip（虛擬ip），機房、機群多了以後，這樣會盡可能的保證運維的靈活度。

資料庫

B/S架構應用運轉的本質就是資料的流動。任何業務邏輯的實現到最後都會被抽象成資料結構，持久化到資料庫中儲存。資料庫種類很多，業務中最常用的可能就是MySQL，Redis，MongoDB等。大多數的B/S應用資料庫選型都會使用MySQL，因為它是最流行的關係型資料庫，體積小、速度快、效能卓越。Redis常用於session共享及業務邏輯資料快取，提高介面響應速度。說到MySQL，phpMyAdmin是一個不錯的MySQL資料庫管理工具，當然，作為新時代的FEer，在不方便使用phpMyAdmin的場合，你也得掌握基礎的MySQL命令。

// 登入MySQL server
mysql -h IP -P port -u username -ppassword

// RD讓你匯出個表，不能不會
mysqldump database table 

// 看下MySQL server上有哪些資料庫
show databases;

// 想操作哪個庫
use db;

// 想操作的庫裡有哪些表
show tables;

// 檢視下編碼
show variables like "%char%";

// 咦、不是utf8?
SET character_set_client=`utf8`;
SET character_set_connection=`utf8`;
SET character_set_results=`utf8`;

// 增？
INSERT INTO `table` (`prop`,`prop`...) VALUES(value1,value2);

// 刪？
DELETE FROM `table` WHERE conditions;

// 改？
UPDATE `table` SET prop=value WHERE conditions;

// 查？
SELECT * FROM `table` WHERE condition;

前端

如果還不用美中三強或其他MVVM框架（比如百度errorrik大神的san，據說能扛IE6的MVVM）怎麼好意思說自己是前端。前端標配已經是webpack + babel + MVVM + (FE)-router + (FE)-Store/x… 包括module bundler，transformer，MVVM，前端路由，前端狀態管理，資料驅動，狀態機，這些東西已經融入到現代WEB前端產品內，缺少一樣，都覺得少了點什麼，像個中官。

後端

說到node.js，說到後端伺服器框架，不得不再感謝一個大拿，TJ，貢獻太大了。express, koa, co等等，進一步降低了FEer進入的門檻。後端選TJ大拿的框架就夠了，當然包括百度、阿里在內都有一些自己的服務端框架，基本都是基於TJ大拿加上業務線的實際運用場景之上的封裝。包括yog2，egg等。對了，MySQL orm推薦使用sequelize，這裡有篇文件介紹的挺全。

服務端

如上文所述，FEer把路由分發、頁面渲染這些雜活攬下以後，RD大大們就可以專心寫服務端介面了。node server 與其他服務端server的通訊可以通過RPC、Webservice等方式實現，node server也可以做proxy，將客戶端的請求代理到其他伺服器獲取業務的資料。當前開源風愈來愈強的風氣下，各類相關node包一片大繁榮，大家可以自行選擇你看中的。在我的業務場景下，我最常使用的是百度FEX Team的 node-ral。

MORE

責任越大，就要求能力越強。從FEer到Full stack developer，不是那麼簡單，需要變化的不止一點，要不斷擴大自己的技術關注圈，提升自己的技術廣度與深度，增強技術視野，只有真正按RD的標準來要求自己，配合FEer的看家本領，才能做一名合格的全棧開發。

相關文章