我对分层的理解(二)

 昨天发表了我对分层的理解第一部分..今天发表第二部分.对于文章的定位,一直是围绕层与层这部分,其中牵涉到方方面面的东西.我尽量在每一篇都集中说明其中的一块..不牵涉其他内容..今天这部分主要内容将围绕层次开发的前期规划上进行总结说明.

大家在理解了需求之后,有的朋友可能就会开始急于投入项目,开始划分层次,接着根据需求分工编写业务层和数据层.界面交给美工.似乎这样的开发顺序很适合国内这样的小团队开发.但是这样的开发的可能会导致,层次衔接不明朗,后期维护难,给后期维护人员也带来不方便.后期功能扩展也不方便.造成代码的大量沉淀.

层次衔接不明朗:国内大多数的中小企业在项目管理上都存在缺陷,就是对于项目的管理化分不合理.例如:A负责业务,B负责数据,C负责美工,而初期项目经理会根据需求和大家谈需求..然后告诉你.你要干这个,你要做那个.然后大家就开始自己的工作.之后如果A遇到数据问题.就会和B商量,可能会有改动.但是这个时候如果有改动而忘记告诉C.则项目衔接有问题..如果C遇到界面表示问题需要和A解决,这个时候B不知道的话.衔接又会出现问题..类似这样的需求变动,团队缺乏合作意识的问题想必大家都可能遇到过.
我的建议:建立专职项目负责人制度.由项目负责人统一调配分发需求,即便是在开发阶段一样要提交项目负责人,由负责人解决.并在周期性的开会会议上做需求变更报告..这样就解决了团队间推诿扯皮的事情.因为项目有专职负责人,下面的开发人员有任何需求的变动,都要提交给负责人,并由负责人解决.类似古代的君主中央集权制..如果公司规模小,没有能力执行专职项目负责人制,可以考虑由小团队中的开发人员兼任.但是职责一定要明确..

后期维护难:由于现在国内开发人员流动量大,给国内的项目后期维护带来了一定的难度.解决这一问题的最好办法就是在开发阶段就要养成良好的编程习惯.俗话说的好,前人栽树后人乘凉.做程序开发就更应该是这样的.不能抱着反正做完就行了的心理.如果每个人都能在开发的时候多为以后想想,多为维护人员想想,能贯彻真正的前人栽树后人乘凉的正确思想.那么写程序是件开心的事情,维护程序更是件开心的事情.
我的建议:养成良好的编程习惯,尽量把你的方法和类中加入详细的说明吧..这不管是对于自己和以后维护人员都是有百利而无一害的事情..就如有人所说:要判断一个的程序员的代码是否优秀就看他的代码吧,例如一个代码文档你完全可以40%是代码,60%是注释..这样的代码我认为是艺术.甚至可以让其他人员象读书一样就理解了你的代码..注意:不要因为写注释的兴奋而真的把琼瑶,金庸的小说真的写到注释中哦..那样的话.嘿嘿..BOSS很生气,后果很严重!

这次暂时说到这里,下次继续说后期维护的问题.因为关于后期维护的问题比较多,牵涉到对类的理解和接口的使用.所以放在下一篇中讲述..偶需要整理下思路..因为刚才被美女瞄了一眼...现在处于极度脑重血...