讀軟體設計的要素06概念完整性

1. 概念完整性

1.1. 當概念組合成一個軟體時，它們可以同步以便協調行為

• 1.1.1. 同步可能會消除一個概念的某些行為，但決不會新增與該概念的規範不一致的新行為

• 1.1.2. 在使用概念設計軟體時，即使你沒有精確定義同步，至少要說服自己，概念之間的每次互動至少在原則上都可以被視為同步

1.2. 如果概念組合的方式不正確，從特定概念的操作和結構來看，概念的行為可能會破壞它的規範

1.3. 概念違反完整性的行為會使使用者感到困惑，因為他們針對概念行為的心智模型受到了破壞

1.4. 當一個由概念組成的系統執行時，每個概念也都作為一個“小機器”執行著，控制著操作發生的時間及其對概念狀態的影響

• 1.4.1. 同步使一個概念的操作與另一個概念的某些操作同時發生，這能進一步約束操作

1.5. 一個概念不能直接改變另一個概念的狀態，也不能以某種方式改變概念的某個操作行為

1.6. 如果概念的實現框架允許它們以其他方式互動，或者程式碼中出現錯誤，那麼一個概念可能會以一種違反它自身規範的方式執行

• 1.6.1. 一些調整可能會在保留概念規範的基礎上新增一些新的功能，也有一些調整可能會直接破壞概念規範

1.7. 當一個概念與其他概念組合時，保持概念的完整性至關重要

1.8. 如果你在使用軟體或分析可用性問題時遇到問題，並發現某個概念的行為方式比較異常，請想想這是否能歸咎於另一個概念的干擾

1.9. 為了保證概念完整性，請確保一個看似通用的概念確實是通用的

2. 預訂

2.1. 假設有一個餐廳的老闆因餐廳的綜合評級較低而感到十分沮喪，他決定入侵該軟體來懲罰惡意差評的顧客

2.2. 他修改了軟體設定以便惡意差評的顧客在後續預訂時，即使沒有取消預訂，當他們到達餐廳時也沒有預訂記錄，因此沒有餐桌供他們使用

• 2.2.1. 行為不符合任何合法的同步原則

• 2.2.1.1. 不僅將兩個概念結合在一起，還破壞了預訂這個概念

• 2.2.1.2. 違反概念完整性的行為

2.3. 假設報復顧客的餐廳老闆入侵了該軟體，使得任何顧客只要釋出差評就會失去在任何餐廳的任何預訂

• 2.3.1. 可憐的顧客儘管從未打算取消預訂，但仍可能收到取消通知，因為預訂概念與通知概念同步

• 2.3.2. 在給出通知的情況下取消預訂不侵犯預訂概念的完整性，因為從預訂概念的規範來看，它是完全可以理解的

2.4. 預訂概念的規範沒有提及誰可以取消預訂

3. 字型格式

3.1. 文字格式有三個簡單的屬性：粗體(Bold)、斜體(Italic)和下劃線(Underline)

3.2. 真正的印刷體斜體從來不是羅馬式斜體，而是更流暢和有書法效果的經典版本

3.3. 有了這些豐富的字型，所有的麻煩都煙消雲散了，但格式切換概念也不再有效

• 3.3.1. 字型概念的擴充套件破壞了格式切換概念

4. Google Drive

4.1. 同步的目的是保持兩個資料夾之間的一致性，其操作原則是一個資料夾中的任何改動也會作用於另一個資料夾

4.2. 與備份概念不同，同步概念也會傳遞刪除操作，這會讓檔案井井有條

4.3. 同步概念的一個基本屬性是兩個集合中的檔案副本完全一致

5. 戰略家、分析師和技術顧問

5.1. 識別概念及其價值是最重要的，而設計單個概念的細節則是次要的

5.2. 考慮的問題

• 5.2.1. 有哪些關鍵概念

• 5.2.1.1. 關鍵概念是什麼

• 5.2.1.2. 透過構建概念清單，你將獲得概念功能的“鳥瞰圖”​，即思考戰略行動的視角

• 5.2.1.3. 構建這些概念的依賴關係圖，看看它們如何相互關聯，以及哪些概念處於核心位置

• 5.2.2. 概念是否發生了變化

• 5.2.2.1. 當你檢視現有系統中的概念時，確定每個概念是何時引入的，並研究它們是否隨時間的推移發生了變化或持續保持穩定

• 5.2.3. 最有價值的概念是什麼

• 5.2.3.1. 是否有一個殺手級的概念

• 5.2.4. 是否有讓人困惑的概念

• 5.2.5. 定義軟體系列的共享概念是什麼

• 5.2.5.1. 共享同一概念的不同軟體彼此一致，還是存在隨機的微小差異？

• 5.2.5.2. 如果將多個軟體中出現的概念統一起來，它們將來可能會有共享概念

• 5.2.6. 每一個概念的目的分別是什麼

• 5.2.7. 是否有缺失的概念

• 5.2.8. 競爭對手的概念是什麼

• 5.2.8.1. 看看同一領域的競爭軟體，盤點一下它們的關鍵概念

6. 互動設計師和產品經理

6.1. 還需要關注單個概念的設計和實現問題，以及概念的可用性問題

