什么是业务

业务和技术的关系

业务和因解决业务而衍生的业务

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

如何从写业务代码中跳出来，做你所谓的有技术含量的工作

首先，我们先来看看，什么是业务。

▼

1. 什么是业务
   简单讲，“业务”就是需要处理的各种事务，但通常偏向指客户实际作业涉及的事务，“业务”最终的目的是完成工作所做的所有事务。

比如取款就是一种业务，ATM 机内运转的软件，要解决的业务就是取款。

比如挂号、预约、查检查报告，都是业务，趣医网的 App 就可以用来解决这些业务。

比如买火车票也是业务，12306 这个网站就是为解决买车票的业务服务的。

▼

1. 业务和技术的关系
   软件是用来解决现实世界中的业务给人们的工作带来便利的。

比如到火车站买票，要坐车、提前、排队，又麻烦又消耗时间又浪费精力，而 12306 网站和 App ，通过把买火车票这种现实业务虚拟化，为人们省去了奔波、排队、耗时的麻烦。

比如大家都想到好医院看病，人人都想挂专家号，很多人为了挂到某个医生的号，通宵排队，非常辛苦，而现在的各种网上挂号网站、微信公众号、 App 。

通过软件技术手段，把专家大夫这种资源虚拟化，让大家随时随地能挂号，还不用到医院、不用通宵憋尿排队、不用担心被医托和黄牛忽悠，给患者带来了极大便利。

软件是现实业务虚拟化的载体，技术最终是为了解决业务问题的。从这个角度讲，所有的开发者，其工作最终都是指向某个特定业务问题的。没有业务，技术的存在就没有意义。技术不能解决实际问题，不能给人们带来便利，就没有价值。

但从另一方面来讲，技术是现实业务虚拟化的必要条件，没有技术，现实中的业务就无法被虚拟化。而且，同一种技术又可以实现多种业务的虚拟化。

所以，很多初阶的开发者才会有种“错觉”：技术牛 X ，因为没有技术就无法实现业务，业务很 Low ，技术牛 X 了，随随便便就能搞定。

实际上，这些感觉虽然在一定阶段有其道理，但并不是真理哦。

关于业务和技术的关系，这里下个结论：

技术是为了解决业务问题的，只有在实现业务、给人们带来便利的前提下，技术的存在才有意义，所以，多数时候，是业务决定技术、业务统领技术。

没有技术，业务就无法被虚拟化，生产效率就很难有效提升

业务和技术具有相互促进、相互依存的关系。

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

▼

1. 业务和因解决业务而衍生的
   很多开发者会用割裂的眼光来看待业务和技术，比如把增删改查（CRUD）看作是无意义的业务代码，把实现 libuv 或 Redis 这样的框架看作是有技术含量的事情。

比如京东上《程序员的成长课》这本书的详情页，是这样的：

它对应的架构是这样的：

很多开发者会觉得，写那些用来展示《程序员的成长课》的图书封面、优惠券、促销等相关信息的代码是没什么技术含量的，因为那些是业务代码。

他们会觉得，写商品详情页架构中的 Redis、JMQ 或 JIMDB 是有技术含量的，是真正的技术代码。

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

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

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

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

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

从这个广义业务的视角来看，每一层代码，都是业务代码！

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

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

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

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

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

而当你远离用户业务时：

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

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

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

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

▼

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

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

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

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

注2 ：软件架构师和业务架构师这两个角色也可能由没有架构师头衔的研发经理兼任。

架构师一定是要以业务为导向的，要搞懂业务的。所以，在架构师这个阶段，在团队管理者这个阶段，业务的重要性，往往是高于技术的，在他们的眼中，业务统领技术，技术是用来实现业务的。

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

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

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

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

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

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

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

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

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

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

所以普通程序员最纠结写业务代码这件事！

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

▼

1. 如何从写业务代码中跳出来
   孔子说过一段话：“弟子入则孝，出则悌，谨而信，泛爱众而亲仁，行有余力，则以学文。”

