作为一线技术人员，如何更好的提升自己

请大家看本篇文章务必带着一句话读下去：真正起决定作用的，在于我们的行动和热情！

概述

看了网上的学习方法，也综合了一下他人的意见，总结下来，想来自我学习以及自我提升的方式，大抵就是如下三种了

1. 从文字视图中学习

2. 向身边的人学习

3. 向自己学习

其中向自己学习最为靠谱。

而向自己学习最有效的方法，就是自省。

“曾子曰:吾日三省吾身，为人谋而不忠乎?与朋友交而不信乎?传不习乎?”

“古人诚不我欺”。总结，是自省反馈出来的一种结果。写这篇文章，希望不只是自己能够学到东西，进行成长，也希望能将自己的思考和经验传播出来，与大家共勉。

业务与技术的困扰

相信很多开发经常会被业务代码所困扰，绝大多数都是有梦想的程序猿，大家都有着一个想使用代码改变世界的梦，当初我选择软件工程这个专业，原因之一就是我觉得使用代码开发一个网站、一个游戏便是一件很牛的事情。

现在倒是觉得，能够理解业务，可以在企业不同阶段抽象业务语言为合适的技术语言，能够支撑业务发展，可以维持技术稳定才很牛。

在工作中，天天写业务代码，自己如何在技术上进步？大家是不是也经常心生疑惑，我以前也困扰过（自己的老大在总结中点醒了我，对技术有追求，但是并没有很好的结合业务。自己也好好进行了反省，搜集了很多资料，也询问了另外的大佬，如何更好的处理业务和技术），现在倒是觉得贴合业务更加能够提升打磨自己的技术以及增加自己在公司的不可替代性。

看到有文章这样比喻业务与技术，写业务代码学习的技术就像游戏中升级打怪一样，开始打小怪，经验值很高，越到后面经验值越少，打小怪已经不能提升经验值了。这个时候就需要打一些更高级的怪，刷一些有挑战的副本了，没看到哪个游戏只要一直打小怪就能升到顶级的。

成为技术大牛的路也是类似的，你要不断的提升自己的水平，然后面临更大的挑战，通过应对这些挑战从而使自己水平更上一级，然后如此往复，最终达到技术大牛甚至业界大牛的境界，写业务代码只是这个打怪升级路上的一个挑战而已。业务代码都写不好的程序员肯定无法成为技术大牛，但只把业务代码写好的程序员也还不能成为技术大牛。对应自己所处的角色，更好的挖掘出自己的潜力与提升实力，创造出更多的价值。

再说一个现实中的问题，工作都是基于业务来驱动的，国内基本所有公司（抛开研究不讲，广义上来说，所有的技术都是为业务服务的）都是业务来驱动的。

阿里的中间件团队，也是业务驱动而成立的团队（为了解决阿里内部复杂的业务场景、飞速的业务增长、高并发的大促洪峰、层出不穷的稳定性问题而成立的团队），只是做的事情比我们的高大上（高分布式 RPC 服务框架、高可靠分布式消息中间件、分布式数据层、海量数据存储、实时计算、系统性能优化、架构高可用等），后面会介绍到因业务需要而衍生高深技术。

带着问题思考

作为开发人员，如何面对“CRUD，天天写业务代码”这个事情，可以思考下面的几个问题

1. 什么是技术和业务

2. 业务和技术的关系

3. 业务与为解决业务而衍生的业务

4. 对待业务的态度因你在团队的角色不同而不同

5. 如何从所谓的业务代码中学习深入

什么是技术和业务

接下来就从业务和技术来入手进行分析了。

回归到这两个词的定义。

维基百科是这么解释的：

业务

业务是指某种有目的的工作或工作项目。

考虑到企业已经成为现代社会最常见的活动主体，故可为业务作现实定义，即企业运用科学方法和生产工艺生产出可交付用户使用的产品与服务，并以此为企业带来利益的行为。

不只是为企业，能为人类本身带来利益的需求，都可以称之为业务。

技术

技术可以指人类对机器、硬件或人造器皿的运用，但它也可以包含更广的架构，如系统、组织方法学和技巧

它是知识进化的主体，由社会形塑或形塑社会。如电脑等新技术的增生使人们相信技术是社会进化的决定性力量，换句话说，它是驱动改变的自发性动力。

通过人为创造条件，让指定的事件能够按照人类的意愿发生，这就是技术。

比如取火，最早人类只能靠打雷等自然现象产生火。

