阅读链接为: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,不过我相信绝大多数的人都希望往知识效率型人才发展，所以这就要求我们知识积累+学以致用。
《不止代码》一共十三篇文章，我在这只讲了两篇，剩下的我就不讲了，这两篇给我的启发和感触已经够多了。
欢迎大家在读《不止代码》，有什么心得可以留言分享。
