1.比技术重?/p>
你开发Y件是Z供别Z用,没有Z用的软g只是没有意义的数据的集合而已。许多在软g斚w很有成就的行家在他们事业的初期却表现q_^Q因Z们那时候将主要_֊都集中在技术上。显Ӟ构gQcomponentsQ,EJBQEnterpriseJavaBeansQ和代理QagentQ是很有的东西。但是对于用h_如果你设计的软g很难使用或者不能满他们的需求,后台用再好的技术也于事无补。多q旉到Y仉求和设计一个用户能很Ҏ理解的界面上。从微Y操作pȝ和OFFICE套g在市Z的成功可以得到对q个问题的最佌释?/p>
2.理解你要实现的东?/p>
好的软g设计人员把大多数旉p在徏立系l模型上Q偶写一些源代码Q但那只不过是ؓ了验证设计过E中所遇到的问题。这他们的设计方案更加可行。有效的pȝ分析和架构是减少后期错误或复杂实现的必要保证?/p>
3.谦虚是必ȝ品格
你不可能知道一切,你甚臌很努力才能获得够用的知识。Y件开发是一复杂而艰巨的工作Q因Y件开发所用到的工具和技术是在不断更新的。而且Q一个h也不可能了解软g开发的所有过E。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事Y件开发的人来_每天可以学习很多C西(如果愿意的话Q。目IZ切、自满自的人是不可能成Z个优U的Y件架构师的?/p>
4.需求就是需?/p>
如果你没有Q何需求,你就不要动手开发Q何Y件。成功的软g取决于时_在用戯求的旉内完成)、预和是否满用户的需求。如果你不能切知道用户需要的是什么,或者Y件的需求定义,那么你的工程注定会失败。我们进行的很多需求分析,实际上是惛_然的认ؓ用户的需求和自己认ؓ的应该是一L?/p>
5.需求其实很改变,改变的是你对需求的理解
需求分析需要一丝不苟、精的完成,而设计的时候反而可以发挥创造力和想象力?/p>
如果需求经常改动,很可能是你没有作好需求分析,q不是需求真的改变了?/p>
你可以抱怨用户不能告诉你他们惛_C么,但是不要忘记Q收集需求信息是你的工作?/p>
需求真正改变的情况很少Q但是没有做好需求分析工作的理由却很多?/p>
6.l常阅读
在这个每日都在发生变化的产业中,你不可能在已取得的成׃陉太久?/p>
每个月至读2?本专业杂志或?本专业书c。保持不落伍需要付出很多的旉和金钱,但会使你成ؓ一个很有实力的竞争者。这一条在我周围能够真正实现的人很?/p>
7.降低软g模块间的耦合?/p>
高耦合度的pȝ是很隄护的。一处的修改引v另一处甚x多处的变动?/p>
你可以通过以下Ҏ降低E序的耦合度:隐藏实现l节Q强制构件接口定义,不用公用数据结构,不让应用E序直接操作数据库?/p>
耦合度低的Y件可以很Ҏ被重用、维护和扩充?/p>
8.提高软g的内聚?/p>
如果一个Y件的模块只实C个功能,那么该模块具有高内聚性。高内聚性的软g更容易维护和改进?/p>
判断一个模块是否有高的内聚性,看一看你是否能够用一个简单的句子描述它的功能p了。如果你用了一D话或者你需要用类?#8220;?#8221;?#8220;?#8221;{连词,则说明你需要将该模块细化?/p>
只有高内聚性的模块才可能被重用?/p>
9.考虑软g的移植?/p>
UL是Y件开发中一具体而又实际的工作,不要怿某些软g工具的广告宣传?/p>
即仅仅对Y件进行常规升U,也要把这看得和向另一个操作系l或数据库移植一样重要?/p>
当你使用了某个操作系l的Ҏ,如它的进E间通信(IPC){略Q或用某数据库专有语a写了存储q程。你的Y件和那个特定的品结合度已l很高了?/p>
好的软g设计者把那些Ҏ的实现细节打包隐藏v来,所以,当那些特性该变的时候,你仅仅需要更新那个包可以了。这些说到容易做到很难,没有扎实的基本功是很难成功的?/p>
10.接受变化
q是一句老话了:唯一不变的只有变化?/p>
通过在徏模期间考虑q些假设的情况,你就有可能开发出_强壮且容易维护的软g。设计强壮的软g是你最基本的目标?/p>
11.不要低估对Y件规模的需?/p>
Internet带给我们的最大的教训是你必须在Y件开发的最初阶D就考虑软g规模的可扩充性?/p>
今天只有100人的部门使用的应用程序,明天可能会被有好几万人的l织使用Q下月,通过因特|可能会有几百万Z用它?/p>
在Y件设计的初期Q根据在用例模型中定义的必须支持的基本事务处理,定软g的基本功能。然后,在徏造系l的时候再逐步加入比较常用的功能?/p>
在设计的开始考虑软g的规模需求,避免在用LH然增大的情况下Q重写Y件。同时也不能只因虑未知的用户量而花费太大的成本。需求分析是q控制的依据?/p>
12.性能仅仅是很多设计因素之一
x软g设计中的一个重要因?-性能Q这好象也是用户最兛_的事情。一个性能不佳的Y件将不可避免被重写?/p>
但是你的设计q必d有可靠性,可用性,便携性和可扩展性。你应该在工E开始就应该定义q区分好q些因素Q以便在工作中恰当用。性能可以是,也可以不是优先最高的因素Q我的观ҎQ给每个设计因素应有的考虑。花哨的、运行快速但是不能解决用户问题的pȝQ是不会得到用户的满意的?/p>
13.理接口
应该在开发阶D늚早期定义Y件模块之间的接口。这有助于开发h员全面理解Y件的设计l构q取得一致意见,让各模块开发小l相对独立的工作。一旦模块的接口定之后模块怎样实现׃是很重要了?/p>
从根本上_如果你不能够定义你的模块“从外部看上去会是什么样?#8221;Q你肯定也不清楚模块内要实现什么?/p>
14.走近路需要更长的旉
在Y件开发中没有捷径可以走?/p>
~短你的在需求分析上q旉Q结果只能是开发出来的软g不能满用户的需求,必须被重写?/p>
在Y件徏模上每节省一周,在将来的~码阶段可能会多花几周时_因ؓ你在全面思考之前就动手写程序?/p>
你ؓ了节省一天的试旉而漏掉了一个bugQ在来的维护阶D,可能需要花几周甚至几个月的旉M复。与其如此,q不如重新安排一下项目计划?/p>
避免走捷径,只做一ơ但要做寏V?/p>
15.证明你的设计在实践中可行
在设计的时候应当先建立一个技术原型,或者称?#8220;端到?#8221;原型。以证明你的设计是能够工作的?/p>
你应该在开发工作的早期做这些事情,因ؓQ如果Y件的设计Ҏ是不可行的,在编码实现阶D|论采取什么措施都于事无补。技术原型将证明你的设计的可行性,从而,你的设计更Ҏ获得支持?/p>
16.应用已知的模?/p>
目前Q我们有大量现成的分析和设计模式以及问题的解x案可以用?/p>
一般来_好的模型设计和开发h员,都会避免重新设计已经成熟的ƈ被广泛应用的东西?/p>
17.研究每个模型的长处和q
目前有很多种cȝ模型可以使用,如下图所C。用例捕L是系l行为需求,数据模型则描q支持一个系l运行所需要的数据构成。你可能会试囑֜用例中加入实际数据描qͼ但是Q这对开发者不是非常有用。同P数据模型ҎqY仉求来说是无用的。每个模型在你徏模过E中有其相应的位|,但是Q你需要明白在什么地方,什么时候用它们?/p>
18.在现有Q务中应用多个模型
当你攉需求的时候,考虑使用样例模型Q用L面模型和领域U的cL型?/p>
当你设计软g的时候,应该考虑制作cL型,序图、状态图、协作图和最l的软g实际物理模型?/p>
E序设计人员应该慢慢意识刎ͼ仅仅使用一个模型而实现的软g要么不能够很好地满用户的需求,要么很难扩展?/p>
19.带工Lȝq是ȝ
使用一个很优秀的CASE工具q不能你成Z个徏模专Ӟ只能使你成ؓ一个优UCASE工具的用者。成Z个优U的徏模专安要多q的U篏Q不会是一周针Ҏ个h值几千美元工L培训。一个优U的CASE工具是很重要Q但你必d习用它Qƈ能够使用它设计它支持的模型。现在的~程工具来容易上手,有不的人已l不d强对基础知识的学习,q是很危险的?/p>
20.理解完整的过E?/p>
好的设计人员应该理解整个软gq程Q尽他们可能不是精通全部实现细节?/p>
软g开发是一个很复杂的过E,除了~程、徏模、测试等你擅长工作外Q还有很多工作要做。好的设计者需要考虑全局。必M长远考虑如何使Y件满用户需要,如何提供l护和技术支持等?/p>
21.常做试Q早做测?/p>
如果试对你的Y件来说是无所谓的Q那么你的Y件多半也没什么必要被开发出来。徏立一个技术原型供技术评审用,以检验你的Y件模型。在软g生命周期中,晚发现的错误越难修改,修改成本昂c尽可能早的做测试是很值得的。测试工作一贯是得不到重视的Q即便你天天挂在嘴上Q但是请看看你的行动。黑盒测试将压力l了试人员Q实际上很多的无用测试的Ҏ应该从白盒测试中查找Q这是Y件开发h员的问题?/p>
22.把你的工作归?/p>
不值得归档的工作往往也不值得做。归档你的设惻I以及Ҏ设想做出的决定;归档软g模型中很重要但不很明昄部分。给每个模型一些概要描qC使别人很快明白模型所表达的内宏V?/p>
23.技术会变,基本原理不会
如果有h?#8220;使用某种开发语a、某个工h某某技术,我们׃需要再做需求分析,建模Q编码或试”。不要相信,q只说明他还~Zl验。抛开技术和人的因素Q实际上软g开发的基本原理?0世纪70q代以来没有改变过。你必须q定义需求,建模Q编码,试Q配|,面对风险Q发布品,理工作人员{等?/p>
软g建模技术是需要多q的实际工作才能完全掌握的。好在我们可以从以上的徏议开始,完善自己的Y件开发经验?/p>
要想成ؓ优秀的Y件架构师或Y件开发h员,必须要有一个端正的态度Q如果只是想依靠q个所谓的名䆾做幌子、日子。我劝你q是不要t入q个行业Q以免误己?/p>
作者简介:晏高明,中原油田地质录井处信息管理中心工作,2006q获国家U?#8220;pȝ分析?#8221;认证资格证书。原文地址Qhttp://www.zylj.com/Article_Show.asp?ArticleID=1184
本文来自CSDN博客Q{载请标明出处Qhttp://blog.csdn.net/wangtao041/archive/2008/12/12/3505590.aspx