在之前开发一套公司内部系统时一方面时间紧前期工作准备不充分，另一方面也在业务对接及编码工作的规范上做得不是很好导致了这套系统仅停留在能用的状态下。
其中最大的问题就是拓展性了。整个开发整体使用的是：
SpringBoot + shiro + MyBatis + easyPoi + Layui + MySQL5.7(后续升级为8.0) + redis + RabbitMQ 的模式。
前后端无分离。这些其实都是还好的，问题就在于代码中存在不少的硬编码，这就导致了对后续业务拓展支持的不友好！
PS: 能把锅推到敏捷开发上吗？不！还不是因为自己菜！！！
最近业务有些许变更，于是这些硬编码部分就整体出问题了：不，我们不支持这样子的！
但是业务是不能停下来等人的，加之项目的重构排期比较靠后，所以暂时只能在原有系统上进行调整。
这里提到的硬编码不是计算机的硬编码处理，而是软件编程时代码层面的硬编码（简单来说就是死板不支持变通的代码）。
PS: 仅为伪代码示例,意思一下就可以了！
① 条件处理上的硬编码
if("单据检查完成".equals(orderState)){
System.out.println("XXX单据检查完成了！");
}
② 信息处理上的硬编码
if(true){
System.out.println("小明已经完成了任务A！");
}
Java
③ 返回值上的硬编码
if("小明".equals(name){
return "主管职位";
}
Java
④ 属性值上的硬编码
String orderAddUrl = "http://baigedu.com:8080/order/add";
Java
PS: 简单以上述四种情况为例。
① 容易产生条件不匹配的情况导致无法进入条件
比如：项目换人维护了或与前端对接时，他在调用的时候写的是“单机检察完成”
② 这个任务只能是小明完成的？小明在这里只能完成任务A？小华我要完成任务B！
③ 小明：我这辈子就只能是个小主管？瞧谁不起呢！
④ 百个度：我们项目调整了，现在这个接口改成了：
Http://baigedu.com:8089/orderAdd
硬编码的不好之处竟恐怖如斯！
PS: 同时我们也不能单一的认为硬编码是不好的。在写单元测试时不来个硬编码，在一些定值上（男、女、未知），快速开发时硬编码还是有作用的，只是说正式开发中可能会存在一些坏味道...
因为系统的每一个模块都有经手，所以问题存在之处的整理工作倒是并不复杂。
因为一些客观问题本次也只能消除90%的硬编码部分，整个项目的完善就暂时寄托于后续的项目重构了。同时这90%的硬编码改造已经能满足当下需求及后续比较友好的拓展性，本着不追求极端完美主义的想法加之整个改进的些许心得遂有此文。
以上情景二如果把 name 和 task 都作为入参来处理，那很轻易的实现诸如：小花完成了任务C这项功能。
枚举类是对拓展友好的，同时也能规范数据。上述场景一中把状态写成枚举类就能很轻松的解决状态错误及状态拓展问题！
PS: 千万不要把枚举类直接给到前端，因为不讲码德！
以SpingBoot为例，我们可以把一些使用比较多且不易该的属性配置的Xml或者Yml中，然后再代码中使用@Value注解来使用！
这样场景四种的不管怎么变我们都可以直接在配置文件中修改，而且只修改一处！
PS: @Value注解不能使用static修饰
在上述场景三种，我们可以把小明的信息配置到数据库中，然后再使用时读取数据库信息。这样小明以后升职加薪出任CEO迎娶白富美都没有问题。
（小明的肯定！）
其实整体来说这些都是不好的编码习惯或仅考虑到当下而没有对后续的拓展做容错而导致的。
希望我们都能写出一手漂亮的代码，做一个讲码德的好开发！
PS: 代码整洁之道的熟读都应该提上日程了哈！！！
