在網路上也看了很多東西,關於JAVA軟體架構方面的東西,現在還真是很難找到,不過,軟體開發的架構基本上是相同的。所以,我在網路上找了很多其他語言關於軟體架構的文章。再這裡也來談談自己對軟體架構,特別是在JAVA專案架構上的看法。說得不一定對,但這也是我幾年來的總結吧。
1. 盡量不要考慮項目外的重用
許多人認為能提高軟體的重用度是最好的,然而每個專案實際情況都會有所不同,在設計專案中的某個模組、方法時,過多的考慮專案外的重用,必然會增加專案的複雜度,增加開發時間的開銷。也許有人會說,這會減少下一計畫的開銷,試問,下一計畫是什麼計畫?有什麼需求?各方面有什麼影響因素?有誰會在當前知道這一切。 如果真要重用,應該是在專案結束後再將可重用的部分提取出來,經過修改、優化後做為企業的可重用資產,而不是當前專案中的一廂情願。考慮專案外的重用性,這是很多剛從事軟體工作的程式設計師常犯的錯誤,往往是考慮得越多,反而做出來的軟體達不到設計的效果,完不成基本的功能或程式碼邏輯過多,程式功能不完善等等。
2.經常檢查專案架構
專案架構通常是在專案實現開始前就已確定的東西,是一個整體的設計。然而,在這時,對專案需求的理解、複雜度的估計都還停留在一個初始階段。如果在專案開發過程中無法隨著對專案的理解而改善架構,必然讓專案中的成員都依照錯誤的架構去開發專案。所以,必須經常檢查專案的架構,進行必要的重構。
3.重構
有人說,都寫了這麼多了,再修改不是浪費時間嘛。他可能沒有想過,一個下午的重構可以加快以後幾個月的開發速度,這節省下來的時間是無法想像的。再者,透過重構,通常能想到更多簡單的方法來取代現有的實現,這樣的經驗,同樣可以簡化其他模組的開發。
4.避免過度集成,讓每個模組只做自己的事
一個常見的OA開發例子是,在業務系統中通常會有許多的審批,很多人一下子一定會想到把審批做成一個通用的模組。這是沒有問題的,然而通常的問題是,太多的人將審批結束後的業務處理也放到了審批模組的業務邏輯中,其實,那些是各業務模組自己的事,審批應該只完成審批即可,至於審核結束後怎麼辦,讓該做這事的模組自己去處理。
5.避免過度靈活
設計和程式碼並不是越靈活越好的。一個常見的例子是,使用泛型時可以使類別或方法操作不同的對象,然而,在JAVA 常用的三層架構中,如果一系列的類別本來就是針對某個特定實體的操作,就沒有必要還指定為泛型,使用時再指定為使用特定的實體類別。這頗有畫蛇添足的感覺。
6.減少錦上添花的功能
頁面無刷新,更酷的顯示效果等等,對於業務系統來說都是些錦上添花的事,如果因為這些而使業務界面非常複雜,給業務處理帶來一系列的問題,極端情況是業務處理無法繼續時,再漂亮的介面也是無用的。一個忠告時,僅在確保業務處理正確進行的前提下再考慮其他的。這一點有一個前提是與使用者進行必要的溝通。也就是說,JAVA實現的項目,重點在於對業務的處理上,只有很好的實現了業務處理,才能去考慮介面的美觀與使用者的視覺感官。
7.適當拆分
這一點與4 類似。盡量降低每個模組的複雜度,讓腦力勞動轉化成體力勞動。一個常見的例子是,通常對某個表單都會有增加、修改、刪除和檢視的功能。但是,前三種操作通常僅在某個功能點上、特定狀態和特定權限的人進行操作(也許僅在在系統中的唯一一個介面中)。而查看操作會分佈在專案的各個角落,如果將這四種操作都放在同一介面中,雖然可以減少介面數,但增加的卻是此介面的複雜度,要對各種狀態、條件進行必須的判斷來進行介面元素的唯讀設置,這個複雜度的增加是指數級的,而如果將查看拆分開,工作量將是線性的,就算要做10個查看界面,總比複雜度變成10*10 要容易處理很多,況且還可以組件化。
8.與客戶保持良好的溝通
很多人都沒有註意去保持和客戶的溝通,很多架構師都認為,只在專案的需求階段才需要和客戶有溝通和交流,這點是很不好的習慣,因為客戶的要求會隨著時間的變化而變化,只有經常和客戶保持良好的溝通,才能在第一時間內了解客戶的需求變化,從而調整自己的專案架構方案,在最短的時間滿足客戶的需求。
9.專案架構與資料庫架構的聯繫
很多人都認為,專案在開發的過程中,是不需要資料庫的,只要在記憶體中實現就可以了。我個人認為,這是很不好的開發習慣。資料庫雖說是根據專案的具體需求而定。但一個專案在架構過程中完全不考慮資料庫的架構,那很可能會讓專案中實現的東西,在資料庫中很難記錄或是資料庫設計很麻煩,無形中增加了專案開發的難度。並且,在專案的開發過程中不考慮資料庫,可能會使專案在掛靠資料庫後,出現部分業務邏輯的無法實現,資料的遺失等等。
當然,很多人的架構風格的不同,會有不同的架構見解,我的見解不一定是正確的。希望大家可以從我的東西都學到一些東西,也希望大家可以多多交流在架構上的看法