KISS原則Keep It Simple and Stupid！
簡單設計敏捷開發中非常重要的一項實踐，但是這條原則說起來簡單卻做起來難。因爲每個程序員其實都是一個有完美主義的藝術家，所做軟件其實都是一件自己的藝術品，同時受到許多關於設計方面的資料的影響，所以在做設計的時候會情不自禁的加上許多“優雅特性”和“靈活性”。
另一個很重要的原因在於，在產品推出後又不得不疲於應付客戶頻繁提出的許多新增加的需求的時候，會自然而然的想到：當時要是在做軟件的時候能考慮到這些需求該多好啊，現在來改實在是太麻煩了。要是當初改的話，我只用添加幾條代碼就可以了。
其實這兩種原因都能歸結爲一個：程序員希望自己所設計的系統能最大範圍內適應變化！
這種想法的出發點是非常好的，可是在實際中卻往往不是降低了工作量，反而增加了巨大的工作量。根本原因就在於：用戶需求是無限量的，你永遠也無法預測客戶的需求變化。
舉個形象一點的例子，用戶真正的需求就好比是一個1000G甚至更大的硬盤，其大小僅僅只受用戶想像力的約束。而根據軟件技術的發展程度來看，你現在所做的程序很可能只是能滿足了用戶萬分之一的需求，也就是100M左右。你爲了讓以後可能少開發一點程序，花了很多工夫做了個10M的緩存。可是你想想，10M VS 1000G，你的緩存命中率有多高？
即使不是做項目而是做產品，也不能妄自猜度用戶的需求。一個好的產品的功能完善也是從初始的最簡單版本開始，不斷的從實際使用中接受用戶的使用反饋，通過無數次的迭代而產生的。不可能有任何一個產品在第一個版本的時候，就憑着幾個設計人員的想像，就把用戶的需求考慮的面面俱到，完美無缺。
另外軟件是一件非常講究實效性和成本的產品，想推出最完美的產品當然沒錯，但是要考慮當我們在做這些“完美”產品的時候是否會加長實現的時間和成本代價。
道理說了一大堆，但是實際做起來就是非常難。Agilelabs Team內部在開發過程中也經常會討論某項設計是否過度，有時候就連我自己其實也經常犯這樣的錯誤。有時候回憶起自己當初洋洋自得的一些設計，確實有一些不必要的過度設計在裏面。
過度設計的尺度很難把握，錯誤人人都會犯，犯錯誤沒什麼要緊的。但是關鍵在於是否有勇氣推翻自己花了許多心血的勞動成果，做到這一點非常難，但這確實是我們開發人員的基本素質之一。據說John Carmak在寫Doom的時候曾經整整全部重寫了8遍代碼，那時候還是用匯編，真是讓人佩服。
程序員和項目經理的矛盾往往在於對技術方案的爭論。程序員一般會按照自己的理想提出一個比較“完美”的設計方案，而項目經理則更加關心項目的完成時間。我現在更加深刻的理解項目經理的想法，同時我也是從一個程序員過來的，深知一個“設計方案”對項目的重要性。許多人說項目經理可以不懂技術，但是如果不懂技術怎麼能評估“方案”的好處和實施成本？錯誤的否決一個優秀的技術方案和採納一個錯誤的技術方案都會對項目產生致命的影響。項目經理責任重大啊！
扯遠了點。任隨思維的跳躍，隨手寫了這許多，算是對今天關於權限系統設計討論的一個心得記錄。
