程序員布局圖解

程序員分前端與後端，那麼後端程序員都做些什麼？看完就知道了

我剛開始做Web開發的時候，根本沒有前端，後端之說。

原因很簡單，那個時候伺服器端的代碼就是一切：接受瀏覽器的請求，實現業務邏輯，訪問資料庫，用JSP生成HTML，然後發送給瀏覽器。

即使後來Javascript在瀏覽器中添加了一些AJAX的效果，那也是錦上添花，絕對不敢造次。因為頁面的HTML主要還是用所謂「套模板」的方式生成：美工生成HTML模板，程序員用JSP,Veloctiy,FreeMaker等技術把動態的內容添加上去，僅此而已。

那個時候最流行的圖是這個樣子：

在最初的J2EE體系中，這個表示層可不僅僅是瀏覽器中運行的頁面，還包括Java寫的桌面端，只是Java在桌面端太不爭氣，沒有發展起來。

每個程序員都是所謂「全棧」工程師，不僅要搞定HTML,JavaScript,CSS，還要實現業務邏輯，編寫訪問資料庫的代碼。等到部署的時候，就把所有的代碼打成一個WAR包，往Tomcat指定的目錄一扔，測試一下沒問題，收工回家！

不差錢的公司會把程序部署到Weblogic，Websphere這樣的應用伺服器中，還會用上高大上的EJB。

雖然看起來生活「簡單」又「愜意」，但實際上也需要實現那些多變的、不講邏輯的業務需求，苦逼的本質並沒有改變。

隨著大家對瀏覽器頁面的視覺和交互要求越來越高，「套模板」的方式漸漸無法滿足要求，這個所謂的表示層慢慢地遷移到瀏覽器當中去了，一大批像Angular,ReactJS之類的框架崛起，前後端分離了！

後端的工程師只負責提供介面和數據，專注於業務邏輯的實現，前端取到數據後在瀏覽器中展示，各司其職。

像Java這樣的語言很適合去實現復雜的業務邏輯，尤其是一些MIS系統，行業軟體如稅務、電力、煙草、金融，通信等等。所以剝離表示層，只做後端挺合適的。

但是如果僅僅是實現業務邏輯，那後端也不會需要這么多技術了，搞定SSH/SSM就行了。

互聯網，尤其是移動互聯網開始興起以後，海量的用戶呼嘯而來，一個單機部署的小小War包肯定是撐不住了，必須得做分布式。

原來的單個Tomcat得變成Tomcat的集群，前邊弄個Web伺服器做請求的負載均衡，不僅如此，還得考慮狀態問題，session的一致性。

（註：參見文章《小白科普：分布式和集群》）

業務越來越復雜，我們不得不把某些業務放到一個機器（或集群）上，把另外一部分業務放到另外一個機器（或集群）上，雖然系統的計算能力，處理能力大大增強，但是這些系統之間的通信就變成了頭疼的問題，消息隊列（MQ)，RPC框架（如Dubbo）應運而生，為了提高通信效率，各種序列化的工具(如Protobuf)也爭先空後地問世。

單個資料庫也撐不住了，那就做資料庫的讀寫分離，如果還不行，就做分庫和分表，把原有的資料庫垂直地切一切，或者水平地切一切，但不管怎麼切，都會讓應用程序的訪問非常麻煩，因為數據要跨庫做Join/排序，還需要事務，為了解決這個問題，又有各種各樣「數據訪問中間件」的工具和產品誕生。

為了最大程度地提高性能，緩存肯定少不了，可以在本機做緩存(如Ehcache)，也可以做分布式緩存(如Redis)，如何搞數據分片，數據遷移，失效轉移，這又是一個超級大的主題了。

互聯網用戶喜歡上傳圖片和文件，還得搞一個分布式的文件系統（如FastDFS），要求高可用，高可靠。

數據量大了，搜索的需求就自然而然地浮出水面，你得弄一個支持全文索引的搜索引擎(如Elasticsearch,Solr)出來。

林子大了，什麼鳥都有，必須得考慮安全，數據的加密/解密，簽名、證書，防止SQL注入，XSS/CSRF等各種攻擊。

前面提到了這么多的系統，還都是分布式的，每次上線，運維的同學說：把這么多系統協調好，把老子都累死了。

得把持續集成做好，能自動化地部署，自動化測試（其實前端也是如此），後來出現了一個革命化的技術docker，能夠讓開發、測試、生成環境保持一致，系統原來只是在環境（如Ngnix,JVM,Tomcat,MySQL等）上部署代碼，現在把代碼和環境一並打包，運維的工作一下子就簡化了。

