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

所謂“利用IT基礎設施實現業務邏輯”，意味著以下幾個概念：

IT基礎設施有哪些？

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

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

如何正確的分析業務邏輯？

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

業務邏輯如何與IT設施結合？

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

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

日志打得很少

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

資源沒有即用即放！

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

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

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

不做重復的事；

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

充分利用IT基礎設施的特性。比如多核、CPU親和性、存儲介質的性價比、網絡報文的收發等。

為了達到這一點，我們必須學習：

算法復雜度；

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

計算機體系的特點，如CPU架構、網絡通訊成本等；

常用數據結構，如樹、哈希表、圖等。

本文出現的原因是團隊中有前端同事想在后端試試水，我當然非常歡迎，于是盡量從我對前端的理解上闡述后端開發的要點，或者更準確的說，是后端WEB應用開發工程師的開發要點。全棧工程師的要求高得多，這里雖然有些標題黨嫌疑，但好在標明了基礎版，進階版在好好談談前端轉全棧工程師的其他要求。