6.2. 考慮的問題

• 6.2.1. ①傳達給使用者的概念是否一致

• 6.2.1.1. 你的軟體是否透過它的使用者介面、使用者手冊和幫助指南等支援材料，將概念成功地傳達給了使用者

• 6.2.2. ②如何解釋概念

• 6.2.2.1. 令人信服地展示了每個概念實現其目的的設計方式？

• 6.2.3. ③是否有可用性問題

• 6.2.4. ④軟體都有哪些概念

• 6.2.5. ⑤是否有冗餘概念

• 6.2.6. ⑥是否有概念過載

• 6.2.7. ⑦概念可以被分解嗎

• 6.2.8. ⑧是否有效使用了熟悉的概念

• 6.2.9. ⑨概念是如何同步的

• 6.2.9.1. 是否存在同步不足的情況

• 6.2.9.2. 是否存在同步過度的情況

• 6.2.10. ⑩是否在利用協同效應

• 6.2.11. ⑾概念是否能有效地對映到使用者介面

• 6.2.12. ⑿是否分析過概念的依賴關係

• 6.2.13. ⒀概念是否可以完整地組合在一起

• 6.2.13.1. 每個概念單獨來看都是合理的，但當與軟體中的其他概念組合在一起時，單個概念的合理性可能會被削弱

• 6.2.14. ⒁概念的知識是否有安全的文件記錄

• 6.2.14.1. 一個概念設計可能經過多年的演變，積累了幾代設計師的大量修正和完善

• 6.2.14.2. 如果這些知識只能體現在程式碼中，那麼一旦一個新程式設計師沒有意識到其中的微妙之處而修改了這些程式碼，這些知識就會丟失

• 6.2.14.3. 記錄一個軟體的設計知識是很重要的，從中可以跟蹤一個概念的發展

7. 支援材料編寫者、培訓師和營銷人員

7.1. 使用者可以透過這些材料熟悉軟體並在遇到困難時尋找解決之道

7.2. 考慮的問題

• 7.2.1. 支援材料是否圍繞概念組織

• 7.2.2. 概念是否具有清晰明確的目的

• 7.2.3. 概念的操作原則是否能解釋清楚

• 7.2.4. 概念的解釋是否合理

8. 程式設計師和架構師

8.1. 依賴關係圖可以用於劃分開發階段，也可用於規劃版本升級路線

8.2. 考慮的問題

• 8.2.1. 哪些概念集合可用於構建最小可行產品

• 8.2.2. 哪些概念實現起來很有挑戰性

• 8.2.3. 能避免重蹈覆轍嗎

• 8.2.4. 是否在適當的地方使用了標準庫概念

• 8.2.5. 概念是否儘可能通用

• 8.2.5.1. 是否使用了不必要的特殊資料型別

• 8.2.6. 能否將概念模組化

• 8.2.6.1. 概念之間是否存在可以消除的程式碼依賴關係，使得概念更容易被修改和重用

• 8.2.7. 概念之間是否存在複雜的同步

• 8.2.8. 有些概念操作是否涉及複雜的條件

9. 研究人員和軟體哲學家

9.1. 考慮的問題

• 9.1.1. 概念目錄應該如何構建

• 9.1.1.1. 概念目錄或手冊既有助於設計師記錄他們的專業知識，也可使新手更容易獲得這些專業知識

• 9.1.1.2. 概念目錄對概念的重用也大有裨益，能夠幫助設計師避免已知的陷阱

• 9.1.2. 是否存在複合概念

• 9.1.2.1. 一個概念被分解成更小的概念時，這個概念是否仍然擁有自身的權益和目的呢？

• 9.1.3. 是否存在不同種類的目的

• 9.1.3.1. 一個概念的目的決定了是否應當設計該概念

• 9.1.3.2. 標籤概念和資料夾概念的目的都是整理檔案，這個目的使得它們都可以被納入設計，但只有標籤概念才有過濾檔案的目的

• 9.1.4. 通用概念的例項化會產生什麼問題

• 9.1.5. 操作同步是否足夠

• 9.1.6. 如何闡述對映原則

• 9.1.7. 關於使用者行為的假設在概念設計中扮演什麼角色

• 9.1.7.1. 有些概念只有在使用者做出某種特定行為時才能實現其目的

>  9.1.7.1.1. 只有當使用者設定高強度密碼、記住自己的密碼並且不共享密碼時，密碼概念才能提供有效的身份驗證

• 9.1.8. 概念可以實現完全模組化嗎

• 9.1.8.1. 微服務架構可能是實現概念的一個有用基礎，其中每個微服務架構代表一個單獨的概念，或許被稱為“奈米服務”更合適

• 9.1.9. 可以在程式碼中檢測到概念設計缺陷嗎

• 9.1.9.1. 不規範的概念不僅讓使用者困惑，也讓程式設計師困惑

• 9.1.9.2. 當概念不清楚時，程式碼就會更混亂和有更多缺陷

• 9.1.10. ⑩概念能否應用於API設計

• 9.1.10.1. 概念是面向使用者的

• 9.1.10.2. 程式內部使用服務或API時產生的許多問題與使用者面對的問題很相似