公司自己購買伺服器比較貴，維護也很麻煩，又難於彈性地增長，那就搞點虛擬的伺服器吧，硬碟、內存都可以動態擴展（反正是虛擬的），訪問量大的時候多用點，沒啥訪問量了就釋放一點，按需分配，很方便，這就是雲計算的一個場景。

隨著時間的推移，各個公司和系統收集的數據越來越多，都堆成一座大山了，難道就放在那裡白白地浪費硬碟空間嗎？

有人就驚奇地發現，咦，我們利用這些數據搞點事情啊，比如把數據好好分析一下，預測一下這個用戶的購買/閱讀/瀏覽習慣，給他推薦一點東西嘛。

可是這么多數據，用傳統的方式計算好幾天甚至好幾個月才能出個結果，到時候黃花菜都涼了，所以也得利用分布式的技術，想辦法把計算分到各個計算機去，然後再把計算結果收回來，時勢造英雄，Hadoop及其生態系統就應運而生了。

之前聽說過一個大前端的概念，把移動端和網頁端都歸結為「前端」，我這里造個詞「大後端」，把那些用戶直接接觸不到的、發生在伺服器端的都歸結進來。

現在無論是前端還是後端，技術領域多如牛毛，都嚴重地細分了，所以我認為真正的全棧工程師根本不存在，因為一個人精力有限，不可能搞定這么多技術領域，太難了。

培訓機構所說的「全棧」，我認為就是前後端還在拉拉扯扯，藕斷絲連，沒有徹底分離的時候的「全棧」工程師。

那麼問題來了，後端這么多東西，我該怎麼學？

之前寫過一篇文章叫做《上天還是入地》，說了學習的廣度和深度，在這里也是相通的。

往深度挖掘，可以成為某個技術領域的專家，如搜索方面的專家、安全方面的專家，分布式文件的專家等等，不管是哪個領域，重點都不是學會使用某個工具和框架，而是保證你可以自己的知識和技術去搞定這個領域的頂尖問題。

往廣度發展，各個技術領域都要了解，對於某種需求，能夠選取合適的軟體和技術架構來實現它，把需求轉化成合適的技術組件，讓這些組件以合適的方式連接、部署、運行，這也需要持續地學習和不斷的經驗積累。

最後，以一張漫畫來結束吧！

C/C++高級工程師學習路線圖：

前端開發主要做的是用戶所能看到的前端展示界面；後端開發主要做的是邏輯功能等模塊。其實主要區別體現在以下兩個方面：知識結構與實現和工作職責。

1、知識結構

（1）展示的方式不同

前端指的是用戶可見的界面，網站前端頁面也就是網頁的頁面開發，比如網頁上的特效、布局、圖片、視頻，音頻等內容。前端的工作內容就是將美工設計的效果圖的設計成瀏覽器可以運行的網頁，並配合後端做網頁的數據顯示和交互等可視方面的工作內容。

後端是指用戶看不見的東西，通常是與前端工程師進行數據交互及網站數據的保存和讀取，相對來說後端涉及到的邏輯代碼比前端要多得多，後端考慮的是底層業務邏輯的實現，平台的穩定性與性能等。

（2）所用的技術、技能與工具不同

前端開發，就是要創造上面提到的網站面向用戶的部分背後的代碼，並通過建立框架，構建沉浸性的用戶體驗。為了實現這個目標，開發需要熟練運用下列語言、框架、工具庫：

後端開發者使用這些工具編寫干凈、可移植、具有良好文檔支持的代碼來創建或更新Web應用。但在寫代碼之前，他們需要與客戶溝通，了解其實際需求並轉化為技術目標，制定最有效且精簡的方案來進行實現。

（3）所用技術不同

前端開發用到的技術包括但不限於html5、css3、javascript、jquery、Bootstrap、Node.js、Webpack，AngularJs，ReactJs，VueJs等技術。

後端開發以java為例主要用到的是包括但不限於協議ServletTomcat伺服器等技術。

2、工作職責

前端工程師主要的工作職責分為三大部分，分別是傳統的Web前端開發，移動端開發和大數據呈現端開發。Web前端開發主要針對的是PC端開發任務；

移動端開發則包括android開發、iOS開發和各種小程序開發，在移動互聯網迅速發展的帶動下，移動端的開發任務量是比較大的，隨著5G標準的落地，未來移動端的開發任務將得到進一步的拓展；大數據呈現則主要是基於已有的平台完成最終分析結果的呈現，呈現方式通常也有多種選擇，比如大屏展示等。

後端工程師的主要職責也集中在三大部分，分別是平台設計、介面設計和功能實現。平台設計主要是搭建後端的支撐服務容器；介面設計主要針對於不同行業進行相應的功能介面設計，通常一個平台有多套介面，就像衛星導航平台設有民用和軍用兩套介面一樣；功能實現則是完成具體的業務邏輯實現。

