程序员:请你不要对业务逻辑「嗤之以鼻」

最近感受很多,感慨也很多。我发现很多程序员对于处理业务逻辑都是「嗤之以鼻」。感觉自己天天写业务逻辑代码,改 Bug 都没有时间学习,没有时间实现个人成长?

但是,作为程序员来讲,如果不是做底层基础技术研发的话,大部分的工作不就是做这些拧螺丝的工作吗?其实拧螺丝有那么容易吗?可能拧螺丝很容易,但是拧好螺丝就不那么简单了。

别小瞧业务逻辑代码, 如果真正写好, 要把逻辑写得清晰简单易用, 功能健壮稳定,性能同时达到要求的话,其实是挺难的。

最近和一个刚接触编程的程序员聊天,问他喜欢编程吗?他说非常喜欢,所以就干了这行。由于是初学者,前期兴奋,喜欢正常,干了两个月后,再问他喜欢吗?他说最近有些浮躁,好像并不是那么喜欢了,感觉编程就那样,整天写写界面,处理一下业务逻辑,改改 Bug ,真没什么。

其实很多程序员都跟他一样,都在痛苦的编程,一方面对自己有更高的要求,一方面又嫌弃现在写的代码没有技术含量。又有更高的要去和希望,又嫌弃现在的工作,就是不思考出现的原因,不去付诸行动。还不停的抱怨:感觉自己天天写业务逻辑代码,改 Bug 都没有时间学习,没有时间实现个人成长?

到这里,我们不禁一问:那我们该如何摆脱这种现状呢?其实很简单,我们应该摆正自己的态度和观点,正确看待写业务逻辑这些代码就行了。

坚持不懈的写好业务逻辑代码

就像我在上面说的:别小瞧业务逻辑代码, 如果真正写好, 要把逻辑写得清晰简单易用, 功能健壮稳定,性能同时达到要求的话,其实是挺难的。

所以,我们要正确看待写业务逻辑的代码,应该摆正心态,坚持不懈的去写,所谓量变引起质变,就是这个道理。写业务代码,积累代码量,一力降十会,在积累了巨量的代码量之后,几乎任何所谓的有技术含量的东西都构不成挑战性。当然,要想真正的通过自己写业务代码,写好业务代码还应该有接下来的这个思考。

业务逻辑代码同样可以玩出很多花样

其实业务逻辑代码一样可以玩出很多花样,而这才是能够提升你能力的本质。比如:你写了一个处理单任务的业务逻辑,虽然满足了用户的需求,但是你这时能不能对自己有一个更高的要求呢?单任务虽然是功能实现了,但是效率可能不行,处理慢,那搞个多任务处理的逻辑怎么样?任务池、线程池、内存池、并发、同步等等这些技术点都来了。如果你对自己有这样的要求,而你自己有追求的话,就会进一步思考如何去做到这些,你做到了,你能力就提升了。

同样,很多人感觉处理业务逻辑,就是一些各种循环,条件判断,只要逻辑稍微严谨点,功能就都没问题,就都实现了,确实是这样的。这就是你对于业务逻辑没有兴趣的根点所在。

那你为什么不想想:如何使用循环和条件判断可以提升效率呢?满足了功能的那些需求,是不是有些地方可以优化一下呢?是不是可以提升一下性能呢?

其实,这个技术的进步和积累,就在于自己内心对自己有没有更高的要求和追求。这是大实话,也是大白话。很多人就感觉只要实现了功能需求就够了,满足了用户就行了。然后,这个项目完事了,下个项目遇到差不多的逻辑,还是这么处理,又完事了,每个项目,每个功能都是这样重复的处理,从来不思考最优的实现方式,你感觉能够进步吗?你能不烦气吗?十年如一日的工作,10 年也就积累了一年的工作经验,在重复使用。

业务逻辑的最优方式,就是思考如何大道至简

通过一个业务逻辑实现一个功能,基本上只要是程序员,脑子不笨,都能做出来,做出来是一回事,但是做好是另外一回事。大道至简,我们要做就得想办法做到最好。这里的好有很多层意思。

比如:你写的业务逻辑代码 是否能够做到准确, 稳定, 高效, 易读, 易扩展, 易维护,兼容性强呢?问自己一句,如果你能做到这些,那确实是好。如果做不到,你还是处理初级水平,当然不行,这就是你在工作中提升能力的机会。别说没时间,都是借口。

精益求精是对代码大道至简的永恒的追求,也是我们在处理业务逻辑代码中不断提高自己能力的过程。

