技术人员成长的坑

在软件和互联网行业做了20多年，结合自己的成长过程和看到的其他人的成长过程，谈谈我的感受，希望能够对在技术上发展不同阶段的人有所启发。如果有疑问，大家也可以消息我，或者加我微信讨论。

对于入行的新人

1. 切记不要太追求安逸，把他人的果实当作自己的能力

大家都是从新人进入到这个行业的，软件这个行业可以说很浅，很容易，也可以说很难，很深。很浅，很容易，因为现在的框架和工具太多了，让编程变得越来越容易，比如做GUI，之前有VB这种拖拉编程模式，现在的IOS和安卓也是控件拖拉方式。如果做WEB前端， 之前的jquery和现在的VUE都有很多组件框架，都非常强大和漂亮，而且网上还有很多例子代码，让工作变成了拷贝粘贴流程。如果做后台，现在很多功能强大的中间件，都不需要自己去写SQL，就可以完成很多事情。现在的一线大厂也是分工细化，基础架构的东西也是由核心团队负责的，多数人都是在写业务代码，当然写业务代码不代表不会有技术含量，看你怎么去发现，有兴趣请参看”写好业务代码的难点在哪里”。

长期做这种简单重复式的开发导致和基础的东西脱离太久，很多人连SQL都忘记了，更谈不上SQL性能的优化，也就导致很多人错误的认为基础知识无用。框架这些东西是变化无穷的，但基础的东西是基本上不变的。要走的远，必须去理解这些底层的不变的东西，才能真正的做到以不变应万变，走出死循环。如果把大量的精力去学习这种层出不穷的框架上面，最后只能是事倍功半的结果。当然现在很多公司加班很厉害，加班去创造BUG，然后又不断的修复BUG，你修复了一个他人的BUG，然后又给其他人留下了新的BUG。因为基础能力的缺失，导致很多人常常使用了框架，看似避免重造了轮子，是一种高效的体现，但实际上经常是用错了轮子，把卡车轮子用在了轿车上面。其实，掌握基础知识的目标不是让你去重造轮子，而是为了知道怎么正确的使用轮子，甚至去完善提升轮子，其实很多优秀的框架都预留了扩展的空间，怎么做客户化改造是非常重要的。

2. 努力去捡回之前的理论知识，并且思考怎么应用到实际当中

说到怎么吃透这些框架，确实不是一件容易的事情，需要去啃理论知识，需要去实践验证，需要勤思考。比如做一个好的后台，数据库基础能力，操作系统知识，多线程知识，网络协议知识都是必须的，这些东西都是和语言框架无关的，而这些基础的东西是很少变化的，当然有不断进步的过程，例如操作系统异步IO的出现，让服务器的并发能力大大提升。很多知名的并发框架，如java.util.concurrent都是基于操作系统层面的支持的，如果理解了操作系统基础知识，如IO，内存管理，多线程，知名的框架Netty也会变得容易读懂很多，很多框架在内在是相通的，当然在某些场景处理上面会有差异，从原理和场景上理解了这些框架，自然就会做到上面讲的“用对轮子，甚至改造轮子”。

如果自己开始能力不行，需要机会锻炼，但因为能力不行，可能就不会有机会，这样也就进入了一个死循环。其实学习好这些理论知识，第一步还是比较枯燥的，必须有啃硬山头的决心，大学毕业第一年，我就把TCP/IP的两本原版英文书啃了下来，奠定了我对TCP/IP的深入理解。对理论有了一定了解以后，就需要去实践，实践就是可以去看开源框架，看看人家是怎么应用这些基础知识的，这是一种从下往上的思路，可能会比较困难，因为很多时候，你不知道运用的场景，所以就很难理解这些理论背后的原因。所以，还有一种办法就是从上而下来学习，先认识到场景，认识到需求，然后再往下钻研，这也就是工作以后再去学习理论知识的优势。

