软件开发


今天主要从项目经理的角度讲讲软件开发中遇到的问题与解决的方法。项目经理经常面临及早交付产品的巨大压力,而其中时间是最关键的,究竟如何才能完成任务?

###一、代码审查的重要性

    假如你的团队中有两个人,知识面相同,编程技巧也相当。但是在实际开发中A实现产品功能的速度远远超过B。而实际上是当A正着力于快速完成编码时,B正花时间写代码并对其进行重构,一旦程序完整运行起来就分块进行测试与重构。假设你不知道这些,那么作为项目经理的你显然会认为A表现的更好,不是吗?这时就需要了解情况,并做代码审查。

###二、技术债务不能欠

    技术债务其实是每一个开发者都会遇到的问题,在项目快到截止日期我们想到的绝对是管他三七二十一,先把代码提交了再说。这有时是迫不得已,好的开发者也许会在后期选择重构甚至重写这部分代码,而大多数,呵呵。作为项目经理,必须做到在项目收尾时估计这期间可能产生的技术债务,并在事后合理安排重构这部分代码。

###三、编码规范

    首先,作为整个项目的负责人,你必须意识到,整个项目期间会有人离开,会有新人进来。在这个时候,整个项目的进度必然会减慢。如何将这个人员交替阶段的问题降到最低,这是必须考虑的。最好的解决办法就是做代码的统一规划,制定一套人性化的编码规范,让整个团队拥有整体的编码风格。当然这人性化三个字说起来容易,实现起来就很难了,毕竟每个人都有自己的编码风格,如果要考虑到所有人,必须首先对团队成员编程风格非常了解,同时了解哪些人适应性更强,哪些人不喜欢改变自己的风格。这里有一份google的《java编码规范》,可以值得你参考。

###四、项目架构

    在很多时候,作为一个团队的领导者,更多的是需要你去从一个系统的角度搭建好项目框架。对于一个服务器端架构,抽象角度看设计模式你是必须能够熟练运用了,至少常用的那几种应该用在什么地方你是要知道的;在实际项目中,应该采用整体统一自顶向下的设计方式还是分布迭代模块化设计亦或两者同时使用,都需要根据实际业务逻辑来抉择。对于一个客户端架构,也许只需要常用的工厂,观察,适配,代理,命令,模板,这些要知道。客户端更重要的是用户界面,与用户打交道的一定要有优秀的交互体验,不要认为这不关你的事,一个按钮的响应时间有可能决定一个用户的去留。服务器端则需要更多的考虑安全性,在设计中要确保即使客户端完全开源也不会影响到服务器的正常运行。

###五、不要指望完美的开发

    软件开发中有两个定律,28定律和60/60。用20%的时间完成80%的内容,用80%的时间完成剩下20%的内容;软件生命周期中60%的费用与维护有关,而维护活动中有60%的费用和改进相关。每一个发布的软件产品中都不可避免的有BUG,既有严重的原因(比如忽视了语言特性或细节处理)也有尚可原谅的原因(比如沟通或理解不畅)。而BUG却是软件发生变化的根源,因为当我们识别出BUG时就会重构代码来修复它们,从而也会在这个过程中增加新的BUG。因此一次开发出完美的产品是不可能的,更多的是需要你从开发那一刻就考虑到未来可能的无数次迭代,从而预留好可能会扩展改动的接口。

    以上几点,是有关软件开发过程中,项目经理所应该意识到的东西。有我自己的感悟,也有根据书本的理解,也有书本的原话,有什么写的不对的还希望大家能够严厉指出与批评。唯有在压力下才能逼迫自己学会更多,记的更牢。愿我们共同成长。



软件开发


今天主要从项目经理的角度讲讲软件开发中遇到的问题与解决的方法。项目经理经常面临及早交付产品的巨大压力,而其中时间是最关键的,究竟如何才能完成任务?

###一、代码审查的重要性

    假如你的团队中有两个人,知识面相同,编程技巧也相当。但是在实际开发中A实现产品功能的速度远远超过B。而实际上是当A正着力于快速完成编码时,B正花时间写代码并对其进行重构,一旦程序完整运行起来就分块进行测试与重构。假设你不知道这些,那么作为项目经理的你显然会认为A表现的更好,不是吗?这时就需要了解情况,并做代码审查。

###二、技术债务不能欠

    技术债务其实是每一个开发者都会遇到的问题,在项目快到截止日期我们想到的绝对是管他三七二十一,先把代码提交了再说。这有时是迫不得已,好的开发者也许会在后期选择重构甚至重写这部分代码,而大多数,呵呵。作为项目经理,必须做到在项目收尾时估计这期间可能产生的技术债务,并在事后合理安排重构这部分代码。

###三、编码规范

    首先,作为整个项目的负责人,你必须意识到,整个项目期间会有人离开,会有新人进来。在这个时候,整个项目的进度必然会减慢。如何将这个人员交替阶段的问题降到最低,这是必须考虑的。最好的解决办法就是做代码的统一规划,制定一套人性化的编码规范,让整个团队拥有整体的编码风格。当然这人性化三个字说起来容易,实现起来就很难了,毕竟每个人都有自己的编码风格,如果要考虑到所有人,必须首先对团队成员编程风格非常了解,同时了解哪些人适应性更强,哪些人不喜欢改变自己的风格。这里有一份google的《java编码规范》,可以值得你参考。

###四、项目架构

    在很多时候,作为一个团队的领导者,更多的是需要你去从一个系统的角度搭建好项目框架。对于一个服务器端架构,抽象角度看设计模式你是必须能够熟练运用了,至少常用的那几种应该用在什么地方你是要知道的;在实际项目中,应该采用整体统一自顶向下的设计方式还是分布迭代模块化设计亦或两者同时使用,都需要根据实际业务逻辑来抉择。对于一个客户端架构,也许只需要常用的工厂,观察,适配,代理,命令,模板,这些要知道。客户端更重要的是用户界面,与用户打交道的一定要有优秀的交互体验,不要认为这不关你的事,一个按钮的响应时间有可能决定一个用户的去留。服务器端则需要更多的考虑安全性,在设计中要确保即使客户端完全开源也不会影响到服务器的正常运行。

###五、不要指望完美的开发

    软件开发中有两个定律,28定律和60/60。用20%的时间完成80%的内容,用80%的时间完成剩下20%的内容;软件生命周期中60%的费用与维护有关,而维护活动中有60%的费用和改进相关。每一个发布的软件产品中都不可避免的有BUG,既有严重的原因(比如忽视了语言特性或细节处理)也有尚可原谅的原因(比如沟通或理解不畅)。而BUG却是软件发生变化的根源,因为当我们识别出BUG时就会重构代码来修复它们,从而也会在这个过程中增加新的BUG。因此一次开发出完美的产品是不可能的,更多的是需要你从开发那一刻就考虑到未来可能的无数次迭代,从而预留好可能会扩展改动的接口。

    以上几点,是有关软件开发过程中,项目经理所应该意识到的东西。有我自己的感悟,也有根据书本的理解,也有书本的原话,有什么写的不对的还希望大家能够严厉指出与批评。唯有在压力下才能逼迫自己学会更多,记的更牢。愿我们共同成长。