翻译成现代文，是这个意思：“年轻人，在家就要孝顺父母，出门在外就要尊敬兄长，行为谨慎，言语有信，博爱众人，亲近仁者。这样都做到之后还有余力的话，就可以去学习从政，做更大的事业。”

这段话呢，给普通程序员指明了方向：轻松搞定你的业务代码，还有余力，就可以做更重要的事情。

也就是说，当下你能力不够，组织上不可能给你更复杂的模块让你负责（再说团队里已经有更厉害的人在做那些事了），你得先轻松且漂亮地搞定手上的任务再说。

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

那怎样才能做到轻松、漂亮地搞定任务呢？ 4 点：

在深度和广度两个方面提升技术能力（如果当下任务繁重，就利用业余时间练习）

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

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

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

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

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

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

▼

1. 小结
   前面我们分 5 个部分阐述了业务和技术的关系，总结一下，关键的其实有 3 点：

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

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

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

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

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

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

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

从文字视图中学习
向身边的人学习
向自己学习
其中向自己学习最为靠谱。

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

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

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

自我回顾
从年初到年末，从一个技术人员 仅3人的小手游公司到了如今开发团队近200人的中大型公司。

下面从工作和个人成长两个方面进行入手，剖析一下自己。

工作上，从一个人埋头干活，到主导跨4，5个小部门共同协作的技术经理以及现在作为一个小组的leader，作为员工，如何在业务中继续成长下去以及如何在公司体现出自己的不可替代性（技术和业务上的），也让公司看到你的潜力（你的成长能为公司为团队带来的收益）；作为小组leader，如何更好的带好自己的小组（这点在后面并没有讲到，明年见）；

另外，自己技术上的成长。也许我扯一大堆的技术名词，并不是很直观，简单粗暴的讲，就是从一个日流量不到万级的游戏到如今日流量亿级的项目以及其他大大小小高流量项目的开发。

稍微从技术层面说就是Java的单体SpringBoot项目发展到基于Dubbo、SpringBoot的，使用到分布式事务，分布式锁，分布式数据分片，负载、限流、熔断、降级、链路追踪、elasticsearch、消息队列、缓存redis、自动化部署、apollo、Sentinel等一大堆名词和技术搭建的高并发高可用服务化项目；

凭我这浅薄的知识，至少目前不可能用自己理解的概念来把上面列到的一些知识点的原理来进行讲解，自己对其也只是懂个大概，更不想误人子弟，仅仅讲点自己也似懂非懂的概念。自己目前对其理解的，就是很多开发所处的，调用接口使用的这个层次。原理知识，以后会慢慢道来。余生漫漫，请君勿急。

篇幅有限，开始想着能写很多，但是思考下来，关于技术和业务就能写一大篇的文字。

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

现在倒是觉得，比如开发一个GitHub开源项目的star几千上万才是牛逼哄哄的事情了。

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

看到有文章这样比喻业务与技术，写业务代码学习的技术就像游戏中升级打怪一样，开始打小怪，经验值很高，越到后面经验值越少，打小怪已经不能提升经验值了。这个时候就需要打一些更高级的怪，刷一些有挑战的副本了，没看到哪个游戏只要一直打小怪就能升到顶级的。
成为技术大牛的路也是类似的，你要不断的提升自己的水平，然后面临更大的挑战，通过应对这些挑战从而使自己水平更上一级，然后如此往复，最终达到技术大牛甚至业界大牛的境界，写业务代码只是这个打怪升级路上的一个挑战而已。业务代码都写不好的程序员肯定无法成为技术大牛，但只把业务代码写好的程序员也还不能成为技术大牛。对应自己所处的角色，更好的挖掘出自己的潜力与提升实力，创造出更多的价值。

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

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

什么是技术和业务
业务和技术的关系
业务与为解决业务而衍生的业务
对待业务的态度因你在团队的角色不同而不同
如何从所谓的业务代码中学习深入
什么是技术和业务
接下来就从业务和技术来入手进行分析了。

回归到这两个词的定义。

维基百科是这么解释的：

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

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

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

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

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

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

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

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

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

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

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

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

