軟件架構建設雜談
軟件建設需要考慮的重要的兩點我覺得是:
1、客戶的功能需求以及非功能需求。
2、軟件的維護性。
軟件的技術架構就是為了滿足以上重要的兩點而誕生的,同時由于軟件的技術架構決定了使用它的開發人員所需的水平以及開發的難易,此時又要盡量做到降低對使用者素質的要求以及開發的門檻,以保證開發的高效性,但這個相對上兩點來說更沒那么重要。
在做一個框架級或者現在流行的諸如應用支撐平臺的東西的時候,此時的客戶一般來說是公司的開發人員或其他公司的開發人員,那么首先就要得到他們的功能需求以及非功能需求,但軟件開發人員此時作為客戶來說同樣是不夠成熟的,因為也許很多的開發人員已經適應了它現有的開發模式,你讓它重新接受一套新的肯定會很容易引起它的抵觸情緒,這個和很多的行業客戶是一樣的,它習慣的做法一旦被你打破,甚至你把它以前的做法都改變了,這個時候得到的只能是客戶的不滿意,同時需求也不好挖掘,呵呵,覺得這個時候一方面的做法通常是先吸取客戶現在的做法,提供它目前做法的實現方式,另一方面向客戶灌輸現在方式的好處,慢慢的讓它接受。
另外一方面而言,對于開發人員最重要的就是開發的高效以及簡易性,如果框架讓開發人員反倒覺得不如以前的開發高效、簡易,那么是很難去說服開發人員接受它的,就拿現在基于JAVA的web框架來說,為什么現在很多的web系統不是基于java而是基于php、asp.net等,就技術來說Java的Web框架不會比他們差吧,但為什么呢?就是基于java的web框架實現web系統不夠方便,對開發人員的要求比較高,而且效率也比不過基于php、asp.net,當然,這個另一方面是很多的web應用系統真的非常小而且非常簡單,很多都是普通的CRUD操作,想想現在基于Java的web框架,N多都是N層架構體系,在開發一個CRUD操作往往涉及到N個層次代碼的編寫,即使N多的JAVA人員可能會認為那很簡單,因為層次職責清晰,開發起來也挺簡單什么的,但我想對這個對比起數據驅動的方式進行開發確實是更為復雜了,而且由于層次很多時候會讓開發人員難以理解,這個也許是基于Java的框架需要值得思考的地方的吧,很多人都說microsoft就是會討好開發人員,但如果要做框架級的東西的話要討好的就是開發人員呀,客戶才是上帝嘛。
其實框架也要看面對什么樣的開發人員,而且是要看開發人員是做些什么類型的項目的,如果那個項目對于系統的維護性什么并沒有特別的要求,而且又比較簡單,基本沒什么業務邏輯,需求又相對比較固定、范圍小的話,我想對這樣的情況而言基于Java的框架真的不那么適合,或許可以做一個簡化版的JAVA框架更適合這樣的需求,或許就是在做這樣的JAVA的框架的時候真的值得思考,考慮這樣的實現方式,maybe mda is a good solution,^_^
還是那句話,架構要貼近需求,這個才是重點,框架軟件的架構則更需要考慮開發人員的易用性,^_^,此時要對框架所面對的客戶(也就是開發人員)的項目進行充分的了解,并了解他們現有的開發模式。
ps:說點實際的,舉例現在在JAVA界的主流Web技術架構:MVC+Domain Model(Service Facade+Domain Object)+Persistent Layer,在這樣的技術架構中寫一個CRUD通常要涉及到非常多,比如編寫PO,采用ORM的話還得用工具生成xml,同時編寫DAO、Service Facade,在這樣情況下的Service Facade其實真的是毫無意義,呵呵,變成了無意義的一個層,而且增加了開發人員的工作,得考慮考慮解決方法,也許基于Domain Model去自動生成DAO、Service Facade是個方法,^_^,大家在這種情況下會怎么做呢??呵呵,反正我覺得這樣的情況下MDA確實是一種不錯的解決方法。
1、客戶的功能需求以及非功能需求。
2、軟件的維護性。
軟件的技術架構就是為了滿足以上重要的兩點而誕生的,同時由于軟件的技術架構決定了使用它的開發人員所需的水平以及開發的難易,此時又要盡量做到降低對使用者素質的要求以及開發的門檻,以保證開發的高效性,但這個相對上兩點來說更沒那么重要。
在做一個框架級或者現在流行的諸如應用支撐平臺的東西的時候,此時的客戶一般來說是公司的開發人員或其他公司的開發人員,那么首先就要得到他們的功能需求以及非功能需求,但軟件開發人員此時作為客戶來說同樣是不夠成熟的,因為也許很多的開發人員已經適應了它現有的開發模式,你讓它重新接受一套新的肯定會很容易引起它的抵觸情緒,這個和很多的行業客戶是一樣的,它習慣的做法一旦被你打破,甚至你把它以前的做法都改變了,這個時候得到的只能是客戶的不滿意,同時需求也不好挖掘,呵呵,覺得這個時候一方面的做法通常是先吸取客戶現在的做法,提供它目前做法的實現方式,另一方面向客戶灌輸現在方式的好處,慢慢的讓它接受。
另外一方面而言,對于開發人員最重要的就是開發的高效以及簡易性,如果框架讓開發人員反倒覺得不如以前的開發高效、簡易,那么是很難去說服開發人員接受它的,就拿現在基于JAVA的web框架來說,為什么現在很多的web系統不是基于java而是基于php、asp.net等,就技術來說Java的Web框架不會比他們差吧,但為什么呢?就是基于java的web框架實現web系統不夠方便,對開發人員的要求比較高,而且效率也比不過基于php、asp.net,當然,這個另一方面是很多的web應用系統真的非常小而且非常簡單,很多都是普通的CRUD操作,想想現在基于Java的web框架,N多都是N層架構體系,在開發一個CRUD操作往往涉及到N個層次代碼的編寫,即使N多的JAVA人員可能會認為那很簡單,因為層次職責清晰,開發起來也挺簡單什么的,但我想對這個對比起數據驅動的方式進行開發確實是更為復雜了,而且由于層次很多時候會讓開發人員難以理解,這個也許是基于Java的框架需要值得思考的地方的吧,很多人都說microsoft就是會討好開發人員,但如果要做框架級的東西的話要討好的就是開發人員呀,客戶才是上帝嘛。
其實框架也要看面對什么樣的開發人員,而且是要看開發人員是做些什么類型的項目的,如果那個項目對于系統的維護性什么并沒有特別的要求,而且又比較簡單,基本沒什么業務邏輯,需求又相對比較固定、范圍小的話,我想對這樣的情況而言基于Java的框架真的不那么適合,或許可以做一個簡化版的JAVA框架更適合這樣的需求,或許就是在做這樣的JAVA的框架的時候真的值得思考,考慮這樣的實現方式,maybe mda is a good solution,^_^
還是那句話,架構要貼近需求,這個才是重點,框架軟件的架構則更需要考慮開發人員的易用性,^_^,此時要對框架所面對的客戶(也就是開發人員)的項目進行充分的了解,并了解他們現有的開發模式。
ps:說點實際的,舉例現在在JAVA界的主流Web技術架構:MVC+Domain Model(Service Facade+Domain Object)+Persistent Layer,在這樣的技術架構中寫一個CRUD通常要涉及到非常多,比如編寫PO,采用ORM的話還得用工具生成xml,同時編寫DAO、Service Facade,在這樣情況下的Service Facade其實真的是毫無意義,呵呵,變成了無意義的一個層,而且增加了開發人員的工作,得考慮考慮解決方法,也許基于Domain Model去自動生成DAO、Service Facade是個方法,^_^,大家在這種情況下會怎么做呢??呵呵,反正我覺得這樣的情況下MDA確實是一種不錯的解決方法。
posted on 2005-11-21 21:04 BlueDavy 閱讀(2676) 評論(2) 編輯 收藏 所屬分類: 系統設計