『貳』 程序員成長之路鍵盤系列（2）——鍵盤鍵數及布局

寫在前面的話

不要小看看似簡單的知識，因為很多時候，我們往往陷入了只學了一點點簡單知識，卻難以掌握復雜內容的困境。學習的關鍵在於，先把簡單的東西學得「門兒清」，這樣你會發現之前覺得難的知識也變得容易了。記住鍵盤的鍵數、布局和每個鍵的功能，暫時記不住沒關系，先有個印象，然後在練習中加深記憶。

一、鍵數

現在常見的標准鍵盤鍵數有108鍵、104鍵、96鍵、92鍵、87鍵。鍵盤圖片可以參考此鏈接：jingyan..com/article...

或者自行網路搜索「鍵盤鍵數」

這里需要記住：

二、鍵盤區域及布局

以104鍵為例，先上圖

通常，我們將鍵盤分為四個區域：主鍵盤區、功能區、編輯區和數字鍵盤區。

功能區主要用於操作操作系統或軟體的各種功能，包括1+12+3=16個鍵：

12個F鍵，F代表功能；1個Esc鍵，Esc代表逃脫；3個明顯標識的鍵分別是Print Screen/System Request、Scroll Lock、Pause/Back，分別代表列印屏幕（截圖）/系統請求、滾動鎖定、暫停/返回。

主鍵盤區的鍵最常用，用於輸入數據，共有26+10+11+14=61個鍵：

包括26個字母、10個數字、11個符號（包括左上角的反勾號）和14個控制鍵（左6+右6+空格+Backspace）。

編輯區主要用於編輯功能（增、刪、改、查），包括6+4=10個鍵：

包括6個英文標識的鍵和4個方向鍵。6個英文標識鍵用於增、刪、改、查，查在人類視角中意味著跳轉，例如在文本編輯器中移動到行首。4個方向鍵用於移動游標或軟體。

小鍵盤區主要用於數字輸入和計算，與銀行的密碼機類似，共有10+4+1+2=17個鍵：

包括10個數字鍵、4個運算符鍵、1個句點和2個控制鍵。

104鍵以外的其他鍵數的鍵盤，主鍵盤區不會改變，只會通過打包式增加或減少其他區域的鍵。打包的意思是會增刪一系列相關的鍵，例如刪除方向鍵時，需要同時刪除4個鍵，而不是只刪除一個鍵。

具體刪減情況，請參考標題一中的鏈接。

三、關鍵字與名詞

鍵盤、游標、運算、鍵數、布局、功能。

『叄』 Android 界面排版

Android布局是應用界面開發的重要一環，在Android中，共有五種布局方式，分別是：FrameLayout(框架布局),LinearLayout (線性布局),AbsoluteLayout(絕對布局),RelativeLayout(相對布局),TableLayout(表格布局).
一、FrameLayout
這個布局可以看成是牆腳堆東西，有一個四方的矩形的左上角牆腳，我們放了第一個東西，要再放一個，那就在放在原來放的位置的上面，這樣依次的放，會蓋住原來的東西。這個布局比較簡單，也只能放一點比較簡單的東西。

二、LinearLayout

線性布局，這個東西，從外框上可以理解為一個div，他首先是一個一個從上往下羅列在屏幕上。每一個LinearLayout裡面又可分為垂直布局（android:orientation="vertical"）和水平布局（android:orientation="horizontal" ）。當垂直布局時，每一行就只有一個元素，多個元素依次垂直往下；水平布局時，只有一行，每一個元素依次向右排列。
linearLayout中有一個重要的屬性 android:layout_weight="1"，這個weight在垂直布局時，代錶行距；水平的時候代表列寬；weight值越大就越大。

三、AbsoluteLayout

絕對布局猶如div指定了absolute屬性，用X,Y坐標來指定元素的位置android:layout_x="20px" android:layout_y="12px" 這種布局方式也比較簡單，但是在垂直隨便切換時，往往會出問題，而且多個元素的時候，計算薯指比較麻煩。 AbsoluteLayout 可以讓子元素指定準確的x/y坐標值，並顯示在屏幕上。AbsoluteLayout 沒有頁邊框，允許元素之間互相重疊（盡管不推薦）。他是絕對坐標，所以在實際中不提倡使用。
相對布局可以理解為某一個元素為參照物，來定位的布局方式。主要屬性有：
相對於某一個元素
// 相對於給雀埋定ID控制項
android:layout_above 將該控制項的底部置於給定ID的控制項之上;
android:layout_below 將該控制項的底部置於給定ID的控制項之下;
android:layout_toLeftOf 將該控制項的右邊緣與給定ID的數歲配控制項左邊緣對齊;
android:layout_toRightOf 將該控制項的左邊緣與給定ID的控制項右邊緣對齊;