比如取款就是一种业务，ATM
机内运转的软件，要解决的业务就是取款。（取款是为了交易，当初交易不方便，于是便有了移动支付，聚合支付等等）
比如买火车票也是业务，12306 这个网站就是为解决买车票的业务服务的。（春运买票不易，于是出现了抢票软件，加速软件等等）

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

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

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

技术和业务的关系
接下来以取火为例吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

业务与为解决业务而衍生的业务
打开淘宝首页，随便浏览一个商品详情页面。

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

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

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

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

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

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

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

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

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

细节越多，繁琐度越高，越不容易做好，越容易因为一点小瑕疵而被否定，让人觉得自己的劳动没价值
现实性越强，变化几率越高，越容易来回修改代码，越让人觉得自己的掌控感低下
实现的代码可迁移性越差，劳动成果被复用的概率越低
而当你远离用户业务时：

你用到的技术，多数都是被高度抽象过的、用来解决从用户业务衍生出的技术性业务的，它们比具体的用户业务稳定，它们的适用面更广，也更容易被迁移到其它的业务领域
你的劳动成果因为具有抽象属性，被复用的概率会更高，你会更愿意打磨它，会更有成就感
你受到压力，经过距离用户近的几层同事的传递，得到了衰减，没那么大
你打交道的对象，多数时候是内部同事、是技术人群，更容易达成一致
对待业务的态度因你在团队的角色不同而不同
你对业务的态度，会因你在团队中承担的角色不同而不同。这是由开发团队的组织结构和职责分工导致的。

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

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

注1 ：有的研发团队里有业务架构师和软件架构师两种角色，业务拆分由业务架构师或业务分析师完成。
注2 ：软件架构师和业务架构师这两个角色也可能由没有架构师头衔的研发经理兼任。
架构师一定是要以业务为导向的，要搞懂业务的。所以，在架构师这个阶段，在团队管理者这个阶段，业务的重要性，往往是高于技术的，在他们的眼中，业务统领技术，技术是用来实现业务的。
当团队完成业务架构和软件架构之后，就会选择不同的开发者来负责不同功能模块的实现。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

熟悉业务相关的更多业务和代码，不管业务是不是你负责的，不管代码是不是你写的；这样的好处太多，不列举，有兴趣的可以搜索
这个业务有没有优化的点；
重复代码太多，是不是可以考虑使用设计模式进行优化
系统中业务是不是庞大，能不能进行解耦成几个服务或者模块
开源框架中的一些功能正好能够用到，可不可以引进
代码中性能有没有需要优化的地方
在高并发情况下，有没有潜在Bug
能不能使用缓存，减少数据库压力，增加访问性能
思考一下这个系统的架构，该系统使用了些什么技术，我还有哪些不知道的
系统为什么使用这个技术，为什么使用这种架构
下次类似的业务，我能不能抽出相关代码，进行复用，或者直接开发成服务，暴露出来
… …
很多普通程序员天天抱怨老写业务代码没长进，可手上的任务却总是敷衍了事，完成得凑凑合合，甚至还出现频现线上Bug，那是很难摆重复简单业务任务的泥沼的。

如何轻松、漂亮的搞定业务
可以从这四方面进行入手：

在深度（研究领域中非常具有代表性的某几个框架的原理链）和广度（开源的框架这么多，至少要认识吧）两个方面提升技术能力（如果当下任务繁重，就利用业余时间练习）
把自己的做的事情放在全局理解，提升业务理解能力
培养好的工作习惯，比如计划、回顾、总结等
做好汇报和展示，让领导知道你的能力
当你慢慢做了上面4点之后，每次拿到任务，都能轻松又漂亮地搞定，超出领导的预期，还有未发挥完的火力，那团队就一定会给你复杂一点的任务。

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

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

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

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

