怎样才能成为一个优秀的软件开发者.doc

怎样才能成为一个优秀的软件开发者？(译者注：原文是for BCBer 的，但其实本文所述对所有Programmer都适用,具体到编程语言的几乎没有，所以就这样译了.）作者： 不详 出处： 不详英文转贴：Bird1945 简介： 最近有人要我就怎样才能成为一个好的C+ Builder开发者提些建议。在二十多年的职业编程生涯中，我使用的编程语言从IBM 360 汇编、Pick Basic、Modula 2到C、C+、Icon，使用的操作系统从MVS、Unix、Amiga OS到DOS、Windows、Win95以及多种数据库管理系统，创作的产品被应用于制造业、保险业以及GIS领域。这些年来，我涉足过很多种技术领域，从而也获得了很多方面的知识积累，它们对我有着“润物细无声”式潜移默化的帮助。我希望它们会对你有用。对于此文的读者，我假设你至少了解一些C+、 C+ Builder、继承、数据和程序抽象、关系型数据库、ER图及一些基本的编程知识。 但你可以通过此文的阅读知道你可以在其它与此相关的书籍中学习哪些知识，同时，也会提到一些参考书目及作者。首先，你要知道，作为一个软件开发者，多方面、多层次的经验对你的提高非常重要。Smalltalk(译者注：80年代初广泛使用的语言，曾掀起了一场“面向对象运动”，随之诞生了面向对象的C、C + +、Eiffel和CLOS等语言) 和 Icon 可以提高你的C+能力；面向对象的Lisp语言和 Self programmers(?) 对你使用继承和组件很有益处；多种软件开发方法学的使用不但可以帮助你做出更棒的设计，同时也可以使你学到很多设计重用的知识；广泛地了解不同的操作系统上开发的形式各异的程序用户界面（尤其是那些经典的例子）可以使你的软件产品获得更多用户的认可。其次，你要记住，作为一个软件开发者，客户需求对你至关重要，虽然你要面对的客户经常是需求难测。即使你是在开发一个小范围使用使用的系统时也是如此。你要确信你理解客户的需求，而且如果你要开发的系统是要应用于客户的日常工作中的，这时你要想开发出满足客户需求的东西出来，你就必须非常清楚客户他们的目的、他们的处理方法以及局限性从长远看来，这也是你盈利的唯一办法。最后一点，你要热爱你的作品。对她，你要爱若珍宝，时时擦拭，她会拥有精妙绝伦的设计、精雕细刻的界面、良好感知的数据库系统、优异卓绝的性能，并且同时具有最大程度的简洁、精练、产品化，以及最大可能的对包括代码、组件、程序和设计等可重用的资源的重用。 建议：要想成为一个BCB软件开发好手，你就必须时刻记住你是一个软件开发者，而不仅仅是一个程序员。这就是说，你所要考虑的，不仅仅是怎样写出优秀的代码！你还要考虑如何做到软件、数据库以及用户界面的良好设计、最终产品的可重用性及可维护性。当然，对产品的市场等商务环境方面的因素你也应该有相当的了解。在我看来，即使在项目规模大幅增长而超出预先规划的情况下，优秀的软件开发者也可以始终如一地保持他的全局意识。但在这种情况下，唯一可行的办法是开发者在先前软件模块的基础上开发出功能更好的可重用软件模块，即使在你觉得你为了使某模块可重用而做的工作会对你需要实时达到的仅仅是使它运行起来的短期目标有所妨碍的情况下，也不要例外。希望你在C+ 语言方面的经验会使你更好地了解这一点。我的要旨是：如果你编码中用到相似的部分超过三次，我想你应该对这些部分进行抽象和重用。这在BCB中也同样适用，当然，如果重用的间隔度有可能很大的情况下例外。(译者注 以下文字请最好参阅相关建模技术方面的知识来理解！)具体到BCB，重用有很多级别，懂得它们对你大有裨益。最大限度有效地重用你现有的资源。我的意思是，你要尽可能地搞清楚VCL组件的机理，并且，你要经常尝试着使用新的方法应用这些去解决你的实际问题。理解VCL所提供的属性及其还可挖掘的可抽象性。绝对不要在仅仅设置一个属性就可解决问题的情况下创建一个方法 记住，特别是在BCB中，面向对象思想的应用中的一个方面就是在编程中努力做到：少用过程式编码以及控制结构，而尽量通过更改对象的属性来实现。要了解BCB中VCL组件的应用，推荐你看这本书， Miano 的 C+ Builder How-To (ISBN 1-57169-109-X)。 必要时开发新组件。我的所谓的“事不过三”规则要派上用场了。如果你发现你以同样的办法设置一个组件超过三次，我想你应该考虑将它做成一个新的组件。分析一下现有组件，继承和它最接近的组件，只添加一些你所需要用到的东西。因为这只是单继承，你不能通过藕合将其它功能也添加进来，但你应该考虑尽量使它在以后可以被继承使用。在开发新组件时，尽量创建更多的接口和属性而不是方法。学习属性和组件编辑器并且清楚它们是如何在你创建新组件时简化你的工作的。（相关推荐书目：Thorpes Delphi Component Design (ISBN 0-201-46136-6)）尽早形成自己的定规。“事不过三”规则部分上是在这一条尽早形成自己的定规中形成的。这样来解释吧：不要只是为了改变而改变(/faint)。坚持使用已经工作地很好的东西，只有这样，你才可能有足够充分的时间来比较详细地了解它，从而知道是否可以通过对其抽象建模以提供给你更好的功能。另一方面，如果这条道路通向的是一堵墙，那我想你最好还是另寻它路。(译者注：rut 同时有 车辙, 惯例意)选择合适的组件模式。仍然，注意“事不过三”。你的组件中包含了那些经常被提及的组件譬如 一个Combo 和一个使Combo 的内容得到使用的CheckBox 吗？如果有，你就可以做一个聚合组件了。（获得更多聚合组件的相关资料，可以看看“Creating An Aggregate Component With Streamable Sub-Components”，Konopka的Custom Delphi 3 Components(ISBN 1-57610-112-6)中也有很多有用信息）选择合适的设计模式。遵循“事不过三规则”，使用前面提及的 Rut 规则，尝试做到设计部分重用。你在创建设计框架时，首先尝试寻找一套可以实现你的要求的组件，并且试试能否从中抽象出你所需要的（其中的子功能部分尽量使用属性而不是在其中编码来实现）而建立一个模型，而这个模型就可以在你系统的其它地方或你的下一个系统中得到重用。在面向对象编程领域有关设计和编码模式的书籍很多，我的大多数这方面的知识来自于ACM（美国计算机学会）和OOPSLA（面向对象编程系统、语言、应用软件）组织发表的会议录及学报等文档，当然，你也可以找到其它一些好书。不过，我强烈建议你能够加入ACM（这个建议也是自开始编程生涯以来我得到的最有益的建议）。如果你加入，可以成为以下特殊兴趣小组的成员(SIGPLAN ：编程语言；SIGCHI：计算机知识交流；SIGSOFT ：软件工程),可以索取OOPSLA, SIGCHI等组织的学报以及UIST的会议录，你还将有机会获得以前发表的学报文档，而这些文档都是值得精读的，从中可以学习关于编程技巧、模式、用户界面设计的知识。选择合适的应用程序模式。很多应用程序都有着很大的通用部分，所以，你可以先创建一个包含这些通用部分的核心系统，然后再在这个基础软件模型上进行相应的改进来满足需求。要获得更多这方面的信息，请参见“重用你的整个软件系统”一文。(译者注 以下为作者对程序界面设计等方面的建议）作为一个BCB开发者，你也必须充分认识到在程序用户界面中的用户方的因素，你也必须熟知一些如何使你的产品界面好看易用并且可以在相当一段时间内不会被淘汰的设计原则。确信你理解了客户的需求。在系统设计时，多问“这个是为了解决什么问题？”或者“你需要它为你完成什么功能？”等诸如此类的问题。不要让用户来为你设计用户界面。如果客户在说“我这儿放什么，那儿放什么”等界面设计细节方面的话，试着用上述的问题让他回到正道上来。你熟悉设计良好用户界面的工具和技巧，而你所要做的就是将客户的所有需求转换成可以满足所有需求的抽象性界面，而不是为每一个任务创建一个用户界面。尽可能地简化你的系统界面。你的应用系统越复杂，这一点越难做到但也越重要。界面设计中，经常用到的部件要一直可见，较少用到的部件就无需这样了。要知道，人在同一时刻只有在面对不多于七个部件时才可以有较好的工作效率，而且，这些不应该需要去刻意地记忆，应该做到让用户可以轻易地识别开来。在必要的情况下界面可以设计地比较复杂，你要保证没有遗忘或者隐藏掉某些完成工作所必须的部件。保持界面风格一致。实现不同功能的界面中风格不应有差异。完成相似功能的界面中应该使用一致风格的部件，提供相近功能控件也应该保持一致，使得用户可以依赖他们的直觉来操作。尽可能地捕获并处理可能的错误。我很憎恶程序中会出现Alpha value in numeric field或这种类型的错误消息系统根本就不应该允许我在这儿输入不合适的值！另外，对于不可撤消的操作（譬如删除），应该在未进行之前提供明确的取消途径（譬如“你真的要删除这条记录吗？”）。注意各系统中各个部分之间的关联。譬如，你不能允许用户删除一个尚有订单未处理的账目、还在原料单上的产品、尚有病人未重新分配的医生除非你得到订单撤消、原料单作废、病人重新分配的确认。保持整体均衡和谐。界面中重要的部分应该大一点，次要一些的选择性的出现或者放在 Tab 页上使得它可以被访问但暂时不出现。确保你软件的界面整洁，各个控件排列整齐而且布置和谐，就如同一副令人赏心悦目的画面。学习图形设计、布局方面的技术并应用到界面设计中去。如果可能，尽量使用系统提供的字体和颜色而不要太过花哨。相关部件应放在一起。确保那些经常会同时用到的部件放置在一起。客户应该快速找到所需部件而不会手忙脚乱。隔离有可能产生危险性操作的控件。这些控件不可和经常使用的控件放置在一起。如果用户误操作删掉了数据库，哼哼，用户肯定会咬牙切齿的，相信换作是你也不会例外。使用模式，但又要避免使用它。是的，这听起来有点矛盾。模式可能带来很多问题。假设这样一个场景：你本以为当前是选择模式而进行了某些操作，遗憾的是，你最终发现当前是删除模式！噢，天呐，你将有何感想？ 所以，尽量避免在你的系统中使用模式切换，这个比你想像的要易于做到。有新意、精练、并且没有使用模式切换这样你将设计出世界上最易于使用的程序界面！你可以随时任意地操作它，而在（大多数情况下）你结束时会恢复成它应有的初始模式。当然，不可否认，一些模式切换可以让用户接触不到会导致危险操作的界面元件。如果你使用了模式，想办法尽可能清楚地标识它，同时做到易于切换，再通过增加确认来避免那些可能导致的错误(此项最好可选以方便高级用户)。尽量使你的界面标准化。我指的是，使用系统的标准格式，诸如系统字体，同时使用控件的方式也应该遵循比较通用的标准，或者使用那些用户可以很直觉地明白如何操作的方式。尽可能地允许用户改变他们所想改变的。至少可以允许用户来改变你的程序的窗口对话框中也希望如此并且做到可以记录用户所做的改动并可以在下次恢复。(译者注 以下为作者对数据库设计方面的建议）你还得成为一个数据库开发者一个关系型数据库开发者。你需要读一读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、Object Pascal、ODBC等东东，同时也时时了解一下相关的语言，譬如 SmallTalk、Common Object Lis