• <acronym id="eyrpt"></acronym>
    <track id="eyrpt"></track>
    <p id="eyrpt"></p>

      <table id="eyrpt"><ruby id="eyrpt"></ruby></table>
      <table id="eyrpt"></table>

    1. 當前位置:首頁 > 短網址資訊 > 正文內容

      【FT12短網址】JavaScript 疲勞終極指南:我們行業的真相

      引言

      812是個很有含義的數字,本文是FT12短網址摘錄自網絡,版權和其他權益歸原作者所有。

      正文從這開始~

      抱怨 JS 疲勞就像是在抱怨人類發明了太多解決問題的工具:從郵件到飛機到宇宙飛船。

      上周我在 NebraskaJS 2017 會議上做了一個和這個話題極其類似的演講,我也收到了許多積極的反饋,所以我就想這個演講也可以寫成一篇文章發表出來,讓更多的人知道,并幫助他們應對 JS 疲勞,理解我們行業的真相。這篇文章的目的是希望改變你對軟件工程行業的普遍的看法,助你在你可能工作的領域上一臂之力。

      激勵我寫下這篇文章并且徹底改變我生活的一個原因是 Patrick McKenzie 寫的這篇很贊的文章,文章名叫《請不要自稱程序員和一些職業生涯建議》。強烈推薦你閱讀下上面這篇文章。本文的大部分內容都是基于 Patrick 的那篇關于 JavaScript 生態系統的文章的建議,其中也夾雜了最近幾年我在科技行業工作的一些想法。

      第一個章節可能會有點哲學化,但是我保證絕對值得一讀。

      我們行業的真相 101

      就像 Patrick 在 他的文章 里寫到的,我們先從一些最基礎、最根本的真相說起:

      軟件是用來解決業務問題的

      實事就是這樣。軟件存在的意義并不是用來取悅我們程序員的,并不是為了讓我們寫出漂亮代碼的,也不是為科技行業創造就業機會的。實際上,軟件的存在扼殺了太多的工作崗位,其中也包括我們的,這就是為什么基本工資在未來的幾年將會變得更加重要,但是這就完全是另一個話題了。

      我這樣說很抱歉,但是歸根結底原因在于:在軟件工程中(其他行業也是如此)只有兩樣東西至關重要:

      支出和收益

      支出削減的越多,收益提升的越多,那么你的價值就越大,削減支出、提升收益最通用的一個方法就是用機器代替人工,從長遠來看,這種方法是更有效的,而且支出也更少。

      你不是被雇傭來寫代碼的

      科技不是目的。沒有人關心你使用的是什么編程語言,沒有人關心你的團隊選擇的是什么框架,沒有人關心你的數據結構有多么優雅,也沒有人關心你的代碼寫得有多漂亮。人們唯一關心的是:你的軟件支出是多少,產生的收益是多少,僅此而已。

      寫出漂亮的代碼對于你的客戶而言沒有任何卵用。我們之所以要寫漂亮的代碼,是因為長遠來看這樣會更高效,能夠減少支出,增加收益。

      我們努力避免 bug 不是說我們重視正確性,而是我們的客戶重視正確性。如果你曾經遇到過一個 bug 成為了一個特性的話,那么你就知道我在說什么了。這個 bug 確實存在,但是我們不會去修復。出現這種情況并不是說我們的目的就是制造 bug,我們的目的是創造價值。但是如果我們的 bug 能夠使客戶開心,能夠提升他們的收益,我們也能達成我們的目標,如此皆大歡喜,何樂而不為呢。

      可重復使用的太空火箭、自動駕駛汽車、機器人、AI:這些東西之所以存在,并不是因為我們覺得它們很酷,而是因為在它們的背后有商業利益存在。我并不是說這些東西背后的那群人只在乎金錢,我確定他們也認為這東西很酷,但事實是,如果沒有經濟利益或者說沒有潛在的經濟價值,這些東西是不會存在的。

      也許我不應該將這一章節取名為“我們行業的真相 101”,也許應該取名為“資本主義真相 101”。

      說到我們的目標——減少支出提升收益——我認為作為程序員的我們應該更加關注需求和設計,積極思考,積極參與業務決策,這就是為什么了解我們正在開展的問題領域變得極其重要。之前你有多少次在你的經理或商務人士沒有考慮到的某些邊緣案例中想到應該發生什么?

      1975 年,Boehm 做過一項研究,研究發現,軟件中 64% 的錯誤都是由設計引起的,只有 36% 的錯誤是代碼錯誤。另一項叫做 “高階軟件——軟件定義方法論” 的研究也顯示:在 NASA 的阿波羅計劃中,73% 的錯誤都是設計錯誤。

      設計和需求存在的唯一目的就是定義我們將要解決的問題,而解決問題就能創造收益。

      沒有了需求或設計,編程就是往一個空的 text 文件里面添加 bug。@Louis Srygley

      這個原則同樣適用于 JavaScript 生態系統的工具。Babel、webpack、react、Redux、Mocha、Chai、Typescript,所有這些工具之所以存在就是為了解決對應的問題,我們要理解它們要解決的是什么問題,要仔細思考什么時候需要這些工具,否則,我們就會感到 JS 疲勞,因為:

      當我們使用我們不需要的工具來解決根本就不存在的問題的時候,JS 疲勞就出現了。

      正如 Donald Knuth 曾今說的:“過早優化是萬惡之源”。請記著,軟件的存在是為了解決相應的業務問題,大部分的軟件其實都挺令人厭煩的,既沒有多強的擴展性,也沒有高性能約束。要專注于解決業務問題,專注于減少支出、提升收益,這才是需要關注的焦點。只有在當你需要優化的時候才去優化,否則,軟件可能會增加一些不必要的復雜性,而這些復雜性會增加支出,并且不能產生足夠的收益來抵消這些支出。

      這就是為什么我認為應該在我們的工作當中應用 測試驅動開發 原則。我說的測試驅動開發并不是說僅僅去做測試。我說的是在問題暴露之前將其扼殺在搖籃里。這才是 TDD 要做的。正如 Kent Beck 說的“TDD 減少了恐懼”,因為它能夠指導你的開發節奏,允許你慢慢地逐步解決你的問題,一步一個腳印,一次解決一個問題。當我們要使用新的技術時,這樣做同樣也會減少恐懼。

      一次解決一個問題同時也降低了 分析麻痹,舉個栗子,就好比你打開了 Netflix,你本可以看一些視頻的,但是卻花了三個小時來決定看什么。一次解決一個問題的方式可以縮小我們做決定的范圍,縮小了做決定的范圍我們的選擇就會相對減少,選擇減少了我們就降低了分析麻痹。

      不知道你有木有想過,如果只有幾個可看的電視頻道,決定看哪個頻道會變得多么簡單?如果家里只有幾張游戲盤,決定玩兒哪個游戲會變得多么簡單?

      那么對于 JavaScript 而言呢?

      截止到我寫這篇文章時,NPM 上有 489,989 個包,第二天將會有差不多 515 個包在上面發布。

      我們使用、抱怨的這些包都是有一個歷史出發點的的,為了理解我們為什么需要這些包,我們必須理解這個歷史出發點:它們是用來解決問題的。

      Babel、Dart、CoffeeScript 和其他轉義器之所以會出現,是因為我們不僅僅使用 JavaScript 寫代碼,但是我們又想使其能夠在瀏覽器中正常運行。Babel 甚至能夠使我們使用 JavaScript 新版本語法寫的代碼在舊版本瀏覽器中運行,因為眾所周知,不同版本的 ECMA 規范在各個瀏覽器中的兼容是一個很大的問題。盡管現在 ECMA 規范已經越來越可靠,但是我們仍然需要 Babel。如果你想了解更多關于 Babel 的相關知識,我強烈推薦你讀讀 這篇由 Henry Zhu 寫的很贊的文章。

      像 Webpack 和 Browserify 這樣的模塊化打包工具也有它們存在的理由。想必你們依然記得,曾幾何時,我們使用大量的 script 標簽將腳本引入使其能夠正常運行。這樣做的結果就是污染了全局命名空間,當一個腳本依賴另一個腳本時,很難合理地將它們整合起來。為了解決這個問題,Require.js誕生了,但是它仍然有它自己的問題:它不夠簡單,語法也會引起其他問題,正如你在這篇文章中看到的。然后 Node.js 借鑒了 CommonJS 的 import,這種 import 是同步的,簡單整潔,但是我們仍然需要一種可以在瀏覽器中運行的方式,這就是為什么我們需要 Webpack 和 Browserify 的原因。

      Webpack 確實解決了很多問題,比如可以像處理 JavaScript 依賴那樣處理 CSS、圖片和許多其他的資源。

      前端框架確實有點復雜,但是由于它們的存在,使得我們寫代碼時減少了同步加載,如此一來,我們就不必擔心 DOM 操作,甚至也不用和那些亂七八糟的瀏覽器 API(JQuery 已經解決了這個問題)直接打交道,眾所周知,瀏覽器的兼容性處理錯誤百出,而且效率低下。

      這就是我們在計算機科學中一直在做的事情。我們使用低級抽象,并在其上構建更多的抽象。我們應該更多考慮的是,我們的軟件應該如何運行,而不是怎么讓它運行,這樣的話,才能更高效。

      但是所有這些工具都有一個共同之處:它們之所以存在是因為 web 平臺發展太快了。如今任何地方都有 web 技術的存在:web 瀏覽器,桌面應用,電話應用,甚至手表應用。

      這個革命性發展同樣也暴露出了我們需要解決的問題。比如,漸進式 web 應用(PWA),它們之所以存在不是因為它們很炫酷,不是因為作為程序員的我們樂于寫 PWA。請牢記本文的第一節:PWA 之所以存在,是因為它們創造了商業價值。

      通常情況下,標準的制定速度并沒有那么快,因此,針對對應的問題我們需要自己尋求解決方法,這就是為什么有一個活躍度高、有創造力的社區是一件很 nice 的事情。我們不是在解決問題,就是在去解決問題的路上。當然,我們也會順其自然。

      適用于我們的工具會更好地成長,獲得更多的貢獻者,更快地發展,有時一些工具最終將融合來自于其他工具的優秀想法,并且變得比它們更受歡迎。這就是我們演變的進程。

      擁有越多的工具,我們就會擁有越多的選擇。想必你還記著 UNIX 思想,它主張我們在編程時,一次只做一件事情,而且要將它做到極致。

      我們可以清晰的看到這種思想在 JS 測試環境中重現,比如,我們使用 Mocha 跑測試,使用 Chai 做斷言,而在 Java 中,JUnit 把這些事情全部包攬了。這就意味著,如果你在使用某一個工具的過程中遇到了問題,并且發現另一個工具更適合我們的話,那么我們就可以直接簡單的替換掉之前的工具就可以了,其他工具的優勢我們依然能夠保留。

      UNIX 思想同時主張我們應該去寫能夠“和諧相處”的程序。這正是我們在做的!比如說 Babel、Webpack 和 React。同時使用它們完全能夠正常運行,但是我們并不需要使用一個工具而去依賴另一個工具。比如我們在測試環境中使用 Mocha 和 Chai,那么我們也可以安裝 Karma 在多種環境中來跑同樣的測試。

      如何應對

      針對正在遭受 JS 疲勞的同學,我的第一個建議是:你要清醒的認識到你并不需要掌握所有東西。有時我們會一次性學習過多的知識——甚至當我們并不需要的時候,這樣做只會增加疲勞感。你喜歡的領域你要保持積極的學習動力,可以深入了解,而對于其他的知識,你大可保持慵懶的態度。我這里說的慵懶不是讓你懶惰,而是在你需要某些知識的時候再去學習。當你遇到了問題,且需要使用某項知識技能來解決的時候,直接現學就可以了。

      另一個重要的建議是:腳踏實地,從頭開始。在你使用任何 JavaScript 框架之前,請確保你對原生 JavaScript 學習的已經足夠透徹。這是你掌握 JavaScript 并能夠將其“玩弄于鼓掌之中”的唯一途徑,否則,當你遇到了你之前從來沒有見過的問題時,你就不知道該如何下手。學習核心的 web 技術——CSS、HTML5、JavaScript和計算機科學基礎,甚至是 HTTP 協議的工作原理——將會有助于你快速掌握任何其他的技術。

      但是,請務必不要用力過度。偶爾你要挑戰一下自己,親自動手做一些項目。正如 Sacha Greif 在這篇文章里寫到的那樣:花費過多的時間學習基礎知識就像你要學習游泳時總是在學習流體動力學。學到一定程度以后,你就應該跳到游泳池里去嘗試游泳。

      同時,請務必不要拘泥于一項技能。我們現在可用的技術其實在過去都早已被發明出來了。當然,它們特性不同,名字不同,但是,本質上它們都是相同的。

      如果你看看 NPM 的話,它也不是什么新技術,很早之前就有 Maven Central 和 Ruby Gems 了。

      用來轉義代碼的 Babel,也是借鑒了早期一些非常出名的編譯器的原則和理論,比如 GCC。

      甚至 JSX 也不是什么新想法。E4X(ECMAScript for XML)10 多年前就存在了。

      那么現在你可能會問:“那 Gulp、Grunt 和 NPM 腳本又如何呢?”額,好吧,很遺憾的告訴你,這些問題 GNU Make 在 1976 年都已經解決了。實際上,現在仍然有大量的 JavaScript 工程在使用 GNU Make,比如 Chai.js。但是我們不會那樣做,因為我們是喜歡復古的潮人。我們使用 make,因為它解決了我們的問題,正如我們之前討論過,這就是你的目標所在。

      如果你真的想要理解某項技術,想要在面對任何問題時都能夠得心應手,那么,請深入了解。成功最關鍵的一個因素就是好奇心,所以請深入了解你喜歡的技術。嘗試自下而上的理解它們,每當你認為某些東西如“魔法”一般時,那么請通過探索代碼庫來揭開它的神秘面紗。

      在我看來,說到學習這塊兒,Richard Feinman 的這句名言最適合不過了:

      我創造不了的東西,我理解不了

      再來看看下面這句,這是 Richard 在同樣的一塊兒黑板上寫下的:

      對于已經存在答案的問題要知道如何解決

      是不是很贊?

      當 Richard 說這些話的時候,他正在討論的是關于獲取理論結果并如何復現的問題,但是我認為,該原則同樣適用于軟件工程。能夠解決我們的問題的這些工具已經被發明出來了,它們已經存在了,所以我們也應該能夠自己來實現它們。

      這正是我喜歡 Egghead.io 中一些視頻的原因,視頻中 Dan Abramov 解釋了如何從頭開始實現 Redux 中存在的某些功能,或者教你如何構建自己的 JSX 渲染器。

      那么我們為什么不去嘗試著自己來實現或者去 GitHub 上閱讀代碼庫理解它們的原理來實現這些東西呢?我確定你一定能夠發現很多有用的知識。評論和 demo 也許會撒謊,也許會誤導,但是代碼不會。

      另一個我們在這篇文章中談論的最多的話題是:你不應該超前你自己。遵循 TDD 原則,一次只解決一個問題。你被雇傭是來降低成本提升收益的,你所做的都是為了解決問題,這就是軟件存在的意義。

      既然我們喜歡拿我們自身的角色和土木工程相關的作對比,那么就讓我們快速對比下軟件開發和土木工程,就像Sam Newman 在《構建微服》中做的那樣。

      我們喜歡自稱“工程師”或“架構師”,但是這樣真的好么?我們一直在為不到一百年前的計算機開發我們所知的計算機軟件,而競技場都存在大約兩千年了。

      還記得最近一次看到一座橋坍塌是什么時候嗎?還記得最近一次你的手機或瀏覽器奔潰是什么時候嗎?

      為了更好的解釋,我借用一個我比較喜歡的栗子。

      這是美麗驚艷的巴塞羅那。




      當我們從這個距離看這座城市的話,它開起來和世界上的其他城市一般無二,但是當我們從上面俯瞰時,巴塞羅那看起來是這個樣子的:




      正如你看到的,每一個塊兒都有著相同的尺寸,所有的塊兒都有條不紊的排列著。如果你曾經去過巴塞羅那的話,你一定知道穿越這座城市有多么爽,知道它運行的多么良好。

      但是坐在飛機上俯瞰巴塞羅那的人無法預知兩百年或者三百年后它會成為什么樣子。城市里的人們進進出出,他們要做的是讓城市隨著時間的流逝有機地成長、適應。他們必須做好應對變化的準備。

      同樣的事情也發生在軟件方面。軟件更新迭代很快,會經常需要重構,需求也會頻繁的變更,這完全在我們的預期之外。

      所以,不要把自己當做軟件工程師,要把自己當做城市規劃者。讓你的軟件有機成長,按需適應。兵來將擋,水來土掩,問題來了就去解決,但是要確保一切都有其所在。

      在軟件領域做這些事情比在城市里做這些事情要容易的多,因為軟件是靈活的,土木工程并不是,在軟件世界里,我們的“建筑時長”就是編譯時長。在巴塞羅那我們不能通過簡單地毀掉建筑給新的建筑騰出空地兒,但是在軟件世界里我們可以非常簡單的實現。我們隨時可以推翻重做,隨時可以做實驗,我們想構建幾次就構建幾次,時間花費也就那么幾秒鐘,但是我們思考的時間卻比構建的要多得多。我們的工作是純智力型的。

      所以把自己當做城市規劃者,讓你的軟件按需成長、適應。

      通過這樣做,你就能夠更好的抽象,也會知道在什么合適的時間來采用它們。

      正如 Sam Koblenski 所說:

      抽象只適用于合適的語境,而合適的語境是隨著系統的發展而發展的。

      有時候我經常會看到這種現象:有些同學在學習一項新技術時會去尋找模板,但是在我看來,當你開始學習的時候,應當避免使用模板。當然,如果你已經有了一定經驗,那么模板和生成器還是很有用的。模板剝奪了大部分的控制權,因此你就學不到如何去新建一個工程,你也無法準確理解每個代碼片段適合哪里。

      當你無法輕輕松松地把事情搞定,當你感受到的都是苦苦的掙扎時,也許是時候另辟蹊徑了。我們的宗旨是力爭懶惰,你應該為了以后不工作的目標而去工作。如此一來,你就會有更多的自由時間去做其他的事情,從而減低了成本,提升了收益,所以這也是你達成目的的另一條途徑。你不應該沒頭沒腦的努力工作,你要更加聰明的工作。

      也許有些人也會擁有你現在的煩惱,但是如果沒人這樣做的話,那么你的機會就到了,你可以找到你自己的解決方法,可以給其他人伸出援助之手。

      但是有時候在你沒有看到別人做的更優秀之前,你并不會意識到其實你也可以做的更高效。這就是與人交流的重要性。

      通過和其他人交流,你可以分享你的經驗,為對方的職業生涯提供幫助,也能發現能夠提升我們工作流的新工具,而且更重要的是,你能夠學到解決問題的方法。這就是我喜歡閱讀分享公司解決問題方法的文章的原因。

      尤其是在我們的領域里,我們總是認為 Google 和 StackOverflow 能夠回答我們的所有問題,但是我們仍然有必要知道我們要問的問題。我確定會有這么一種場景:你遇到了一個你無法解決的問題,因為你無法準確的知道發生了什么事情,所以你自己都不清楚你應該問什么問題。

      但是如果我需要用一個建議來總結整篇文章的話,那就是:

      解決問題。

      軟件不是魔法箱,也不是一首詩(很不幸)。它的存在是為了解決問題,提高人們的生活水平。軟件的存在是為了讓世界向前發展。

      年輕人,該你出動解決問題了。

      最后,不知道你在前端圈工作幾年了,你是否在某一時刻動過轉行離開前端圈,去做點其他的事情呢?


      掃描二維碼推送至手機訪問。

      版權聲明:本文由短鏈接發布,如需轉載請注明出處。

      本文鏈接:http://www.virginiabusinesslawupdate.com/article_398.html

      分享給朋友:

      相關文章

      暗網?No,你落伍了,它是“蜜罐”

      暗網?No,你落伍了,它是“蜜罐”

      最近發生在美國一個華人綁架事件把“暗網(Darknet或Dark Web)”帶入到公眾的視野,本文從技術角度分析暗網的工作原理和安全性。什么是暗網我們日常使用的互聯網(Internet)被稱為“明網”,與之對應的借助互聯網而形成的“隱藏”的...

      職業打假人,這幾年的沉浮路

      職業打假人,近代的歷史,可以從這個行業的“祖師爺”王海說起,在上個世紀90年代初,王海的打假行為,對于這個行業的誕生,起到了“啟蒙”的作用,雖然在90年代,整體的大環境并未引起太大的波瀾,但是“職業打假”的這 顆種子,和王海的職業,一同發展...

      正態分布為什么常見?

      正態分布為什么常見?

      統計學里面,正態分布(normal distribution)最常見。男女身高、壽命、血壓、考試成績、測量誤差等等,都屬于正態分布。以前,我認為中間狀態是事物的常態,過高和過低都屬于少數,這導致了正態分布的普遍性。最近,讀到了 J...

      微博開源的Motan RPC最新進展:新增跨語言及服務治理支持

      微博開源的Motan RPC最新進展:新增跨語言及服務治理支持

      https://github.com/weibocom/motanMotan 是一個基于 Java 開發的高性能的輕量級 RPC 框架,Motan 提供了豐富的服務治理功能和優秀的擴展能力,可以方便的基于 Motan 進行二次開發。Mota...

      Uber宣布正式進入卡車行業 美國核心產業或將被顛覆

      Uber宣布正式進入卡車行業 美國核心產業或將被顛覆

      據CNBC報道,專車使用Uber日前推出名為Uber Freight的新使用,可協助貨車公司更高效地配貨,并協助司機減輕壓力。這款使用的推出標志著Uber正式進入貨車工作,并也許推翻美國的中心工業。美國勞工統計局發布數據顯現,交通和物資運送...

      URL短鏈接壓縮算法-短網址一一映射

      URL短鏈接壓縮算法-短網址一一映射

      微博短地址原理解析 (Java實現)一種方法是調用第三方提供短址服務的接口來生成即可。一般他們提供接口或調用包。如:怎樣調用百度短網址api?  http://www.baidu.com/search/dwz.html...

      發表評論

      訪客

      ◎歡迎參與討論,請在這里發表您的看法和觀點。
      一本色综合网久久
    2. <acronym id="eyrpt"></acronym>
      <track id="eyrpt"></track>
      <p id="eyrpt"></p>

        <table id="eyrpt"><ruby id="eyrpt"></ruby></table>
        <table id="eyrpt"></table>