記得分享了一篇文章到一個android群裡，不一會，有人就開始問了，我用某某開源三行程式碼就能搞定，何須那麼複雜，我頓時啞口無言，愣的不知所措，對啊，三行程式碼就能實現了，我這南轅北轍拐了一大圈，圖個啥，我就弱弱的問，它是咋實現的？管它咋實現幹嘛，會用不就得了，這是他給我的答案。
時間的前進，優秀的開源也會隨之不斷的湧現，開發中，藉助於這些開源，使得我們的效率翻倍的增加，省去了大量的開發時間，節省了太多太多的成本，然而，所謂的詬病，我只會用，其中的原理我不知道也越來越突出，越來越明顯；我們站在了世界的前沿，在大環境的烘托下，前沿的人群中，我們大多隻是看熱鬧的那個，前邊走著的，後面過去的，只知其名，卻不知道他是誰，後面追趕的人太多太多，95後甚至00後的小孩也已經加入了這個龐大的人群中，處於這樣一種競爭的環境下，我們既然都知道的他的名字，何不繼續認識他呢？畢竟“朋友”多了，好辦事，我相信你知道我說的“他”代指什麼，我也相信，你會從中得到什麼，畢竟，如果這個你會用，95後00後也會用，一個企業會用你，還是95後00後呢？
對於開源，我們不僅僅是要去運用，而是更深層次的去理解，去滲透，只有這樣，在未來的競爭市場，我們才有競爭力，才有發言權；假如，一個功能，一個人藉助開源三行程式碼實現了，另一個人自己寫用了兩百行，你是面試官，你會做出如何選擇呢？一個靠自己能寫出來的人，他一定會得到面試官的青睞，所以，我們要懂開源而用開源，而不是用開源而不懂它，如果我們是後者，則吃虧的終究是我們。
在開發中盲目的使用開源，有時也只會讓我們的專案變得越來越遭。例如我只需要A功能，正好有個開源有A功能，但是這個開源除了A功能之外，還有B功能，C功能，D功能等等功能，本來這個A功能就只有一個類，但是整個開源卻有幾百個類，引入到我們的專案中，無形中就佔據了我們的應用的記憶體，增加了apk的大小，也許你並不在乎，畢竟你已經實現了功能，實現了上頭交代的任務，你可以就此高興大吉，這是一個還算完美的結局；但是，在很多情況下，引用的開源，會和我們本身的專案有許多的衝突，比如引用了共同的jar包，gradle版本不一致，有時還會導致我們的應用超出65535方法數，這一系列的不利因素，我們是不是得花些許時間來解決呢？
我需要一個蘋果，你給了我一車水果，這是很多開源我們不得不面對的一個問題，如果我們能獲取原始碼，那麼我們就可以對需要的功能做一個抽取，取其精華，棄其糟粕，這樣以來，就會精簡很多無用的程式碼，但很多情況下，我們所用到的這些開源，要麼依賴一個jar包，要麼依賴一個地址，所謂的原始碼，能暴露的少之又少，在某種功能自己能寫出來的情況下，我們何不動手自己去實現呢？一來，加深了你對這個功能的印象，二來，少了第三方的引用則會節省了應用記憶體，apk的大小，三來，減少了一些因引用開源所帶來的種種問題；當然了，所謂的這些得建立在你的專案有充足時間的情況下，要不然，某個功能是能寫，但沒個兩三天搞不出來，而專案上線時間迫在眉睫，那麼這種情況下，請你一定要用第三方，不為什麼，因為你的這份工作重要！
所謂的多此一舉，在很多情況下，不過是搪塞自己的一個藉口罷了，我們在一個幸福的時代裡被眾多的優秀開源寵溺的，逐漸失去了求知的慾望，我們變得懶散，變得不在積極主動，變得只會幾行程式碼，變得只追求結果，不注重過程，以至於慢慢失去了“多此一舉”。為何要多此一舉？其實並不是為了什麼，而是為了我們能夠獲得更多的知識，懂得0到1的質變，也是為了，某個崗位，我們會他們不會，而爭取的一個就業就會。
幾行程式碼就能搞定，不能代表一個人很牛，藉助了開源，只是站在了巨人的肩膀上，讓你省去了去往成功的一大段路，然而這一段路上的風景，還請你仔細去欣賞，到頭來，你會發現，路上的風景會遠遠美於終點的成功。