幾行代碼就能實現爲什麼要畫蛇添足

記得分享了一篇文章到一個android羣裏，不一會，有人就開始問了，我用某某開源三行代碼就能搞定，何必那麼複雜，我頓時啞口無言，愣的不知所措，對啊，三行代碼就能實現了，我這南轅北轍拐了一大圈，圖個啥，我就弱弱的問，它是咋實現的？管它咋實現幹嗎，會用不就得了，這是他給個人答案。

時間的前進，優秀的開源也會隨之不斷的涌現，開發中，藉助於這些開源，使得咱們的效率翻倍的增長，省去了大量的開發時間，節省了太多太多的成本，然而，所謂的詬病，我只會用，其中的原理我不知道也愈來愈突出，愈來愈明顯；咱們站在了世界的前沿，在大環境的烘托下，前沿的人羣中，咱們大多隻是看熱鬧的那個，前邊走着的，後面過去的，只知其名，殊不知道他是誰，後面追趕的人太多太多，95後甚至00後的小孩也已經加入了這個龐大的人羣中，處於這樣一種競爭的環境下，咱們既然都知道的他的名字，何不繼續認識他呢？畢竟「朋友」多了，好辦事，我相信你知道我說的「他」代指什麼，我也相信，你會從中獲得什麼，畢竟，若是這個你會用，95後00後也會用，一個企業會用你，仍是95後00後呢？

對於開源，咱們不只僅是要去運用，而是更深層次的去理解，去滲透，只有這樣，在將來的競爭市場，咱們纔有競爭力，纔有發言權；假如，一個功能，一我的藉助開源三行代碼實現了，另外一我的本身寫用了兩百行，你是面試官，你會作出如何選擇呢？一個靠本身能寫出來的人，他必定會獲得面試官的青睞，因此，咱們要懂開源而用開源，而不是用開源而不懂它，若是咱們是後者，則吃虧的終究是咱們。

在開發中盲目的使用開源，有時也只會讓咱們的項目變得愈來愈遭。例如我只須要A功能，正好有個開源有A功能，可是這個開源除了A功能以外，還有B功能，C功能，D功能等等功能，原本這個A功能就只有一個類，可是整個開源卻有幾百個類，引入到咱們的項目中，無形中就佔據了咱們的應用的內存，增長了apk的大小，也許你並不在意，畢竟你已經實現了功能，實現了上頭交代的任務，你能夠就此高興大吉，這是一個還算完美的結局；可是，在不少狀況下，引用的開源，會和咱們自己的項目有許多的衝突，好比引用了共同的jar包，gradle版本不一致，有時還會致使咱們的應用超出65535方法數，這一系列的不利因素，咱們是否是得花些許時間來解決呢？

我須要一個蘋果，你給了我一車水果，這是不少開源咱們不得不面對的一個問題，若是咱們能獲取源碼，那麼咱們就能夠對須要的功能作一個抽取，取其精華，棄其糟粕，這樣以來，就會精簡不少無用的代碼，但不少狀況下，咱們所用到的這些開源，要麼依賴一個jar包，要麼依賴一個地址，所謂的源碼，能暴露的少之又少，在某種功能本身能寫出來的狀況下，咱們何不動手本身去實現呢？一來，加深了你對這個功能的印象，二來，少了第三方的引用則會節省了應用內存，apk的大小，三來，減小了一些因引用開源所帶來的種種問題；固然了，所謂的這些得創建在你的項目有充足時間的狀況下，要否則，某個功能是能寫，但沒個兩三天搞不出來，而項目上線時間迫在眉睫，那麼這種狀況下，請你必定要用第三方，不爲何，由於你的這份工做重要！

所謂的畫蛇添足，在不少狀況下，不過是搪塞本身的一個藉口罷了，咱們在一個幸福的時代裏被衆多的優秀開源寵溺的，逐漸失去了求知的慾望，咱們變得懶散，變得不在積極主動，變得只會幾行代碼，變得只追求結果，不注重過程，以致於慢慢失去了「畫蛇添足」。爲什麼要畫蛇添足？其實並非爲了什麼，而是爲了咱們可以得到更多的知識，懂得0到1的質變，也是爲了，某個崗位，咱們會他們不會，而爭取的一個就業就會。

幾行代碼就能搞定，不能表明一我的很牛，藉助了開源，只是站在了巨人的肩膀上，讓你省去了去往成功的一大段路，然而這一段路上的風景，還請你仔細去欣賞，到頭來，你會發現，路上的風景會遠遠美於終點的成功。