程序员如何避免写过多的业务逻辑代码?


题主提出这个问题非常好 。该问题是绝大部分程序员学习过程中都会遇到的困惑 。这个阶段的选择很大程度上决定自己今后职业生涯的发展方向 。小编建议你先踏踏实实把业务逻辑代码写好 。然后再寻求技术方面的突破 。

程序员如何避免写过多的业务逻辑代码?

文章插图
究其本质 。技术是工具 。业务是根本 。技术为业务服务 。业务促进技术发展 。小编结合自身及周边同事的经历总结出了一点浅薄认识分享给大家 。以供参考 。
此问题要从程序员发展必经的几个阶段说起 。
首先是入门阶段 。立下flag要在编程领域有一番作为 。于是苦读了编程相关书籍 。也选择了一门开发语言 。并且能把书本上的示例程序使用编译器正确的运行出来 。假如让写一个100以内口算的小程序 。十有八九会写不出来 。主要原因还是没有具备编程思维 。形象点来说就是你手里现在有把刀 。到底是用来杀猪还是宰羊 。还是削水果 。自己也没想好 。
程序员如何避免写过多的业务逻辑代码?

文章插图
可用一句话来形容这个阶段 。“路漫漫兮其修远 。吾将上下而求索” 。
其次是上道阶段 。基本上就是刚参加工作那阵 。每完成一个需求或者解决一个问题 。都有很成就感 。项目组中能解决各种疑难杂症的大神让自己崇拜的五体投地 。随着工作年限的增长对业务也越来越熟练 。已掌握的技术足以应付绝大部分业务场景 。时间久了就会有与题主类似的困惑 。
程序员如何避免写过多的业务逻辑代码?

文章插图
再往后发展就涉及到职业生涯规划 。一是业务专家 。跟随行业发展方向 。深耕业务细节 。进可跳到甲方 。退可做产品经理 。二是技术专家 。业务在熟悉业务细节的同时提高自己的技术深度和广度 。掌握产品的底层细节原理是必要条件 。多接触不同的编程语言 。做到一主多从地步 。项目经理、架构师都是可选择的岗位 。三是转向管理或销售岗位 。充分利用自己的技术背景 。也能做出一番成绩 。
这个阶段也可用一句话来概括 。“众里寻他千百度 。蓦然回首 。那人却在灯火阑珊处 。”
然后是高手阶段 。到了这个阶段 。你会发现技术不再是你解决问题的障碍 。只要有利于解决问题 。短时间内可让各种编程语言和框架齐上阵 。相应地你完成了从具体执行者到整体设计者角色转变 。
“手中无剑 。心中有剑”是对此阶段最好的形容 。
程序员如何避免写过多的业务逻辑代码?

文章插图
最后再强调一下业务的重要性 。现在大家接触到的各种技术框架 。标准库等都是为解决特定的业务场景而生的 。我所在的证券交易更是有“七分业务 。三分技术”之说 。总之 。技术和业务的关系与鸡和蛋关系类似 。
程序员如何避免写过多的业务逻辑代码?

文章插图
我是@代码Go说科技。码农的视角看科技 。带给大家不一样的感受 。欢迎大家阅读评论转发加关注 。
声明:图片来自网络 。如有侵权 。联系必删!
【程序员如何避免写过多的业务逻辑代码?】其他观点:
业务代码是技术产品化的关键 。是实现需求最直接的部分 。脱离了业务 。再牛逼的基础代码 。框架代码 。构件代码……都是一文不值 。它们无法成就产品 。
程序员如何避免写过多的业务逻辑代码?

文章插图
实际开发中 。大多数公司 。大多数程序员 。都是在写业务代码 。对产品来说 。应用是业务 。对方案来说 。功能接口是业务 。所以很多人总觉得自己所处位置较为低端 。不在技术核心范筹 。容易被别人替代 。也难和新生力量竞争 。因为新生力量更年轻 。更精力丰富 。
程序员如何避免写过多的业务逻辑代码?

文章插图
可替代性高 。技术含量不高 。更新迭代快 。使这部分程序员不安 。小编认为 。业务不精 。思维能力不强 。学习进步能力不高 。才是不安的关键 。
程序员如何避免写过多的业务逻辑代码?

文章插图
有主动想过优化业务吗?有了解过同行或同类优秀产品的业务吗?有参考学习优质开源业务吗?有分析总结过业务和平台(系统)的对接关联吗?有深入了解业务的本质吗?
程序员如何避免写过多的业务逻辑代码?

文章插图
谢谢大家 。
其他观点:

推荐阅读