要真正的能够从上钻研到下面的理论知识，并且能够吃透和灵活应用，必须有一个突破自我，去努力把握机会，努力创造机会的心。公司后台缺人手，希望前端能够做后台，这本来是个好机会，技多不压身呀，而且能够做到前后台融会贯通是件很难的事情，后续的发展是非常光明的。跟一个感觉很钻研的前端讲，给他讲了道理，当时勉强同意了，干了几天，说太多东西不会了，希望放弃。另外一个前端自告奋勇，说自己想做后台，当然他做前端IOS很多年了，是应该发展一下后台能力了。当然，刚刚进入后台，很多东西都要学习，典型一个错误就是不知道日志的重要性。前端程序员调试程序喜欢使用GUI的debug工具，但后台生产环境怎么debug呀，而且这个哥们一开始都不知道怎么记录日志，这些都提醒他补上了。比前面放弃的程序员，他进了一步，自然也学习到了新的知识，掌握了新的技能，但我发现他解决问题的方式多是去百度查找答案，总是在框架的外围绕来绕去。有一次，后台使用的Mybatis分页出了问题，一个报表分页是正确的，但另外一个报表的分页是错误的，这个问题，他绕来绕去花了好几天时间没有解决。晨会上，我问他，抛开这个框架的分页功能，如果直接在数据库JDBC层面实现分页，你知道怎么做吗？他胡乱说了一通，显然是对分页的基础原理都不知道。如果有一定SQL基础知识，其实分页是一个很简单算法，就是先使用COUNT计算总行数，然后除以定义的分页大小，得到页数，最后使用游标功能一页一页返回数据，当然有分组GROUP BY的情况，分页稍微复杂一些，但也不是很难。Mybatis分页的BUG就是分组查询分页问题，Mybatis处理的不是很好。因为他对数据库基础知识的缺失，导致讲给他听解决方案，他也没有听懂，最后他使用了多次查询的办法解决了这个问题，当然不是一个好的解决办法。后来，在一个项目当中使用了MQ队列，其中队列监听遇到了多线程问题。开始后台设计没有用到线程block方式去监听消息队列，导致消息的丢失问题，我给他们提出的解决方案是使用线程block监听，这里就遇到多线程通信问题，把3个后台叫来开会，给他们讲解了实现的原理，让他们都能理解和学习一下。结果，其中两个程序员的第一反应就是，这个部分任务是A负责的，两个人像是大解放似的，其中就包括前端转后台的那个程序员，我当时就感到非常生气，怎么连对自己的要求都没有呢。困难来了就是锻炼自己的机会呀，真是不能理解他们。解决实际问题是理解理论知识的最佳办法，这是提升他们理论理解的机会呀。很多人自己能力常年没有提升，就是自己一次一次的放弃了机会。常健身的人都会知道，只有把你的肌肉练得非常非常酸痛，才会有肌肉的壮大，因为肌肉纤维不断长大的过程，就是不断撕裂，然后不断愈合的过程。一个技术人员能力的成长就是你不断去解决实际问题，不断突破压力的过程。后来，我把分页问题作为一个面试题，面试通过率不到十分之一，而且很多是做后台3年以上的人，甚至接近10年的人。看来，多数的程序员都是不知不觉的做着温水里面的青蛙。

工作当中，不要只满足了解自己工作部分，尽量去和同事沟通，去了解其他部分遇到的问题和困难，因为只要知道了问题，你才会有方向，有目标，学习技术是为了解决问题的，知道问题是学习技术的最大推动力。面试当中，遇到太多的人就知道自己负责的那小部分，对其它部分一无所知。记得之前面试一个携程做测试的人员，在携程做很小部分的测试做了2年，简直都变成了机械劳动了，其实华为解聘一些35岁以上的人，也是有一定道理的，具体的论述，请您参看”华为员工中年危机”。最近，甲骨文中国也是大裁员，太多人直到失业，才发现自己脱离先进技术太远了，保持一颗突破自我和危机感的心，是每个做技术的人的必须的素质，只有这样才不会被时代抛弃，连个再见都没有。

3. 加强自己的沟通表达能力

很多做技术的人不注重这方面的能力，但这种”纸上谈兵”的能力其实是非常非常重要的，因为通过沟通发现问题是最高效的，学会画图表达也会帮自己理清思路。小时候看到高手下象棋是不需要看棋盘的，慢慢锻炼自己的整体思维能力，是离不开表达沟通能力的。而且，很多程序员写不好软件注释，要不不写，要不就是乱写，没有条例重点。实际开发当中，很多错误的发生都是因为团队成员之间沟通不到位导致的，所以沟通能力就是团队协作的润滑剂，不要只知道撸代码，不知道怎么去表达自己的思路。

4. 不要把百度来的答案当作最终答案

去百度上找答案，本身没有啥错误，但要知道消化吸收，逐步夯实自己的理论基础，提升自身解决问题的能力，同时提升自己思辨的能力。其实网上的东西太多了，不能讲全部是对的，而且越到后期难解决的问题，也是不能靠网上，一个国外技术大牛的一句话，”read the dam code”，去读代码是解决问题的终极解决办法。高中时候，大家会有一个体会，不管你看了多少例题分析，到你做题的时候，还是卡壳。其实，把遇到的问题深入刨析，就是一个消化吸收的过程，抄来的永远是他人的，吸收思考运用了，才是你自己的。

