以互联网公司发展的速度，老项目被新项目替代，新需求不满足老的设计原理，是考虑新开一个项目呢，还是在原有的项目中进行范围性改造满足现有需求呢
如果你选择新开一个项目，首先需要梳理项目流程，然后抽象业务需求，再基于前人的肩膀上选择一些适用的框架和技术。
在此跟大家多说一句，重构的时候好多前辈都说只有适合的技术才是重构需要，不要去追寻那些前沿的新奇的还不是很成熟的技术，其实这种话听着挺有道理的，比如：有A框架和B框架，A简单易上手轻便，但是相比较B而言，有可能在高可用，熔断，限流等一些技术上要差一些。有的人可能就要说了如果A能满足现有得业务需求，应该选A，但是作为一个技术人员相信每一个人都想去学习一些新的技术，简单方便的工具固然能让大部分人爱上它，但是相比较自行车人们为啥还是更爱小轿车。
相同的原理每个技术人都愿意将自己的小米步枪换成飞机大炮，在使用B框架的过程中我们能够去学习他的复杂原理，了解他的熔断啊，限流啊一些牛逼点的技术，虽然对现在的业务有一种大材小用的感觉，但是一切的一切都是值得的。
在选定B框架之后我们需要去调研她，首先要知道在她的基础上能实现哪些功能，是否满足我们的需求，满足需求的基础上我们还要知道哪些可以更方便我们去管理该系统，如果我们只是用她的最简单的一些功能又何必辛辛苦苦去研究一个复杂的系统呢。当你要异步发消息的时候会想我要用kafka，因为她比mq更新，她是现在技术的主流，如果你只是用她发一些简单的配置数据，或者你们的业务流量寥寥无几，我劝你还是用rabbitmq吧，何必呢，kafka的高吞吐量根本感觉不出来，当你对使用几个线程去消费信息都不在意的时候，在你手里mq跟kafka毫无二至。既然我们选择了kafka 我们就要去了解她的原理，broker，partition，offset，group等等难道不能引起我们的注目礼嘛，这也是我推荐大家用新技术的目的。
用只是谋生 的手段，学习才是我们进步的阶梯
如果以上步骤走完了，接下来就是设计开发的事情了。面向对象讲了好多年了，正好应该是我们发挥自己才能的机会，最基本的几个原则要遵守吧，可维护，可扩展，可开放，OCP。。说起来简单，做起来比较难，总有你没有考虑到的地方。人不是上帝，但是是上帝的制造者。那咱们一步一步来造上帝吧，抽象业务需求的时候你总会发现他们有着很多的共同点，他们有着重合的属性，那我们避免重复性代码
1.避免重复代码
2.减少巨大类和方法
3.逻辑控制尽量简单
4.尽量抽象，能不暴露的属性尽量不要暴露
5.多加一些注释，不能只写代码，而不让别人看代码吧～