5分鐘學會6個阿里內部編程的方法

新入職場，公司安排一個全棧大牛帶我。

從大三起,自學了大概半年,感受還不錯,比傳統的老師授課模式效果好多了。在這個過程當中我領悟了一個道理：

學習說到底仍是本身的事,有人教天然好,可是主要仍是依賴本身下功夫。

事實上,今天我仍是這麼認爲的,因此當初對於公司的安排我不覺得意。沒有想到,在三個月後前輩給了我兩個意外:

1. 他刷新了我對學習編程的認識。
2. 他在我入職三個月後離職了。

工做已經半年了,我在實踐中不斷反思他說過的話,也逐漸能明白他當時的意思,如今作一下總結。

注重實踐,理解放後面

工做中會遇到各類難題,而後我去找前輩請教時, 經常會被前輩說問了一個錯誤的問題,並唸叨着:「注重實踐,理解放後面。」學習就是對知識的理解,爲何要放後面呢?咱們來剖析一下這個問題:

1. 不必討論原理,每一個人的理解不一樣
   所謂的理解,就是對代碼實現原理的理解,當前代碼實現邏輯的背後每每還有源碼,而源碼的背後還有更深的源碼,因此原理自己是複雜且有相對性的。由於這種特性,致使了每一個人對原理的理解是不一樣的。對於這種複雜且沒有標準答案的問題,討論起來對現實的意義很小,因此沒有必要討論。
2. 若理解是正確的話,能夠找到方法來證實,不須要跟人討論
   代碼是能夠不會騙人的,因此相比於跟人討論,無論從效率角度仍是不被誤導的角度來看,用代碼驗證理解都是最佳選擇。
3. 沒有足夠的前置知識,沒法談理解
   當雙方沒有具有在一個層次上的相關的知識來談原理, 每每不構成交流,只是雞同鴨講,浪費時間。
4. 關注解決問題的方法才能離真相更近
   在不斷遇到問題,尋找方法解決問題中,天然會對代碼產生理解,而這個理解是不斷變化的,也會離真相愈來愈近。
   重要的是不斷找方法解決問題,在這個過程當中加深理解。
5. 當心複述的陷阱
   我一直有一個複述的習慣, 在別人對我講話後, 我會複述一遍以肯定是否理解正確。一般狀況下這個習慣有利於提升溝通效率,在某些時候這個習慣也會有害。
   當咱們在複述的時候,會強化本身的記憶,好比大聲朗讀有助於記憶,能被唱出歌詞也跟容易被記住。一樣複述理解時會強化它們在大腦中的印象。
   以前已經講了理解是在實踐中不斷變化的,因此當前的理解每每是片面的,而這些片面的理解有可能阻礙咱們以後正確得理解代碼。
   因此咱們應該重視重現方法而不是複述原理,由於複述原理可能會強化咱們錯誤的理解。

經驗路線和深度路線

程序員在經歷過職場的3年野蠻成長後,大致會分化爲兩種路線：廣度路線和深度路線。

所謂廣度路線就是在有必定基礎後,將更多的精力花在接觸各類不一樣方面的技術或工具上。

所謂深度路線就是將更多的精力投入到進一步加深工做領域內的知識和能力中。

在實踐工做中,咱們依賴的東西不少,單純追求深度路線,並不能很好的適應不斷變化的 IT 行業。

因爲技術間有不少東西是相通的, 因此在學習新技術的時候,學習效率和掌握水平每每由以前已掌握的技術深度決定。而單純追求廣度路線,因爲深度不夠,因此新技能的能力不足以有效解決工做中的各類問題。

整體而已, 深度和廣度須要平衡發展。

另外一方面, 作了幾年的程序員,容易自滿,再加上深度路線須要持續的鑽研和實踐,且很容易自覺得懂了而停滯不前,因此有些程序員再不往深度方向走了。因而成天嘴裏都跑着新名詞,談着架構,可是不能解決工做中碰到的難題。

避免趕代碼

如今都在追求小步快跑,快速迭代,在加上行業節奏快,老闆催得緊,因此加班對程序員來講是屢見不鮮。

儘管咱們都知道只寫本身熟悉的代碼,不學習,能力提不高,工資也提不高,可是面對 deadline 的壓力,如何能靜心鑽研下代碼的工做原理?

想解決工做和學習的平衡問題,首先咱們的覺察到本身是否正在趕代碼以完成工做。

我有天天寫日記的習慣,因此個人自我覺察方法就是天天寫日記時,問問本身,是否在趕代碼。

