你是否把程式中的類都看做是抽象資料型別了？是否從這個角度評估了它們的介面了？
類是否有乙個中心目的？
類的命名是否恰當？其名字是否表達了其中心目的？
類的介面是否展現了一致的抽象？
類的介面是否足夠抽象，使你能不必考慮它是如何實現其服務的？你能把類看作是黑盒了嗎？
類提供的服務是否完整，能讓其他類無須動用其內部資料？
是否已從類中除去無關資訊？
是否考慮過把類進一步分解為元件類？是否以盡可能將其分解？
在修改類時是否維持了其介面的完整性？
是否把類的成員的可訪問性到最小？
是否避免暴露類中的資料成員？
在程式語言所許可的範圍內，類是否已盡可能地對其他的類隱藏了自己的實現細節？
類是否避免對其使用者，包括其派生類如何使用它做了假設？
類是否不依賴與其他類？它是鬆散耦合的嗎？
繼承是否只用來建立「是乙個/is-a」的關係？也就是說，派生類是否遵循了lsp原則？
類的文件中是否記述了其繼承策略？
派生類是否避免了「覆蓋」不可覆蓋的方法？
是否把公用的介面，資料和行為都放到盡可能高的繼承層次中了？
繼承層次是否很淺？
積累中所有的資料成員是否都被定義為private 而非protected的了？
類中是否只有七個或更少的資料成員？
是否把類直接或間接呼叫其他類 的子程式的數量減少到最少了？
類是否只在絕對必要時才與其他的類相互協作？
是否在建構函式中初始化了所有的資料成員？
除非擁有經過測量的，建立淺層次副本的理由，類是否都被設計為當做深層副本使用？
你是否研究過所用程式語言裡和類相關的各種特有問題？
如何快速開發出乙個高質量的APP
先，呵呵，一下，大概預估了一下，兩個月20w，乙個月10w，基本就是乙個高階ios，乙個高階android，乙個高階後台，基本不靠譜。乙個方案 從技術的角度，想到乙個比較折中比較靠譜的方案，歡迎討論，1.需求分析 資料庫設計 這個是重點，就像大廈的地基，所以建議，花重金請高手給理清需求設計好資料庫 ...
如何組織乙個高質量的解決方案 PROPOSAL
proposal，解決方案建議書，是一切專案的起點。銷售能力是現網際網路時代非常重要的能力，而乙個好的proposal是能否贏得目標群體，決策層的信任，獲得行動機會的重要載體。凱哥在過去的近二十年的諮詢實施過程中，包裝了眾多跨行業的解決方案並勝出。proposal的包裝不僅適用於投標，專案領域，同時...
如何快速開發出乙個高質量的APP 創業談
先，呵呵，一下，大概預估了一下，兩個月20w，乙個月10w，基本就是乙個高階ios，乙個高階android，乙個高階後台，基本不靠譜。這樣問還算比較靠譜，如果是 我有乙個想法，就差乙個程式設計師 那就呵呵了。2.預算有限，不管外包還是自己組建團隊貌似都不靠譜 3.期限很緊，不能按部就班的去做 4.並...