一、背景
1.1、時間緊任務重
在之前開發一套公司內部系統時一方面時間緊前期工作準備不充分，另一方面也在業務對接及編碼工作的規范上做得不是很好導致了這套系統僅停留在能用的狀態下。
1.2、拓展不友好
其中最大的問題就是拓展性了。整個開發整體使用的是：
SpringBoot + shiro + MyBatis + easyPoi + Layui + MySQL5.7(后續升級為8.0) + redis + RabbitMQ 的模式。
前后端無分離。這些其實都是還好的，問題就在于代碼中存在不少的硬編碼，這就導致了對后續業務拓展支持的不友好！
PS: 能把鍋推到敏捷開發上嗎？不！還不是因為自己菜！??！
1.3、該來的總歸是要來的
最近業務有些許變更，于是這些硬編碼部分就整體出問題了：不，我們不支持這樣子的！
但是業務是不能停下來等人的，加之項目的重構排期比較靠后，所以暫時只能在原有系統上進行調整。
二、關于硬編碼
2.1、什么是硬編碼
這里提到的硬編碼不是計算機的硬編碼處理，而是軟件編程時代碼層面的硬編碼（簡單來說就是死板不支持變通的代碼）。
2.2、常見的硬編碼示例
PS: 僅為偽代碼示例,意思一下就可以了！
① 條件處理上的硬編碼
if("單據檢查完成".equals(orderState)){
System.out.println("XXX單據檢查完成了！");
}
JAVA
② 信息處理上的硬編碼
if(true){
System.out.println("小明已經完成了任務A！");
}
Java
③ 返回值上的硬編碼
if("小明".equals(name){
return "主管職位";
}
Java
④ 屬性值上的硬編碼
String orderAddUrl = "http://baigedu.com:8080/order/add";
Java
2.3、硬編碼所帶來的一系列困擾
PS: 簡單以上述四種情況為例。
① 容易產生條件不匹配的情況導致無法進入條件
比如：項目換人維護了或與前端對接時，他在調用的時候寫的是“單機檢察完成”
② 這個任務只能是小明完成的？小明在這里只能完成任務A？小華我要完成任務B！
③ 小明：我這輩子就只能是個小主管？瞧誰不起呢！
④ 百個度：我們項目調整了，現在這個接口改成了：
Http://baigedu.com:8089/orderAdd
2.4、綜上所述
硬編碼的不好之處竟恐怖如斯！
PS: 同時我們也不能單一的認為硬編碼是不好的。在寫單元測試時不來個硬編碼，在一些定值上（男、女、未知），快速開發時硬編碼還是有作用的，只是說正式開發中可能會存在一些壞味道...
三、應對性處理
3.1、遍尋硬編碼遺留
因為系統的每一個模塊都有經手，所以問題存在之處的整理工作倒是并不復雜。
3.2、硬編碼模塊重構
因為一些客觀問題本次也只能消除90%的硬編碼部分，整個項目的完善就暫時寄托于后續的項目重構了。同時這90%的硬編碼改造已經能滿足當下需求及后續比較友好的拓展性，本著不追求極端完美主義的想法加之整個改進的些許心得遂有此文。
三、規避硬編碼的一些常用方法
3.1、拒絕定值，使用參數傳遞
以上情景二如果把 name 和 task 都作為入參來處理，那很輕易的實現諸如：小花完成了任務C這項功能。
3.2、枚舉類
枚舉類是對拓展友好的，同時也能規范數據。上述場景一中把狀態寫成枚舉類就能很輕松的解決狀態錯誤及狀態拓展問題！
PS: 千萬不要把枚舉類直接給到前端，因為不講碼德！
3.3、配置文件
以SpingBoot為例，我們可以把一些使用比較多且不易該的屬性配置的Xml或者Yml中，然后再代碼中使用@Value注解來使用！
這樣場景四種的不管怎么變我們都可以直接在配置文件中修改，而且只修改一處！
PS: @Value注解不能使用static修飾
3.4、數據庫配置
在上述場景三種，我們可以把小明的信息配置到數據庫中，然后再使用時讀取數據庫信息。這樣小明以后升職加薪出任CEO迎娶白富美都沒有問題。
（小明的肯定?。?/p>
四、后記
其實整體來說這些都是不好的編碼習慣或僅考慮到當下而沒有對后續的拓展做容錯而導致的。
希望我們都能寫出一手漂亮的代碼，做一個講碼德的好開發！
PS: 代碼整潔之道的熟讀都應該提上日程了哈?。?！
