所以在开发过程中，如果可以将业务流程拆分成多个组件模型 ， 组件和组件配合完成一个完成的业务流程；当业务发生变化或有新业务的时候，只需要重新编排这些组件，或对某一个组件做少量更改，就可以满足业务变化；如果能做到这个程度，也是非常不容易的 。
在这个过程中，你需要做到高内聚低耦合，避免过度抽象 ， 从业务流程和动机出发，已满足业务需要为主；既然做不了“科学家”，我们就努力把业务代码写好把 。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注 。
首先，我认为写业务代码不“low” ， 但是大部分不假思索拷贝粘贴的业务代码比较“low” ， 换句话说就是所谓的五年工作经验就是把第一年的工作重复了五遍 。
技术人员成长一般有两条线，一条是成为技术专家，一条是成为领域专家 。所谓的转管理我理解也就是领域专家，毕竟不懂得领域知识是无法做好管理的，比如说你是互联网金融某个业务部门的leader，那么你肯定要懂金融 。领域知识就是在不断的写业务代码和思考中积累起来 。
还有一个问题就是如何定义业务，比如说“实现一个修改订单功能”，这是一个业务需求，看起来很low，但是如果业务需求改成“实现一个修改订单功能 ， 要求在有限资源的情况下并发10k，响应时间不高于10ms”，那这个需求就有挑战 。说这个问题想说明白一件事情，如果做业务不要停留的在业务表面，仅仅满足于实现功能，要主动思考 。
最后总结一下，没有最好的技术，只有最适合业务的技术 。技术是内功，业务是招式，内功不足，后续成长乏力，没有招式，内功也不能发挥威力 。这是也很多互联网创业公司做大了之后要技术转型的原因 。
业务程序开发相对于底层基础架构层的程序开发有所不同：
业务开发的时间比较紧，变化快 。
这个特点导致程序员没有时间重构代码，或者不愿意重构代码，而是用最简单粗暴的复制黏贴的方式快速实现业务逻辑 。其实所有的复制黏贴都意味着需要重构 。
底层系统的开发，一般是架构师和高级程序员来设计和控制项目时间 。相对来说，开发周期长 ， 变化缓慢 。会更加注重架构的合理性和稳定性 ， 而且会不断重构和改进 。
业务开发一旦完成，只要平稳运行就不会有人再回来补技术债务，不会把它写得更好 。除非这个业务爆发了 ， 不得不从新架构以支持更高的并发 。如果上线之后表现不佳，很可能下线不再维护 。所以公司也不太愿意花太多精力在一个还没有被市场认可的产品项目上 。
而底层架构框架的项目会在不同的产品项目中不断应用 。不断地进化 。就像Spring之类的开源框架一样，不断的升级和完善 。
相对来说 ， 业务开发程序员会花大量的时间学习和理解业务知识；而底层框架程序员更多的时间在学习技术架构 。如果业务知识在行业内通用，比如财务，金融行 。那么长期的积累对业务开发也是很有帮助的 。如果业务是很小众的 ， 甚至，这几个月做这个业务，下半年又做另一个业务，做的时候也一知半解，就像很多外包一样，那就没有什么业务沉淀了 。
我就是写业务代码的，不过我觉得这很正常啊，不知道你是怎么就觉得low啦？
所以，做为一个企业 ， 支撑发展的肯定是他的业务，不管是卖什么服务 ， 都要通过业务来赚钱 ， 可能针对业务，企业内部还会做一些细化 。比如说 ， 有人会是做一些前端 ， 一些人做后端 ， 还有运维，运营，产品的配合 。前端再细化 ， 一部分人会做一些页面的展示，呈现，还有一部分人会做一些适合业务的工具，来提升开发效率 。
推荐阅读
- 如何跳转到公众号关注，跳转到公众号关注页面
- 包含佛山sap维护服务的词条
- 电视屏坏了怎么保修呢，电视屏坏了在保修范围内么
- 直播年终活动宣传文案，直播活动宣传语言
- c语言范围内缺失函数 c语言函数缺省
- 电商平台如何策划，电商平台策划方案
- 模拟裁判评分java代码，模拟裁判测试
- java的修改密码代码 java程序编写修改密码
- asp.net书籍文献，aspnet web开发 书籍