??xml version="1.0" encoding="utf-8" standalone="yes"?>
E-mail: robbin_fan@yahoo.com.cn
我是从学?fn)Java~程开始接触OOP(面向对象~程)Q刚开始用Java~写E序的时候感觉很别扭Q因为我早以?fn)惯用C来编写程序,很欣赏C的简z性和高效性,喜欢Cl而表达能力丰富的风格Q特别忍受不了Javaq行h慢吞吞的速度Q相对冗长的代码Q而且一个很单的事情Q要写好多类Q一个类调用一个类Q心里的抵触情A很强?br />
我对Java的面向对象的Ҏ(gu)琢良久,自认为有所领?zhn)Q也开始有意识的运用OOP风格来写E序Q然而还是经怼(x)觉得不知道应该怎样提炼c,面对一个具体的问题的时候,?x)觉得脑子里千头万A的,不知道怎么下手Q一不小心,又会(x)回到原来的思\上去?br />
举个例子Q要发广告邮Ӟq告邮g列表存在数据库里面。倘若用C来写的话Q一般会(x)q样思考,先把邮g内容dQ然后连接数据库Q@环取邮g地址Q调用本机的qmail的sendmail命o(h)发送?br />
然后考虑用Java来实玎ͼ既然是OOPQ就不能什么代码都塞到mainq程里面Q于是就设计了三个类Q?br />
一个类是负责读取数据库Q取邮g地址Q调用qmail的sendmail命o(h)发送;
一个类是读邮g内容QMIME~码成HTML格式的,再加上邮件头Q?br />一个主c负责从命o(h)d敎ͼ处理命o(h)行参敎ͼ调用发email的类?br />
把一件工作按照功能划分ؓ(f)3个模块分别处理,每个cd成一件模块Q务?br />
仔细的分析一下,׃(x)发现q样的设计完全是从程序员实现E序功能的角度来设计的,或者说Q设计类的时候,是自低向上的Q从机器的角度到现实世界的角度来分析问题的。因此在设计的时候,已l把E序~程实现的细节都考虑q去了,企图从底层实现程序这L(fng)出发Ҏ(gu)辑ֈ满现实世界的Y仉求的目标?br />
q样的分析方法其实是不适用于Javaq样面向对象的编E语aQ因为,如果改用C语言Q封装两个C函数Q都?x)比Java实现hL的多Q逻辑上也清楚的多?br />
我觉得面向对象的_N在于考虑问题的思\是从现实世界的hcL维?fn)惯出发的,只要领?x)了这一点,领?x)了面向对象的思维Ҏ(gu)?br />
举一个非常简单的例子Q假使现在需要写一个网计数器Q客戯问一ơ页面,|页计数器加1Q计数器是这h讉K?br />
http://hostname/count.cgi?id=xxx
后台有一个数据库表,保存每个idQ一个id对应一个被l计讉Kơ数的页面)的计数器当前|h面一ơ,对应id的计数器的字D加1(q里我们忽略q发更新数据库表Q出现的表锁定的问题)?br />
如果按照一般从E序实现的角度来分析Q我们会(x)q样考虑Q首先是从HTTP GETh取到idQ然后按照id查数据库表,获得某id对应的访问计数|然后?Q更新数据库Q最后向面昄讉K计数?br />
现在假设一个没有程序设计经验的人,他会(x)怎样来思考这个问题的呢?他会(x)提出什么样的需求呢Q他很可能会(x)q样惻I(x)
我需要有一个计数器Q这个计数器应该有这L(fng)功能Q刷Cơ页面,讉K量就?x)?Q另外最好还有一个计数器?的功能,当然计数器如果有一个可以设ZQ意值的功能的话Q我可以作弊了?br />
做ؓ(f)一个没有程序设计经验的人来_(d)他完全不?x)想到对数据库应该如何操作,对于HTTP变量该如何传递,他考虑问题的角度就是我有什么需求,我的业务逻辑是什么,软g应该有什么功能?br />
按照q样的思\(h意,他的思\其实是我们qx在生zM?fn)惯的思维方式)Q我们知道需要有一个计数器c?CounterQ有一个必ȝ和两个可选的Ҏ(gu)Q?br />
getCount() // 取计数器值方?br />resetCounter() // 计数器清0Ҏ(gu)
setCount() // 设计数器为相应的值方?br />
把Countercd整的定义如下Q?br />
public class Counter {
public int getCount(int id) {}
public void resetCounter(int id) {}
public void setCount(int id, int currentCount) {}
}
解决问题的框架已l有了,来看一下如何用Counter?在count.cgi里面调用Counter来计敎ͼE序片断如下Q?br />
// q里从HTTP环境里面取id?br />...
Counter myCounter = new Counter(); // 获得计数?br />int currentCount = myCounter.getCount(id); // 从计数器中取计数
// q里向客h览器输出
...
E序的框架全都写好了Q剩下的是实现CountercL法里面具体的代码了,此时才去考虑具体的程序语a实现的细节,比如Q在getCount()Ҏ(gu)里面讉K数据库,更新计数倹{?br />
从上面的例子中看刎ͼ面向对象的思维Ҏ(gu)其实是我们在现实生zM?fn)惯的思维方式Q是从hc考虑问题的角度出发,把hc解决问题的思维方式逐步译成程序能够理解的思维方式的过E,在这个翻译的q程中,软g也就逐步被设计好了?br />
在运用面向对象的思维Ҏ(gu)q行软g设计的过E中Q最Ҏ(gu)犯的错误是开始分析的时候,想CE序代码实现的细节,因此装的类完全是基于程序实现逻辑Q而不是基于解决问题的业务逻辑?br />
学习(fn)JDBC~程的经兔R误问法是Q“我怎样装Ҏ(gu)据库的select操作Q?br />
面向对象的设计是Z解决业务问题的设计,而不是基于具体编E技术的设计。我不会(x)d装select语句的,我只装解决问题的业务逻辑Q对数据库的d是在业务逻辑的编码实现阶D|去考虑的问题?br />
回过头看上面那个发广告邮件的例子Q应该如何应用面向对象的思维Ҏ(gu)呢?
对于一个邮件来_(d)有邮件头Q邮件体Q和邮g地址q三个属性,发送邮Ӟ需要一个发送的Ҏ(gu)Q另外还需要一个能把所有邮件地址列出来的Ҏ(gu)。所以应该如下设计:(x)
cJunkMail
属性:(x)
head
body
address
Ҏ(gu)Q?br />sendMail() // 发送邮?br />listAllMail() // 列邮件地址
用Java来表C:(x)
public class JunkMail {
private String head;
private String body;
private String address;
public JunkMain() { // 默认的类构造器
// 从外部配|文件读邮g头和邮g?br />this.head=...;
this.body=...;
}
public static boolean sendMail(String address) {
// 调用qmailQ发送email
}
public static Collection listAllMail() {
// 讉K数据库,q回一个邮件地址集合
}
}
当把JunkMail设计好了以后Q再调用JunkMailcd成邮件的发送,是非常L的事情?br />
如果说传l的面向q程的编E是W合机器q行指o(h)的流E的话,那么面向对象的思维Ҏ(gu)是W合现实生活中hc解决问题的思维q程?br />
在面向对象的软g分析和设计的时候,要提醒自己,不要一上来去想程序代码的实现Q应该抛开具体~程语言的束~,集中_֊分析我们要实现的软g的业务逻辑Q分析Y件的业务程Q思考应该如何去描述和实现Y件的业务。毕竟Y件只是一个蝲体,业务才是我们真正要实现的目标?br />
但是在设计过E中Q心里却往往在担心,如果我完全不去考虑E序代码的实现的话,那么我怎么知道我的设计一定合理呢Q我怎么知道我设计的cR接口一定可以实现呢Q所以经常可以看到的现象是Q?br />
在设计过E中Q虽然知道不能过早考虑代码实现Q但是每设计一个类Q一个接口,心里都要不知不觉的用自己熟?zhn)的编E语a大概的评C下,看看能否~出来,因此Q一不小心,׃(x)又回到按照程序功能实现的思\q行设计的老\上去了?br />
举个例子来说明,在做WebE序设计的时候,l常要遇到分|C数据的情况。比如说需要把pȝ中所有的用户都列出来q样的功能。假设用UsercL表示用户Q增加用户addUser()Q删除用户deleteUser()Q查询所有用户listUsers()Ҏ(gu)。而数据库中有一个user表,一条记录是一个用L(fng)信息。下面考虑一下UsercȝҎ(gu)的实玎ͼ(x)
addUser()和deleteUser()Ҏ(gu)都好实现Q就是对数据库增加记录和删除记录。对于listUsers()Ҏ(gu)Q其实就是对user表的selectQ取Z个记录集。但是该怎么从listUsers()Ҏ(gu)中得到所有用L(fng)列表呢?
一个方法调用的q回值只有一个,没有多个Q所以很多情况下采用的办法就是返回值定义ؓ(f)集合cdQ比如Vector。这样就可以在listUsers()Ҏ(gu)的具体代码实现的时候,从数据库依次取出一个个记录Q插入到Vector里面来。在ȝ序里面,调用listUsers()Ҏ(gu)可以q回一个VectorQ然后再对Vector遍历操作Q就可以得到用户列表了?br />
public class User {
public static void addUser(...) {
// 数据库insert一条记?br />}
public static void deleteUser(...) {
// 数据库delete一条记?br />}
public Vector listUsers(...) {
// 数据库selectl果攑ֈ一个集合里?br />}
}
q样的设计基本合理,但是仍然有点问题。因为在设计的时候,p虑C用Java的集合类Vector来实现对不定长数据集的存放,因而违反了面向对象设计的一个原则:(x)在设计的时候不应过早的考虑具体E序语言的实现。所以必ȝ抽象的方法,和具体实现无关的Ҏ(gu)来表达业务逻辑?br />
我们知道Q通常对具有集合特征的数据l构q行遍历通常可以使用next和hasNextҎ(gu)Qnext实现取下一个用PhasNext判断是否q有元素?因此我们定义一个接口IteratorQ这个接口中定义两个Ҏ(gu)next和hasNextQ?br />
public interface Iterator {
public boolean hasNext() {}
public Object next() {}
}
而UsercȝlistUsesҎ(gu)q回值改为Iterator接口的实现类:
public class User {
...
public Iterator listUsers() {
}
...
}
q样把Usercȝ设计和具体的实现Ҏ(gu)分离开了,因ؓ(f)此时M实现了next()和hasNext()Ҏ(gu)的类都可以做为listUsers的返回|都可以被用来表达“用户列表”,而不仅仅可以使用Vector而已。比如,我可以用ArrayList来表辄户列表,因ؓ(f)ArrayList也实CIteratorQ当然我也可以自׃门写一个类来存攄户列表,只要实现next()和hasNext()Ҏ(gu)p了?br />
q样在具体的~写代码的时候,E序员具有了最大的灉|性,可以Ҏ(gu)具体的情况,采用不同的编E方法来存放用户列表。特别是降低了程序的耦合度,提高了程序的可移植性。对于上面那个JunkMail的listAllMail()Ҏ(gu)也同样应该改为接口类型?br />
然后Q在ȝ序里面就q样来用UsercȝlistUsersҎ(gu)Q?br />
User myUser = new User();
Iterator iterator = myUser.listUsers();
while (iterator.hasNext()) {
iterator.next();
}
q样可以完全不用考虑E序代码实现了,从高层次上把功能抽象出来Q定义成为接口,同时又可以把pȝ设计的很合理Q完全根据业务的需求来q行设计?br />
l语
通过上面的几个例子的设计说明Q用面向对象的思维Ҏ(gu)Q其实是一个把业务逻辑从具体的~程技术当中抽象出来的q程Q而这个抽象的q程是自上而下的,非常W合人类的思维?fn)惯Q也是先不考虑问题解决的细节,把问题的最主要的方面抽象成Z个简单的框架Q集中精力思考如何解决主要矛盾,然后在解决问题的q程中,再把问题的细节分割成一个一个小问题Q再专门去解决细节问题?br />
因而一旦牢牢的抓住了这一点,你就?x)发现在软g设计和开发过E中Q你自己L?x)不知不觉的q用面向对象的思维Ҏ(gu)来设计和~写E序Qƈ且程序的设计和开发也变得不再那么枯燥Q而一个合理运用面向对象技术进行设计和架构的YӞ更是具备了思维的艺术美感?br />
最后,愉K向对象的思维Ҏ(gu)也能l?zhn)的程序设计之路带来创作的乐趣?/span>
]]>
以下文章都是l典Q看不看随你的便Q我只希望知识掌握在更多中国人的手里Q?br />
中国有很多小朋友Q他?8,9岁或21,2岁,通过自学也写了不代码,他们有的代码写的很漂亮,一些技术细节相当出众,也很有钻研精,但是他们被一些错误的认识和观点左叻I~Z对系l,对程序的整体理解能力Q这些hQ一个网上的朋友说得很好Q他们实际上只是一些Coding fansQ压Ҏ(gu)有资格称为程序员Q但是据我所知,不少网l公司的CTO是q样的coding fans,拿着吓h的工资,做着吓h的项目,目的结局通常也很吓h?
E序员基本素质:(x)
作一个真正合格的E序员,或者说是可以真正合格完成一些代码工作的E序员,应该h的素质?
1Q团队精和协作能力
把它作ؓ(f)基本素质Qƈ不是不重要,恰恰相反Q这是程序员应该具备的最基本的,也是最重要的安w立命之本。把高水q程序员说成独行侠的都是在呓语,M个h的力量都是有限的Q即便如linusq样的天才,也需要通过l成强大的团队来创造奇q,那些遍布全球的ؓ(f)linux写核心的高手们,没有协作_是不可想象的。独行侠可以作一些赚qY件发点小财,但是一旦进入一些大pȝ的研发团队,q入商业化和产品化的开发Q务,~Zq种素质的h完全不合格了?
2Q文档习(fn)?
说高水^E序员从来不写文档的肯定是^臭未q的毛孩子,良好的文档是正规研发程中非帔R要的环节Q作Z码程序员Q?0Q的工作旉写技术文档是很正常的Q而作为高U程序员和系l分析员Q这个比例还要高很多。缺乏文档,一个Y件系l就~Z生命力,在未来的查错Q升U以?qing)模块的复用时就都?x)遇到极大的麻烦?
3Q规范化Q标准化的代码编写习(fn)?
作ؓ(f)一些外国知名Y件公司的规矩Q代码的变量命名Q代码内注释格式Q甚臛_套中行羃q的长度和函数间的空行数字都有明规定,良好的编写习(fn)惯,不但有助于代码的UL和纠错,也有助于不同技术h员之间的协作?
有些coding fans叫嚣高水q程序员写的代码旁h从来看不懂,q种叫嚣只能证明他们自己压根不配自称E序员。代码具有良好的可读性,是程序员基本的素质需求?
再看看整个linux的搭建,没有规范化和标准化的代码?fn)惯Q全球的研发协作是绝对不可想象的?
4Q需求理解能?
E序员需要理解一个模块的需求,很多朋友写E序往往只关注一个功能需求,他们把性能指标全部归结到硬Ӟ操作pȝ和开发环境上Q而忽视了本n代码的性能考虑Q有人曾l放a说写一个广告交换程序很单,q种Z来不知道在百万甚臛_万数量的访问情况下的性能指标是如何实现的Q对于这L(fng)E序员,你给他深蓝那套系l,他也做不出太极链的ƈ访能力。性能需求指标中Q稳定性,q访支撑能力以及(qing)安全性都很重要,作ؓ(f)E序员需要评估该模块在系l运营中所处的环境Q将要受到的负荷压力以及(qing)各种潜在的危险和恶意d的可能性。就q一点,一个成熟的E序员至需??q的目研发和跟t经验才有可能有心得?
5Q复用性,模块化思维能力
l常可以听到一些程序员有这L(fng)抱怨,写了几年E序Q变成了熟练工,每天都是重复写一些没有Q何新意的代码Q这其实是中国Y件h才最大浪费的地方Q一些重复性工作变成了熟练E序员的主要工作Q而这些,其实是完全可以避免的?
复用性设计,模块化思维是要程序员在完成Q何一个功能模块或函数的时候,要多想一些,不要局限在完成当前d的简单思\上,x看该模块是否可以qq个pȝ存在Q是否可以通过单的修改参数的方式在其他pȝ和应用环境下直接引用Q这样就能极大避免重复性的开发工作,如果一个Y件研发单位和工作l能够在每一ơ研发过E中都考虑到这些问题,那么E序员就不会(x)在重复性的工作中耽误太多旉Q就?x)有更多旉和精力投入到创新的代码工作中厅R?
一些好的程序模块代码,即便?0q代写成的,拿到现在攑ֈ一些系l里面作为功能模块都能适合的很好,而现在我看到的是Q很多小公司软g一升或改q就动辄全部代码重写Q大部分重复性工作无谓的费了时间和_֊?
6Q测试习(fn)?
作ؓ(f)一些商业化正规化的开发而言Q专职的试工程师是不可的Q但是ƈ不是说有了专职的试工程师程序员可以不q行自测QY件研发作Z工E而言Q一个很重要的特点就是问题发现的早Q解决的代h(hun)p低,E序员在每段代码Q每个子模块完成后进行认真的试Q就可以量一些潜在的问题最早的发现和解冻Iq样Ҏ(gu)体系l徏讄效率和可靠性就有了最大的保证?
试工作实际上需要考虑两方面,一斚w是正常调用的试Q也是看程序是否能在正常调用下完成基本功能Q这是最基本的测试职责,可惜在很多公司这成了唯一的测试Q务,实际上还差的q那Q第二方面就是异常调用的试Q比如高压力负荷下的E_性测试,用户潜在的异常输入情况下的测试,整体pȝ局部故障情况下该模块受影响状况的测试,频发的异常请求阻塞资源时的模块稳定测试等{。当然ƈ不是E序员要对自q每段代码都需要进行这U完整测试,但是E序员必L醒认识自q代码d在整体项目中的地位和各种性能需求,有针Ҏ(gu)的q行相关试q尽早发现和解决问题Q当然这需要上面提到的需求理解能力?
7Q学?fn)和ȝ的能?
E序员是人才很容易被淘汰Q很Ҏ(gu)落伍的职业,因ؓ(f)一U技术可能仅仅在三两q内h领先性,E序员如果想安n立命Q就必须不断跟进新的技术,学习(fn)新的技能?
善于学习(fn)Q对于Q何职业而言Q都是前q所必需的动力,对于E序员,q种要求更加高了。但是学?fn)也要找对目标,一些小coding fans们,他们也|z乐道于他们的学?fn)能力,一?x)学会(x)了aspQ一?x)儿学?x)了phpQ一?x)儿学?x)了jspQ他们把q个作ؓ(f)炫耀的资本,盲目的追逐一些肤的Q表面的东西和名词,做网l程序不懂通讯传输协议Q做应用E序不懂中断向量处理Q这L(fng)技术h员,不管掌握了多所谓的新语aQ永q不?x)有质的提高?
善于ȝQ也是学?fn)能力的一U体玎ͼ每次完成一个研发Q务,完成一D代码,都应当有目的的跟t该E序的应用状况和用户反馈Q随时ȝQ找到自q不Q这样逐步提高Q一个程序员才可能成长v来?
一个不具备成长性的E序员,即便眼前看是个高手,也不要选用Q因Z落伍的时候马上就C?
具备以上全部素质的hQ应当说是够格的E序员了Q请注意以上的各U素质都不是由IQ军_的,也不是大学某些课本里可以学习(fn)到的Q需要的仅仅是程序员对自己工作的认识Q是一U意识上的问题?
那么作ؓ(f)高E序员,以至于系l分析员Q也是对于一个程序项目的设计者而言Q除了应该具备上q全部素质之外,q需要具备以下素质:(x)
W一Q需求分析能?
对于E序员而言Q理解需求就可以完成合格的代码,但是对于研发目的组l和理者,他们不但要理解客户需求,更多时候还要自行制定一些需求,Z么这么说呢?
一般而言Q进行研发Q务,也许是客h出需求,也许是市场和营销部门提出的需求,q时候对于研发部门,他们看到的不是一个完整的需求,通常而言Q该需求仅仅是一些功能上的要求,或者更正规些,可能获得一个完整的用户视图Q但是这都不够,因ؓ(f)客户׃非技术因素多一些,他们可能很难提出完整和清晎ͼ或者说专业性的性能需求,但是对于目l织者和规划者,他必能够清醒认识到q些需求的存在q在完成需求分析报告的时候适当的提出,同时要完整和清晰的体现在设计说明书里面,以便于程序员~码时不?x)失去这些准则?
E序设计者必L理解用户需求所处的环境Qƈ针对性做出需求的分析QD例而言Q同样一个Y仉过ASPU用方式发布和通过License方式发布Q性能需求可能就是有区别的,前者强调的是更好的支撑能力和稳定性,而后者则可能更强调在各种q_下的普适性和安装使用的简h?
W二Q项目设计方法和程处理能力
E序设计者必能够掌握不于两到三种的项目设计方法(比如自顶至下的设计方法,比如快速原型法{等Q,q能够根据项目需求和资源搭配来选择合适的设计Ҏ(gu)q行目的整体设计。设计方法上选择不当Q就?x)耽误研发周期Q浪费研发资源,甚至影响研发效果?
一个程序设计者还需要把很多功夫用在程囄设计和处理上Q他需要做数据图以确立数据词典;他需要加工逻辑图以Ş成整体的pȝ处理程。一个流E有问题的系l,q代码多漂亮,每个模块多精_(d)也不?x)成Z个好的系l。当Ӟ做好程分析q择好项目设计方法,都需要在需求分析能力上h_的把握?
W三Q复用设计和模块化分解能?
q个g又是老调重谈Q前面基本素质上不是已经说明了这个问题吗Q?
作ؓ(f)一个从事模块Q务的E序员,他需要对他所面对的特定功能模块的复用性进行考虑Q而作Z个系l分析h员,他要面对的问题复杂的多,需要对整体pȝ按照一U模块化的分析能力分解ؓ(f)很多可复用的功能模块和函敎ͼqҎ(gu)一模块形成一个独立的设计需求。D个例子,好比是汽车生产,最早每辆汽车都是独立安装的Q每个部仉是量w定做的Q但是后来不一样了Q机器化大生产了Q一个汽车厂开始通过水U来生汽RQ独立部件开始具有一定的复用性,在后来标准化成ؓ(f)大趋势,不同型号Q品牌甚至不同厂商的汽R部g也可以进行方便的换装和升U,q时候,汽R生的效率达到最大化。Y件工E也是同L(fng)道理Q一个成熟的软g行业Q在一些相关项目和pȝ中,不同的部件是可以随意换装的,比如微Y的许多桌面YӞ在很多操作模块(如打开文gQ保存文件等{)都是复用的同一套功能模块,而这些接口又通过一些类库提供给了桌面应用程序开发者方便挂接,q就是复用化的模块设计明昄一个佐证?
一个大型的Q错l复杂的应用pȝ分解成一些相对独立的Q具有高度复用性的Qƈ能仅仅依靠几个参数完成数据联pȝ模块l合Q是作ؓ(f)高E序员和pȝ分析员一Ҏ(gu)重要的工作,合适的目设计Ҏ(gu)Q清晰的程图,是实现这一目标的重要保证?
W四Q整体项目评估能?
作ؓ(f)pȝ设计人员Q必能够从全局出发Q对目又整体的清醒认识Q比如公司的资源配置是否合理和到位,比如工程q度安排是否能最大化体现效率又不至于无法按期完成。评估项目整体和各个模块的工作量Q评估项目所需的资源,评估目可能遇到的困难,都需要大量的l验U篏Q换a之,q是一U不断ȝ的篏计才能达到的境界。在西方一些Y件系l设计的带头人都是很q长的,比如4Q?0岁,甚至更老,他们在编码方面已l远q不如年Mh那样zȝQ但是就目评估而言Q他们几十年的经验积累就是最重要和宝늚财富。中国缺q么一代程序员Q主要还不是~那U年U的E序员,而是那种q纪的程序员基本上都是研I单位作出来的,都不是从专业的品化软g研发作出来的Q他们没有能U篏那种产品化研发的l验Q这也是没有办法的事情?
W五Q团队组l管理能?
完成一个项目工E,需要团队的齐心协力Q作为项目设计者或研发的主hQ就应当有能力最大化发挥团队的整体力量,技术管理由于其专业性质Q不大同于一般的Z理Q因里面设计了一些技术性的指标和因素?
首先是工作的量化Q没有量化就很难做到合适的l效考核Q而程序量化又不是单的代码行数可以计算的,因此要求技术管理h员需要能真正评估一个模块的复杂性和工作量?
其次是对团队协作模式的调_(d)一般而言Q程序开发的协作通常分ؓ(f)组q行Q小l有ȝ序员方式的,也有民主方式的,Ҏ(gu)E序员之间的能力水^差距Q以?qing)根据项目研发的需求,选择合适的l队方式Qƈ能将责权和成员的工作d紧密l合Q这h能最大发挥组队的效率?
一个代码水q高的hQ未必能成ؓ(f)一个合格的目研发ȝQ这斚w的能力欠~往往是容易被忽视的?
lg可以看到Q作Z个主研发的负责人,一个项目设计者,所需要具备的素质和能力ƈ不是E序代码~写的能力,当然一般情况下Q一个程序员通过不断的ȝ提高辑ֈ了这U素质的时候,他所h的代码编写能力也已经相当不简单了Q但是请注意q里面的因果关系Q一个高水^的项目设计者通常已经是代码编写相当优U的h了,但是q不是一个代码相当优U的程序员可以胜任项目设计的工作Q这里面存在的也不是智商和课本的问题Q还是在于一个程序员在积累经验,逐步提升的时候没有意识到应当思考哪斚w的东西,没有有意识的项目的l织和复用设计进行揣摩,没有l常性的文档?fn)惯和ȝ?fn)惯Q不改变q些Q我们的合格的项目设计者还是非常欠~?
另外Qؓ(f)防止有无聊的人和我较真,补充一点,本文针对目标是作商业化的软g目和工E,那些U研机构的编E高手,比如法高手Q比如图象处理高手,他们的工作是研究N而非直接完成商业软gQ当然最l间接成为商业品,比如微Y研究院在作的研究NQ,因此他们的素质可能是另外的东西,q些人(专家Q,q不能说是程序员Q不能用E序员的标准去衡量?
最后补充一点东西,一个Y仉目研发的设计程是怎样的呢Q以通常标准的设计方法ؓ(f)例,Q不q笔者喜Ƣ快速原型法Q?
W一个步骤是市场调研Q技术和市场要结合才能体现最大h(hun)倹{?
W二个步骤是需求分析,q个阶段需要出三样东西Q用戯图,数据词典和用h作手册。用戯图是该Y件用P包括l端用户和管理用P所能看到的面样式Q这里面包含了很多操作方面的程和条件。数据词典是指明数据逻辑关系q加以整理的东东Q完成了数据词典Q数据库的设计就完成了一半多。用h作手册是指明了操作流E的说明书。请注意Q用h作流E和用户视图是由需求决定的Q因此应该在软g设计之前完成Q完成这些,׃ؓ(f)E序研发提供了约束和准Q很遗憾太多公司都不是这样做的,因果颠倒,序不分Q开发工作和实际需求往往因此产生隔阂p的现象?
需求分析,除了以上工作Q笔者以Z为项目设计者应当完整的做出目的性能需求说明书Q因为往往性能需求只有懂技术的人才可能理解Q这需要技术专家和需求方Q客h公司市场部门Q能够有真正的沟通和了解?
W三个步骤是概要设计Q将pȝ功能模块初步划分Qƈl出合理的研发流E和资源要求。作为快速原型设计方法,完成概要设计可以进入编码阶D了Q通常采用q种Ҏ(gu)是因为涉?qing)的研发d属于新领域,技术主h员一上来无法l出明确的详l设计说明书Q但是ƈ不是说详l设计说明书不重要,事实上快速原型法在完成原型代码后Q根据评结果和l验教训的ȝQ还要重新进行详l设计的步骤?
W四个步骤是详细设计Q这是考验技术专家设计思维的重要关卡,详细设计说明书应当把具体的模块以最‘干净’的方式(黑箱l构Q提供给~码者,使得pȝ整体模块化达到最大;一份好的详l设计说明书Q可以ɾ~码的复杂性减低到最低,实际上,严格的讲详细设计说明书应当把每个函数的每个参数的定义都精_l的提供出来Q从需求分析到概要设计到完成详l设计说明书Q一个Y仉目就应当说完成了一半了。换a之,一个大型Y件系l在完成了一半的时候,其实q没有开始一行代码工作。那些把作Y件的E序员简单理解ؓ(f)写代码的Q就从根子上犯了错误了?
W五个步骤是~码Q在规范化的研发程中,~码工作在整个项目流E里最多不?x)超q?/2Q通常?/3的时_(d)所谓磨刀不误砍柴功,设计q程完成的好Q编码效率就?x)极大提高,~码时不同模块之间的q度协调和协作是最需要小心的Q也怸个小模块的问题就可能影响了整体进度,让很多程序员因此被迫停下工作{待Q这U问题在很多研发q程中都出现q。编码时的相互沟通和应急的解决手段都是相当重要的,对于E序员而言Qbug永远存在Q你必须永远面对q个问题Q大名鼎鼎的微YQ可曾有q箋三个月不发补丁的时候吗Q从来没有!
W六个步骤是试
试有很多种Q按照测试执行方Q可以分为内部测试和外部试Q按照测试范_(d)可以分ؓ(f)模块试和整体联调;按照试条gQ可以分为正常操作情冉|试和异常情况试Q按照测试的输入范围Q可以分为全覆盖试和抽h试。以上都很好理解Q不再解释?
MQ测试同h目研发中一个相当重要的步骤Q对于一个大型YӞ3个月?q的外部试都是正常的,因ؓ(f)永远都会(x)又不可预料的问题存在?
完成试后,完成验收q完成最后的一些帮助文档,整体目才算告一D落Q当然日后少不了升Q修补等{工作,只要不是想通过一锤子买卖骗钱Q就要不停的跟踪软g的运营状况ƈ持箋修补升Q知道这个Y件被d淘汰为止?
写这些步骤算不上卖弄什么,因ؓ(f)实话讲我手边是一本《Y件工E》,在大学里q是计算Z业的必修评Q但是我知道很多E序员似乎从来都只是热衷于什么?0天精通VC》之cȝQ他们有些和我一h击队nQ没有正规学q这个专业,q有一些则早就在够学分后把q些真正有用的东西还l了老师?
|上现在也很躁Q一些coding fans乱嚷Ph视听Q实际上真正的技术专家很在|上乱发帖子的,如笔者这样不知天高地厚的Q其实实在是不上什么高手,只不q看不惯q种Ҏ(gu)术,对程序员的误解和胡说Q只好挺w而出Q做拨ؕ反正之言Q也希望那些q沉q于一些错误h士的coding fans们能认真xQ走到正途上Q毕竟那些聪明的头脑q远q没有发挥应有的价倹{?