1. 軟件質量

如何評價一款軟件的質量呢（software quality）？通常情況下，我們會從“外部質量”和“內部質量”兩個方面進行考量。

外部質量：外部質量通常是從用戶的角度進行考量，例如軟件功能是否正確，軟件的性能Performance，軟件的可用性和安全性等。

內部質量：內部質量是從開發人員的角度進行考量，例如代碼的可讀性，是否易於維護，是否具有良好的擴展性，複用性，是否易於測試等等。

外部質量是容易被管理團隊發現的，例如軟件功能的缺陷，性能的低下等。但內部質量相對隱蔽，對於一般的項目管理團隊是一個黑箱，但內部質量對於一個軟件確是十分關鍵的，如果一款軟件的內部質量低，當發生需求變更或是功能擴展時，將會是一場惡夢。

2. 技術債

在軟件實現過程中所遺留下的低質量的代碼，可以視爲這款軟件在技術上虧欠的“技術債”。

我們知道，“出來混早晚是要還的”，欠下的技術債，會一點一滴的積累，如果不及時解決，則一定會爆發出嚴重的後果。

正如破窗效應（Broken Window Effect）那樣，如果放任代碼中的技術債持續存在，那麼代碼的質量將會持續下降，直到代碼變得無法維護。

持續低下的內部質量將會顯現到外部質量上，例如微小功能的改動都可能導致各種無法預測的問題，軟件功能變得脆弱無比。

積累的“技術債”，也會直接降低軟件開發的效率，越來越多的時間和人力不得不被投入到運維和缺陷的修復上，甚至會出現“修不完的bugs”(修復某一功能的代碼，又導致了另一個功能上的bug)，如果出現在這種情形，軟件基本不要奢望任何新功能的擴展了。

3."技術債"的成因

爲啥會出現“技術債”？技術債堆積的代碼往往是哪些“時間緊，任務重”的代碼，例如要在最短的時間內，儘快的上線某一功能，這樣情況下的程序，其最大特點就是“埋了很多雷”。

欠了銀行錢要付利息，欠下的“技術債”要靠不斷的重構和re-design來支付其時間上的利息，如果欠下的債務超出了“償還能力”，那這個軟件也基本就到了“無法運維”的境地了。

4. 避免欠下"技術債"

可以說“技術債”等同於向未來借時間，如果技術債持續的積累，那麼要解決其帶來問題的時間也會被持續的放大，如果銀行的複利累積一樣。

因此，在編碼過程中，就要盡力避免留有“技術債”，這也就引申到另一個重要的概念Clean Code，也即代碼整潔之道，在開發團隊中要形成“代碼整潔、規範”的良好風氣，有明確的guideline，明確的check-point和criteria，並通過Pair Programming結對編程，代碼review等方式來確保代碼質量，讓團隊的每一位成員都意識到自身所擔負的責任。

一以貫之的優秀代碼質量也會帶來持續的“正向反饋”，例如軟件的已有功能會是成熟的，穩定的，並且容易添加新的功能；同時對於開發人員，其運維代碼時也會變得less pressure，並且對代碼很有信心。

對於遺留的技術債，不要放任不管，自暴自棄，要儘早制定計劃並預留相應的effort來解決這部分問題，控制問題的影響面，因爲這不僅僅是對軟件質量的控制，更是對整個項目或軟件的風險控制。