趕代碼的標準以下:

1. 直接 Copy&Paste 網上搜索到的代碼,無論其中的邏輯。
   咱們常常會引用一些代碼來解決問題,引用本無可厚非,可是也須要知道插入進來的這段代碼究竟是在幹嗎,和以前本身的寫法有什麼不一樣。
2. 碰到問題, 試各類寫法,一旦試成功後就完事了, 不考慮到底幾種寫法的區別。
   我這方面比較嚴重的是 css 代碼, 只是胡亂拼湊各類參數, 而沒有理解各類參數的實際做用。
3. 只是單純參考文檔來寫,不思考這個框架或工具的內部邏輯。
   好比在學習使用一個框架的時候,會在各類demo 的代碼, 這時須要理解這些代碼的邏輯,而不是改改能用就好了。固然不是要深刻到源碼去理解,對於剛開始使用的框架,只有大致知道每一塊代碼是幹嗎用的就好了。

在察覺到本身的趕代碼行爲後,還須要深刻的思考下本身這麼作的緣由, 這裏列舉下我察覺後的結果:

1. 迴避難點
   當代碼中遇到難點時,應該試圖弄清楚,而不是單純找個 workgroud 的方法草草了事。
2. 得到團隊的認同
   團隊的認同感其實就是信任,首先培養信任是一個長期的行爲, 其次信任來自於任務的妥善完成, 只重視量而不重視質的趕代碼行爲顯然不是一個好的信任培養策略。
3. 享受作得快的快感
   快速寫出一堆能夠用的代碼確實很產生快感,可是這種快感只在短時間有效。咱們應該提升快感品位,作能產生長期快感的事情。

先框架仍是先語言

咱們常常會碰到多看語言書仍是多學習框架的選擇題。以前我一直以爲顯然語言更重要,框架總在不停的出新,而語言的變化性就小得多。
如今發現,對於程序員新手來講,先學框架更重要。由於掌握框架後容易找到工做平臺,並快速成長到能爲團隊產出。一個工做平臺對新手程序員的成長相當重要, 至於語言和代碼能力,能夠在以後來補。
至於技術的選擇,對新手來講最好的方式就是跟着項目走,這樣更容易實踐和成長。技術和技術之間有不少是相通的,當學習到必定深度時,再轉而學習其餘技術也會很快。

關於工具的選擇

咱們是生活在「輪子」上的一羣人, 成天找輪子,比較輪子,甚至造輪子。程序員界激烈的「編輯器聖戰」,「什麼是最好語言」能夠看出咱們對輪子的熱愛。
可是咱們在折騰輪子上也浪費很多時間。總想找到一個"完美"的輪子,優雅地解決咱們全部的問題,又足夠簡潔。以後我明白了,關於輪子的選擇,不用想那麼多,也不用討論那麼多,更不不必去爭論什麼。
咱們只須要多嘗試,而後選個大致適合本身的就好了。
別磨刀耽誤了砍柴。

博客和書

讀書和看博客是通常擅長閱讀學習的人的經常使用渠道。那麼這兩種方式有什麼不一樣呢?

因爲技術發展很快,因此書本的出版每每滯後,因此書上的有些知識實際上是過期了的。可是做者爲了寫一本書會積累更多,沉澱更久,因此寫出來的東西也會更有深度和總結性。

所以咱們若想技術進階, 掌握核心思想,就應該多讀書。

與書本相反,博客更新很快,篇幅很短,因此一些關於新技術的討論每每只能在博客裏找到。因爲篇幅有限,博客的做者只會針對一個點或幾個點來闡述, 相比於書會顯得淺顯和片面。

所以咱們若想了解新技術或者快速入門,能夠多看看博客。

今天的分享就先到這裏，若是覺的對您有幫助請關注小編，持續更新程序員相關知識與一手學習資料；下次見~

推薦閱讀

字節跳動總結的設計模式 PDF 火了，完整版開放分享

刷Github時發現了一本阿里大神的算法筆記！標星70.5K

若是能聽懂這個網約車實戰，哪怕接私活你均可以月入40K

爲何阿里巴巴的程序員成長速度這麼快，看完他們的內部資料我懂了

程序員達到50W年薪所須要具有的知識體系。

—小時解讀併發編程三大特性

關於【暴力遞歸算法】你所不知道的思路

看完三件事❤️

若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：

點贊，轉發，有大家的 『點贊和評論』，纔是我創造的動力。

關注公衆號 『 Java鬥帝 』，不按期分享原創知識。

同時能夠期待後續文章ing🚀