开发者社区> 狼人2007> 正文

艾伟也谈项目管理,软件开发前期设计时的注意事项

简介:   说起软件设计,我们可能每个人都做过,但是什么样的方案才是好的设计方案?如何才能设计出一个好的设计方案?在设计过程中需要注意哪些呢?不要总是说:低耦合、可维护性、可扩展性、简易性、可重用性等,本文试图另一个角度出发,带着前面的这些问题,使大家能明白那些问题的答案,并与大家一起探讨。
+关注继续查看

  说起软件设计,我们可能每个人都做过,但是什么样的方案才是好的设计方案?如何才能设计出一个好的设计方案?在设计过程中需要注意哪些呢?不要总是说:低耦合、可维护性、可扩展性、简易性、可重用性等,本文试图另一个角度出发,带着前面的这些问题,使大家能明白那些问题的答案,并与大家一起探讨。

  什么样的方案才是好的设计方案?

  当我们完成了一个良好的设计方案后,我们回头再仔细分析是什么因素影响了我们的思路,使我们最终完成(确切的说是选择了)了这个设计方案(而不是另一个),我们会发现这些因素是:用户功能性的需求、技术性能上的要求和研发成本(或能力)的制约,当然其实还有一些其它因素如:客户主观上的要求、审美或商务因素、向前兼容性要求等,不过这些因素多半是一些非技术性因素,我们在此不做过多讨论;能否很好的满足这些因素就决定了一个设计方案是否是一个好的设计方案,所以我们在设计之初就必须对这些因素加以充分的考虑。

  如何才能设计出一个好的设计方案?

  但事实上,基本上没有一个方案是可以每个因素都能百分之百满足的,一个好的设计方案,往往是一个平衡的结果,这也是为什么我们在讨论设计方案是总是可能争论不休的原因,因为不同的人从不同的角度出发都可以得到他认为好的一个方案,人们总是会有各自的理由,而且那些理由都是有道理的,但请大家记住:一个好的设计方案,往往是一个平衡的结果。从某种意义上说能否做好平衡是决定一个方案是否是好的方案的关键,尤其是对那些复杂的大的设计方案。

  平衡的艺术

  但怎样才能做好平衡呢? 答案显然不是:一碗水要端平。有一个著名的原理叫 28 原理,它同样也适合我们软件开发的规律,我们的百分之 80 的精力设计和开发的部分只给我们带来了百分之 20 的回报,或者说,我们百分之 80 的回报只是我们的百分之 20 的努力得来的,这个原理告诉我们,我们在平衡时要抓住重点,那些非重点的部分,如果必要可以舍弃,舍弃它们可能会带来更大的价值。下面我们先分析一下前面提到的几个关键因素来仔细讨论下平衡的艺术。

  用户功能性的需求

  毫无疑问,我们的软件最终的目的就是为了要满足用户的需求,由于我们要设计的是一个产品型的软件,这就决定了我们的需求不是很好明确,面可能比较广,甚至有些需求可能还是我们自己想象出来的,但正因为如此我们才有平衡的必要,试想如果我们做的是一个项目,那只需要按照甲方的要求完成即可,合同上甚至很明确要求了,此时也没有多少需要平衡的了。一个产品型的软件,要把百分之80 以上用户都用的功能进行良好的设计做到易用好用性能出众并投入大量人力研发,而那些 50% 用户会用到的需求就可以少投入些人力与时间,那些百分之 5 用户才可能会用的功能且需要耗费大量人力时间的甚至可以舍弃不做。

  但平衡也不仅仅是在与选择做与不做某个功能,更在于怎么做某个功能,一般对于用户的需求我们会有下面几个实现方式:

  1 实现一个简单易用、设计良好、100% 满足用户需求的界面或功能

  2 通过一些界面上的选项设置来实现用户的需求

  3 通过手工修改一些配置文件来实现用户的需求(这种实现方式可能需要的研发资源只占第一种实现方式的1% )

  4 通过脚本来实现用户的需求

  5 通过插件或定制开发来实现用户的需求(后2 种方式其实就是说现在不考虑这个需求,以后就算有了我们能支持即可)

  不同的实现方式需要投入不同的量级的研发资源,从上至下占用研发资源越来越少,这就是我们需要做平衡的地方。

  技术性能上的要求

  用户总希望在软件界面上执行任何操作都能立即得到结果、希望系统能支持越来越多的在线并发、希望系统能全年不停机运行不出任何错误,希望系统能兼容各种平台…… ,所以对我们的系统有很多性能上的要求,要求我们必须支持集群、各种高速缓存、多语言、支持事务操作等,有些性能要求是必须在设计之初加以认真考虑的,因为从以往的经验来看,如果出于研发成本的考虑,系统一开始没有考虑集群、多语言、事务,而在以后系统成型后再予以考虑,那会往往付出更大的代价,这种代价有时是伤筋动骨的。

  同样是满足用户功能上的需要,一个实现需要投入大量研发资源,但程序效率很高,而另一个只需要少量的研发资源,但程序效率稍差,此时该如何平衡呢?相信大多数人都能做出正确的选择,要综合考虑:目前可用的人力资源数量、需要投入的研发资源的差异,模块的使用频度的因素;我经常说,对于客户端应用来说在用户的一次界面操作中只执行一次的函数就可以少花点时间实现,因为3ms 完成一个操作的执行和 300ms 完成一个菜单的执行其实对用户来讲是差别不大的,但这个并不适用与服务器端应用,服务器端应用还需要考虑到在线人数,如果能 3ms 完成就能支持更多的在线用户。

  研发成本(或能力)的制约

  这个因素往往是我们最应该多考虑,但是经常缺忽视的一个因素。

  以一个工程师一年开发3 个模块和一年让他开发 10 个模块来做个比较,只开发 3 个模块时,他基本上可以做到让每个模块完成到 90 分以上,包括代码质量、测试单元、文档等,还能有些时间学习和研究些新技术,并能保持一个愉快的心情高效率的工作下去;但是如果一年让他开发 10 个模块,他可能只能勉强做到让每个模块完成 60 分以上,代码可能有考虑不周全留下隐患、测试覆盖率不高、文档欠缺,终日忙于赶进度没时间充电,工作疲惫效率低下。

  多半的研发工程师是乐观的,在开始的时候自信满满,过低的估计了研发需要的时间,我经常说,要把一个模块完成到60 分可能 1 个人月,要完成到 80 分可能就要 3 个人月,要完成到 90 分以上可能需要 8 个人月,这个增长的比例并不是直线性的而是抛物线形的,所以研发周期往往难以估计,我们必须为将来准备足够的缓冲时间,某种意义说,越多越好。

  所以这也正是在上面的一些平衡过程中,有一些因素要让位于研发资源的投入的重要原因,一个为将来的研发困难做好了充分准备的设计方案才能算是一个好的方案。

  在设计过程中需要注意哪些呢?

  从需求出发

  从用户角度理解的需求出发考虑总是没错的,最忌设计时只考虑技术方面的问题,当然技术方面的问题也必须予以考虑,但前提是必须对需求最好充分的了解和分析,从需求出发并不是说需求最大,需求有时也必须让位于其他的一些因素,要做好平衡。

  从一开始就考虑那些影响面很广的技术要求

  这些因素很可能严重的影响设计,必须提前予以研究,这种研究可以是脱离需求的零散的,有时甚至可以写一些测试代码,但最终必须还是从需求出发,在充分的了解了各种技术点之后,再决定自己的最终设计

  充分考虑研发资源成本

  再好的设计没有付诸实施的资本也不行,所以还是那句话,要做好平衡。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
