七年漫漫技术路的一点感悟

转眼毕业七年，转眼工作七年！一路走来，有过坎坷，有过煎熬，有过放弃，但更多的是经历这些复杂情绪和心态背后的收获。

作为一个从事编码技术的“老人”，借此机会谈谈自己的一些心得。

一、关于基础

千里之行始于跬步，万丈高楼起于夯土，高手都从新手来，所以，基础一定要夯实。

对于基本知识，一定要掌握牢固，不但要知其然，更要知其所以然，还要知其为何所以然。只有深层次的挖掘这些知识，才能做到对技术的真正掌握。

比如Java，基本数据类型有哪些？对应的自动包装类型是什么？它们是否线程安全？在并发情况下该怎么使用这些类型等等，这是知其然的过程。并发情况下它们怎么保证数据的准确性？即，它们各自实现的原理是什么，这是知其所以然的过程。而，为什么要使用这样的原理，这样原理为什么能解决这样的问题？即，为什么设计成这样？这是知其为何所以然的过程。

在学习基础知识的过程中一定要吃的通透才好！

二、关于框架及原理

这部分内容属于基础知识的拔高，不外乎将基础知识（不只语言基础知识）和设计模式做了组合搭配处理。比如我们常用的Spring框架，Mybatis框架等等，说白了就是将一些共同的技术进行了封装，然后只暴露出一些业务接口来方便开发者使用。

比如Spring的依赖注入，可以简单的理解为反射+工厂模式的组合。

当然，如果更深层次的挖掘框架原理，以及实现，绝对会受益匪浅，不仅能学到框架原理及实现，更能看到优秀的代码及规范，这对日后的编码绝对是大有裨益的。

所以，在研究框架的时候，建议多看一些相关的书籍、博文的同时，也可以看看框架的源代码，包括各自使用的语言，比如Java。

三、关于业务

很多喜欢钻研技术而不喜欢业务，这是大多数技术从业人员的心态，因为业务常常是N个CRUD的组合，写多了也就没有新鲜感了。

技术就不一样了，同样的一个功能，有不同的实现方式，哪种才是更高效、更简单的实现方式？这对程序员来说才更有吸引力，如果能找到新的解决办法，往往更有成就感。

可是，没有业务的技术，就如同没有汽油的汽车，写的再好看也没用。所以业务往往是锤炼技术的最好方式。

身边很多程序员的共态就是，这个业务简单，一个CRUD搞定。说这话的程序员要么很牛，要么很菜，而往往99%的都很菜。

对于一个看似简单的业务，你真正的吃透了么？

比如提供一个对外接口，获取数据库某表的数据。你会怎么做？

很多说，这个简单的要命，写给接口，查数据库不就行了。这是普通的程序员的方案。

中级的程序员会怎么设计实现方案？

1、先查缓存，如Redis、mangoDB等，如果没有再查数据库。
2、对查询数据做限制

高级的程序员会怎么设计方案呢？

1、 获取什么业务的数据？
2、 敏感 or 不敏感？即，是否需要脱敏处理
3、 数据量有多大？后期增长量如何？确定是否需要使用缓存？使用什么类型的缓存？是jvm还是redis等缓存？还是使用elastic search，更或者使用Hbase等。如果必须使用MySql数据库，那么该表是否需要加索引？什么样的索引？
4、 接口请求频率是什么？即，每分钟请求多少次？
5、 异常怎么处理？
6、恶性或者类似恶性（并非故意刷接口，但是由于某些原因，比如前端的定时任务没有正常结束一直请求后台接口）刷接口该怎么办？
7、 是否可以提供分页查询？
8、 接口日志该怎么打？是单独一个日志文件？还是共同使用某个日志文件？

所以，真的是业务简单就学不到知识么？显然并不是。

思维如果不能提升，技术也不会提升。这只是一个简单的例子，而对于更复杂的业务，往往也需要更复杂的处理逻辑。可以说，每一个看似简单的业务背后，都有一个值得深挖的技术方案。

业务很重要，只有真正明确了要做什么？才能真正的达到业务的预期甚至超预期的效果。否则，就是不断的迭代以及leader、同事对你的不认可。

业务，最终是需要细致化的。

四、关于优化

你的代码是否符合规范？至少有注释（写代码不写注释的人都是脑残）。很多时候定位问题，以及项目交接的时候，不写注释梳理起来真的很费心。不是别人不会看代码，你写的代码又不是牛逼到飞起，但是从头梳理起来真的很耗时。

别做缺德事，所以代码加注释。

有了注释，代码是否格式化？即，是否整齐。

在上面的基础上，代码的性能怎么样？是否能进行优化，如果你学过深入Java虚拟机，你就应该知道，方法中的变量属性等等的存储是否合理。

日志打印是否有效合理，即不会打印一些无法定位具体问题，且无效的日志。

方法执行完毕后，是否会被虚拟机回收。

提供的接口或者服务是否会发生超时异常等等

写在最后

平常多思考，多学学身边技术大牛的工作方式，以及他们解决问题的方式，总有一天你的技术也会突飞猛进。