明明自己水平初级,就容易骄傲自满,感觉可以了,我想学更高的技术,那么更高的技术是自己在处理业务逻辑中一步一步积累出来的,不是干了初级的活,不用积累,直接学高级的技术,就能高级了。

我特别喜欢网上有个网友写的一段话:

有的人在一个行业写 10 年业务逻辑代码,那他就是这个行业的大牛, 有的人在各行各业写 10 年不同项目代码,那他就是互联网界的大牛, 有的人喜欢精于钻研某一项技术,那他就是这个领域的专家, 有的人善于整体把握系统的架构,那他就是软件行业的专家, 只要你喜欢你的工作,你就会去主动的学习,成长。

其实很多技术大牛和技术专家,都是从业务逻辑做起,慢慢积累思考起来的。比如:在处理业务逻辑之前,会思考如何设计这个架构,可以让代码更好的扩展和维护。在处理业务逻辑的时候,思考如何的处理才能提高性能和效率?一步一步的实验和总结,积累,才成就了今天的成绩。

所以,不要对处理业务逻辑嗤之以鼻,不要以为能够满足需求就够了。你重复不思考的粘贴和复制肯定是不行的,必然会对编程失去兴趣,自然无法更好的成长和进步。应该在编程的过程中追求更高的要求,寻找更高的兴趣,这样才能让你持续进步,从而进阶。

原文发布于微信公众号 - 非著名程序员(non-famous-coder)

原文发表时间:2018-09-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

【演讲实录】下一代企业级应用架构管理体系

在IT系统的建设和管理中,敏态和稳态似乎不可协调的两个问题,那么在企业IT系统的管理中,如何根据需求去合理管控,今天将通过王璞老师在第七届数据技术嘉年华上的分享...

34250
来自专栏EAWorld

【超详解PPT】元数据驱动的微服务架构(下)

上次分享了两个部分:微服务架构需要元数据,微服务与元数据的关系,那么微服务中的元数据中具体如何应用,有哪些应用场景?我们接下来看一下——微服务中元数据的价值...

37630
来自专栏云计算D1net

混合云平台为何更适合现代应用开发

混合云平台,即云和本地系统的混合,能够为大型企业和遗留环境中的开发团队提供一些他们一直想要的东西:那就是与整个开发领域以相同的节奏一起进步的能力。这其中最难的部...

34540
来自专栏互联网杂技

前端工程师是怎样一种职业

前端工程师已经是大家不再陌生的一个软件行业的工种了,尽管这一工种诞生也没几年。作为一名从业三年的前端工程师,我尝试结合业界标准与我的理解,来尽可能诠释一下前端工...

39560
来自专栏ATYUN订阅号

【业界】当前的深度学习框架不会改变机器学习的能力增长

框架只是在应用程序中广泛采用机器学习的中间步骤。我们需要的是更多的视觉产品,而这些可能还需要几年的时间。 ? 当前的机器学习(ML)框架是ML的产品化过程中需要...

29240
来自专栏数据之美

转转数据平台从 0 到 1 的演进与实践

1、背景 在转转开始大数据平台建设之前,整个数据从需求提出到研发流程再到数据报表、数据产品,也是经历过一段非常混沌的时期,而且效率和质量往往很难得到保障,主要表...

29660
来自专栏ThoughtWorks

实践中的精益产品设计 | TW洞见

今日洞见 文章作者来自ThoughtWorks:Natalie Hollier,译者来自:田萌。图片来自网络。 感谢ThoughtWorks校对小组:宋国强、杨...

35590
来自专栏云计算D1net

IaaS供应商选择:传统应用 VS. 云原生应用

随着IaaS供应商们不断扩展其产品组合并提供包括更高级别服务在内的产品,用户应用的需求(不仅仅只是用户的基础设施)也成为了选择供应商的考虑因素之一。 在多年的犹...

31860
来自专栏BestSDK

系统剖析“夺宝类”产品设计方案,他们都有一个重要共同点

一、夺宝产品形态 夺宝产品和其他产品一样,有H5站、PC站、APP应用三种形态,三种形态的应用情景不尽相同。 ? 夺宝H5站主要应用于以下情况中: 1)最小成本...

38970
来自专栏Java架构师学习

如何从一个优秀的Java程序员变成一个高薪架构师

做了4年的java程序员,一直考虑以后的发展方向。感觉不适合走管理路线的人,所以考虑继续在技术方面深入下去。 相信好多程序员都有相同的感觉,做了好多年代码民工,...

30850

扫码关注云+社区

领取腾讯云代金券