android:layout_alignBaseline 將該控制項的baseline與給定ID的baseline對齊;
android:layout_alignTop 將該控制項的頂部邊緣與給定ID的頂部邊緣對齊;
android:layout_alignBottom 將該控制項的底部邊緣與給定ID的底部邊緣對齊;
android:layout_alignLeft 將該控制項的左邊緣與給定ID的左邊緣對齊;
android:layout_alignRight 將該控制項的右邊緣與給定ID的右邊緣對齊;

// 相對於父組件
android:layout_alignParentTop 如果為true,將該控制項的頂部與其父控制項的頂部對齊;
android:layout_alignParentBottom 如果為true,將該控制項的底部與其父控制項的底部對齊;
android:layout_alignParentLeft 如果為true,將該控制項的左部與其父控制項的左部對齊;
android:layout_alignParentRight 如果為true,將該控制項的右部與其父控制項的右部對齊;

// 居中
android:layout_centerHorizontal 如果為true,將該控制項的置於水平居中;
android:layout_centerVertical 如果為true,將該控制項的置於垂直居中;
android:layout_centerInParent 如果為true,將該控制項的置於父控制項的中央;

// 指定移動像素
android:layout_marginTop 上偏移的值;
android:layout_marginBottom 下偏移的值;
android:layout_marginLeft 左偏移的值;
android:layout_marginRight 右偏移的值;

example:
android:layout_below = "@id/***"
android:layout_alignBaseline = "@id/***"
android:layout_alignParentTop = true
android:layout_marginLeft = 「10px」

還可以指定邊距等，具體詳見API

五.TableLayout
表格布局類似Html裡面的Table。每一個TableLayout裡面有表格行TableRow，TableRow裡面可以具體定義每一個元素，設定他的對齊方式 android:gravity="" 。
每一個布局都有自己適合的方式，另外，這五個布局元素可以相互嵌套應用，做出美觀的界面。TableLayout 將子元素的位置分配到行或列中。一個TableLayout 由許多的TableRow 組成，每個TableRow 都會定義一個 row 。TableLayout 容器不會顯示row 、cloumns 或cell 的邊框線。每個 row 擁有0個或多個的cell ；和html中的table查不多少。在實際中也經常使用。

Android的Margin和Padding跟Html的是一樣的。通俗的理解 Padding 為內邊框，Margin 為外邊框
對應的屬性為
android:layout_marginBottom="25dip"
android:layout_marginLeft="10dip"
android:layout_marginTop="10dip"
android:layout_marginRight="10dip"
android:paddingLeft="1dip"
android:paddingTop="1dip"
android:paddingRight="1dip"
android:paddingBottom="1dip"
如果左右上下都是相同的設置則可以直接設置
android:layout_margin="10dip"
android:padding="5dip"

過去，程序員通常以像素為單位設計計算機用戶界面。例如，定義一個寬度為300像素的表單欄位，列之間的間距為5個像素，圖標大小為16×16像素 等。這樣處理的問題在於，如果在一個每英寸點數（dpi）更高的新顯示器上運行該程序，則用戶界面會顯得很小。在有些情況下，用戶界面可能會小到難以看清 內容。

與解析度無關的度量單位可以解決這一問題。Android支持下列所有單位。

px（像素）：屏幕上的點。

in（英寸）：長度單位。

mm（毫米）：長度單位。

pt（磅）：1/72英寸。

dp（與密度無關的像素）：一種基於屏幕密度的抽象單位。在每英寸160點的顯示器上，1dp = 1px。

dip：與dp相同，多用於android/ophone示例中。

sp（與刻度無關的像素）：與dp類似，但是可以根據用戶的字體大小首選項進行縮放。

為了使用戶界面能夠在現在和將來的顯示器類型上正常顯示，建議大家始終使用sp作為文字大小的單位，將dip作為其他元素的單位。當然，也可以考慮使用矢量圖形，而不是用點陣圖.
dp是與密度無關，sp除了與密度無關外，還與scale無關。
如果屏幕密度為160，這時dp和sp和px是一樣的。1dp=1sp=1px，但如果使用px作單位，如果屏幕大小不變（假設還是3.2寸），而屏幕密度變成了320。
那麼原來TextView的寬度設成160px，在密度為320的3.2寸屏幕里看要比在密度為160的3.2寸屏幕上看短了一半。
但如果設置成160dp或160sp的話。系統會自動將width屬性值設置成320px的。
也就是160 * 320 / 160。其中320 / 160可稱為密度比例因子。也就是說，如果使用dp和sp，系統會根據屏幕密度的變化自動進行轉換