咱們和優秀工程師的差距在哪兒

關注微信公衆號: BaronTalk,獲取更多精彩好文。

我相信每一個工程師都曾懷揣一個成爲技術大牛的夢想,但是真正走向技術大牛這條路的少之又少。工做中咱們經常會發現,有些同窗工做沒幾年但成長迅速;很快就能走向團隊核心崗位,成爲一名優秀的工程師;而有些同窗工做幾年後卻在公司裏默默無聞,能力和職位上都沒有太大提高,得過且過最終淪爲一名普普統統的碼農。因此我經常會有感慨,太多人(包括我本身)真的只不過是用一兩年的經驗在職場上混了五年十年甚至更久。git

那麼普通工程師和優秀工程師到底差距在哪兒?那些優秀工程師是怎麼一步一步成長起來了的呢?如下就我本身的觀察和思考來談一談,看看能不能一探究竟,瞭解通向優秀工程師的法門;而後與你們共勉,一塊兒朝着優秀工程師的方向去努力。github

差距在哪兒?

咱們拿吳軍老師在獲得專欄中講解的一道 Google 面試題來展開聊一聊,看看面對一樣的問題,普通工程師和優秀工程師是如何思考解決問題的。面試

問題以下:如何設計一個地圖功能,找到離當前最近的加油站?算法

在最近公司的招聘面試過程當中,我也拿相似的問題去問過部分候選人,大部分候選人都把問題想的太簡單。一般普通工程師給出的解決方案是:根據經緯度算出全部加油站到當前位置的距離,而後對這些加油站按照距離的遠近進行排序,選擇距離最近的幾個加油站。服務器

可問題是,在路面上行駛,從 A 點通往 B 點,每每不是直線距離。由於不管是駕車仍是步行,咱們都不可能穿過建築直達目的地,A 點到 B 點的距離是不少距離片斷的組合,這可能會有上千種組合,那麼如何從這上千種組合的路線中選擇距離最近的一條路線呢?使用動態規劃算法可以很好的解決這個問題,在上千種組合中只需幾十個步驟就能計算出最短路線。這對部分工程師已是個門檻了。微信

接下來就須要按照距離排序,找到最近的幾個加油站。數據結構

絕大部分工程師面對這樣的問題都會想到排序,排序固然可以解決問題,但並非最優方案。就算使用效率最高的快速排序,也須要 N 乘 LogN 的計算量。假設城市裏有 1000 個加油站,那麼 LogN 約等於 10,也就是說計算的複雜度差很少是 1000,固然 1000 的計算量對於計算機算不上什麼,可是考慮到一個城市的路面上可能有上百萬輛行駛的汽車,這個計算量的消耗就很可觀了。框架

假設咱們只須要最近的 5 個加油站,若是對全部的加油站排序那顯然作了不少無用功。數據結構中有一種叫二叉樹的數據結構,在二叉樹中有一種更細的分類:「堆」,經過堆排序咱們能夠只用排出前幾名,而不用管後面的名次。經過堆排序排出第一名的時間複雜度是N,排出第二名、第三名、第四名、第五名的時間複雜度都 LogN,比對 1000 個加油站排序要快的多。對於咱們的需求:選出最近的 5 個加油站,差很少只須要 1000 的計算量,比快速排序快了近 10 倍。工具

到這裏你是否是以爲問題已經解決的很完美了?性能

咱們在解決問題的時候情不自禁的作了一個假設,就是整個算法的優化過程是圍繞一個使用者的某一次使用來進行的。可是在現實生活中,一個城市裏有不少人會同時在不一樣的地方尋找加油站。相似的,同一我的在不一樣的時間不一樣的地點開車時也須要尋找加油站。考慮到這個現實場景,時時刻刻都有不少人在不停的尋找附近的加油站,那麼不少計算實際上是能夠預先算好的,等到提供服務的時候直接把結果調出來就行了,避免重複計算。

好比咱們能夠把上海市全部路口點到點的距離事先計算好,當一我的要找加油站的時候,距離的計算就再也不須要實時地採用動態規劃來計算了,只須要計算從當前位置出發到附近幾個路口的距離,再計算下某個加油站到它所在地附近路口的距離,因爲各個路口點到點的距離是事先計算好的,所以作幾回簡單的加法便可,這樣計算距離的時間就能省幾十倍。這就是對上面的問題進行了全局優化的好處。

其實面對這樣的問題,優秀的工程師並不會遇到問題就直接着手去解決,而是會更全面的去考慮問題。好比會考慮到目前的行車方向,好比在解決問題中其實距離要求並不須要太精準,由於對於開車的人來講 2.5 千米和 2.3 千米其實並無什麼差異,再考慮到道路擁堵的狀況,200 米的距離更加能夠忽略不計了。但若是是行人要尋找附近的便利店,200 米的距離就不得不考慮了。

那麼從上述這個問題的解決上咱們能看出普通工程師和優秀工程師的差距在哪兒呢?

