初學者摸索之算法學習

此文轉自我我的微信公衆號，時間雖然過去已經四個多月了，可是我我的認爲仍是可以給你們帶來啓發意義，因此借這個時間分享給你們，微信公衆號分享比較有限，並且時效性也比較差，而博客時效性比較好，並且還能集思廣益，歡迎朋友在評論區留言，俗話說，衆人拾柴火焰高。

原文以下:

春節的假期在家待了10天。明天就要回北京了。

微信公衆號文章也停更了兩週。感謝天天新關注的朋友們，同時也感謝一直關注和支持的朋友們。2019年爭取輸出更多的技術乾貨或者其它非技術乾貨(不過我對於個人微信公衆號定義主要仍是以技術導向爲主，非技術可能會少一些)。

 

算法對我來講，用一句詩歌來講，「蜀道難，難於上青天」。

本來以前想着用一年時間來攻克，如今看來可能性不大。

身處在一線城市於我而言，不只僅須要經過閒暇時間學習算法，同時我也還要學習最新的技術，同時也還要時常補補計算機相關的基礎(當年不努力，太過對本身放鬆所形成的後果)。

 

春節假期中，不只僅放鬆玩了玩，好比跑得快、王者、看電影及其和幾個好哥們聚會，同時也刷了下知乎，在知乎中東看看西看看，看了好幾篇於我目前而言比較感興趣的文章，如何學好算法。

 

於我目前而言算法並無給我帶來實際的利益，至少沒有其它軟件工程技術那樣給我帶來直觀的利益(好比使用shiro我能夠輕鬆的完成接口權限控制、使用Nginx作負載均衡、使用Redis緩存數據等這樣的例子數不勝數）。

 

由此能夠推斷出算法對我而言實際利益並不大，但我爲何要堅持要學呢？

 

以拉勾、boss直聘等招聘網站來講，一些上市大公司和大部分中小公司所要求的主要是豐富的項目經驗和對開發經常使用技術掌握的很是熟練、某些特定領域的經驗，好比銀行、醫療、辦公等，對於算法方面的能力並不十分看重(固然了，若是是在校參加過acm比賽獲獎、刷過算法題的或者是github上有過開源項目的也是一項優點)。

好比下圖所示:

圖一:

圖二:

 

 圖三:

若是要說給出的理由的話，我以爲可以說服我本身的最大的理由是我不想成爲一名碼農(我對碼農的定義的是將腦力勞動變成的體力勞動，通過這一年多的開發，我發如今工做中，有一半是體力，有一半是腦力，其實那一半體力是能夠靠腦力解決的)。

 

另外研究算法的也是爲了更好的讀懂Java源代碼和Spring源碼相關的,做爲一名Java後端開發，不深刻了解源代碼的實現思路是很難混的好的(主要指靠技術吃飯)。我以爲一個算法能力強的人讀Java源代碼和Spring源碼及其其它相關的軟件源碼要比算法能力弱的人效率高的多。儘管二者之間不必定是正比。

 

關於算法學習(我做爲初學者就很少說太多了，參考前輩們的經驗)

 

固然了，雖然說不說太多，可是仍是要說的。

 

我對我目前的要求，只有一條。

一道算法題目，將思路想清楚想明白了將其攻克，再繼續下一道題目和儘量不借鑑其它已知的解決方案(參考很多知友的回答加上以本身1月份的作題經驗來講，沒有通過深度思考嘗試屢次解題直接去參考現成答案，收穫過小，效率不高，感受太浪費時間了)。

 

知友們給出的觀點(如何學好算法)，以下圖所示:

圖一:

圖二:

圖三:

看了這篇知友的回答，我點擊該連接:

https://visualgo.net/en

這個連接的效果圖，以下所示:

點擊其中的一個，以排序爲例(它會以動畫的形式展示，有助於更形象的感覺，能夠做爲算法學習的輔助工具):

圖四(爲何要學算法)：

圖五(有沒有學不會算法的人):

 

這讓我想起曾經看過的一篇文章，說的是一位十幾歲就出來打工，快三十歲或者三十歲以上年齡咬緊牙關學軟件開發，最終仍是學成對的。由此看，人必需要有決心，想當初新中國創建也才十來年，自力更生造出了原子彈、氫彈等核武器，使咱們再也不受制於他國的核威脅。

 

關於刷算法題網站有不少，好比目前我經常使用的就是力扣，

力扣題庫(也就是如今比較出名的leetcode，記得前段時間咱們經理招人時，特別強調這麼幾點，有leetcode刷題經驗的、有我的github的、有我的博客的優先):

https://leetcode-cn.com/problemset/all/

 

還有一個國內挺出名的牛客網:

https://www.nowcoder.com/

 

圖六:

 

 

想到我當初看書，一週一本書，然而並無什麼用處。

有句話叫作，欲速則不達。

慢就是快，快就是慢。

舉例說明:

以我爲例，經理要求某個功能時，我在完成該功能以前，事先畫個草圖，仔細分析，功能拆分(一般要求的功能是一個大的功能，大的功能通常包含好幾個小功能)，再度確認(將列舉畫好的草圖跟經理確認一遍，這樣的好處是，肯定需求無誤，減小盲目開幹浪費時間)。事實上證實是很是有必要的，前期我沒有這樣作，盲目埋頭幹致使的需求沒有理解透，作出的功能也不對，以致於重作(重作是一件很是痛苦的事情)，不少程序員都有過這樣的經歷，新增功能是一件很容易的事情，可是要重構原有的功能代碼是一件很不容易的事情(特別是時間過了很長，若是編碼規範不是特別好的話，會致使許多問題，好比代碼可讀性、代碼耦合性等，我以爲這兩個是維護代碼最痛苦的事情)。

由此推論出以下:

給定需求->分析思考需求(肯定需求的合理性，功能多少，時間週期，能不能作)->跟領導肯定需求->需求肯定，擼起鍵盤開敲->完成後的效果，找產品經理或者領導確認。

這一個流程下來時間雖然花很多，可是想一想若是沒有聽清需求正確分析需求直接開敲那樣的後果，你會發現這樣作實際上是很節約時間的，因此正好驗證，慢就是快。

 

 

今天就說到這吧，回到北京後，一切都將回到正軌。

繼續個人工程師成長之路。

 

另祝2019年，你們都能實現本身的目標，也許實現目標的過程當中是一件比較痛苦的事情，可是想一想度過這段痛苦的過程後，你將會得到無比強大的力量。

 

個人微信公衆號，如圖: