??xml version="1.0" encoding="utf-8" standalone="yes"?>
一Q目的:(x)Z更快、更加方便处理客户(f)时发现的一些bug;
二:(x)原因Q由于目前所有版本都不稳定,在标准版下的修改可能?x)媄响到其他已交付项目的应用?br />三:(x)关于版本的处理意见:(x)
1.每交付给客户一套程序时Q要在此目录下新Z个文件夹Q存放交付时打包所需的所有源代码Q一定要包括当时数据库的表结构)Q?br /> 2.每当客户提出修改意见Ӟ要先在bug理工具的此目上做详细记录Q然后测试标准版本是否也有类似问题,再根据实际情况在标准版的目bug中做详细记录Q?br /> 3.修改时要从服务器上相应的版本下拷贝出完整的一份项目,强烈不要在原目上进行修改;
4.Ҏ(gu)客户提出的问题进行修?
5.修改完后Q认真严格测试(注意Q不能仅仅测试用h出的问题Q要全面试所有的功能Q以防由于代码复用造成其它功能出现问题Q?
6.自己试完毕Q则提交本项目(注意是本目Q暂时还不要提交标准版的Q的bug修改Q?br /> 7.最好再有其他h完整试一遍(Q最好有不同的h员来试Q;
8.l确认没问题Q则关闭本项目下的bug.
9.如果试通过则备份原版本Q一定要备䆾Q,再将本版本用修改后的覆盖Q徏议:(x)原版本存放一个月后,如无问题可以删除Q如果硬盘空间够大Q则可以保留至下一个版本更新时再删除)Q?br /> 10.按相同的Ҏ(gu)修改标准版下的问题(不一定完全相同,有时可能Z辑ֈ兼容需要添加额外的东西Q根据实际情况,但目的不变,是解决标准版下出现的相同问题)Q?br /> 11.自己试完毕Q则提交标准版的bug修改Q?br /> 12. 再有其他人完整测试一遍(同样Q最好有不同的h员来试Q;
13. l确认没问题Q则关闭标准版下的bug.
四:(x)好处
1.版本控制工具上的各个目的代码共享(q所有代码,只是共同功能的代码)Q可以达C改一ơ,其他通用Q而不必每个项目都L斎ͼ
2.保留最新客户处的项目源代码Q包括表l构Q,可以更快更及(qing)时地针对用户的问题进行调试修攏V?/p>
原来在作修改用户Ӟ׃考虑到角色权限的改变Q我q接把所有用戯色相关的l角色清掉重建,然而在修改状态时Q又重复调用了这个方法,死锁在所隑օ了?br />
考虑到这个错误引发的问题Q我有两Ҏ(gu)触,一是功能最好不要叠加,否则造成的连锁反应很难调试;二是不应该偷工减料,应该针对不同的需求实C同的功能Q忌讛_制粘_(d)很容易引发许多莫名其妙的问题。在出现大量复制_脓(chung)的功能时Q尽可能的重构自q代码Q这一点也许有些困难,但要可能的dQ目的是减轻后箋工程的维护量Q?img src ="http://www.aygfsteel.com/TrampEagle/aggbug/61653.html" width = "1" height = "1" />
codecomplete_101.part2.rar
codecomplete_101.part3.rar
目前Q我们国家大多数的Y件公司,都有着极不明确的项目开发计划,大多都围l着短期的市场需求{Q因为它直接关系着老板的腰包,很少有经q长旉的市研的。于是,当市场开始需要什么东西时Q大家一H蜂的都dQ很有够静下心来和用户仔细交流沟通,原因是旉太紧Q他们担心这D交沟通的旉?x)gq项目的开发时_(d)?x)被其它公司占领先机Q因为,像有的E序员所说的Q我们根本就不知道客L(fng)竟想要什么,因ؓ(f)客户他自己就不知道自己想要什么。他们争着看谁在最短的旉里能够拿Z点东西,即用户有一百个的不满意。然而老板认ؓ(f)q样他们抢占了先机Q就能够拿出来作为同用户q行谈判的筹码,也不它的性能的优劣,然后把推销的光荣而艰巨的d丢给销售或业务人员Q市场的占有份额完全靠这些h员的推销能力Q也不管他用什么途径Q至于以后的问题嘛,以后再慢慢说。于是问题就逐个暴露出来了:(x)
׃Z抢占市场Q需要尽快地制定一份需求分析说明,但是q䆾需求ƈ不是较ؓ(f)完善的(当然了,在没能达到用L(fng)满意之前Q也不可能有癑ֈ之百的完善,因ؓ(f)众所周知的原因,客户的需求是不断的变化的。我们这里说的是可能的完善Q,因ؓ(f)我们q未同我们诸多的惌中的Q或是预期的Q客戯行较多的沟通,可能的就是依赖个别的比较或是非常熟?zhn)q方面的人员来简单的分析制定一些需求计划文(有的甚至Ҏ(gu)没有Q何文,完全地凭口头的指C)。其实原因很单,因ؓ(f)老板有要求,必须要在多长旉内搞出来Q否则。。。。。。所以一切从了,C愿浪费一点点的时间同客户q行M的交?/SPAN>
q就牉|C个问题,如果那些制定需求的人对所开发的行业实是专家的,能够考虑到面临客L(fng)可能多的需求变化时Q这是非常q运的,然而,不可能我们每家公叔R有一些这斚w的专业h才,何况现在的社?x)提倡打倒权威,我们的客户似乎也特别热衷于此Q他总能提出一些需要你改变需求的问题Q不为别的,只ؓ(f)让你知道q方面他也是“行家”,所以开发之前我们也要尤其尊重这些h的看法,即他们真的一无所知。然而时间就是金钱,我们不会(x)费旉dq种解,不会(x)和他们沟通这个问题的比较好的处理办法Q因为我们没有时_(d)我们?x)认为我们所做的是最好的Q即使用h一百个的不满意Q所以ؓ(f)了避免出现类似的情况Qؓ(f)了避免浪费向那些白吃用户们解释的旉Q我们有的项目组Q或公司Q,q脆闭门造R了?/SPAN>
接下来,很单了Q需求分析有了,赶紧搭徏框架Q徏立数据结构,分配d了,也不ȝ什么文了。这时候的老板恨不得你明天p拿出来一个东ѝ没话说了,开始敲代码了?/SPAN>
q里又出现几个问题Q?/SPAN>
有时候(q不是所有时候)Q可能我们公司比较成熟的技术,刚好是现在的客户所厌倦或是不喜欢的,他们通过某些途径知道或是了解C一些比较新的技术,有些对他们来说只是些丽的花Ӟ但他们就要求用这个,没办法,֮是上帝嘛,我们引进。这Ӟ如果到一些比较慷慨的老板Q还好办些,可以花高薪聘请一些高手,假若要是q样的话Q也q不太差,q样我们可以省却很多用来解决项目开发过E中可能到的难题的旉Q同Ӟ他们都有着比较良好的开发项目的?fn)惯Q我自己以ؓ(f)Q如果没有良好的开发项目习(fn)惯的人,水^再高Q也不能U得上是高手Q最多只能说是字典)Q他们在分析处理问题Ӟ本n׃(x)考虑很多用户需求本w的变化。这P我们也会(x)省出一部分开发时间和一部分重构的时间?/SPAN>
然而,q不是所有的老板都很hQ也q不是说所有的人都是高手(甚至有的公司Z降低开发成本,Ҏ(gu)没有或不会(x)L聘高手)Q于是,在开发阶D问题就出来了,一些入门的程序员Q面对着崭新的从未接触过的行业需求,痛苦而无奈的敲着׃八糟的代码,他们面对着很多早已l不是问题的问题而陷入查找解册料的泥沼中,不能自拔Q同时还要进行着莫名的需求的变更。ƈ且,有些公司Qؓ(f)了加快项目的q度Q在开始阶D,开始加班加点地工作Q终于有些h员承受不住这U折,开始纷U槽走了,然而,他们不知道的是只不过从这个地pC另一个地狱;另一部分人,虽然没有赎ͼ但是心情烦躁hQ开始变得失落,没有M的成感Q整天似乎就是ؓ(f)了工作而工作,没有了乐,~程再也不是一Un受了Q而是一Q务,效率来低Q但是还要赶旉Q因为时间太紧了Q同Ӟ走的一部分人员Q又需要有新的人员来补充,重新了解需求,了解已走的h的编E习(fn)惯,修改甚至重写一些不太完善或卛_完善的代码,如果没有较ؓ(f)完备的文档,p的时间就更长一炏V然而我们没有时_(d)不可能让他花贚w么多的时间去熟?zhn)Q去了解Q他需要匆忙上阵,q要能够解围保驾Q于是,他就开始按照自己新的一套风格做自己被要求要做的东西Q周而复始,代码来难以维护。然而时间还是这样不紧不慢的走着Q需求就在这个时间的逝中Q开始不断地发生着或大或小的变化,于是Q大家也跟着日复一日地修改以前~写的代码,同时q要l箋增加那些新的需求里的功能?/SPAN>
好了Q终于有一天,你自以ؓ(f)可以长出一口气了,因ؓ(f)Q在你看来,需求里的功能似乎都已经有了Q始乎这个项目也已经开发完毕了。于是,开始向老板汇报Q开始拿d用户演示Q虽焉些笨蛋什么都不会(x)Q但是还要给他们解释Q给他们做培训,请他们提要求Q因为,q时候才发现Q那些白吃们拿着自己惌?/SPAN>money。当Ӟ客户们也不会(x)攑ּ展现自己才华的机?x),各种意见、需求变_(d)UL(fng)从地底冒了出来,然后对这些意见和需求重新评伎ͼ重新调整规划Q重C攚w求文,调整数据l构Q因为客戯然不是上帝,但是人家掌握着财政大权Q掌握着我们的经命脉。于是,一切似乎都又不那么好Q一切都又变得ؕ七八p,Z应付不同的客P我们开始针对不同的用户q行不同的修改,因ؓ(f)旉Q也许只有这P我们才可能尽快地满某个用户Q一个又一个版本出CQ当大部分客户开始要求修改一些东西时Q不同的版本一个接着一个开始修改,Q再加上有些版本的升U,以致后来有的公司Q同一个Y件竟有上百个不同的版本。我们一Ҏ(gu)加着新的内容Q一边修改着软g中的bug,同时抱怨着旉太紧。我们不断地抱怨说Q如果某个问题当时给我多长多长时间的话,现在׃?x)怎样怎样, g一切都是时间的错?/SPAN>
然而说实话Q即使一切ƈ不都是时间的错,但时间在q里q是起到了至关重要的作用Q最L(fng)Q如果时间不是很紧迫Q我们可以制定一份相对较为完善的需求分析,我们也能够进行一些合适的业务知识的培训,不可否认Q这样对我们整个目开发会(x)有不帮助?/SPAN>
然而,我想说的Q其实ƈ不单单的是市场需求的旉紧,q只是一个客观原因,q个问题我们是避免不了的Q但q真的是旉紧吗Q我看未必,如果真的是因为时间紧Q那极有可能是我们在不知不觉中浪费了太多。想想上面的情况Q我们可以通过其它途径来加快整个项目的q程Q比如,高薪聘请一些高手,q对于一个Y件公司绝Ҏ(gu)很有必要的,q样最L(fng)可以减少一些不必要的查询如何解决那些早已不是问题的问题的时_(d)同时他们q能够预到某些做法可能?x)出现的问题Q毕竟他们是有经验的Q这样也?x)减不必要的回头率。其实这节省的是旉Q也是金钱。还有,如果刚开始我们能够尽可能多的同用戯行交沟通,也会(x)减少我们诸多的需求变_(d)q样节省的也不仅仅是旉?/SPAN>
当然一个项目开发的成功与否Q还有很多其他重要的因素Q即使这个时_(d)也还有很多方斚w面,然而,一个项目刚开始时Q如果先把成本放在第一位,一切都要考虑降低成本Q最l会(x)发觉?x)消耗更大的成本Q因为,旉是项目开发中最大的成本。所以,一旦我们能够把握住q个目在时间上的进度,q个目即刚开始做Q也已经是很成功的了Q?/SPAN>
声明Q这只是我在目开发过E中的一些感想体?x),仅代表个点,q不针对具体公司和具体h员!同时q䆾文章q在l箋更新中,Ƣ迎大家一h探讨Q项目开发的得失Q?/SPAN>