5. 把自己从单任务操作系统转变成多任务并行操作系统

DOS是早期的操作系统，单任务操作系统，功能局限性很大，不能充分利用硬件资源，多任务操作系统WINDOWS彻底取代了DOS。并行意味着高效，但同时也意味着管理复杂度的大幅度提升。在20多年的从业经历中，我发现优秀的技术人才一定是多任务操作系统，因为他知道怎么管理时间，利用自己的空闲时间。其实工作当中很多时候需要我们同时处理多个项目的事情，很多程序员一是不知道轻重缓急，就和操作系统把垃圾清理工作安排到了高峰期一样，第二是不知道怎么样实现灵活自由切换。其实这是一个人的做事方式问题，需要自己去摸索培育，比如，要学会做总结记录，不要和狗熊掰玉米一样，在空闲的时间多思考思考自己做的工作是不是有提升的空间，这些都可以是些碎片时间，多个项目编码的时候，学会使用TODO标签，防止自己忘记，或者做个什么备忘录，小技巧太多了，自己去积累培育吧。经过长期持续的多任务培训，你的思维也会变得可以并行起来。下面，就举例说明一下并行思维的好处，如果不能并行思维，会出现什么问题。

举个供货例子，你向供应商订货，发出订单A，但在订单的货物回来之前，你可能会发出订单B，而供货商很可能一次把你的订单A和B的货物返回给你。这个流程很合理吧，是符合合并节约原则，但很多订单系统就不能处理这种N-N的关系，导致信息化处理阶段很繁琐。

再说一个工作中的案例，公司开发远程控制系统，需要控制远程的很多洗车机，所以需要建立通信协议。通信协议里面描述，发出指令A，收到指令A1，发出指令B，收到指令B1，协议看似很简单，理解了，结果后来出问题，而且花了好大力气才发现。洗车机通信客户端为了提升效率，有时候会把多个返回指令合并一起返回，就和上面的采购例子一样，而负责服务器端的程序员还是串行思维，任务指令一个对一个，把后面的指令抛弃了，然后以为指令传输中丢包了，完全找错了方向。就拿TCP/IP来讲吧，也会使用这种合并机制，这是一种普遍适用的机制。

所以，去培育自己的并行处理能力，让自己逐步高效起来吧。

对于需要进一步提升的较资深的人

1. 走向技术管理是一个路径，团队的力量是永远大于一个人的力量的，做好技术管理，不但要加深自己的技术能力，而且要提升自己的管理能力。很多人会觉得管理提升和技术提升似乎是矛盾的，但这要看你怎么利用你的团队成员。技术管理者更多的精力需要花在架构和思路分析上面，需要知道怎么去安排团队成员来验证自己的思路，如果管理得当，一个人的学习，变成了一个团队的学习，技术管理者自身的技能外延也会迅速扩张。即使是一个管理者，我也很喜欢去向手下的人学习，一个做了很久测试的人，自然会在一些测试工具上面比我有多些理解，去听听他们的说法，辩证的去理解合理性，合理的就收纳，不合理的就提出疑问，让对方去验证。

2. 扩大自己的技能范围，如前端的去学习后台，后台的学习前端，去理解产品上面的事情，去学习测试方面的知识。越是复杂的软件，越是需要综合能力强的技术人员，程序员如果具备的产品思维和测试思维，则会如虎添翼。现代战争越来越重视多兵种联合作战，现代软件开发也是一样，真正业务逻辑复杂的B端软件是急需综合能力强的人才的，而中国智能制造2025的实现，也必将无法离开强大的B端软件的支撑，具体论述，请您参看”30多年过去为啥中国没有B端软件巨头”，”为什么BAT做不好B端软件”和”程序员要有产品和测试思维”。

3. 进一步深入理论基础，理论能力和运用能力的加强是需要进行反复作用的，反复在理论和实践中穿梭，做到不要只运用框架，更多的要思考怎么改善框架，或者设计自己的框架。其实任何解决方案都是由适用场景的，知道背后的理论，才能做到灵活运用。网上很多人推崇微服务，Mybatis和SpringMVC，我的观点反而是恰恰相反，当然我是有自己的实践理由的，有兴趣，请您参看”软件框架设计实例_微服务”，”软件框架设计实例_Hibernate”和”软件框架设计实例_Struts”。

更多精彩内容，请您专注公众号哟，也可以消息我，提出您感兴趣的话题。