為什麼每個程式設計師都應該懂點前端知識?
【編者按】本文作者為 OneAPM 工程師李哲,文章主要介紹前端知識對於程式設計的必要性。
這裡說的前端知識是比較通俗的前端知識,包括網頁,桌面或移動端程式的介面,命令列程式的提示等等,即和使用者進行互動的那一部分。我的工作經歷中,很多人是不在乎這一部分的,更有很多人覺得這個很 low,在年初的時候,還聽到一位這樣說,“前端無非就是 Copy Paste”,在前端技術發展這麼迅猛的現在,還能說出這樣的話,可見這個人的眼界是多麼的狹小了,連衝他苦笑的時間都騰不出來。
由於工作內容的關係,大部分情況都是在 Linux 的虛擬終端下,也就是敲擊鍵盤輸入各種命令,等著系統的反饋。我使用過很多更好用的命令列程式的替代品,比如 top 命令的替代 htop,看看 top 和 htop 的區別吧,很明顯 htop 要更好用。
虛擬終端用了那麼多年,也沒有什麼實質上的改進,只是多了幾種 shell 的變種,比如 zsh,fish 等等。實際上有很多人在做這方面的嘗試,原因也就是現在的虛擬終端太難用了。讓我們看看 black-screen 是什麼樣子的。black-screen 基於 electron 開發,也就是 github atom 的底層引擎。做的還不是完全相容,能滿足一般使用吧。
即使在虛擬終端這個領域,大家都在追求友好的介面設計,以及互動的友好。如果你認為 black-screen 沒有什麼技術含量的話,那就大錯特錯了,一個頁面裡渲染那麼多的內容,如何提升渲染的效能,是一個很大的難題,github 對 electron 有很多的優化,都是在如何渲染字元上下的功夫,可 github 的技術實力,相比微軟還是差了一大截,微軟的 VSCode 同樣基於 electron,但是啟動速度,執行速度都甩出 github 的 atom 幾條街。有點扯遠了,O(∩_∩)O~。
前面兩個例子可能有人沒有辦法理解,這和前端有什麼關係?從我使用這兩個工具的感覺是,他們更加好用,與原來的 top 和 terminal 來對比的話,我發現他的介面漂亮,使用起來簡單,出了錯誤的時候提示比較友好,比如 black-screen 在執行了一個長時間執行未立即返回執行結果的命令時,它會顯示一個滾動的進度條,而傳統的終端就是停在那裡,也不知道它是不是已經僵死了。
現在通常意義上的前端,就是 HTML,CSS,JavaScript 了,還有無數的前端框架,對於非專職的前端工程師來說,僅僅需要懂些基本的 HTML,CSS,以及一些 CSS 框架就可以了,比如 Twitter 的 Bootstrap,在真正的前端工程師看來,這些都是小菜一碟,而對於一個只搞後端的工程師來講,那真是全世界最難的事了,他們看不起前端,卻又做不出來。缺少介面,你做的工具就沒有辦法用,介面難用,工具也就很難用,雖然裡面的程式碼可能寫的很棒。
拿我們用了一年的 OpenTSDB 說吧,那個介面真是讓人想死的心都有,動不動就是直接報錯,雖然是好東西,可是這臉面真是不能恭維。對比一下它和Grafana。
其實也不用做這麼好看,但是最起碼是可用的,看起來是整整齊齊的,就像命令列的幫助文件那樣,雖然是基於字元的,但是一看就是認認真真的做出來的,像 OpenTSDB 那個明顯是出來糊弄事兒的。
這個都比 OpenTSDB 的介面好
說點歷史問題吧,最早的程式設計師根本不分前後端,VB,Delphi 的 C/S 時代,介面就是妥妥拽拽,寫任何程式都是要自己做介面的;後來到了 B/S 時代,做網頁的稱為美工,終於提取出這樣一個工種,還需要懂 PS 切圖,又出來一個 Dreamweaver,也是想拖拖拽拽的解決問題。再到後來,網頁前端越來越複雜,像 Java 社群出的 JSF ,還有 HTML5 崛起前的那兩年,Adobe 的 Flex,AIR,很多工作流軟體就是用這兩項技術做的,以及 Java 從誕生起最雞肋功能 — JavaFX。那個時候,真正用軟體的人少,其實也是人們不會用,因為介面上也就是前端了,沒有人用的明白,太複雜。直到最近五年,到了每個人都會用軟體的時代,技術雖然是進步了,但是讓人們,從小孩到老人都能去用這些軟體的根本原因不僅僅是技術進步,更重要的是介面的互動設計進步了,它讓每個人都能很簡單的學會如何操作。
現在到了大資料的時代,儲存資料是一個要解決的問題,從資料中發現價值是另一個要解決問題,而資料視覺化可淺顯的歸為前端工作,畢竟是要從資料中“看到”價值,當然,這部分工作只是懂前端知識是不夠的,所以如果大資料工程師能夠懂得如何將資料視覺化出來,也許更能體現他們的價值,而不僅僅是把那些大資料的元件玩的滾瓜爛熟,卻不能“看到”什麼東西。
前端已然發展成為一個和大資料一樣熱門的職業了,雖然你可能不是一個前端工程師,但是稍微學一點,不要讓時代把你給落下了。
OneAPM Browser Insight 是一個基於真實使用者的 Web 前端效能監控平臺,能幫助大家定位網站效能瓶頸,實現網站加速效果視覺化;支援瀏覽器、微信、App 瀏覽 HTML 和 HTML5 頁面。想閱讀更多技術文章,請訪問 OneAPM 官方技術部落格。
相關文章
- 為什麼每個程式設計師都應該學習程式碼編譯器知識程式設計師編譯
- 每個程式設計師都應該瞭解的硬體知識程式設計師
- 為什麼說每個程式設計師都應該有臺Mac電腦程式設計師Mac
- 每個程式設計師都應該成為架構師程式設計師架構
- 每個程式設計師都應該瞭解的記憶體知識程式設計師記憶體
- 程式設計師都該懂點 HTTP程式設計師HTTP
- 為SSD程式設計(6):總結—每個程式設計師都應該瞭解的固態硬碟知識程式設計師硬碟
- 每個人都應該懂點函數語言程式設計函數程式設計
- 每個程式設計師都應該瞭解的“虛擬記憶體”知識程式設計師記憶體
- 每個前端工程師都應該瞭解的圖片知識前端工程師
- 每個程式設計師都應該讀的書程式設計師
- 前端程式設計師為什麼應該拿高薪前端程式設計師高薪
- 程式設計師都應該知道的福利【必知必懂】程式設計師
- 每個程式設計師都應該讀《Unix程式設計藝術》程式設計師
- 程式設計師都應該懂一點開源協議程式設計師協議
- 每個程式設計師應該知道的計算機網路知識程式設計師計算機網路
- 程式設計師都應該瞭解哪些安全知識程式設計師
- 為什麼人人都該懂點LLVMLVM
- 每個程式設計師都應當知道的編譯器優化知識程式設計師編譯優化
- 每個程式設計師都應該知道的 15 個最佳 PHP 庫程式設計師PHP
- 每個程式設計師都應該參加一次 GDD程式設計師
- 每個程式設計師都應該知道的基礎數論程式設計師
- 為什麼每個Android開發者都應該使用AnkoAndroid
- 為什麼每一個爬蟲工程師都應該學習 Kafka爬蟲工程師Kafka
- 設計師都應該知道的ICON知識
- 國外程式設計師推薦:每個程式設計師都應該讀的非程式設計書程式設計師
- 程式設計師為什麼不應該加班程式設計師
- 每個程式設計師都應該學習使用Python或Ruby程式設計師Python
- Rework:每個程式設計師都應該讀的一本書程式設計師
- 每個程式設計師都應該學會分解複雜的方法程式設計師
- Java 程式設計師都該懂的 HashMapJava程式設計師HashMap
- web前端入門很容易,全棧卻很難,為什麼每個程式設計師都那麼說?Web前端全棧程式設計師
- 每個程式設計師都應該知道的下一個程式語言——Kotlin程式設計師Kotlin
- 每個程式設計師應該知道12件事程式設計師
- 每個程式設計師都應該經歷一次軟考薦程式設計師
- 為什麼程式設計師應該少寫程式碼程式設計師
- 作為一個Java 程式設計師 你應該會什麼Java程式設計師
- [譯] 為什麼每個 Android 開發者都應該嘗試 FlutterAndroidFlutter