作為一名程序員，在編程中，難免會遇到很多坑。小編有過幾年的編程經(jīng)歷，這中間為自己為別人挖過很多坑，也踩過別人的坑，幫別人填過坑。作為一名過來人，我把自己踩坑的經(jīng)驗總結(jié)一下，讓大家參考一下，或許能避免一些坑。
1.任何修改都要經(jīng)過測試才可以上線
小編有次在投產(chǎn)上線前發(fā)現(xiàn)自己的代碼有bug,由于時間緊迫，小編改完后閱讀了下代碼自認為沒有問題了，自測都沒有進行，就把代碼提交上線了。
結(jié)果第二天用戶使用這個功能時，直接報錯了，只得當天晚上重啟服務(wù)器放上經(jīng)過測試的代碼。
此事被大領(lǐng)導通報批評，連累項目經(jīng)理一起挨批。
2.sql防注入是最基本的常識
小編剛開始做項目的時候，看到項目組中有把入?yún)⑵唇釉?code>sql中，沒有采用預(yù)編譯的方式輸入?yún)?shù)，小編也跟著這樣寫。
而這些接口都是通過外網(wǎng)手機app端來調(diào)用的，危險性瞬間提高。
部門的安全組及時掃描識別出這些問題，小編花了整整一個元旦的假期才把這些sql拼接參數(shù)的代碼換成預(yù)編譯的方式，還改錯了一個接口，還好修復(fù)完后沒有大礙。
sql注入是一件極其危險的事情，使用預(yù)編譯的方式避免sql注入是最有效的方式之一。當然，除了sql注入，還有命令注入等等注入。
3.編程的關(guān)鍵在于解耦以及可讀性
小編之前的老板教小編，好的代碼一定要具有良好的可讀性，可讀性是可維護性的基礎(chǔ)。
小編寫代碼的時候就琢磨，這個類，這個方法，這個變量起什么名字好呢？好的代碼是具有自解釋的能力。
小編在維護之前同事的代碼時，發(fā)現(xiàn)有的同事的代碼寫得又臭又長，變量有時是a1,a2,a3之類的。明明是個新增方法，偏偏用get開頭；有的同事用魔鬼數(shù)字，看得小編莫名其妙。
解耦性呢，就是我做我該做的事情，你做你該做的事情，互不干涉內(nèi)政，各自應(yīng)對變化。
比如說大家繼承了一個類或者實現(xiàn)了一個接口，就各自做好自己本分的工作就好了。
又比如說一個復(fù)雜的邏輯，可以分拆成多個子邏輯，每個子邏輯就解耦開來，修改一個方法，不會影響另一個方法的使用，方法的復(fù)雜度也降低了。
4.盡量不要重復(fù)造輪子
有的類或者jar包已經(jīng)被廣泛應(yīng)用，沒有什么問題了，自己有空研究就好，沒有必要再寫一個了。
之前小編做一個導入的功能時，由于要入庫的數(shù)據(jù)很大，需要對集合分割分批導入。
小編就寫了一個分割集合的方法，經(jīng)項目另外一個同事的提醒，發(fā)現(xiàn)系統(tǒng)引入的開源jar包中已經(jīng)有這個方法了，直接導包使用就行了。
集合的分組，過濾，list轉(zhuǎn)map,list對象提取屬性等使用java 8 的項目都可以通過java8的流來操作。
5.數(shù)據(jù)庫建表要盡量遵循數(shù)據(jù)庫表的范式
小編的項目組發(fā)現(xiàn)很多表都建立了不必要的冗余字段，比如名稱這些。
當用戶修改了基表的數(shù)據(jù)時，業(yè)務(wù)表的名稱數(shù)據(jù)又沒有修改過來，而查詢的時候卻不是關(guān)聯(lián)基表去查詢名稱字段的，導致用戶兩邊看到的數(shù)據(jù)不一致。
維護這些數(shù)據(jù)和修改查詢功能花費了小編大量的時間。
6.盡量不要答應(yīng)業(yè)務(wù)直接在后臺數(shù)據(jù)庫導數(shù)入庫
數(shù)據(jù)庫導入數(shù)繞過了代碼邏輯，沒有經(jīng)過代碼邏輯的攔截和業(yè)務(wù)規(guī)則的校驗，有可能導致不合法的數(shù)據(jù)入庫，甚至影響正常的業(yè)務(wù)流程。
而且導入的數(shù)據(jù)往往數(shù)量巨大，更加重的之后的維護成本。之前小編做的功能也導入過大量歷史存量數(shù)據(jù)，結(jié)果這些數(shù)據(jù)很多有問題。
導完這些數(shù)據(jù)后，用戶發(fā)現(xiàn)對現(xiàn)有的使用造成了影響，不得不一筆筆向業(yè)務(wù)確認，重新刷數(shù)，真是心累。
那么有想了解SQL數(shù)據(jù)庫的同學，可以看一下教程
SQL教程：http://m.hgci.cn/sql/