取火其实就是一个业务目标，要解决的是人类自己的问题，这就是业务，实际就是人类的利益。这个时候人类并没有生火的技术，只能靠不断的加木材，保持火不熄灭。

后来人们发现了钻木取火：只要用一个干的木棍，在另一个干木表面快速的转动，就可以生火。这个办法让人类可以自行创造火源，就产生了钻木取火的技术。

但是双手快速转动木棍钻木取火，并不是所有人都能够做得到的，需要很多力量和速度，对人的要求太高。为了解决快速转动的问题，就有人采用弓弦来提升木棍转动的速度。

业务目标是为了取火，钻木取火这个技术的出现解决了这个问题。

钻木取火的效率不高，影响了业务（取火）的效率，就有了进一步改进的动机，改进转动木棍的方式，产生了弓弦转动木棍的技术。

再用比较现代化的业务来进行说明一下

比如取款就是一种业务，ATM 机内运转的软件，要解决的业务就是取款。（取款是为了交易，当初交易不方便，于是便有了移动支付，聚合支付等等）

比如买火车票也是业务，12306 这个网站就是为解决买车票的业务服务的。（春运买票不易，于是出现了抢票软件，加速软件等等）

实现软件/网站功能的系统，架构，框架等便是技术（而技术本身又可能是建立在其他技术之上的）。

从上面的定义以及例子中，可以知道，业务是具有强目的性的，比如说我的业务就是为了取款，而 12306 网站的业务就是为了解决买车票的业务服务，是为某个具体特定的问题而生的；但是业务就具有弱目的性，普遍性和通用性，比如前面实现取款的技术框架，可能在 12306 中的框架还能复用等等。

技术存在演变，也是为了更方便的服务于业务本身。

技术和业务的关系

接下来以取火为例吧。

前面说到最开始是通过雷电获取火源，接下来是火石、钻木取火，然后渐渐演变到弓弦加速转动木棍取火，随着科技的发展，渐渐的生成火源便成为了一种业务，并且可以出售带来另外的利益，这个时候，生成火柴、打火机便是业务。而其中业务中使用的剧烈氧化还原反应、汽油制作、物理化学知识、工业制作等便是技术。

简单的可以得出如下几个结论

1. 技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提

2. 有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求 -- 也就是业务

有人会问，不用钻木取火了，但是弓弦加速转动木棍还可以用啊？ 没错，因为弓弦转动木棍这个技术，不是来生火的，是用来加速木棍转动的，所解决的问题不一样（引出了后面因解决业务而衍生出来的业务）。但是多种不同的技术，合理结合起来，会更好更有效率的解决业务问题。

所以技术与技术之间，有如下的两种关系：

1. 在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。

2. 一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来说，技术才是业务的 促成者）。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。

当更好的技术发生的时候，必定会形成一个切分，新技术会通过某种方式和原有的技术连接在一起形成一个整体，让这个新的技术可以和原有技术共同工作，使得原有的技术可以用更高的效率解决问题。因为要解决的主要业务（生火）并没有发生改变，分拆所形成的是一个树状的结构。

这个时候其实已经产生了架构。也就是说，一般是先有技术，才会有架构。这些其他技术（弓弦拉动木棍、氧化还原反应生火等），是从直接解决问题的初始主要技术中分拆出来形成的，并通过树状结构和主要技术（钻木取火）组合在一起。在解决主要问题（生火）之后，再开始逐渐的分拆为更为细粒度的技术（弓弦转木棍）

而这个细粒度的技术（弓弦转动木棍）往往不会和业务的主要目标（生火）发生直接的关系。不同的技术，通过树状结构，组合在一起，形成了一个完整的架构解决方案，共同完成业务的目标。这就是技术，业务和架构之间的关系。（分析火柴与打火机原理生成火源类似）

很多人把这个过程称为架构的进化，我更愿意把这个过程称为技术的进步所导致的新的架构分拆，因为这个过程内在的动力，更多的是来自技术对解决业务问题的解决。

我们回到开发者身上来看，写业务代码多一些，还是所谓的技术代码多一些，没有高下之分，只有个人取向和组织分工的不同。

业务与为解决业务而衍生的业务

打开淘宝首页，随便浏览一个商品详情页面。

是不是有人会第一眼觉得商品封面，优惠券等相关信息的代码是没有什么技术含量的，因为那些是业务代码。

