這幾天看了看《硝煙中的Scrum和XP》，其中作者將產品質量分為兩種——“外部質量”和“內部質量”。作者認為，在項目工期緊的時候，外部質量是可以妥協的。而內部質量是不容妥協的。但是，哪些問題屬于內部質量呢？
作者并沒有詳細的論述這個問題。下面，我列出了一些常見的場景和劃分。你怎么看待這個問題呢？
外部質量
● 可擴展性
我一直認為，一個沒有明確的目標的可擴展性設計往往會變成過度設計。因此，我覺得可擴展性相關的質量問題應該作為外部質量看待。敏捷中強調 做的剛夠就好。
● 功能不完整的實現
有些時候，對某個功能模塊的實現中存在 明顯的 功能不完整。這一點我認為也是外部質量。因為，我們采用迭代式開發的目的就是可以逐漸的完成這個功能。但是，我認為這種功能不完整應該是 顯而易見 的。否則，我認為就屬于內部質量中的“邏輯嚴整性”和“語義清晰性”的問題了。
● 性能
性能優化往往會犧牲架構的簡單性和代碼的可維護性。而且，我個人認為從實際的產品角度來看，性能只有“能夠接受”和“不能接受”的差別，而沒有“好”和“不好”的差別。因此，我認為它是產品是否能夠驗收的一個重要指標。但不是一個我們應該時刻關注的質量問題。
內部質量
● 代碼規范
混亂的代碼意味著更加難以維護。劃分外部質量和內部質量的一個重要標準是：對產品的可維護性有很大影響的質量問題應該稱之為內部質量。因此，我認為代碼規范為“內部質量”。
● 設計和實現的邏輯嚴整性
例如：你設計了一個集合類，就應該確保集合的基本增刪改操作正確。你可以在集合的刪除操作中拋出“NotSupportException”或斷言錯誤以標示該集合是一個只增集合。但是，你不能通過忽略刪除方法的實現來達到同樣的目的。
另外一個邏輯嚴整性問題的例子是：Equals方法和GetHashCode方法實現上。你可以同時不實現這兩個方法。如果實現，就一定要實現正確。不能因為目前沒有需求將該對象作為Hashtable的Key，而忽略GetHashCode的實現。
一個邏輯上不嚴整的設計往往會對將來使用該模塊的開發人員造成誤導。 最終造成可維護性問題。因此參考上面的原則，我認為這一條應該歸為“內部質量”。
● 語義清晰性
這一條和“邏輯嚴整性”類似。不能在方法命名等地方出現語義上的不清晰。對將來的使用者造成誤導。
關于劃分原則的思考
● 對產品未來可維護性有影響的點應該歸為內部質量
正因為“可維護性”往往是一個不易被覺察的問題，我才覺得可維護性是團隊最應該關注的質量問題。是不能夠放棄的底線。相對而言，“可擴展性”和“可維護性”如此相似，卻恰恰相反，它看起來如此美妙。但，過度設計往往都是因為對“可擴展性”的追求而導致的。它反而是我們程序員應該時刻警惕的東西。
● 內部質量往往比較虛，而那些清晰明確的問題或目標個人認為歸為“外部質量”比較好。
人的精力是有限的，正因為這種有限性，讓我們需要建立一些簡單的原則來幫助我們將精力放在更重要的問題上。盡可能減少我們關注的范圍，會讓我們在這個范圍內做的更好。因此，我覺得應該盡可能的將那些顯而易見的問題排除出“內部質量”問題之外。這樣，我們才能夠更好的控制“內部質量”。那些顯而易見的問題，其實，往往都不是問題。
● 性能
這一點我一直很猶豫，因為往往一個不好的架構會導致難以修復的性能問題。但是，就這個話題而言。我還是更加傾向于將性能看做是外部質量。因為它往往是顯而易見的。產品的Master，Customer等等很多人會關注與這個問題上。很多時候，在產品前期準備的時候就已經提出了明確的性能要求。因此，它是一個重要的產品測量點，但是，不是“內部質量”。