閱讀鏈接為:https://102.alibaba.com/downloadFile.do?file=1530517140411/Codelife.pdf
強烈推薦讀一讀
我大致瀏覽過一遍+重新選了幾篇文章細看了一遍，有如下體會。
關於如何成為技術大牛這篇文章，我的體會如下？(這里也要引入文章部分內容)
作者提出了這么幾個觀點？
觀點一，寫業務代碼也可以很牛逼，如果連業務代碼都寫不好的人，肯定無法成為技術大牛，當然業務代碼寫好的人，也不能成為技術大牛
觀點二，工作中學習，實踐出真知，學以致用，這是效果比較好的。對於碎片化時間，只能自覺靠自己利用上下班地鐵或者其他空閑時間
就觀點一而言，確實，記得剛剛畢業沒過多久，進入一家以辦公為主的互聯網企業，那個時候公司用的前端框架是ext.js,我想起那個時候我居然會心中疑惑，為什么不用jsp呢？因為在校的時候用的比較多的就是bootstrap+jsp。我的第一個博客系統就是用它開發的。
正式開發后，才明白，jsp本質就是serlvet，而serlvet同jsp不同的是主要是邏輯控制，接收來自前台的請求，並進行響應，這個響應就將數據輸出到前台並以html形式展示。
如下圖所示:
這里有點扯遠了，但是並不影響我想表達的一個觀點是，業務代碼也可以讓人成長，比如設計模式，設計模式在校的時候，只聽老師提過，沒仔細講過，即便講了也不一定明白，因為設計模式是前輩們經過無數次代碼實戰中得到的真知灼見，如果沒有一定的代碼量積累很難理會的到。而通過進入公司，在公司不斷的寫業務代碼，大家會發現很多，比如之前的某某寫的代碼出現冗余(有很多幾處相同代碼，其實可以封裝成一個函數調用),再比如，某個接口里面既要做這件事情又要做那件事情，違反了設計模式中單一原則，你可以將其進行功能分離，將其接口按功能分為兩個接口，遵守單一原則。業務代碼寫多了，你會發現你會不知不覺中接觸到很多設計模式的原則，有些你一直在用，在遵守，比如“高內聚，低耦合”，就涉及到迪米特法則(又稱最少知道原則)。還比如單例模式、模板模式等等，都在用。不知不覺中從代碼中領會到設計模式並實踐運用，這也說明觀點二的重要性。
關於學習時間，個人認為還是得從生活中去擠。比如上下班地鐵，還有就是午休，一般午休通常是一個小時，可以利用二十分鍾看看書之類的，或者是晚上的時候，就我個人而言，一般11點睡覺，通常就利用9點或者10點，睡前看半個小時的書。時間只會越擠越多而非越擠越少，總而言之，關鍵自覺。
作者給了這么幾點建議?（我個人覺得很受用）
(1).做的更多;
(2).做的更好;
(3).不斷練習(系統學習，嘗試，教學);
關於這三點，我就不引用作者的具體例子。
就(1)而言，做的更多，不僅有助於提高編碼能力，特別是對於剛入職的或者是剛入職一年的，從學生時代轉入職場時代，會聽過不曾聽到的新名詞和一些技術或者是業務等等。做的更多，可以提高熟練度，至少可以再應對不同的業務或者需求變更，也不會覺得那么陌生了。另外做的更多，不僅可以獲得上司的賞識，而且有助於提高自己。
就(2)，做的更多當然重要，但是做的更好更重要。比如，如果你沒有聽清需求及其有條理的分析好需求並將哪些不理解的與業務相關人員及時溝通，而是直接開敲。這樣你哪怕做的再多，也是無用功。記得在很久之前打過暑假工的時候，記得一個班長對我說的，100-1=0的原則，意思是你做好了100件事情，最后有一件沒做好，那么相當於你前面100件事情都白做了。在軟件這一行同樣如此，做的更多固然重要，做好更重要。我記憶比較深刻的是我來到現在這家公司做的第一個項目，之前上家公司的話沒有項目可做，基本處於維護階段，按照相似套路維護和改bug，加功能等等。第一個項目是酒店管理系統，為了適應當時的快速開發，我們采用架構是單體應用+SSM框架+表現層jsp技術等等。這第一個項目我們用了一個多月的時間，基本就開發完了。不過問題非常嚴重，小公司是沒有前端的，和我上家公司一樣，后台就前端，前端就是后台。不過這個項目做的確實糟糕，在沒有制定好良好的前端和后端規范就直接開發，開發完后，就陷入一個死循環，就是Bug。改完舊的Bug，出現新的Bug。Bug是越改越多。后來我想了想，為什么會出現這種情況呢？
第一，抱着不負責的完成任務態度，bug解決就好，稍微測試一下，沒問題了，就不管了，這是個人原因；
第二，代碼亂七八糟，一個jsp，基本就全部引用行內樣式包括js和css，而且還用到很多jstl標簽，通常一不留神，忽略了某個地方，要么就是版本回退，要么就是叫同事發原文件過來，這不僅僅是個人的原因，還有就是團隊的原因;
后來，我們在開發門鎖系統的時候，汲取了第一次慘痛的教訓，按照軟件工程的套路:
第一,可行性分析，我們參考了該行業比較出名的企業，借鑒其成功經驗和模型，這讓我想起了《勸學》中的一句話，“君子性非異也，善假於物也”；
第二，在第一的前提下，我們進行需求分析，需求整理好了后，我們用Xmind工具，進行了概要設計；
第三，在概要設計的的前提下，我們進行架構設計，如下圖所示
而且在這個基礎上再補充和添加了一些，如圖所示:
關於Java規范，我們主要以阿里巴巴的Java開發手冊為主，下載鏈接:https://102.alibaba.com/downloadFile.do?file=1528269849853/Java_manual.pdf
第四，我們參考模型，進行先前端再后端的開發，前端模型開發完畢后，通過與相關業務人員溝通，達成共識后，進行后台開發；
第五，后台開發完畢后，並與安卓方面及時對接，這次前后端分離，代碼方面也有規范可循，自然比第一個要好的多，無論是從性能上還是從維護上來看；
第六，編寫用戶操作文檔；
第七，正常上線；
在此，只列出上述七條。我希望這七條能給剛剛入職的和入職有一定年限的人啟發和歡迎他們有什么好的建議，及時留言提出，畢竟“兼聽則明，偏信則暗”嘛！
關於(3)，(3)實際上又可分為如下三部分：
a.系統學習;
b.嘗試;
c.教學（教給他人，並能跟他人通俗易懂的講明白，他人(指團隊成員或是業界相關朋友等等）;
關於a,對於在校沒有好好學習的人或者是從培訓班出來的人來說，是十分有必要的，在校沒好好學習的人，現在很多大學生，上了大學就好像逃離世界之外的桃花島，想怎么樣就怎么樣，最后，畢業等於失業的定律在他們的身上應驗了。為什么要系統學習？不管是科班出身還是培訓班而言，科班出身，本身已經經過系統學習了，再系統學習對於他們而言相當於溫故而知新及其舉一反三，融會貫通等等，而對於培訓班的人來說，他們只是得到了初級軟件開發的技能，換言之就是一個入門的技能而已，計算機遠遠不僅僅只是編程語言那點東西，編程只是一種技術工具。記得關於這一點，很多書和不少CSDN或者思否及其博客園上的文章都着重的強調過這一點。系統學習一些計算機和操作系統或者是一些編程語言等等，對於現在而言，不一定能在工作中用到，但是從長遠角度，一定會使你收益的。畢竟技多不壓身嘛！
關於b,用一句話來概括，“光說不練，假把式”，看了這么多書，而不嘗試去試驗，等於白看。當然，話不能說的太絕對了，但是對於軟件這門以實踐為主的科學，就是這么個理。想象着，我們當初學C,學JAVA,學Python,Hello World這個例子大家都不會感到陌生。最簡單最有效的學習，就是實踐。
關於c,記得白居易寫詩，他寫詩要讓老婆婆看懂，才算是完美之作，如果老婆婆都看不懂，他就會撕掉重寫。這里我想表達的意思是，當你能把一項技術，講給別人時，並讓別人聽明白了聽懂了，而且當他提出某些問題時，你能夠條條有理的跟他講出來，說明你真正懂了。
最后，作者也着重強調了這個觀點，“技術熱情+興趣”，要想成為大牛，沒有熱情和興趣是不行的。熱情+興趣會使你不斷前行，不斷進步，不斷成長。這對於任一行業都是一樣的道理。
關於第二篇文章，畢業三年為何技術差別那么大？
畢業三年，每個人在技術能力跑道上，有了或大或小的差距。有些
人永遠在重復的勞動，有些人卻能從中總結和解決問題。
比如，在開發第二個項目時，我為什么改變以往的方式，不使用MyBatis而使用MyBatis Plus?簡單的說，MyBatis Plus可以避免我做不少重復勞動，當然了MyBatis也是可以的，不過需要逆向工程或者是結合FreeMarker進行代碼生成，不過我不喜歡這種方式，逆向工程我之前也強調過，為什么不用它，因為它太繁雜了，當然了，我相信前輩們或者其他朋友們，不乏有人對其改造，使其更符合自身的需求，比如jeesite就對MyBatis進行改造了，使其消去繁雜片段，對於提高開發效率有很大的幫助。
關於MyBatis Plus的學習教程，大家除了參考官網http://mp.baomidou.com/，也可以參考我的博客:MP實戰系列(13)文章
作者寫在前言的話，值得深思:
高考的時候大家都是一樣的教科書，同一個教室，同樣的老師輔導，時間精力基
本差不多，可是最后別人考的是清華、北大或者一本，而有些童鞋的實力只能考個三
本，這是為什么？
作者提出了問題關鍵點和兩種人才
(1)知識積累;
(2)知識+實踐結合(聯系在一起，舉一反三);
知識效率人才和工程效率人才：
有些人純看理論就能掌握好一門技能，還能舉一反三，這是知識效率，這種人非
常少。
大多數普通人都是看點知識，然后結合實踐來強化理論，要經過反反復復才能比
較好地掌握一個知識，這就是工程效率，講究技巧、工具來達到目的。
使勁挖掘自己在知識效率型方面的能力吧，兩者之間當然沒有明顯的界限，知識
積累多了，邏輯訓練好了，在別人看來你的智商就高了。
不同的人才看待問題，分析問題，解決問題的角度和方式都不同：
解決問題方式:
a.善用搜索引擎，前提是把握問題關鍵點;
b.經驗豐富積累的解決問題方式(遇到的坑);
知識效率的人才總能把握好a,當然了，自身的知識積累，有些時候，他並不需要a。
對於工程效率的人才而言，b是較為常見的，我個人就屬於b,不過我相信絕大多數的人都希望往知識效率型人才發展，所以這就要求我們知識積累+學以致用。
《不止代碼》一共十三篇文章，我在這只講了兩篇，剩下的我就不講了，這兩篇給我的啟發和感觸已經夠多了。
歡迎大家在讀《不止代碼》，有什么心得可以留言分享。