发信人: bency (回家了…………), 信区: Npsos
标 题: 怎样才能成为一个优秀的软件开发者�
发信站: 哈工大紫丁香 (2003年01月18日14:28:41 星期六), 站内信件
★ 简介：
最近有人要我就怎样才能成为一个好的C++ Builder开发者提些建议。在二十多年的职业编
程生涯中，我使用的编程语言从IBM 360 汇编、Pick Basic、Modula 2到C、C++、Icon，
使用的操作系统从MVS、Unix、Amiga OS到DOS、Windows、Win95以及多种数据库管理系统
，创作的产品被应用于制造业、保险业以及GIS领域。这些年来，我涉足过很多种技术领域
，从而也获得了很多方面的知识积累，它们对我有着“润物细无声”式潜移默化的帮助。
我希望它们会对你有用。
对于此文的读者，我假设你至少了解一些C++、 C++ Builder、继承、数据和程序抽象、关
系型数据库、ER图及一些基本的编程知识。 但你可以通过此文的阅读知道你可以在其它与
此相关的书籍中学习哪些知识，同时，也会提到一些参考书目及作者。
首先，你要知道，作为一个软件开发者，多方面、多层次的经验对你的提高非常重要。Sm
alltalk(译者注：80年代初广泛使用的语言，曾掀起了一场“面向对象运动”，随之诞生
了面向对象的C、C + +、Eiffel和CLOS等语言) 和 Icon 可以提高你的C++能力；面向对象
的Lisp语言和 Self programmer's(??) 对你使用继承和组件很有益处；多种软件开发方法
学的使用不但可以帮助你做出更棒的设计，同时也可以使你学到很多设计重用的知识；广
泛地了解不同的操作系统上开发的形式各异的程序用户界面（尤其是那些经典的例子）可
以使你的软件产品获得更多用户的认可。
其次，你要记住，作为一个软件开发者，客户需求对你至关重要，虽然你要面对的客户经
常是需求难测。即使你是在开发一个小范围使用使用的系统时也是如此。你要确信你理解
客户的需求，而且如果你要开发的系统是要应用于客户的日常工作中的，这时你要想开发
出满足客户需求的东西出来，你就必须非常清楚客户他们的目的、他们的处理方法以及局
限性－－从长远看来，这也是你盈利的唯一办法。
最后一点，你要热爱你的作品。对她，你要爱若珍宝，时时擦拭，她会拥有精妙绝伦的设
计、精雕细刻的界面、良好感知的数据库系统、优异卓绝的性能，并且同时具有最大程度
的简洁、精练、产品化，以及最大可能的对包括代码、组件、程序和设计等可重用的资源
的重用。
★ 建议：
要想成为一个BCB软件开发好手，你就必须时刻记住－－你是一个软件开发者，而不仅仅是
一个程序员。这就是说，你所要考虑的，不仅仅是怎样写出优秀的代码！你还要考虑如何
做到软件、数据库以及用户界面的良好设计、最终产品的可重用性及可维护性。当然，对
产品的市场等商务环境方面的因素你也应该有相当的了解。
在我看来，即使在项目规模大幅增长而超出预先规划的情况下，优秀的软件开发者也可以
始终如一地保持他的全局意识。但在这种情况下，唯一可行的办法是开发者在先前软件模
块的基础上开发出功能更好的可重用软件模块，即使在你觉得你为了使某模块可重用而做
的工作会对你需要实时达到的仅仅是使它运行起来的短期目标有所妨碍的情况下，也不要
例外。希望你在C++ 语言方面的经验会使你更好地了解这一点。我的要旨是：如果你编码
中用到相似的部分超过三次，我想你应该对这些部分进行抽象和重用。这在BCB中也同样适
用，当然，如果重用的间隔度有可能很大的情况下例外。
(★译者注★ －－ 以下文字请最好参阅相关建模技术方面的知识来理解！)
具体到BCB，重用有很多级别，懂得它们对你大有裨益。
最大限度有效地重用你现有的资源。我的意思是，你要尽可能地搞清楚VCL组件的机理，并
且，你要经常尝试着使用新的方法应用这些去解决你的实际问题。理解VCL所提供的属性及
其还可挖掘的可抽象性。绝对不要在仅仅设置一个属性就可解决问题的情况下创建一个方
法 －－ 记住，特别是在BCB中，面向对象思想的应用中的一个方面就是在编程中努力做到
：少用过程式编码以及控制结构，而尽量通过更改对象的属性来实现。要了解BCB中VCL组
件的应用，推荐你看这本书， Miano 的 《C++ Builder How-To》 (ISBN 1-57169-109-X
)。
必要时开发新组件。我的所谓的“事不过三”规则要派上用场了。如果你发现你以同样的
办法设置一个组件超过三次，我想你应该考虑将它做成一个新的组件。分析一下现有组件
，继承和它最接近的组件，只添加一些你所需要用到的东西。因为这只是单继承，你不能
通过藕合将其它功能也添加进来，但你应该考虑尽量使它在以后可以被继承使用。在开发
新组件时，尽量创建更多的接口和属性而不是方法。学习属性和组件编辑器并且清楚它们
是如何在你创建新组件时简化你的工作的。（相关推荐书目：Thorpe's "Delphi Compone
nt Design" (ISBN 0-201-46136-6)）
尽早形成自己的定规。“事不过三”规则部分上是在这一条－－尽早形成自己的定规中形
成的。这样来解释吧：不要只是为了改变而改变(/faint)。坚持使用已经工作地很好的东
西，只有这样，你才可能有足够充分的时间来比较详细地了解它，从而知道是否可以通过
对其抽象建模以提供给你更好的功能。另一方面，如果这条道路通向的是一堵墙，那我想
你最好还是另寻它路。(译者注：rut 同时有 车辙, 惯例意)
选择合适的组件模式。仍然，注意“事不过三”。你的组件中包含了那些经常被提及的组
件－－譬如 一个Combo 和一个使Combo 的内容得到使用的CheckBox 吗？如果有，你就可
以做一个聚合组件了。（获得更多聚合组件的相关资料，可以看看“Creating An Aggreg
ate Component With Streamable Sub-Components”，Konopka的"Custom Delphi 3 Comp
onents"(ISBN 1-57610-112-6)中也有很多有用信息）
选择合适的设计模式。遵循“事不过三规则”，使用前面提及的 Rut 规则，尝试做到设计
部分重用。你在创建设计框架时，首先尝试寻找一套可以实现你的要求的组件，并且试试
能否从中抽象出你所需要的（其中的子功能部分尽量使用属性而不是在其中编码来实现）
而建立一个模型，而这个模型就可以在你系统的其它地方或你的下一个系统中得到重用。
在面向对象编程领域有关设计和编码模式的书籍很多，我的大多数这方面的知识来自于AC
M（美国计算机学会）和OOPSLA（面向对象编程－－系统、语言、应用软件）组织发表的会
议录及学报等文档，当然，你也可以找到其它一些好书。不过，我强烈建议你能够加入AC
M（这个建议也是自开始编程生涯以来我得到的最有益的建议）。如果你加入，可以成为以
下特殊兴趣小组的成员(SIGPLAN ：编程语言；SIGCHI：计算机知识交流；SIGSOFT ：软件
工程),可以索取OOPSLA, SIGCHI等组织的学报以及UIST的会议录，你还将有机会获得以前
发表的学报文档，而这些文档都是值得精读的，从中可以学习关于编程技巧、模式、用户
界面设计的知识。
选择合适的应用程序模式。很多应用程序都有着很大的通用部分，所以，你可以先创建一
个包含这些通用部分的核心系统，然后再在这个基础软件模型上进行相应的改进来满足需
求。要获得更多这方面的信息，请参见“重用你的整个软件系统”一文。
(★译者注★ －－ 以下为作者对程序界面设计等方面的建议）
作为一个BCB开发者，你也必须充分认识到在程序用户界面中的用户方的因素，你也必须熟
知一些如何使你的产品界面好看易用并且可以在相当一段时间内不会被淘汰的设计原则。
确信你理解了客户的需求。在系统设计时，多问“这个是为了解决什么问题？”或者“你
需要它为你完成什么功能？”等诸如此类的问题。不要让用户来为你设计用户界面。如果
客户在说“我这儿放什么，那儿放什么”等界面设计细节方面的话，试着用上述的问题让
他回到正道上来。你熟悉设计良好用户界面的工具和技巧，而你所要做的就是将客户的所
有需求转换成可以满足所有需求的抽象性界面，而不是为每一个任务创建一个用户界面。
尽可能地简化你的系统界面。你的应用系统越复杂，这一点越难做到但也越重要。界面设
计中，经常用到的部件要一直可见，较少用到的部件就无需这样了。要知道，人在同一时
刻只有在面对不多于七个部件时才可以有较好的工作效率，而且，这些不应该需要去刻意
地记忆，应该做到让用户可以轻易地识别开来。
在必要的情况下界面可以设计地比较复杂，你要保证没有遗忘或者隐藏掉某些完成工作所
必须的部件。
保持界面风格一致。实现不同功能的界面中风格不应有差异。完成相似功能的界面中应该
使用一致风格的部件，提供相近功能控件也应该保持一致，使得用户可以依赖他们的直觉
来操作。
尽可能地捕获并处理可能的错误。我很憎恶程序中会出现"Alpha value in numeric fiel
d"或这种类型的错误消息－－系统根本就不应该允许我在这儿输入不合适的值！另外，对
于不可撤消的操作（譬如删除），应该在未进行之前提供明确的取消途径（譬如“你真的
要删除这条记录吗？”）。
注意各系统中各个部分之间的关联。譬如，你不能允许用户删除一个尚有订单未处理的账
目、还在原料单上的产品、尚有病人未重新分配的医生－－除非你得到订单撤消、原料单
作废、病人重新分配的确认。
保持整体均衡和谐。界面中重要的部分应该大一点，次要一些的选择性的出现或者放在 T
ab 页上使得它可以被访问但暂时不出现。确保你软件的界面整洁，各个控件排列整齐而且
布置和谐，就如同一副令人赏心悦目的画面。学习图形设计、布局方面的技术并应用到界
面设计中去。如果可能，尽量使用系统提供的字体和颜色而不要太过花哨。
相关部件应放在一起。确保那些经常会同时用到的部件放置在一起。客户应该快速找到所
需部件而不会手忙脚乱。
隔离有可能产生危险性操作的控件。这些控件不可和经常使用的控件放置在一起。如果用
户误操作删掉了数据库，哼哼，用户肯定会咬牙切齿的，相信换作是你也不会例外。
使用模式，但又要避免使用它。是的，这听起来有点矛盾。模式可能带来很多问题。假设
这样一个场景：你本以为当前是选择模式而进行了某些操作，遗憾的是，你最终发现当前
是删除模式！噢，天呐，你将有何感想？ 所以，尽量避免在你的系统中使用模式切换，这
个比你想像的要易于做到。有新意、精练、并且没有使用模式切换－－这样你将设计出世
界上最易于使用的程序界面！你可以随时任意地操作它，而在（大多数情况下）你结束时
会恢复成它应有的初始模式。当然，不可否认，一些模式切换可以让用户接触不到会导致
危险操作的界面元件。如果你使用了模式，想办法尽可能清楚地标识它，同时做到易于切
换，再通过增加确认来避免那些可能导致的错误(此项最好可选以方便高级用户)。
尽量使你的界面标准化。我指的是，使用系统的标准格式，诸如系统字体，同时使用控件
的方式也应该遵循比较通用的标准，或者使用那些用户可以很直觉地明白如何操作的方式
。
尽可能地允许用户改变他们所想改变的。至少可以允许用户来改变你的程序的窗口－－对
话框中也希望如此－－并且做到可以记录用户所做的改动并可以在下次恢复。
(★译者注★ －－ 以下为作者对数据库设计方面的建议）
你还得成为一个数据库开发者－－一个关系型数据库开发者。你需要读一读Codd 和 Date
的原作，并且应该搞懂ER图。
(译者注：
Codd: E F. Codd ： 关系数据库领域著名专家,1970年，身为IBM公司San Jose研究室研究
员的他在 "A RelationalModel of Data for Large Shared Data Banks" 一文中首先提出
了关系数据模型(这篇文章就发表在前文曾提及的ACM的会刊上)，以后他又提出了关系代数
和关系演算、函数依赖的概念，还有关系的1NF、2NF、3NF的概念，还和Boyce合作提出了
BCNF，“为关系数据库系统奠定了理论基础”，曾获ACM最高奖——图灵奖。
Date: C J. Date ： 数据库领域著名专家，著有多本数据库书籍。An Introduction to
Database System 为其名作，1975年第一版发行，现在好像已经出到第六版了。)
每个表都应该有一个唯一ID属性，这个你可以在向表中增加元组的时候指定。用数值来表
示这个属性。在数据库中维护一个包含数据库中所有表的元组，在每个元组中，贮存相对
应的表中唯一ID的最大值；程序中每向表中增加一个元组，这个唯一ID属性就应该跟着增
加。这个唯一ID属性在任何关系中都属于一个外码。
使用ER模型设计你的数据库。把表作为一个实体看待，联系在表中一般是一个外码。但有
时候联系也可以是仅仅包含两个码值（偶尔也可能是三个）的表，其中的码值对应这个联
系的两方。
设计关系数据库时，理解4NF(第四范式)，并且将它付诸应用。每个表中应该只包含那些与
主码紧密关联的字段，而且所贮存的字段的绝大部分元组都不会为空。一个表中如果包含
大比率的空字段，就意味着有多种类型的固有字段模式各异的记录存在。这样的表应该一
分为二，其中一个为包含公共数据项（主干部分）的特定数据表，另一个包含其固有字段
的各种类型，同时分配一个对应于主干表的关键字和符合其类型的合适的数据项给它们。
每个可供取值的域都应对应一个表。这个表由一个唯一ID、一个名称或者是一个描述组成
，也可能包含其它数据项。在数据栅格中，如果包含了域中的属性，那就使用组合查询以
便用户在域表的元组中选择数据。把名称或者描述语句显示出来，把唯一ID贮存在元组中
，这样，你就可以在不暂停数据库的某些服务的情况下方便地改变其名称或者描述。
另外，你也应该多多关注业界涌现的新知识和新技术。最好了解一下诸如ActiveX、Objec
t Pascal、ODBC等东东，同时也时时了解一下相关的语言，譬如 SmallTalk、Common Obj
ect Lisp、Icon以及其它获得较少关注的面向对象语言。每一种语言都拥有自成体系的技
术和风格，而这些，对你的工作都会有所帮助。
★ 至于编码本身嘛...
命名要科学。命名一个记数变量为"Index"而不是"i",定义一个变量名为"BillOfMaterial
sCompleted" 而不是 "BOMComp"。虽然这样需要你多敲键盘，但与它在程序维护期间给我
们带来的方便性相比，这一点小麻烦微不足道。希望你在命名之前先考虑一下与它关联的
内容。举个例子，命名你是数据模块为“Account”，其中的数据表为“Table”，这样你
的代码中就会出现这样的程序代码：Account->Table->FieldByName("ID")->AsString =
AccountIDEdit->Text，看起来很清楚。注意选择合适的命名，使得类似这样的关系流就如
同语言般的流畅自然，易于理解。
使用整齐的缩进格式和空格来保证程序段的条理性。为了突出显示，括号最好单独占一行
。
选择适当的注释方式。尤其对那些不可见并且不包含控件的类更是如此（这些类绝大多数
继承自TObject，也有一些是独立的）。这方面可以参考一下“转换模式”)。
要想成为一个好的软件开发者，你需要具备多方面的高超技能，而这些技能中，大多数是
来自于你所开发过的各种项目、应用软件、开发系统、开发语言以及方法学。所有这些，
是不可能一蹴而就的，你要有耐心，不懈努力，让更清晰明快、更优美简洁、更流畅自然
的风格不仅仅体现在你的代码上，也体现在程序的界面上、功能上... .
--
郁闷
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 210.46.72.251]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间：3.835毫秒