從苛希納定律想到

失眠的夜裡，偶然讀到一段話，據說是管理學中的「苛希納定律」（我對管理學是外行，不知道是否管理學中真的有這麼乙個定律）：如果實際管理人員比最佳人數多兩倍，工作時間就要多兩倍，工作成本就要多四倍；如果實際管理人員比最佳人數多3倍，工作時間就要多3倍，工作成本就要多6倍。

我沒有什麼管理工作的經驗，不過這個定律似乎同樣適用於軟體設計。當過度設計帶來額外的複雜度時，它的負面效應似乎不是線性增長，而是成倍數的向上翻。bug，額外的維護成本，公升級和改造都成了噩夢。

我個人的切身體會，就是有一段時間熱衷於複雜的設計，用各種模式和多層架構來實現功能。誠然，這樣的設計帶來了相當大的彈性，但是過度複雜的程式難以除錯和維護。特別是對於我這樣並沒有高超能力的開發人員，程式稍複雜些，就會逐漸超出控制。最後面臨的將是淹沒在**的海洋裡。

所以近來開始轉向輕量級的設計方式，也越來越感嘆這個世界的螺旋式軌跡。是的，我們不應該為不需要的功能付出額外的代價，也不應該為」可能「的需求去實現某種功能——考慮擴充套件的話，也應該是在可以預計的範圍內，同時盡量預留介面而不是實現。雖然沒有對aop有深入的了解，但是也能感覺到這種」織入「式的思想確實可以帶來這樣美妙的平衡。如果我們可以更方便的織入**，就可以方便和靈活的迭代我們的軟體。

sample is smart，如是如是。讀stl，感覺有一種震撼，同時開始憧憬.net 2.0。

科技術的進步應該可以給我們工作得更輕鬆，而不是相反。如論作為使用者還是創造者，這都是我應該記住的事。

從苛希納定律想到

失眠的夜裡，偶然讀到一段話，據說是管理學中的 苛希納定律 我對管理學是外行，不知道是否管理學中真的有這麼乙個定律 如果實際管理人員比最佳人數多兩倍，工作時間就要多兩倍，工作成本就要多四倍 如果實際管理人員比最佳人數多3倍，工作時間就要多3倍，工作成本就要多6倍。我沒有什麼管理工作的經驗，不過這個定律...