前端與后端的思維專注點很不相同，前端聚焦在如何把內(nèi)容以可視化的方式展現(xiàn)給用戶，后端聚焦在如何利用IT基礎(chǔ)設(shè)施實現(xiàn)業(yè)務(wù)邏輯。所以前端參與后端開發(fā)時（全棧工程師必備！）首先需要理解后端會做哪些事，其次才是如何才能做好這些事。

所謂“利用IT基礎(chǔ)設(shè)施實現(xiàn)業(yè)務(wù)邏輯”，意味著以下幾個概念：

IT基礎(chǔ)設(shè)施有哪些？

數(shù)據(jù)庫一定是最重要的，這里特指關(guān)系數(shù)據(jù)庫，例如mysql。因為前端所用的數(shù)據(jù)庫往往非常簡單，瀏覽器或者APP畢竟只服務(wù)于一位用戶，而后端的數(shù)據(jù)庫需要服務(wù)于全部用戶，這不是一個量級。在現(xiàn)實世界中，一旦量級發(fā)生改變，需要用到的技術(shù)就完全不一樣了。數(shù)據(jù)庫的基本操作ACID、事務(wù)、關(guān)聯(lián)查詢、索引都是完成業(yè)務(wù)邏輯的必備品。

緩存也是前端必須理解的概念。后端可以直接操作SATA磁盤，SSD磁盤，內(nèi)存等不同的存儲介質(zhì)，而這些介質(zhì)的存取速度差異巨大。CPU操作L1和L2緩存只有3個納秒以內(nèi)，到了L3緩存（可以以MB為單位計量了）就得10納秒以上了，而到了內(nèi)存就得100納秒以上，通過網(wǎng)卡訪問遠端則需要數(shù)百微秒，訪問機械硬盤則要幾十毫秒。為了能夠讓用戶的請求盡快獲得響應(yīng)，必須使用緩存。很少的場景下才會直接編寫緩存，通常后端都在使用的緩存服務(wù)包括redis、memcached等，其中前者使用更多。

如何正確的分析業(yè)務(wù)邏輯？

UML圖是一個非常好的手段！類圖、時序圖、狀態(tài)圖可以幫助后端理清先做什么、再做什么、不會漏掉什么。這是因為后端的程序需要整年的運行不能宕機，而前端是沒有這種要求的。因此，后端必須全面的考慮各種異常情況，防止一個用戶（請求）引起的意外把整個服務(wù)宕機，影響了全部用戶。

業(yè)務(wù)邏輯如何與IT設(shè)施結(jié)合？

了解MVC模型！前端有許多模型，例如MVVM等，這些名詞不重要，因為它們的關(guān)注點各不相同。對于后端，通常M意味著關(guān)系數(shù)據(jù)庫，所以后端的WEB框架一定圍繞著M進行。我們分析任何一個WEB框架，一定先要看它的數(shù)據(jù)庫模型，即如何將數(shù)據(jù)庫中的表、行映射到編程語言中。另一方面，HTTP協(xié)議有許多特性，它會導(dǎo)致MVC框架試圖以此解耦，將URL的配置與業(yè)務(wù)處理代碼分開。最后，WEB框架由于處理場景的復(fù)雜，通常以可插拔的方式將許多插件串行的組合起來處理一個請求。前端在學(xué)習(xí)WEB框架時，把握這三點即可快速掌握。

前端做后端時最容易犯2個錯誤：

日志打得很少

后端的復(fù)雜場景會導(dǎo)致bug難以復(fù)現(xiàn)（相比前端更難），且一個應(yīng)用服務(wù)可能跑在多個服務(wù)器上，所以error、info、debug等級日志的輸出顯得尤為重要！沒有日志，問題很難定位！

資源沒有即用即放！

因為服務(wù)是7*24小時運行的，所以一點點資源泄露（如打開了句柄卻未關(guān)閉）都會被時間放大！最后導(dǎo)致嚴重后果。

后端的代碼如何更高效？答案一定是算法！

好的算法在我看來就是3點：

不做重復(fù)的事；

充分利用已知信息或者中間計算結(jié)果；

充分利用IT基礎(chǔ)設(shè)施的特性。比如多核、CPU親和性、存儲介質(zhì)的性價比、網(wǎng)絡(luò)報文的收發(fā)等。

為了達到這一點，我們必須學(xué)習(xí)：

算法復(fù)雜度；

分而治之的思想，這可能是所有算法思想中最有用的了；

計算機體系的特點，如CPU架構(gòu)、網(wǎng)絡(luò)通訊成本等；

常用數(shù)據(jù)結(jié)構(gòu)，如樹、哈希表、圖等。

本文出現(xiàn)的原因是團隊中有前端同事想在后端試試水，我當然非常歡迎，于是盡量從我對前端的理解上闡述后端開發(fā)的要點，或者更準確的說，是后端WEB應(yīng)用開發(fā)工程師的開發(fā)要點。全棧工程師的要求高得多，這里雖然有些標題黨嫌疑，但好在標明了基礎(chǔ)版，進階版在好好談?wù)勄岸宿D(zhuǎn)全棧工程師的其他要求。