艾伟也谈项目管理,成功软件项目管理的奥秘
  如何入门并设定软件成功的目标    1、如何开始项目管理(如何入门) 实践技能建议 要点说明 1.设定优先级 1)         为团队成员提供服务 2)         满足组织客户的需求 3)         从事自己相关的项目 2.分析自我能力差距 人员管理(人际关系、解决冲突、推销想法) 聆听技巧 锻炼演讲表达能力 3.
1091 0
艾伟也谈项目管理,软件开发前期设计时的注意事项
  说起软件设计,我们可能每个人都做过,但是什么样的方案才是好的设计方案?如何才能设计出一个好的设计方案?在设计过程中需要注意哪些呢?不要总是说:低耦合、可维护性、可扩展性、简易性、可重用性等,本文试图另一个角度出发,带着前面的这些问题,使大家能明白那些问题的答案,并与大家一起探讨。
923 0
艾伟也谈项目管理,找出软件开发过程中的BUG,你需要火眼金睛
  1)Bug大都出现在程序员的编码过程中。测试人员工作之一就是找出Bug,面对那些难以被人发现的Bug,测试人员通常会采取哪些手段?以您的经验,对广大测试人员有什么好的建议?对于开发人员,您有什么建议让他们减少Bug的产生?   之所以难以发现,大多是测试案例不够完整,检查测试案例是否全面覆盖了需求,等价类划得是不是够细有助于发现更多的问题。
1330 0
使用OpenApi弹性释放和设置云服务器ECS释放
云服务器ECS的一个重要特性就是按需创建资源。您可以在业务高峰期按需弹性的自定义规则进行资源创建,在完成业务计算的时候释放资源。本篇将提供几个Tips帮助您更加容易和自动化的完成云服务器的释放和弹性设置。
18344 0
【钉钉搭】低代码模版系列——软件项目管理|一个表单的作用有多大?
钉钉搭低代码模版系列上线啦,首期为大家带来的是软件项目管理,这是一个适用IT企业软件项目管理的模版,可以实现从项目立项、到进度计划、任务安排、工时统计等一站式管理,跟踪任务进度,存储项目文档,即时讨论项目相关问题,实现IT企业研发项目全过程管理。
477 0
艾伟也谈项目管理,软件架构师之职责范围
  由于国内外软件土壤差别巨大,适合国外的一些理论在国内不一定行的通,而国内的一些资料往往都是根据国外的资料直接搬过来用的,这也直接导致国外的软件架构师在国内变得水土不服。今天本篇随笔的内容则是在一些培训资料的基础上,加上自己的思考,总结出来的适合国情的软件架构师职责范围。
1056 0
+关注
狼人2007
个人对技术的追求:代码少而精捍;思路清晰美观;可扩展好维护;技术驱动商业; 人生格言:只要你有信念,有追求,并且坚持,那你一定比随波逐流,行得远行得正...
3526
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
OceanBase 入门到实战教程
立即下载
阿里云图数据库GDB,加速开启“图智”未来.ppt
立即下载
实时数仓Hologres技术实战一本通2.0版(下)
立即下载