十一假期的第一天，拖完地、洗完衣服，看了一會《The clean code》，想到了一些問題，決定蒐集資料對劣質代碼是如何產生的整理一番，於是這個上午就寫了這篇博文。
一、理論知識匱乏
1、複製粘貼
先從實習生說起。這幫熊孩子剛畢業後，在對生產環境還不瞭解的情況下，爲了完成工作。於是，就從項目中其他的地方複製類似代碼，然後修改。如此，大概半年後，就會覺得自己似乎已經無所不能了，即便再學習，也是要趕些時髦玩玩HTML5、芒果DB什麼的（要不然出去如何開口是好）。可惜的是，鮮有人會告訴他們長期這麼做無異於自毀。可話說回來，誰管你幹嘛呢？用你的人只關心項目進度。
回到話題，有一種觀點認爲Copy/Paste效率更高，並且認爲這樣做對於程序員的水平要求較低，組建團隊相對容易。但是，從項目的角度講，這樣做會讓錯誤蔓延，從而引起更多的代碼問題以致影響發佈時間，降低質量。從程序員的角度講…沒什麼好講的，既然懶得自己寫，我覺得回家賣水果或許是個更好的選擇。
2、按照流程圖實現代碼
有一些項目經理會採用流程圖的方式進行代碼設計，開發人員會認爲只要照着邏輯流程圖實現代碼即可。但是，採用流程圖進行代碼設計時會誤導開發人員把對象關係、抽象等放在次要地位，這種設計方式容易導致圈複雜度增高，而圈複雜度的提高會導致BUG增多。
3、臨時對策
有些開發人員在時間壓力下，對於一些代碼變更的要求採取了臨時對策，並且認爲這種臨時對策即使留在代碼中也沒有什麼問題，目前的首要任務是完成更多的功能。想一想，自己有沒有在某個時刻爲了解決某一問題，採取了某一臨時對策？
然而，這種臨時對策往往會形成技術債務，當技術債務積累到一定程度時，就要開始還債了。畢竟，出來混都是要還的，利息還很高…
4、定式思維
我們在初學某種技術時會參照一些例子，一旦遇到某種和例子相似的情況就會按照例子的方式來進行書寫。這是一種快速的學習方法。然而，如果對於所有的情況都按照例子的情況來書寫而不敢突破的話，代碼就未必能保持最佳風格。
舉幾個問題，這幾個問題我先不解釋，如果有興趣，可以迴應一下：
（1）動作一定是方法嗎？
（2）狀態只能採用整數定義嗎？
（3）for循環一定要有下標嗎？二、對編程語言不熟悉
這個很基礎，是本，沒什麼需要講的，但是不能忽視。比如Java，現在都已經Java8了，其中的許多特性我們未必懂，整天搞來搞去可能就那麼幾點。其實，Java的使用還是有許多技巧的，推薦讀一讀《Effective Java》.
三、對開發環境不熟悉
由於對開發環境不夠熟悉，有很多很方便、很快捷的功能沒有得到良好的利用，以致花了大量的人工去完成機器可能幾秒就可以完成的工作。畢竟，工欲善其事，必先利其器。思考一下，如果有以下幾種操作，在你的IDE上應該如何實現：
（1）光標的操作
（2）Refactor
（3）添加插件
（4）自動引入外部庫
（5）查看外部源代碼四、對設計方法不瞭解
對於這個問題，我們首先思考一下，是誰把我們這一行變成了“碼農”？是我們自己。由於任務劃分等管理方面的原因，開發人員被定爲爲依靠別人的設計進行代碼加工的“碼農”，以至於開發人員很少能夠思考設計方面的事情，只是機械地堆砌代碼。可是，不要忘記了，編碼本是一種設計行爲，項目不僅是產品，更是我們自己的作品。婉約一點地講，不要因爲忙碌而忘記了初衷…
順便說一下常見的由於對設計不瞭解而造成的問題：
（1）重複與類似
（2）結構包不清晰
（3）類責任不明確
（4）常量數據類
（5）長方法
（6）複雜分支
（7）類膨脹項目中的問題遠比這個多，重要的是，我們在尋找方法解決問題的同時，也要避免自己犯下類似的錯誤。
五、編程方法不佳
爲了快速實現某個功能不顧現有架構，採用了臨時的解決方案。下面的這些常見的編程習慣將會造成技術債務：
（1）迷信IDE自動生成代碼
（2）命名習慣不好
（3）沒有管理好代碼的職責
（4）對照教材照本宣科
（5）不考慮調用時的樣子
（6）不設計就編碼六、英語能力不足
代碼的命名都是通過英文來進行。採用本地語言命名（包括俚語和俗語）會導致對應文化背景的讀者無法理解代碼的意思。但是由於英語不是母語，再加上不使用英語會導致開發人員在書寫代碼時無法正確使用英語，導致難以寫出高可讀性的代碼。
英語不好不是我們選擇中文拼音的理由，英語不好，我們就去學。
許多優秀的資料，也都是英語，所以還是補一補英語比較好。
七、管理人員誤導
1、形而上學的編碼規範
我相信每個公司都至少有一套編碼規範，我以前也提倡過，我和一些同學同事交流的時候，也有不少推崇的。
但是，推崇可以，不能把它當成一把無所不能的瑞士軍刀，有比沒有好，但是有了未必就是最好。
編碼規範的制定是爲了形成一種統一的編碼風格，從而保持代碼的整體一致性和質量。可是，我們可以看到，許多開發人員使用了編碼規範後，就認爲代碼的質量提升上去了，從而對被遮蔽的問題視而不見，或渾然不知。
我更喜歡的一句話是：風格上盡情的隨波逐流，原則上必須穩若磐石。
如果我們都能把代碼寫得一級棒，那代碼規範就可以壽終正寢了。
2、時間壓力下的催促
管理人員在時間的壓力下會催促編碼人員更快地完成工作。然而，速度更快往往意味着採用臨時方案，意味着對質量的放棄，欠下技術債務。
我們真的那麼着急嗎？就像人生那樣，我們都那麼着急結婚幹嘛呢？準備好婚後的人生了嗎?可是我們就這麼急。這方面最常聽的話就是，我們沒有那麼多的時間去想那些問題。
可是，我們不要忘了，如果我們在開發的時候急功近利，欠下的技術債務都將在未來變本加厲的加倍償還。在一個軟件的生命週期中，運維的時間要遠長於開發階段。就好比建造一座大廈，也許建造它只需要五年，可是它有可能要服務五十年，不能因爲某個領導要驗收就偷工減料草草了事。
當國內的某些食品或建築出現安全時，我們常常會不假情面的搬出道德和人倫的大旗對食品廠商和施工單位加以口誅筆伐。
可是，安靜地想一想，我們自己又怎麼樣呢？我們難道和他們不是一類人嗎？我們讓各位領導安心了，可是我們的心往哪裏安放？項目落地了，我們的臉也要跟着落地嗎？
3、過分限制開發人員
當開發人員認爲增加一個代理類可能會更好地解決這個問題時，管理人員卻提出不允許增加類；
當開發人員提出數據庫表的一些字段應該拆出去另作一個表，以降低耦合性的時候，管理人員卻提出不允許修改表結構；
當開發人員提出增加一個全局變量，使數據更容易傳遞時，管理人員卻提出不允許增加全局變量。
…
也許，上述行爲出於某些正當理由，但是，如果武斷地劃定範圍而不是對每個修改行爲進行探討時，就是一種懶人式的管理，是造成好的方法不能夠應用的障礙。
當本該管理項目的的管理人員對技術干預過多的時候，我們年紀輕輕的開發人員就會失去本該有的活力、積極性和創造力，最後和項目一起爛掉。
八、自己不想好了
如果知道了前面的種種問題後，仍然不去思考、不去改變，不想方設法做得更好，那就是我們自己的問題了。
如果我們現在不改，等到我們將來當上了項目管理人員，會害了手下的一幫兄弟，因爲我們其實不懂技術，卻還要在下屬面前裝一把（相信我，你一定會這麼幹的），還會讓項目和一些關係捆綁在一起，做事最後就成了“做人”。
拋開所有的立場，想一想，改變，可能嗎？
可是，什麼是劣質代碼呢？我寫的代碼都很棒啊？！
