jim yeh on 二月 9th, 2007

看了喲哪桑學長寫的〈Rule of Thumb in Program Log〉,他說:

程式 Log 的好壞,與軟體開發週期長短有關,也與軟體維護成本有關。

Log 真的很重要,但站在 architect 的角度思考問題,必須考慮多重觀點;所以,我會思考開發人員不寫 Log 的問題是動機問題還是能力問題呢?

如果是動機問題,我想學長的一番話可以激勵開發者,然而如果不單是動機問題,有時候沒有動機是因為能力問題所導致的呢?

「我也想寫 Log 呀,可是時程那麼趕,寫 Log 會增加我們的工作量,Log 可以等以後要 Debug 的時候再寫,先把功能寫出來比較重要!」

開發者的考量也有道理,要解決這個問題,我們應該想辦法讓 Application Log 更容易實現

依據關注點分離的原則,Log 與 Business Logic 是屬於不同的關注點,前者屬於系統服務,而後者才是業務功能,要更有效率地處理系統的複雜度,這兩種不同觀點是不該混淆在一起的,所以利用 AOP 的手法,我們可以把像 Log 這種的系統服務用横切關注點把它連接到主要關注點亦即主要的 Business Logic 功能面-完全以物件導向設計理念所設計的程式或模組。

採用這種架構設計可以讓開發者不用去理會系統層面的問題,因為它們是由其它的關注點所負責,springframeworkproxy 實作 AOP 機制,只要定義好主要關注點界面,就可以任意加入或移除所需要的横切關注點-而横切關注點是可以被重覆使用的,它們是系統的的共享元件

想辦法讓對方容易做到,才能真正地發揮團隊綜效,所以對系統面做這樣的關照,開發者就可以更專注於業務邏輯,不受系統面的問題所干擾,而系統的垂直品質也不會打折扣,因為我們可以找對系統面熟悉的技術人員來實作它們,這就是《易經》所說的「本乎天者親上,本乎地者親下」的道理,讓萬物各安其位呀。



     

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">