??xml version="1.0" encoding="utf-8" standalone="yes"?> 2 在实现框架代码的时候,当你寚w用那U实现方式犹豫不决的Ӟ换个角度Q想一惛_果你是程序员Q喜Ƣ怎么q些框架。在实现框架的时候一定要考虑E序员是否能够理解你写框架的思\Q除非万不得已不要用一些自以ؓ(f)很高明很巧妙Q然而却很晦涩难懂的Ҏ(gu)Q那L(fng)框架Q程序员臛_合格的程序员是不愿意使用的。我想程序员和编码工人最大的区别是E序员不仅要知其?dng)q要知其所以然?/p>
3 只有在不断实践中Q才能激发你不断的求知欲。只有把学到的知识不断的应用道实践中Q你才能在学?fn)中得到满。不要ؓ(f)?jin)学习(fn)而学?fn)(学院z,不好听点是U怸谈兵Q,而是要从实际问题出发Q在解决问题的过E中不断深入Q不断ȝQ所以说Q当你离开?jin)编E的W一U,你将失去学习(fn)~程知识的欲望。当然如果你愿意Q在别的领域q有更广阔的天空Q但是请不要L说自己原来编E怎么怎么Q其实你已经被三振出局?jin)?/p>
4 惛_行一h考,想专家一样实践,一本书的名字,虽然书没有看q,但她的名子就已经非常有意思了(jin)。这岂不是我们作需求,和作架构时的座右铭吗Q既能象“外行”一L(fng)站在客户的角度思考问题,又能象“专家”一样参与到整个产品的开发和实施当中Q在实践中不断提高自我。然而,不幸的是许许多多的所谓的架构师,pȝ分析员们却正向着相反的方向迈q。“真正”的做到?jin),象“专家”一h考,象“外行”一样实践,可?zhn)呀可?zhn)?br />5设计做到什么样才叫做到位呢。我惛_有真正的开发者才有权利发a。只有有它们才是设计的真正用者和受害者。因为就我所知和所见,l大多数设计都是设计者自q游戏Q当?dng)我可能是井底之蛙了(jin)没有见q什么好的设计)(j)Q程序员所开发往往q是对着原Ş自己再进行一遍设计,且不说额外增加了(jin)多少工作量,费?jin)多时_(d)工作质量而言Q也是差Zh意。毕竟大多数情况下,设计者或UCؓ(f)架构师的在技术方面的l验都更Z富,对业务的理解也更为深入,另外׃个hq行设计在功能复用,和整体性能斚w的考虑也更完整一些。但怎么做才能熊掌和鱼兼得呢Q下面我发表一下我个h的看法:(x) ?不说?jin),说?jin)q么多,只不q是对外行h内行h的一点点感慨。趁q自p在Y件开发这个阶D,多学?fn),多ȝQؓ(f)成ؓ(f)自己?j)目中的软g的项目经理而努力?/p>
1 代码是最好的设计Q这句话不是我说的,?xp开发届 中的一位大牛说的。之所以在q里引用别h的观点,q不是自己是一个xp 的fansQ也q不时完全赞同xp 的理论,我只是觉得这句话得太对了(jin)Q对E序员来说什么设计比代码读v来更亲切呢?。其实设计无非是向开发所着传达设计者的思想Q告诉开发者系l需要开什么个对象Q具有什么属性和行ؓ(f)Q它们之间的调用关系又如何。我们在设计文档中经怋用的Ҏ(gu)是有class 图,协作图,和顺序图对上面所提到的进行描q。然而结果呢Q面对这大量的o(h)人畏惧的抽象图表Q开发者可选择的也只有是“重整江沛_后生?jin)”。想惻Iq样的设计和代码能够同步吗,q样的设计文档还有什么用呢?所以说与其是这栯不如把设计变成代码,如对象属性可以这直接在代码中体现Q方法可以只定义接口Q实现方式可以作Z码的注释Q向写需求分析用例似的来一步一步说明程序是需要怎样调用。当客户要求设文档的时候,只需要提出javadoc可以了(jin)Q而其保证和代码同步。而开发者呢Q在开发前需要阅ȝ例,?jin)解需求,然后在设计者已l搭好的代码框架中进行开发就可以?jin)。如果需要修改的话,不用在去设计文档中更改,只需要修改一下代码注释就可以?jin),Q程序员是比较懒的,不怎么愿意写写文档的)(j)。当然了(jin)Q让懒惰的程序员能够自觉地写好文档也不是一件容易事Q下面也许能l你提供一个好的方?br /> 2 交差开发能够帮助完成最好的设计文档?br /> 3 设计者在开发阶D还作什么呢Q ?br />待箋
]]>
bug 时留下的伤疤Q如果从头写一D|的代码,谁能保证你的代码没有原来那bug呢?其实我们可以采用很多重构的方法来解决Q如设计模式的开闭原则,可以很好的规避q一c问题?br /> 因此我认为,一个企业不要L频繁的发布新版本Q只有可以明的指出现有版本已经满不了(jin)?jng)场的需求了(jin)Q我们才需要重新规划。我们需要明,我们当前最需要做的是对现有版本修修补补,使之不断完善Q不断健壮。君不见Q网景的netscape 和borland 的dbasde是前R之鉴吗?
注:(x)|景的netscape 因新版本重写代码Q整整用?q的旉Q其?jng)场份额?0Q?降到?0Q?br /> borland 从些AragoQdbase的前w)(j) 也把?jng)场白白的让l了(jin) access
]]>
卛_Q但是在一个项目中Q涉?qing)到大量的沟通(正式的和非正式的Q内部的和外部的Q,和协调。如果项目组成员仅仅完成自己分内的工作,而把剩下的工作全部交l项目经理去完成Q那么工作效率之低就可想而知?jin)。这理涉?qing)到一个问题,如何提高目l成员的工作d性,dd成自己分外的Q但是自己最合适的工作呢?当然可以提高员工的工资,但是人的Ʋ望是没有止境的Q长到多合适呢Q在说公司能够承受多呢Q?br /> 可见Q涨工资不是解决问题的根本方法。因此我们需要想一些别的办法?br /> 在矩늮理的模式下,׃每个Z隶属于Q何的目Q只隶属于自q部门。因此,在项目经?br />与组员进行沟通时Q也仿佛(jng)在与其他部门q行交互一P存在q推诿,敯{等许多问题。如何解册
个问题呢Q那是让每个项目组成员都要与这个项目荣׃共。这恰恰是矩阵理存在的最大问题?br /> 在矩늮理中Q当目l成员完成一步䆾工作后,可能׃(x)撤出q个目Q因此这个组员也不会(x)?br />w心(j)的投入项目的开发,因ؓ(f)它还要想着下一个项目。项目经理常常挂在嘴边的一句话Q我的项?br />怎么怎么样了(jin)Q先不管q样说会(x)让其它项目组成员?j)里怎么惻I(j)Q但是很有目l成员会(x)说我的项目。。。。,q是Z么呢。因Z嘴里怎么_(d)目l成员在内心(j)深处没有把他当作自q目
他只需要完成自q工作可以了(jin)Q没有必要作一些额外的工作Q不在其位,不谋其政吗?q里所提到?br />是矩늮理存在的一些共性的问题Q对软Y件小l进行矩늮理存在的问题更大?jin)。众所周知QY件开?br />是一U创造性的工作Q其工作d性所产生的作用更q远大于其它行业。在《h件》认Y件工E的理
其实是对h的管理,一切管理都要以Zؓ(f)核心(j)。但是某些领|往往忽视?jin)这一点,把Y件h员当作一U可以重复利用的资源Q结果吃亏的会(x)是项目本w?br /> 也许大家?x)说了(jin),你是不当家不知柴cQ不作领g不知领导的难处,在这里发发牢?d)谁都?x)Q如果你是领|你会(x)怎么办呢Q?br /> 当然?jin),作?f)非领导的我,只是从我的角度讲?jin)一下我对这个问题的看法Q另外我也不只是在这?br />夸夸其谈Q我呢,在下面也阐述一下,如果是我Q我?x)如何管理,希望某个领导看到后也也考虑考虑?br /> 1 软g组依然存在Q但是其作用已经发生的变化。首先Y件小l对已经q入目的小l成员不?br />q行工作的安排。只能对在项目之外的软g人员q行工作安排。其ơ,软g组需要担付vҎ(gu)入职?br />软g人员q行培训的工作,不能把培训大量的工作攑ֈ真实目中,q样必然?x)降低项目的质量。再?br />软g组Q对目中一些通用的问题集中解冻I寚w目中的疑N题提供技术支持。另外Y件小l还需?br />对小l成员代码的质量q行走查Q提高Y件小l的成员的技能。当然作Y件小l成员的行政单位QY件小l成员的考核q是要有软g组d的?br /> 2 软g人员Q尽能的参与目真个生命周期Q项目紧张h紧张Q项目不紧张人员可以E微放松Q或?qing)时q行充电(sh)。忽略了(jin)软g人员的对不断学习(fn)的需求,是当前Y件管理的一大弊病。(可能有些上岗上线?jin),但这对调动Y件h员的U极性和保持相对E_的团队有q意想不到的作用Q?br /> 3 目l理Q需要对软g开发的特点Q和软g人员的管理有所?jin)解Q徏议读一诅Rh件》这本书。当?br /> 提高目l理本n的Y件素L能根本解决问题,软g目的项目经理一定要具备较强的开发能力和较ؓ(f)丰富的开发经验,公司不要?j)疼一点点工资Q它可以l公司带来的效益要远q高于此?br /> 4 目l理不要_(d)“我的项目”,应该Ҏ(gu)“我们的目”,让项目组的每个成员由一U归属感?br />作ؓ(f)一个项目组成员Q我们需要的是一U经历风雨见彩虹的成功感Q而不是一U机械的忙碌的工作?br /> 5 最后,也是每一个Y件h员都十分兛_(j)的问题,什么时候给我们换一个快点的机器呀。一个好一点的机器
比可能比更高一点的工资更具备吸引力Q对公司来讲也是更划的。(效率和h员流动上Q呵呵)(j)
]]>
2 采用用例和流E的l合形式来描q客L(fng)需求,原因如下Q?br /> 1Q由于用例采用自然语a描述Q所以Q何h可以L的进行阅诅R?br /> 2Q在一定格式的辅助下,用例描述不必受流E分支多的U束?br /> 3Q采用自然语a描述Q可以详l的描述处用L(fng)使用l节Q这些细节可能会(x)对这个项目的开发v着
军_作用?br /> 4Q加入流E图Q让h相关背景知识的hq速的?jin)整个流E的全貌。如果分支不是很多流E图
q是可以ȝ十分z易懂的?br /> 5Q好的用例对后期的设计,开发,试都是很有帮助的。甚臛_以直接作为客L(fng)培训素材
3 如何写用?br /> 1Q写用例需要结合用例图Q用例图可以让用例的读者了(jin)解整个系l提供的功能Q和与其他系l的关系。 这样可以读者的在阅ȝ例时Q在一个限定的范围内思考问题?br /> 2Q用例的格式大体上可以分为前提条ӞL功用例,扩展。当?dng)作者可以丰富用例的格式Q这?br /> 仅仅是一个最单的框架?br /> 3Q由于是在需要阶D늚用例Q因此用例尽量用L的语调来写用例。你甚至可以把用例当作一片散文来写。这里需要注意的是,在写用户U用例的时候需要把pȝ当作一个黑盒,不要Lq系l内部是如何工作?br /> 此时作者一定要以一个客L(fng)角度来考虑问题Q来描述pȝ?br /> 4Q用例可以也可以惛_函数是的写一些通用性比较强的模块,以便其他用例可以复用。如用户w䆾验证模块?br /> 5Q在写用L(fng)的用例时候,对用户用系l的l节需要描qͼ如用者的?j)态。这可能军_着用户易用度的设计?br /> 6Q在写用例的时候一定需要用完整的主谓宾来写。及(qing)谁,在做什?br /> 4 用例描述仅仅是对用户需求一个梳理的q程Q我们还需分析出其中的主要实体Q和他们的关p,在分?br /> 的过E中可能?x)对产生新的疑惑Q可以和客户?qing)时沟通。当然在设计的过E中Q也可以l箋和客h?br /> 但是Q客h不一定能够随时协调到合适h员,q将D目的推后。因此,在集中讨论期?br /> 多做一些分析,乃至设计Q原型的设计Q,可以大大减少后期的工作了(jin)量,提高客户满意度。用例,分析Q和原型 可以是在需求期间一个小的P代周期?br /> 5 在讨论需求的时候,最好是以集中会(x)议的形式q行Q参?x)者应?相关领导Q系l将来的实际使用?br /> Q技术把关h员。ؓ(f)什么者样作,和如何利用其中的微妙关系Q需要大家自己去体会(x)Q去琢磨。呵?img src ="http://www.aygfsteel.com/kevinfriend/aggbug/65965.html" width = "1" height = "1" />
]]>
不是dQ他们需要了(jin)解ؓ(f)什么这功能不能实玎ͼZ么这功能需要推后实玎ͼ在我的经验中Q项?br />中没有什么是客户提出问题Q而仅仅通过目l理的沟通就可以解决的。解决的方式往往是项目经理“无可奈何”的向客户保证××××我们一定完成。恶梦开始了(jin)QY件h员有需要不停的加班来满_户那些毫无理q需求了(jin)?br /> 我认为项目经理在客户的和目l员g应该是一个技术高手的形象Q只要这样他所作的军_才具有一定的说服力,所安排的工作才具备一定的合理性。而不是那些一行代码没有些q,而仅仅花一些钱考一些什么pmp 之类的认证的人。由于缺乏客L(fng)信QQ将D客户l过目l理Q直接找技术h员去解决问题Q这导致项目的逐渐失控?br /> 现在公司不知是怎么想的Q招聘只是考虑有没有意愿,有没有pmp而不是从实际是否具备的能力。在目中也不知多少是由于他们的无知造成工期的g误,一点点问题Q都要到处协调h去解冻I很小的一个问题一来一M知要耽误多少旉Q消耗多资源。最后还颇ؓ(f)感慨的说Q作目l理太篏?jin)。其实这不是太篏?jin),q是因ؓ(f)技术素d低造成的。IT行业所h的特Ҏ(gu)高手和庸?之间生力的差距不仅仅是几倍而是几十倍,甚至是上癑ր?br /> 不具备Y件开发背景的目l理工作q度的安排仅仅是一个漂亮的project 图表Q不具备M实际意义。由于没有亲w经历过开发,他不可能?jin)解软g开发的全过E,不可能对目q度有比较深入的控制。而是靠pmp 中过E控制的方式理软g的开发,q几乎成?jin)Y仉目开发一致命毒药。因此Y仉目的延期甚至p|则变成了(jin)必然?br /> 另外 没有作过软g人员的项目经理,在Y件h员的理斚w存在也存在问题。不?jin)解技术h员所?br />的是什么,更不可能真正调动h术h员的U极性。他们所做的仅仅是不停的催促(j)软g人员开发,其实q也不能怪他Q因为在他的眼里Q整个Y件开发是一个黑盒,他之所以急躁Q是因ؓ(f)他觉的不可控?/p>