这么一解释 ， 我们就立刻明白了；所以如果java只会写业务代码你不明白业务的时候，看着需求敲代码也是非常容易出错的 。
有些人会认为业务逻辑就是一堆 if-else ， 但是我认为在实际工作中，这些 if-else 也是非常难做到的 。
业务逻辑是人设计的，业务逻辑难不可怕 ， 可怕的是它不严谨和变化快；业务逻辑和那些确定性的东西不一样，比如我们写好的代码 if-else 两个分支，那么再怎么也不会跳出这个范围，业务逻辑就不一样了，它是非常灵活的、不确定的 ， 业务机会来的快消失的也快，我们很难开发出来一套全面的、完善的、灵活的的系统，去应对将来可能会发生的需求 。
所以在开发过程中，如果可以将业务流程拆分成多个组件模型，组件和组件配合完成一个完成的业务流程；当业务发生变化或有新业务的时候，只需要重新编排这些组件，或对某一个组件做少量更改 ， 就可以满足业务变化；如果能做到这个程度，也是非常不容易的 。
在这个过程中，你需要做到高内聚低耦合，避免过度抽象，从业务流程和动机出发，已满足业务需要为主；既然做不了“科学家”，我们就努力把业务代码写好把 。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解 ， 希望能得到你的关注 。
首先，我认为写业务代码不“low” ， 但是大部分不假思索拷贝粘贴的业务代码比较“low”，换句话说就是所谓的五年工作经验就是把第一年的工作重复了五遍 。
技术人员成长一般有两条线，一条是成为技术专家，一条是成为领域专家 。所谓的转管理我理解也就是领域专家，毕竟不懂得领域知识是无法做好管理的，比如说你是互联网金融某个业务部门的leader ， 那么你肯定要懂金融 。领域知识就是在不断的写业务代码和思考中积累起来 。
还有一个问题就是如何定义业务，比如说“实现一个修改订单功能”，这是一个业务需求，看起来很low，但是如果业务需求改成“实现一个修改订单功能，要求在有限资源的情况下并发10k ， 响应时间不高于10ms”，那这个需求就有挑战 。说这个问题想说明白一件事情 ， 如果做业务不要停留的在业务表面，仅仅满足于实现功能 ， 要主动思考 。
最后总结一下，没有最好的技术 ， 只有最适合业务的技术 。技术是内功 ， 业务是招式，内功不足，后续成长乏力，没有招式，内功也不能发挥威力 。这是也很多互联网创业公司做大了之后要技术转型的原因 。
业务程序开发相对于底层基础架构层的程序开发有所不同：
业务开发的时间比较紧，变化快 。
这个特点导致程序员没有时间重构代码，或者不愿意重构代码 ， 而是用最简单粗暴的复制黏贴的方式快速实现业务逻辑 。其实所有的复制黏贴都意味着需要重构 。
底层系统的开发，一般是架构师和高级程序员来设计和控制项目时间 。相对来说，开发周期长，变化缓慢 。会更加注重架构的合理性和稳定性，而且会不断重构和改进 。
业务开发一旦完成，只要平稳运行就不会有人再回来补技术债务，不会把它写得更好 。除非这个业务爆发了，不得不从新架构以支持更高的并发 。如果上线之后表现不佳，很可能下线不再维护 。所以公司也不太愿意花太多精力在一个还没有被市场认可的产品项目上 。
而底层架构框架的项目会在不同的产品项目中不断应用 。不断地进化 。就像Spring之类的开源框架一样，不断的升级和完善 。
推荐阅读
- 竞技游戏招聘，游戏招聘平台
- oracle索引物理存储结构，oracle的索引是什么数据结构
- 2070适合搭配什么cpu，2070显卡配什么cpu性价比最高
- gis整形要素未响应，arcmap整形要素工具不能用
- go语言=赋值 go语言赋值语句
- 安卓平板音乐界面在哪，安卓平板音乐播放软件
- 黄浦区网络软件服务代理商，上海软件服务
- 好玩儿的竞技游戏，好玩的竞技游戏排行榜前十名
- linux回根目录命令 linux回到根目录的命令