Delphi企業級系統規劃的一些經驗分享(一), 歡迎討論(50分)

  • 主题发起人 主题发起人 waterluo
  • 开始时间 开始时间
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的纪录.
 
samboy111伟大
而 waterluo 与伟大.........
 
说得很好!!
 
热泪盈眶!
 
可惜這還只是動手寫一個系統前作為一個程序員應知應會的.
离規劃企業級系統還遙遠得很!

 
说真的,samboy111是个好同志,应该加分的哦:)
客观讲,是应该不错的。看来,全心全意为人民服务的兄弟还不少。
 
写得不错!!好!
 
>>可惜这还只是动手写一个系统前作为一个程序员应知应会的.
>>离规划企业级系统还遥远得很!
同意.[8D]
 
不錯,界面處理,畫面繼承,代碼風格基本是這樣的,只不過個人執行中可能就不是那麼回事了。特別是代碼風格。
 
我来补充几点,做了一年多的大型ERP项目,说一说对开发平台的看法:
1、 作一个大的系统一定要有明确分工,比如那些人要分出来写开发框架,那些人
祛写业务,如果这个没有分工,那么到最后最终会导致大家的程序五花八门;
2、 合理抽象,对于开发框架,一定要进行合理抽象,即写业务的程序员用框架来
开发,一定要把他限制在一定的圈子内,比如界面风格等等,但是也应该提供让他自由
发挥的空间,毕竟业务是复杂的。
3、 人的因素,一个大型项目不应该有很多高手,高手通常脾气大,难以留住,
一个大型项目要得是稳定,所以技术一般的人培训一下,然后教他用你的开发平台
就可以拉。
4、 规范:没有规矩不成方圆,一个好的团队一定要有规范,包括代码规范,比如
什么缩进两格,变量命名,窗体命名等等,再比如画UML 统一使用ROSE,统一按照
先画 用例 --- 活动 ----.... 等等模式进行,文档统一用Rose 导出 等等。
这可以为以后节约大量的维护成本,想象一下,大家所有的工作产品都不是一个风格,
恐怖吧。
5、 减少复杂度,最简单的东西才是最完美的,想象一下一个复杂的谁都看不懂
的东西最终会是一个什么样子。减少复杂度有很多体现和解决方法,比如 OOAD,OOP,
数据库上少写触发器等等。
6、 重用、积累: 很多公司并不是有多少机会作大型项目,所以积累一定要有,
另外也应该考虑重用,比如业务重用,比如开发模式,平台,规范的重用(特别注意:
个人认为 : 人不能算是一种积累,半年发不出工资,恐怕人会走光掉 :) )。
7、 实施,这是一个几乎是最重要的过程,为什么很多软件写得很好,但是客户使用
情况却并不好,就是因为实施,软件行业本身就是一个很不成熟的行业,工作产品不太
容易被人认可(比方说 建筑业 盖了一层楼,恐怕没有人敢说让他重干,但是软件可能
因为客户的一句话你就要重新从调研、设计、编码重新开始一遍)。正因为软件业
的不成熟,也就决定了很多时候一个项目成败取决于人,大型软件更多时候是作一个让
你自己觉得恶心,客户觉得基本可以接受的东西,此时说明你们的软件是成功的,归根结蒂
一句话,一定要“泡”客户,让他用,让他感动。
8、 还有好多废话,不说啦!
 
有理想,有道德,有文化,守紀律
數據庫團隊程序員要安紀律, 否則至少我不敢用.
 
好文,收藏!
 
好好学习,天天向上!
 
不错!很多想法我们的一样。
to 贴主:
4)Style. 目前比較流行LookandFeel, 也有這樣的第三方組件, 可以輕鬆讓用戶將系統轉換為WIN傳統風格, 還是WinXP風格.
------------
Look And Fell 意思是观感,你竟然当成了一种风格:(

畫面繼承的層次不要太多, 這樣對於軟件開發工程師比較痛苦, 特別是項目後期和維護階段, 其他的工程師要花很久的時間和力氣來熟悉結構, 到了2層, 就要適可而止.
------------------
不同意,关系是层次设计好且帮好文档,你这么说就是因咽废食。

另外,你说的数据字典,我看不明白呀,是不是偏离数据字典的原意了?

to 我本无才:
贴主说得这么实际,你还说是套话?可见你确实是你自己形容那样子[:D]
 
很高興大家能夠參與討論, 我想重點是把自己開發系統的經驗寫出來, 一方面整理自己的思想, 另外一方面也想聽取大家的觀點.
(1)比較適合維系統架構師(System Architect). 原則上系統結構師, 應該比較熟悉開發的語言和工具. 建議看看<人月神話>這本書, 對於確保軟件產品的品質, 有很大的幫助.
(2)開發一個軟件系統, 是團隊所有人的事情.不過,系統結構最好由1~2個人控管.其實風格沒有最好的, 但一定要有確定的一個.
(3)基本上這裡講的每個項目, 都是多年的多個項目經驗. 當98年第一個系統開發時, 網絡資源, 以及書店的書籍較少, 特別對於介紹企業級應用系統開發的資源就更少了, 現在確實很幸福, 逛書店是每週的樂趣了.
(4)感謝samboy111,轉換簡體.
還有續集, 歡迎指教.
 

Similar threads

后退
顶部