如何从传统软件开发顺利过渡到互联网技术开发

今天来说一个比较普适性的问题：如何从传统软件开发转到互联网技术开发，这也是不少朋友问过我的问题，特整理一篇文章出来分享给大家。

软件无所谓传统与新兴，只不过面向市场的不同，导致大家心里有个对比。何谓传统软件开发，可能更多的与企业内部应用挂钩，采用项目制，人员对项目负责，面向B端用户，用户规模小，业务场景特定，迭代升级频率小，技术实现复试度较互联网应用低。

由于采用项目制，在项目结束后，项目就移交出去，后期的升级、维护、运营、运维几乎很少参与，日常开发工作更多的也仅是业务开发，导致参与这些项目的人员成就感特别低，技术成长有限。有一个词与传统软件开发走的比较近： 外包。所谓铁打的项目，流水的码农，外包人员的流动性是最大的。

那为什么要跳出传统软件开发，去做互联网研发呢？说到底还是生存与发展的问题。BAT，TMD等类似大厂的好待遇好福利好前途，充斥着互联网，影响着身边的每一个人。短短数十年的信息革命又被称为第四次工业革命，远比之前三次来的更迅速，渗透的更深入。互联是趋势，我们要做的就是顺势而为「这让我想起雷总牵头的顺为资本」。

切入正题，不管做什么转到哪行做研发，无非两方面，软实力加硬技能，再具体点就是思维转变结合一定的技术储备。

软实力——思维转变

就是变被动为主动，沟通协调，团队合作，都需要一个转变。举个栗子——需求，不能再一味的按着合同上确定的需求，按部就班一个里程碑接一个里程碑的去实现，有需求变动再去做个需求变更流程后再开发功能。

上篇文章专门介绍了做项目与做产品时的需求区别：产品需求与项目需求的差异。需求是一个转变点，其它还体现在开发模式、产品迭代、团队合作中。互联网研发更多的趋向于产品研发，开发模式抛弃传统软件开发过程中的瀑布模型，更多的采用敏捷模式，KANBAN、SCRUM等，读一下敏捷宣言似乎来的更直观一下。

个体和互动 高于 流程和工具 

工作的软件 高于 详尽的文档 

客户合作 高于 合同谈判 

响应变化 高于 遵循计划

大家都在讲互联网思维，做研发也一样，只有从 自我认知层面转变过来，才能更好的去适应互联网技术开发。

有人说我一直搞传统开发，没有经验啊！其实方法总比困难多，去找从事过相关工作的同学\亲戚\朋友\前同事\网友去聊聊天，到知乎\Google\微博\博客\公众号看别人的总结，参加相关的线上线下活动等等，如果以上都不行的话就来找我吧。

硬技能——技术储备

以结果导向看，因面向对象的不同，导致采用的技术栈差异比较大。互联网应用技术应用更广泛，更考验技术的融合能力。具体有哪些不同，从招聘网站的相关岗位技能要求上就能找到端倪。你需要做的，就是找几个代表性的技能要求摘出来，形成自己的技能学习列表，个个击破。特别是一些常见的，比如分布式、缓存、消息队列等。

肯定有朋友跳出来说我工作中压根都用不到，怎么能掌握住。工作中用不到，只能在工作外想办法，自己啃书看教程学习，照猫画虎做案例；跟别人交流取经，探明暗坑深水，为我所用。

为什么要转型呢？

云计算的盛行，导致很多产品已经云化。另外，长期专注于业务开发导致技术人员自觉乏味，没有提升空间，自我存在感、成就感大幅下降，而互联网、移动互联网、物联网、大数据、人工智能等一波又一波的浪潮，一个又一个造富神话，充满了吸引力，并且有很大的成长空间。

本文也是基于前文的基础上，从一些简单的点入手，引入一些经常用到的开发技能点。从单体应用开发，过渡到分布式应用开发，技术栈的变更必然导致学习、工作上产生不小的变化，以下列出几点，来帮助想要转型的朋友掌握这些技能，以便更好的融入到新团队中去。

分布式通讯技术

单体应用几乎不涉及到系统间的交互，或者有些通过老旧的WebService的形式进行交互，互联网分布式系统倾向于采用轻量化的、更高效率的通讯方式，比如基于HTTP、RPC协议等，了解基本的原理才能更好的使用它们，常见的，再掌握所以你应当掌握一些常用的分布式框架，比如常见的Apache Dubbo,Spring Cloud,Google gRPC等等。数据交互的格式以有轻量的JSON替代原先比较臃肿的xml格式。