是不是觉得写商品页面的框架，分布式架构，分布式缓存，JMQ，Redis 或者说是 等技术才是有技术含量的。

但实际上，所谓的业务代码和技术代码，它们的区别，仅仅是和业务的距离远近不同而已：业务代码离业务更近，技术代码离业务稍远。它们最终都是指向业务实现的。

而且，可以考虑换一种视角来看业务，就会发现，其实每一层代码，都服务于它的上一层代码，上一层代码，就是它的业务！

比如详情页架构的第 2 层“对外提供 API”中的“商品介绍” ，它的服务对象，就是前端页面，要解决的业务，就是“响应前端页面的查询，提供商品介绍”

而第 2 层底部的前端数据集群（JIMDB），它的服务对象，就是商品介绍，要解决的业务，就是“存储商品或代理商品介绍信息”。

简单说，每一层技术实现，都服务于上一层，都以上一层的需求为业务。从这个角度讲，现实中的业务在被虚拟化的过程中，会在技术实现层面引发分层，产生中间性、对用户不可见的新业务。

但是为什么很多开发者又觉得所做的技术实现越接近现实业务越没技术含量呢？

这是因为，你越接近用户业务：

1. 细节越多，繁琐度越高，越不容易做好，越容易因为一点小瑕疵而被否定，让人觉得自己的劳动没价值

2. 现实性越强，变化几率越高，越容易来回修改代码，越让人觉得自己的掌控感低下

3. 实现的代码可迁移性越差，劳动成果被复用的概率越低

而当你远离用户业务时：

1. 你用到的技术，多数都是被高度抽象过的、用来解决从用户业务衍生出的技术性业务的，它们比具体的用户业务稳定，它们的适用面更广，也更容易被迁移到其它的业务领域

2. 你的劳动成果因为具有抽象属性，被复用的概率会更高，你会更愿意打磨它，会更有成就感

3. 你受到压力，经过距离用户近的几层同事的传递，得到了衰减，没那么大

4. 你打交道的对象，多数时候是内部同事、是技术人群，更容易达成一致

对待业务的态度因你在团队的角色不同而不同

你对业务的态度，会因你在团队中承担的角色不同而不同。这是由开发团队的组织结构和职责分工导致的。

下面是“团队结构、能力与职责”图：

在一个开发团队中，架构师这个角色，会负责业务拆分和软件架构的工作，并且领导团队来实现满足业务的软件。

• 注 1 ：有的研发团队里有业务架构师和软件架构师两种角色，业务拆分由业务架构师或业务分析师完成。

• 注 2 ：软件架构师和业务架构师这两个角色也可能由没有架构师头衔的研发经理兼任。架构师一定是要以业务为导向的，要搞懂业务的。所以，在架构师这个阶段，在团队管理者这个阶段，业务的重要性，往往是高于技术的，在他们的眼中，业务统领技术，技术是用来实现业务的。

当团队完成业务架构和软件架构之后，就会选择不同的开发者来负责不同功能模块的实现。

负责不同功能模块实现的开发者，必须能够理解业务，并且要熟悉某个技术栈，能够进行模块设计和任务拆分，我称这样的开发者为“熟练开发者”。

熟练开发者会承接由架构师分派的子业务，负责模块设计和拆分，把拆分后的小任务，交给普通程序员来完成。

当你是一个熟练开发者时，业务和技术几乎同等重要，因为：

你不理解业务，就很难将子业务模块映射到软件实现上，也很难做进一步的业务拆分。

你不具备完整的技术栈和相应的知识体系，就很难找到合适的技术来实现业务，也很难做软件模块的拆分。

熟练开发者完成了子业务和软件模块的拆分，会形成一系列的叶子型任务，并把它们分派给具备特定专项技术能力的普通程序员。

普通程序员要做的事情比较简单，就是接受别人分派的任务，实现特定的业务细节。

注意当你是一个普通程序员的时候，团队要求你具备一定的专项技术能力，能够完成任务即可，你的角色，就拿把螺丝刀拧螺丝，拧好螺丝就 Ok 。

这个时候，你内心是痛苦的，对不停地写业务代码是拒绝的，因为你要再找工作时，别的组织看重你的专项技术能力甚于业务能力（他们有人做业务拆分，你过去了能拧螺丝即可），而你在现有组织中，却因为深陷业务代码的编写而无法持续淬炼你的技能能力。

而开发中普通程序员是占比最大的，所以经常能看到文章或者有人提问纠结写业务代码这件事！

