W
waterluo
Unregistered / Unconfirmed
GUEST, unregistred user!
多年開發系統的經驗, 這裡進行整理, 發表出來,歡迎討論,以期共同進步.
對於系統規劃師(System architect)和項目經理, 應該是有些幫助的.
>>>>>>>>>>>>>>>
1.統一的信息處理
在一般的軟件系統中, 會出現錯誤信息, 或者一般的成功或者失敗信息.當一個系統由多個人在開發時, 每個人可能使用不同的函數來顯示.以Delphi 為例, 就有MessageBox, MessageDlg, ShowMessage等.為了給使用者一致的印象, 系統要求所有人採用統一的信息顯示函數.
可以採用下面的設計
(1)建立一個處理信息顯示的Class, 開發函數給開發者使用.要求開發人員不使用其他的信息顯示函數
(2)建立一個資料表, 對每個信息進行編號, 並且提供介面供使用者客制信息的內容.
(3)信息的來源可能是Database, AppServer, 和client, 統一規劃,分開處理
(4)對於錯誤信息, 可以加以日誌紀錄,便於進一步分析統計.
(5)注意處理Application.OnException 事件.
(6)也可以考慮和Windows本身的Log系統整合
2.介面處理
通常我們在評價一個人的印象時,可能採用' 三分長相, 七分打扮'的標準,軟件系統也是一樣.在系統規劃階段時, 就要先直定統一的規則, 以便讓團隊開發成員共同遵守. 不要夢想系統開發完成之後再統一來修改, 通常再系統後期處理Bug已經有些來不及, 界面的問題反而沒有時間去照顧.
要注意下面的一些要素
(1)字體. 通常採用宋體, 或者新細明體. 字體的字符集,大小, 樣式等, 都要明確下來.
(2)佈局. 功能按鈕的位置, 大小, 圖標, 畫面上Grid 的顯示位置等, 都要明確下來. 同樣性質的作業(如基本資料維護),有的按鈕在上面, 有的在下面, 用戶會覺得很痛苦.其實上面或者下面都可以, 這樣的成功系統還是可以看到.
(3)顏色.畫面上不同的顏色代表不同的意思, 如白色Edit表示可以編輯, 灰色edit 表示ReadOnly等, 有些只是Look Up 出來的內容, 可以進行適當的分析, 把這些顏色參數定義出來, 系統在deploy 時, 提供一些default 的設定, 如果User不喜歡, 就讓他/她自己去設置.注意, 顏色的設定是和User關聯的, 所以可以考慮存在DB 中, 也可以存在本地的文件中.
(4)Style. 目前比較流行LookandFeel, 也有這樣的第三方組件, 可以輕鬆讓用戶將系統轉換為WIN傳統風格, 還是WinXP風格.
3.報表系統
一般的企業應用系統, 報表是很重要的部分, 要知道大老闆是從來不去看電腦,只看報表(比大老闆的更大的老闆報表都不會看, 只要問幕僚, 就可以了^_^). 決定系統價格的人, 就是這些看報表的人.所以報表在設計上, 也要遵循一定的規劃.
(1)報表一定要可以轉存為可以閱讀的文件,如excel, pdf, word ,htm 等.這個大部分報表工具就可以支援
(2)報表的標頭, 標題, 次標題, 表尾應該可以開放給用戶修改.
(3)建立報表訂閱功能, 每日(月/季/年)報表列印出來之後, 自動傳送個訂閱者.可以結合Email, 也可以在使用者啟動系統時, 可以查閱自己訂閱的報表.
(4)一些格式上的修改, 最好可以和程序分離開來. 這樣避免修改報表還要去編譯程序, 這樣又存在一個版本發布的問題. 可以採用FastReport 設計, 將設計文件存放在資料庫中.當又新的修改, 將修改過的設計文件重新載入db 中就好.
(5)報表資料的讀取部分, 最好採用stored procedure來撰寫. 其實資料讀取部分, 就是業務數據的讀取, 和開發工具(Dephi/C++ Builder)分離出來,這樣在客戶現場除錯時, 就很有幫助.AfterSale 的人員可能不熟悉Delphi, 但他們可能熟悉SQL, 這樣對於系統維護有一定的幫助.
(6)報表模組要求採用Plug-in 的方式加入系統, 具體而言可以採用COM+, DLL, 或者BPL的方式, 這樣有助於擴充, 而不去動到程序.
(7)建立報表列印日誌. "誰在伸麼時候依據伸麼樣的條件列印了伸麼報表.", 系統加以紀錄, 當然可以和授權系統結合起來, 但紀錄有助於稽核.
4.數據字典
一般系統中, 總有些數據是可以擴充的.比方有一個欄位紀錄教育程度, 可以是博士, 碩士,大學,專科...等
我們可以建立一個資料表來記錄, 但更通用的方式是建立一個數據字典.
通常包括兩個部分
(1)字典條目(A). 對於字典條目, 通常採用一個編碼機制, 比方說用<xx999>五碼來表示一個條目, xx為大類, 999為這個大類的序號. 這樣在顯示數據字典時, 比較有層次感. 也可以需要把字典條設計成Tree結構, 不過那有些複雜, 通常太大的意義.
(2)字典內容(B). A和B 的關係是一多關係.
5.關於畫面繼承
我們用delphi 在設計系統時, 通常會建立一個BaseForm , 以後每個作業的Form 都要從他繼承.這樣的設計便於總體控制一些內容, 如權限管理, 消息機制等. 這裡提出我的一些經驗
(1)BaseForm 最好不要涉及到UI。其實每個軟件工程師都需要一定的自我發揮, 所以UI侷限之後, 創意就受到限制,這樣開發時, 就沒有伸麼動力了, 當然要求遵守前面的統一的界面風格.
(2)權限可以和ActionList 結合起來
(3)畫面繼承的層次不要太多, 這樣對於軟件開發工程師比較痛苦, 特別是項目後期和維護階段, 其他的工程師要花很久的時間和力氣來熟悉結構, 到了2層, 就要適可而止.
6.第三方控件
'工欲善必先利其器', 相信每個Delphi 的開發人員都擁有一些自己的寶刀和利劍.這裡要注意的問題是, 在系統規劃時,要制定該系統計劃採用的所有控件, 以及每個控件的命名方式.
(1)要求採用大家都熟悉的商業控件, 最好有Source Code的. 對於企業開發, 最好註冊或者買一套正式的版本.如果是自己研究和學習, 那寧當別論了(看你的經紀實力和個人對於知識產權的認知了).
(2)對於系統要用的控件, 包括delphi 自己的, 羅列出來, 並確定每個控件的命名.常見的方式為<xxxName>. 其中xxx為簡寫, Name就是有意義的名字了.
(3)到底採用什麼樣的控件? 這個每個人都有自己的喜好, 但一個團隊要求採用相同的元件庫. Delphi information Magazine Reader Choice每年都會對於市場的上各類元件, 進行讀者評比. 所以把你的金庫和大家供認的比較以下.
下面是2002/2003 的結果, 大家可以去參考一下.
<2003>http://www.delphizine.com/opinion/2003/09/di200309jc_o/di200309jc_o.asp
<2002>http://www.delphizine.com/opinion/2002/06/di200206jc_o/di200206jc_o.asp
7.代碼風格
"金玉其外, 敗鬚其中", 有的代碼不怎麼樣, 軟件產品卻很好, 有市場.今天我們站在一個系統結構師的角度, 還是系統代碼是比較規律, 而且可以見人的.(以往看過一篇報到, 說我們中國人看到印度軟件工程師的代碼, 可能會吐血的, 不過當時是講他們的算法和技巧不好, 好像沒有提到程序的代碼風格)
(1)命名的方式. 這個和前面控件的命名是一致的, 當然包括變量, 單元, Class, 數據庫欄位Field等. 以往不少程序採用拼音簡寫的方式(Foxpro中比較流行),不過我建議還是儘量用英文,通常也是用一些簡單的詞彙, 'Name' 總比'XINGMING'看的舒服.
(2)代碼縮進. 採用2個空個, 不要用Tab. 以及Begin/End 要對好等
(3)注釋.其實在程序中多寫些注釋, 比將來再去寫技術文件更有助於團隊內部協同工作和加入新的成員.程序注釋結合一些流程圖, 基本上就可以讓程序員快速了解.
(4)要注意Database中Table, View, Procedure, Function, Field 的命名.
(5)每次修改, 最好留下修改當時的紀錄,特別是修改其他人的代碼. 如//modified by xxx at 2003/08/11 for yyyy,
(6)Code Review. 在項目開發進行中, 最好對於程序代碼有一個Review的機制. 目前eXtreme Programming中提倡的pair programming , 就是code review 的極端. 而且項目經理應該紀錄每隻程序的開發,review, 修改,review的紀錄.
<待續>
對於系統規劃師(System architect)和項目經理, 應該是有些幫助的.
>>>>>>>>>>>>>>>
1.統一的信息處理
在一般的軟件系統中, 會出現錯誤信息, 或者一般的成功或者失敗信息.當一個系統由多個人在開發時, 每個人可能使用不同的函數來顯示.以Delphi 為例, 就有MessageBox, MessageDlg, ShowMessage等.為了給使用者一致的印象, 系統要求所有人採用統一的信息顯示函數.
可以採用下面的設計
(1)建立一個處理信息顯示的Class, 開發函數給開發者使用.要求開發人員不使用其他的信息顯示函數
(2)建立一個資料表, 對每個信息進行編號, 並且提供介面供使用者客制信息的內容.
(3)信息的來源可能是Database, AppServer, 和client, 統一規劃,分開處理
(4)對於錯誤信息, 可以加以日誌紀錄,便於進一步分析統計.
(5)注意處理Application.OnException 事件.
(6)也可以考慮和Windows本身的Log系統整合
2.介面處理
通常我們在評價一個人的印象時,可能採用' 三分長相, 七分打扮'的標準,軟件系統也是一樣.在系統規劃階段時, 就要先直定統一的規則, 以便讓團隊開發成員共同遵守. 不要夢想系統開發完成之後再統一來修改, 通常再系統後期處理Bug已經有些來不及, 界面的問題反而沒有時間去照顧.
要注意下面的一些要素
(1)字體. 通常採用宋體, 或者新細明體. 字體的字符集,大小, 樣式等, 都要明確下來.
(2)佈局. 功能按鈕的位置, 大小, 圖標, 畫面上Grid 的顯示位置等, 都要明確下來. 同樣性質的作業(如基本資料維護),有的按鈕在上面, 有的在下面, 用戶會覺得很痛苦.其實上面或者下面都可以, 這樣的成功系統還是可以看到.
(3)顏色.畫面上不同的顏色代表不同的意思, 如白色Edit表示可以編輯, 灰色edit 表示ReadOnly等, 有些只是Look Up 出來的內容, 可以進行適當的分析, 把這些顏色參數定義出來, 系統在deploy 時, 提供一些default 的設定, 如果User不喜歡, 就讓他/她自己去設置.注意, 顏色的設定是和User關聯的, 所以可以考慮存在DB 中, 也可以存在本地的文件中.
(4)Style. 目前比較流行LookandFeel, 也有這樣的第三方組件, 可以輕鬆讓用戶將系統轉換為WIN傳統風格, 還是WinXP風格.
3.報表系統
一般的企業應用系統, 報表是很重要的部分, 要知道大老闆是從來不去看電腦,只看報表(比大老闆的更大的老闆報表都不會看, 只要問幕僚, 就可以了^_^). 決定系統價格的人, 就是這些看報表的人.所以報表在設計上, 也要遵循一定的規劃.
(1)報表一定要可以轉存為可以閱讀的文件,如excel, pdf, word ,htm 等.這個大部分報表工具就可以支援
(2)報表的標頭, 標題, 次標題, 表尾應該可以開放給用戶修改.
(3)建立報表訂閱功能, 每日(月/季/年)報表列印出來之後, 自動傳送個訂閱者.可以結合Email, 也可以在使用者啟動系統時, 可以查閱自己訂閱的報表.
(4)一些格式上的修改, 最好可以和程序分離開來. 這樣避免修改報表還要去編譯程序, 這樣又存在一個版本發布的問題. 可以採用FastReport 設計, 將設計文件存放在資料庫中.當又新的修改, 將修改過的設計文件重新載入db 中就好.
(5)報表資料的讀取部分, 最好採用stored procedure來撰寫. 其實資料讀取部分, 就是業務數據的讀取, 和開發工具(Dephi/C++ Builder)分離出來,這樣在客戶現場除錯時, 就很有幫助.AfterSale 的人員可能不熟悉Delphi, 但他們可能熟悉SQL, 這樣對於系統維護有一定的幫助.
(6)報表模組要求採用Plug-in 的方式加入系統, 具體而言可以採用COM+, DLL, 或者BPL的方式, 這樣有助於擴充, 而不去動到程序.
(7)建立報表列印日誌. "誰在伸麼時候依據伸麼樣的條件列印了伸麼報表.", 系統加以紀錄, 當然可以和授權系統結合起來, 但紀錄有助於稽核.
4.數據字典
一般系統中, 總有些數據是可以擴充的.比方有一個欄位紀錄教育程度, 可以是博士, 碩士,大學,專科...等
我們可以建立一個資料表來記錄, 但更通用的方式是建立一個數據字典.
通常包括兩個部分
(1)字典條目(A). 對於字典條目, 通常採用一個編碼機制, 比方說用<xx999>五碼來表示一個條目, xx為大類, 999為這個大類的序號. 這樣在顯示數據字典時, 比較有層次感. 也可以需要把字典條設計成Tree結構, 不過那有些複雜, 通常太大的意義.
(2)字典內容(B). A和B 的關係是一多關係.
5.關於畫面繼承
我們用delphi 在設計系統時, 通常會建立一個BaseForm , 以後每個作業的Form 都要從他繼承.這樣的設計便於總體控制一些內容, 如權限管理, 消息機制等. 這裡提出我的一些經驗
(1)BaseForm 最好不要涉及到UI。其實每個軟件工程師都需要一定的自我發揮, 所以UI侷限之後, 創意就受到限制,這樣開發時, 就沒有伸麼動力了, 當然要求遵守前面的統一的界面風格.
(2)權限可以和ActionList 結合起來
(3)畫面繼承的層次不要太多, 這樣對於軟件開發工程師比較痛苦, 特別是項目後期和維護階段, 其他的工程師要花很久的時間和力氣來熟悉結構, 到了2層, 就要適可而止.
6.第三方控件
'工欲善必先利其器', 相信每個Delphi 的開發人員都擁有一些自己的寶刀和利劍.這裡要注意的問題是, 在系統規劃時,要制定該系統計劃採用的所有控件, 以及每個控件的命名方式.
(1)要求採用大家都熟悉的商業控件, 最好有Source Code的. 對於企業開發, 最好註冊或者買一套正式的版本.如果是自己研究和學習, 那寧當別論了(看你的經紀實力和個人對於知識產權的認知了).
(2)對於系統要用的控件, 包括delphi 自己的, 羅列出來, 並確定每個控件的命名.常見的方式為<xxxName>. 其中xxx為簡寫, Name就是有意義的名字了.
(3)到底採用什麼樣的控件? 這個每個人都有自己的喜好, 但一個團隊要求採用相同的元件庫. Delphi information Magazine Reader Choice每年都會對於市場的上各類元件, 進行讀者評比. 所以把你的金庫和大家供認的比較以下.
下面是2002/2003 的結果, 大家可以去參考一下.
<2003>http://www.delphizine.com/opinion/2003/09/di200309jc_o/di200309jc_o.asp
<2002>http://www.delphizine.com/opinion/2002/06/di200206jc_o/di200206jc_o.asp
7.代碼風格
"金玉其外, 敗鬚其中", 有的代碼不怎麼樣, 軟件產品卻很好, 有市場.今天我們站在一個系統結構師的角度, 還是系統代碼是比較規律, 而且可以見人的.(以往看過一篇報到, 說我們中國人看到印度軟件工程師的代碼, 可能會吐血的, 不過當時是講他們的算法和技巧不好, 好像沒有提到程序的代碼風格)
(1)命名的方式. 這個和前面控件的命名是一致的, 當然包括變量, 單元, Class, 數據庫欄位Field等. 以往不少程序採用拼音簡寫的方式(Foxpro中比較流行),不過我建議還是儘量用英文,通常也是用一些簡單的詞彙, 'Name' 總比'XINGMING'看的舒服.
(2)代碼縮進. 採用2個空個, 不要用Tab. 以及Begin/End 要對好等
(3)注釋.其實在程序中多寫些注釋, 比將來再去寫技術文件更有助於團隊內部協同工作和加入新的成員.程序注釋結合一些流程圖, 基本上就可以讓程序員快速了解.
(4)要注意Database中Table, View, Procedure, Function, Field 的命名.
(5)每次修改, 最好留下修改當時的紀錄,特別是修改其他人的代碼. 如//modified by xxx at 2003/08/11 for yyyy,
(6)Code Review. 在項目開發進行中, 最好對於程序代碼有一個Review的機制. 目前eXtreme Programming中提倡的pair programming , 就是code review 的極端. 而且項目經理應該紀錄每隻程序的開發,review, 修改,review的紀錄.
<待續>