缓存技术

缓存可谓是提高应用效率的大杀器，在互联网产品应用非常广泛，掌握几个常见的缓存中间件是很有必要的。也很多应用场景中，也只能缓存才能保证应用的完整性，比如秒杀场景。缓存按应用场景也有区分，如本地缓存EHcache,Guava等，分布式缓存Redis，Memcache，hazelcast等等。

非结构化数据存储

互联网产品更多会产生一些碎片化的数据，且没有严谨的数据结构，这些些场景上采用非结构化存储势在必行。根据不同的数据类型，还可以细化分为不同的NOSQL库，比如说文档数据库（MongoDB等)、KV库（Redis，LevelDB等）、图库（Neo4j)、列数据库（Hbase等）、搜索引擎（Solr、ElasticStack等）。

异步、多线程技术

同步的一问一答，能比较及时的处理业务，但当业务量大的时候，为提高系统可用性、处理效率，往往会进行异步、多线程方式进行处理。线程池技术，高并发编程显的尤为重要。

消息中间件

MQ天然具有系统解耦的优势，应用场景也比较丰富，如在分布式事务中作为中间办来协调事务、统一的消息（APP推送，短信等等）推送分发、延迟队列，特别是在高并发高承载的情况下进行削峰平谷，缓解系统压力。比较常见的RabbitMQ、ActiveMQ、RocketMQ、ZeroMQ、Kafka等等。

分布式事务

单体系统的事务很容易控制，当系统扩展为很多个子系统时，事务会分面在各个子系统中，只有保证分布式事务的准确性，才能保证数据的完整性。目前现在很通用的分布式开源解决方案比较少，大家都在采用自己的方案在做，阿里最近开源的Fescar是一个比较有潜力的方案，还有华为的SAGA方案等等。

安全开发

安全开发在所有系统中都存在，只不过传统的单体应用开发，特别是外包行业，基本很少考虑。而互联网产品面向大众，所以网络安全、数据安全更为关键，比如常见的XSS攻击、CSRF攻击、撞库、拖库等等，都需要在开发、测试、运维过程中重点关注。OWASP TOP 10或CWE top 25都有比较详细的描述，可以关注下。

运维层面

Linux常见的操作应当掌握，毕竟我们很多的服务器都是运行的x86架构下的Linux服务器中，即便是不同的分发版本，命令很多也是通用的。Devops文化已经不再陌生，开发&运维已经不可分割开来单独作业务，持续集成（CI）、持续部署(CD)技术将二者的边界变的更模糊，共生共存。

下面提几个高级进阶点，这些点并非必须要掌握，但后续肯定会遇到，技多不压身，有条件的话，可以适当的探索一二，扩展眼界，提升格局。

链路追踪技术

单个系统里的日志可以按系统交互的先后顺序输出，单系统分拆后，系统日志分别存在于各个子系统中，再区分请求的先后顺序难度就比较大了，导致追踪定位问题，比较繁琐复杂。还好Google又一次引领了潮流，Dapper论文的出现，催生出一大批开源组件的出现，Zipkin、Pinpoint、CAT等应用比较广泛的几个。

集群部署

听起来比较搞大上，无非是将原来一台机器干的事，分散在不同机器执行而已，对外提供较高的可用性、计算能力。对于每个用到的中间件几乎都会有主从、主备、集群、高可用等部署策略。

高可用技术

与集群技术应该是关联性很大的，更多是来应对单点故障，简写称为HA（High available），比如可能会经常用到keepalived来保证Nginx、Apache、Tomcat的HA策略；比如会用到Supervisor来保证某些进程挂掉后，自动拉起。

容器技术

Docker应用的普及，将云原生应用的提到前所未有高度。Kubernate等容器编排工具更加快了云原生应用（Cloud Native）的普及，CNCF孵化下的各种开源中间件也为业务提供了强大的技术支撑。

由于传统软开发过程中较少的涉及到如上一些技术点，所以需要在工作之余进行练习掌握，这对后续的面试求职也有很大的帮助。没有工作场景，就没有掌握相应的技术，没有相应的技术支撑，就没有机会进入互联网行业，毕竟很多公司都是希望你来就可以上手产出价值，而不是培训一两月时间再上岗。