1. 優秀的工程師必然有着紮實的計算機基礎知識,很好的掌握瞭如數據結構、算法這些工具,可以在工做中藉助這些工具幫助本身解決問題;

2. 優秀的工程師會盡可能避免作無用功

3. 優秀的工程師不會只知足於完成任務,他們會不斷的去思考探索最佳的解決方案;

4. 優秀的工程師不會被思惟所侷限,考慮問題更加全面,懂得從全局角度優化解決方案。

從這個例子咱們也能看出來,一個優秀工程師解決問題的性能多是普通工程師的幾百上千倍,一個優秀的解決方案甚至能幫助公司節省幾百萬的服務器費用。

所以,在軟件工程領域一百個臭皮匠也頂不了一個諸葛亮!

作爲普通工程師的咱們如何提高本身?

學好數據結構、算法、操做系統原理、計算機體系結構等基本功,打好基礎。

若是你是天才,面對像上面這樣的問題,即便你沒有學過計算機理論知識,即便你不知道動態規劃、二叉樹、堆排序,可能也能依靠智力上的優點解決。但遺憾的是絕大多數人都不是天才,所以在解決問題的時候就須要藉助各類工具以便事半功倍。對於開發人員來講,數據結構、算法以及各類數學知識就是咱們手上的工具。

要成爲優秀的工程師須要咱們靜下來,沉下去,老老實實的吃透你所作的項目。作好簡單的事,纔有機會去作更有挑戰的工做。

不少工程師會抱怨本身一直在作業務,沒什麼挑戰,感受不到成長。可事實真的是這樣嗎?每每咱們的業務需求就像這道面試題,看似簡單其實想要作好,背後須要下很大功夫。就算平時作的業務真的很簡單,咱們是否是還能夠想一想,個人代碼實現是否有更好的方式?面對相似的業務個人效率是否能夠提高?線上出 Bug 了是否能夠採集到線上 Log 快速定位並解決問題?你對本身開發的項目中用到的各類框架是否真的理解其原理,是否真的去翻過代碼學習過這些優秀框架的實現?就拿 Android 開發來講,各類開源框架如 RxJava、Retrofit、OKHttp、ORM框架、熱修復框架、插件化框架等等,若是你真的去認真學習過一遍,我相信已經遠超行業裏 90% 的工程師了。

同時在工做中要有不怕吃虧的心態,主動去承擔更多的職責;作的更多每每也意味着接受了更多的挑戰,得到了更多的鍛鍊機會。

利用碎片時間系統化學習

不少人反對碎片化學習,但我並不徹底認同這種見解。碎片化的時間既能夠用來碎片化的學習,也能夠用來作系統化的學習。不少人都期望可以有一天,有一大片的時間,好好的、系統化的把計算機知識惡補一遍。因此買了算法導論、深刻理解計算機系統等等經典書籍放在家裏,等着有一天可以有一大片時間,沐浴更衣、正襟危坐來好好學習。可是學了不久很快又被其它事打斷了,結果下一次又從新再來。最後每每只是把一本書的前幾十頁反覆看了好多遍,其實這種纔是真正的碎片化學習。

而所謂的利用碎片化時間系統化的學習是指制定好完善的學習計劃,利用好每個碎片時間,好比上下班的路上、等公交的時間、坐地鐵的時間、排隊的時間,甚至是蹲馬桶的時間來按計劃的、體系化的學習提升。

持續學習,堅持閱讀,保持輸出

技術更新迭代太快,而計算機科學之複雜也遠不是在學校的幾年學習就能徹底學透的,這就要求咱們保持持續學習。但每每不少人走出校門後就再也沒有正兒八經的學習過、衝過電,這也是爲何咱們畢業後會被那些優秀的工程師越甩越遠的緣由。而我認爲最好的持續學習的方式就是堅持閱讀了。大家看!優秀的工程師就算是掛着鹽水也要堅持閱讀的!!!???

另外學過的知識只有輸出出來了,纔是真正的學到肚子了。向別人講述知識、寫做等都是很好的知識輸出方式。

鍛鍊本身的綜合能力

要成爲一名優秀的工程師,光有過硬的技術是不夠的。出色的完成一項工做每每考研的是一我的的綜合能力。良好的表達能力、出色的會議組織能力、事情的推進能力、我的的成熟度等等都是須要咱們在工做中去刻意的培養和鍛鍊的。拿表達能力來講,若是以爲本身表達上有所欠缺,就能夠經過寫做、主動在團隊內作技術分享等等方式來鍛鍊本身。有時候,不逼本身一把你都不知道本身到底有多棒!

寫在最後

做爲一個技術上的菜鳥,寫這樣的文章實在是有點慚愧。且算是給本身定個基調,與你們共勉好了,這樣也能督促本身不斷進步。

哦,對了!還有一點!!!優秀的工程師是不會抱着手機抖音一刷一夜的。???

若是喜歡個人文章,就關注下個人公衆號 BaronTalk知乎專欄 或者 GitHub 吧!

相關文章
相關標籤/搜索