讀完了討論復雜度的章節（《UNIX編程藝術》），被教導兩個原則：
1，復雜度在所難免，除去代碼量這種太過直觀的衡量不說，人類更傾向于降低實現復雜度，而非接口復雜度。
2，各種分離的接口模式仍然適用，但是如果實在不能完成渴望的功能，才考慮集成到一個IDE下。

軟件課程要做的game項目進展得比較順利，由于已經有了一個demo，得以熟悉game軟件大體的框架，此外UML恰當的運用到設計中，使得各種對象間的接口問題得以輕松解決。
不過，team work的一個基本前提，就是“認識一致”吧。如果某個partner沒有了解到框架如何運作，那么寫起代碼來，應該是比較乏味的。
經驗有1，無耦合的對象間交互。一個對象，盡可能不包含以其他對象作為實參的成員函數。前一個demo就是違反了這點，結果接口設計以及實現都不厭其煩。所有的對象交互問題都離開對象本身，而丟到一個processor里面，由processor根據兩對象的類型，驅動對象的恰當方法，完成交互。
目前的麻煩也有1個：

如上，關鍵是我現在不能過多預料它們的生存期問題。resource manager最長，但是有可能some thing的時間要比some work processor短。如何解決？