刚入行时作为普通程序员，技术是基础，有技术才能实现业务，公司在招人时也以技术水平为门槛，从这点出发，一定要在迅速提升技术，以免被淘汰。
工作了3、5年，成了熟练开发者，可以独自负责一个业务模块时，需要更好地理解业务，这样才能更好的从技术上实现，此时业务和技术并重。
从熟练开发者往前发展，有两条路，技术专家和架构师，如果你选择架构师的路线，则应该调整思维，以业务为导向，把业务放在更重要的位置，因为架构是从业务拆分出来的，如果你选择技术专家路线，则需要在深耕技术的同时保持对业务的敏感。
普通程序员要想从业务代码的泥沼中跳出，要从技术水平、做事的方法、习惯和自我展示几方面入手，努力做到搞定任务有余力，进入正向循环，慢慢获得做重要事情的机会，让自己变得重要。
本文参考了知乎以及InfoQ上关于业务与技术关系思考的文章
https://zhuanlan.zhihu.com/p/32793063
https://www.infoq.cn/article/an-informal-discussion-on-architecture-part09
在此表示感谢。

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

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

结语
总结受个人观点和个人知识面主导，如意见不同，欢迎留言指教，愿与君“论剑”。

酒未逢知己，望以文代酒。

看到这里的基本是真爱粉了，给大家准备了个小小的福利。

本来是想着过年了，看着能不能接入微信红包，给大家来点红包，结果却发现需要接入微信支付，非常遗憾。也不想通过接入第三方，通过开VIP（主要还是因为穷）的方式进行发红包，还不如多补贴你们一点呢。

后面我会通过支付宝口令红包的方式(那肯定是只能关注了的小伙伴才能参与咯)，把红包派送给大家！（实现方式暂时保密。会有菜单附上大家所有人的手气排行榜、留言以及剩余未领红包的展示页面，由于支付宝是否领红包的数据无法通过接口得到，所以排行是以大家得到口令能够领到红包的大小进行排行，最后，考虑到支付宝口令红包的有效时间是24小时，所以，老用户（系统上线前关注的用户）邀请一个新用户关注的，会额外获取到一次获取口令的机会！最多可获取3次口令！这是仅限老用户的福利！）

暂时考虑是发100个左右，拼手气300元起（自己实现的拼手气，考虑二八原则，20%的人拼手气分80%的财富，80%的人拼手气20%的金额，最小金额0.01元，获取最大金额不限制，玩的就是运气）。
相关的所有源码会上传到GitHub，相关获取奖励的区块Hash链也会公开。绝对不会有内定一说。

以后也会陆陆续续考虑不同的活动福利送给大家。

转变心态：从把工作做完的心态转变为把工作做好的追求
  把工作做完很容易，但要同时把工作质量做到位很难，这里说的做好是保证工作的质量，保证质量的前提是尽量减少人员复用、避免人员在业务上满负荷运转。具体体现比如：

明确业务的性能指标并达成，比如启动速度、内存泄露、卡顿占比、功耗、异常率等
明确业务的业务指标并达成，这跟每个业务的功能和定位强关联，比如搜题工具的准确率和评论搜索耗时
通过程序设计及评审，代码评审、自测保证程序提交的质量，程序质量的评估方式可以是千行代码的bug率、异常率等
专人专项解决项目中的技术瓶颈
价值最大化：为团队、公司乃至社区贡献价值
  这方面需要绩效牵引，鼓励额外的付出，比如：

技术分享：将工作成果分享给团队，并形成沉淀作为团队的知识财富
带人：作为mentor辅导团队的新人，帮助团队成长
通过开发工具或者代码复用的方式，解决团队的效率瓶颈，比如将通用代码封装成基础库
将工作成果封装，开源
主人翁心态：技术驱动业务
  这一点很难，但它是技术人员可追求的方向，因为这样你才会有主人翁心态，感觉是在做自己的事情一样。

理解业务、拒绝不合理的需求，避免因为需求不靠谱导致后期的变更
在开发中，发现通过技术可以优化/改变现有产品的体验、提升竞争力的地方，提出建议并实现
关注行业动态和技术方向，结合业务思考，并推动运用在产品中
  当然这些方面的改变是需要从上到下的推行的，并且在文化、规范、绩效和培训等方面做牵引。只有团队leader有追求，耳濡目染，团队成员才会跟着有追求。