看了喲哪桑學長寫的〈Rule of Thumb in Program Log〉，他說：
程式 Log 的好壞，與軟體開發週期長短有關，也與軟體維護成本有關。
Log 真的很重要，但站在 architect 的角度思考問題，必須考慮多重觀點；所以，我會思考開發人員不寫 Log 的問題是動機問題還是能力問題呢？
如果是動機問題，我想學長的一番話可以激勵開發者，然而如果不單是動機問題，有時候沒有動機是因為能力問題所導致的呢？
「我也想寫 Log 呀，可是時程那麼趕，寫 Log 會增加我們的工作量，Log 可以等以後要 Debug 的時候再寫，先把功能寫出來比較重要！」
開發者的考量也有道理，要解決這個問題，我們應該想辦法讓 Application Log 更容易實現。
依據關注點分離的原則，Log 與 Business Logic 是屬於不同的關注點，前者屬於系統服務，而後者才是業務功能，要更有效率地處理系統的複雜度，這兩種不同觀點是不該混淆在一起的，所以利用 AOP 的手法，我們可以把像 Log 這種的系統服務用横切關注點把它連接到主要關注點亦即主要的 Business Logic 功能面－完全以物件導向設計理念所設計的程式或模組。
採用這種架構設計可以讓開發者不用去理會系統層面的問題，因為它們是由其它的關注點所負責，springframework 以 proxy 實作 AOP 機制，只要定義好主要關注點界面，就可以任意加入或移除所需要的横切關注點－而横切關注點是可以被重覆使用的，它們是系統的的共享元件。
想辦法讓對方容易做到，才能真正地發揮團隊綜效，所以對系統面做這樣的關照，開發者就可以更專注於業務邏輯，不受系統面的問題所干擾，而系統的垂直品質也不會打折扣，因為我們可以找對系統面熟悉的技術人員來實作它們，這就是《易經》所說的「本乎天者親上，本乎地者親下」的道理，讓萬物各安其位呀。