那么，该如何才能解脱呢？

从所谓的业务代码中跳出

首先，很遗憾的告诉各位，这不是一蹴而就的，是一个技术深度和业务层次积累的过程，这需要时间。

作为一名技术人员，一方面要认识到技术只是用来解决特定问题的工具，所以一定要从问题出发，提出解决方案，而不能一味的追求技术的完美。

另一方面，也要认识到技术本身也可能成为一项业务，只要它足够通用，能够给其他人、组织提供有价值的解决方案。

但是，公司业务代码太多，总是“沉迷业务无法自拔”，如何更好的提升自己，让自己发光发亮，能够提供更多有价值的东西。

也看到很多文章说的是，需要自己挤出时间出来进行学习，也就是在工作之余进行提升，自己认真的想一想，在业务上真的是无法提升自己吗？当我们轻松、漂亮的搞定业务后，能不能再从下面的方面入手进行思考呢。

例如

• 熟悉业务相关的更多业务和代码，不管业务是不是你负责的，不管代码是不是你写的；这样的好处太多，不列举，有兴趣的可以搜索

• 这个业务有没有优化的点；

• 重复代码太多，是不是可以考虑使用设计模式进行优化

• 系统中业务是不是庞大，能不能进行解耦成几个服务或者模块

• 开源框架中的一些功能正好能够用到，可不可以引进

• 代码中性能有没有需要优化的地方

• 在高并发情况下，有没有潜在 Bug

• 能不能使用缓存，减少数据库压力，增加访问性能

• 思考一下这个系统的架构，该系统使用了些什么技术，我还有哪些不知道的

• 系统为什么使用这个技术，为什么使用这种架构

• 下次类似的业务，我能不能抽出相关代码，进行复用，或者直接开发成服务，暴露出来

• ... ...

很多普通程序员天天抱怨老写业务代码没长进，可手上的任务却总是敷衍了事，完成得凑凑合合，甚至还出现频现线上 Bug，那是很难摆重复简单业务任务的泥沼的。

如何轻松、漂亮的搞定业务

可以从这四方面进行入手：

1. 在深度（研究领域中非常具有代表性的某几个框架的原理链）和广度（开源的框架这么多，至少要认识吧）两个方面提升技术能力（如果当下任务繁重，就利用业余时间练习）

2. 把自己的做的事情放在全局理解，提升业务理解能力

3. 培养好的工作习惯，比如计划、回顾、总结等

4. 做好汇报和展示，让领导知道你的能力

当你慢慢做了上面 4 点之后，每次拿到任务，都能轻松又漂亮地搞定，超出领导的预期，还有未发挥完的火力，那团队就一定会给你复杂一点的任务。

如果你还能轻松、漂亮地搞定并且还有余力，那团队就会给你复杂度再高一些的任务。

往复循环，你就可以跳出最简单的业务代码编写，做越来越重要的事情，你的不可替代性也变得越来越强。

总结

1. 技术是手段，业务是目的；软件开发工作是以业务为导向的，但是没有技术又无法实现业务。

2. 业务和技术的关系，随着开发者角色的变化而变化。

• 刚入行时作为普通程序员，技术是基础，有技术才能实现业务，公司在招人时也以技术水平为门槛，从这点出发，一定要在迅速提升技术，以免被淘汰。

• 工作了 3、5 年，成了熟练开发者，可以独自负责一个业务模块时，需要更好地理解业务，这样才能更好的从技术上实现，此时业务和技术并重。

• 从熟练开发者往前发展，有两条路，技术专家和架构师，如果你选择架构师的路线，则应该调整思维，以业务为导向，把业务放在更重要的位置，因为架构是从业务拆分出来的，如果你选择技术专家路线，则需要在深耕技术的同时保持对业务的敏感。

3. 普通程序员要想从业务代码的泥沼中跳出，要从技术水平、做事的方法、习惯和自我展示几方面入手，努力做到搞定任务有余力，进入正向循环，慢慢获得做重要事情的机会，让自己变得重要。

前面讲的东西，方法论居多，最重要的其实并不在前面，而是这后面的文字

真正起决定作用的，在于我们的行动和热情！

不管结论是什么，关键还是在于自身，是否意识到了自我的提升，是不是有兴趣，是不是有足够好的学习方法，是不是对自己的前路有些目标和计划，有没有足够的自制力执行下去。再多的劝解永远都不如自己想通。不是自己的体会，他人再好的建议都是枉然。