今天主管一大早我連咖啡都還來不急泡,就找我討論接下來要做什麼,順便問了一下我對於現在這個系統的感覺如何?礙於保密協定,我沒辦法透露我參與的系統是什麼,暫且就以代號G表示好了,會找上我似乎跟昨天下午的高層會議有關,感覺得出來G系統的PM希望時程能夠再快一些,所以主管問我,目前這個系統的架構,有什麼方法能讓負責前台的人和負責後台的人合作更流暢一點?老實說,昨天算是到職滿一週,看了幾天的source code下來,這系統用了一個很複雜的架構,2-tier (presentation tier也就是所謂的前台及後台的domain tier)、tier裡又用layer,presentation tier用Struts 2做Web MVC,tier之間以RESTful的web service溝通,layer之間用Spring處理AOP和IoC (Dependency Injection),最後domain tier用Hibernate做資料的persistence。所以我的第一個直覺是,架構師把當今熱門的Java技術都用上了,而且是蠻常見的技術組合,至於合不合適我不敢說,畢竟我看到的規格文件只是一部分而已,無法評估未來的擴充性是否需要這樣的架構,不過,我還是回饋了一些我的想法。

  首先,我說這個架構還是有table-driven的影子,雖然不像用Microsoft的Visual Studio工具所開發的系統那樣:直接從前台到後台操作DB這麼誇張,但這個系統的domain model跟我想像中的domain model不太一樣,雖然有不少物件,但物件本身卻沒什麼行為,感覺比較像C裡面的struct,行為雖然也是用物件包起來,但整個感覺就像是一推的function物件操作資料物件。一提到這一點,主管就說公司裡目前也是兩派,一派就是Microsoft的.Net派或稱table-driven派,另一派也就是最近開始的domain-driven派,可能是經驗的關係吧,很多人還是不習慣domain-driven,所以聽主管說,有些工程師有點微微抱怨:以前用Servlet + JSP直接更新DB,雖然程式沒辦法reuse,但開發速度很快,現在光是前台後台整合就要花上不少時間做資料轉換,這跟我從source code看到的情況吻合,資料轉換的code還蠻多的,但我覺得如果是真的OO系統,有不少資料轉換應該是可以避免的。

  再來是我覺得這個系統的架構也被框架(Framework)影響了,如果不熟悉某些annotation (JPA、Spring、Struts 2、lombok和Apache CXF的annotation非常多),光看source code可能會完全看不懂系統是怎麼運作的(我也是一開始先問了Program Analyst整體大架構後才開始看程式碼,不然見樹不見林很耗時間)。甚至連IDE的啟動都要換載入器,否則只會看到一堆compile errors,雖然這些都可以說是開發環境設定的一部分,而且可以少寫很多行程式,算是目前Java蠻流行的作法。annotation是很方便,但我不喜歡這樣的程式碼,沒什麼可攜性,讀起來很不乾脆,而且domain model帶了很多跟domain無關的東西(用annotation騙自己說沒寫跟domain無關的程式嗎?),假設domain model要reuse,除非上述那些library都要一併攜帶,否則根本不work,但如果我只是要reuse domain model做desktop工具,我攜帶Struts 2的library做什麼?只是為了讓compile能過?

  過去我可能也不會特別注意到這一點,之前在實驗室的Group meeting介紹JPA時,也覺得annotation跟Java程式寫在一起比較好維護,但現在我開始懷疑這樣的方法好嗎?如果annotation加在domain model的class上,那domain model和JPA就綁死了,不管是不是要用DB做persistence。下午開完planning meeting (很像Scrum的planning meeting但又有點不同),回到座位上繼續Study系統,在看《Hibernate in Action》時,讀到其中一段時,我一直點頭,其中一句是:

  We use transparent to mean a complete separation of concerns between the persistent classes of the domain model and the persistence logic itself, where the persistent classes are unaware of — and have no dependency to — the persistence mechanism.

  這也是當初Hibernate選擇用XML做O/R mapping的原因之一,後面又有一句也寫得很好:

  The domain model implementation is such an important piece of code that it shouldn’t depend on other Java APIs. For example, code in the domain model shouldn’t perform JNDI lookups or call the database via the JDBC API. This allows you to reuse the domain model implementation virtually anywhere.

  事實上,有了上次將Comic Surfer核心抽離的經驗,我後來在設計任何Domain model時,只會依賴J2SE的最小集合:java.*的物件。javax裡的套件就算是標準都不一定會用,例如javax.swing.*就被我排除了,因為Android不支援,而且為了向下相容性,核心也只納入J2SE 6才有的功能,J2SE 7新增的功能則是加在核心外的wrapper裡,讓有J2SE 7環境的能用新功能,但只有J2SE 6的人還是能夠用Comic Surfer,但少了一點功能。

  跟主管聊了蠻久的,而且這個架構蠻複雜的,我盡量不去動架構,畢竟我不是架構師,但如果之後有需要refactoring的話,如果我有更好的建議,我會提供意見,再來是我會在協助開發後台時,會幫忙補上一些註解,讓之後的新人(如果有的話),盡量協助他們可以不用在source code和一堆文件中交互查詢才看得懂程式架構和設計,希望能幫上忙。不過,今天planning meeting時,我被assign了新任務,除了繼續Study G系統外,我另外要Study別的東西,這是將來系統G會用到的東西,但之前沒有人用過,算是Study的工作比較適合我做,至於後台的部分還是由原先的PA進行設計,畢竟他比較熟悉架構。

  其實從架構師和主管之間的溝通就可以看出這個系統G,雖然是新project,但是換過幾次架構師和PA所遺留下來的設計,有種在maintain legacy system的味道XD,但這不是壞事,可以當成是經驗學習,不管多新的project,一旦開發下去,除非每次不滿意就打掉重寫,不然新的project馬上就變成legacy system,我現在也是以maintain legacy system的心態在開發Comic Surfer,一邊加新功能一邊refactoring。

  註1:還好上述技術都是open source的東西,設計也是一般常見的architecture pattern,不然礙於保密協定,我什麼都沒法寫。
  註2:說話真的要小心,一句不經意的話,就讓架構師知道我已經摸清不少架構的東西了,還覺得assign給我的工作會不會太輕鬆了XD
  註3:今天進內部的員工系統我才知道:我的Title不是我原先以為的資深程式工程師(Senior Programmer),而是資深程式分析師(Senior Program Analyst),依照公司內部的roadmap,APRG -> PRG -> SPRG -> PA之後才是SPA,原來我跳了這麼多級啊!!

創作者介紹

Spirit的異想世界

dbi1463 發表在 痞客邦 PIXNET 留言(0) 人氣()