【软件设计】深入理解软件的需求

版权声明:欢迎转载 https://blog.csdn.net/antony1776/article/details/77575078

这里的软件,可以是个小程序、小工具,可以是个框架、组件,也可以是个系统。

1 软件的理想

对很多开发人员来说,需求是个比较笼统、模糊的概念。如果不在开发运维的过程中,多揣摩多思考,那么需求这个东西就会变的越来越陌生,甚至觉得不那么重要,不那么相关!

那么到底需求是什么?

我说——需求,是软件的理想!“做人如果没有理想,跟咸鱼有什么区别!”同样,软件也应该有软件的理想,没有理想的软件连咸鱼都不如,会成为一坨si,一坨开发人员“烦”,运维人员“怕”,用户“骂”的一坨si!

2 客户需求是衡量软件的最低标准

既然,谈到了理想,那么什么样的理想?谁关心这些理想?

这里写图片描述

有图可见,软件系统的利益攸关方为: 开发人员、运维人员、客户;软件不单单是客户的软件,还是开发人员的亲儿子,运维人员的好兄弟!在软件系统产生之前,每一方对其都应该是有期待、有幻想的,这些期望和幻想便是软件的理想,就是需求!

某次年会上,一位销售举杯向研发敬酒,说,“我们的工作是向客户撒谎,而你们的工作就是让谎言成为现实!”这时,搞运维的小伙伴们摇着头,一脸忧伤。卖掉软件,只不过是万里长征的第一步,部署,更新,升级,故障修复,问题分析,性能评估,等等等等,路还远着呢!

为什么要提devops,就是因为很多人懈怠了、麻木了,以为满足客户需求就万事大吉了!

要知道,需求 ≠ 客户需求!客户需求是衡量一个软件的最低标准!

软件的理想,应该是客户满意,运维放心,开发喜爱,大家好才是真的好!

3 做一名高尚的开发人员

这里写图片描述

开发人员是个集合概念,由一个个的程序员组成。相对于软件来说,“开发人员”这个集体并没有想象中那么稳定,今天A走了,明天B来了,那么就要进行“知识交接”。常常是,软件还在卖、在不断扩展、在运营,可开发软件的程序员却是换了一茬又一茬。另外 A 开发了 X 模块,有了bug,可能需要 D 来分析排查,那么 D 就要理解 X 的逻辑和机制,这里也涉及到“知识交接”。后续,可能又 C 负责系统的重构,那么 C 就要对系统的前世今生有个彻彻底底的认识!

A 希望搞“敏捷”,去文档化,什么设计文档、架构图、接口模型的,统统简化,手里拿着一份客户需求,不管三七二十一,就是干!什么单元测试,老子的代码不用测!什么,想了解细节,统统去看代码!“我死之后,管他妈的洪水滔天!”这是很多程序员的心里写照,因此命名不讲究,风格不统一,注释很敷衍,文档残缺不全,设计时毫无原则 。。。。

B、C、D 统统懵逼,齐声说——我们的软件应该是有理想的!我们应该做一名高尚的开发人员!有理想、有追求、有节操,为伟大的共产主义事业,奋斗不息!

这里写图片描述

易理解很重要!

在开发过程中,程序员应该多向开源软件看齐,开源软件有很多好的原则、习惯、范式,尤其是在易理解性上。当我们在阅读和学习开源软件时,我们对它有什么期望呢?希望有详细的文档,比如,设计文档,接口文档,模型文档,最好哪位大神再写点《xxx源码分析》的文章,设计文档最好深入浅出,图形并茂,最好有范例,等等等等。使用或学习某些组件、框架后,常常会说,xxx好重啊,难懂,没资料啊,太难用等等。所有这些期望或评价,都关乎软件的可理解性!

子曰:己所不欲,勿施于人。在软件开发时,同时应该做到“己所欲,施于人”。

        1 缺陷处理时的开发人员;
        2 接手后续开发任务的开发人员;
        3 学习软件系统的新员工;
        4 自己;

如果,前期为了赶进度,特别忽视软件在可理解上的重要意义,那么后期任务交接、缺陷处理和功能扩展的时候,必将付出血的代价。

易扩展是一个循序渐进的过程,可能还要与重构相结合,是不断发现设计或结构上的问题,不断优化的过程。就像网站的结构一样,从单服务器,到业务存储分离,再到分布式,是在需求的驱动下,慢慢完善。易测试,也是软件开发中至关重要的一面。

4 运维人员的忧伤

毫不夸张的说,运维几乎占了软件整个生命周期的全部,相较之下,开发不过是“十月怀胎”。一个软件,会是长命百岁,还是少小夭折,运维期很重要!

部署、配置、更新、升级,统计、评估、业务跟踪、问题定位!如果在开发时,没有站在运维的角度去思考、去设计,那么这样的软件对运维人员来说将是灾难。这里的运维人员,不单单是一线的技术,还包括后台的研发,研发将会被无穷无尽的bug搞的怀疑人生!

这里写图片描述

在运维人员眼中,怎样的软件才算好软件呢?

易管理:部署方便,配置灵活,最好能提供多种模式,有“一键式”的傻瓜模式,也有高阶模式,用起来很有成就感的那种!快速恢复的能力,当出现故障的时候,能及时恢复!

易度量:有时跟现场技术交流时,常常听到,“慢”、“卡顿”,等等定性的,主观的词汇,为什么呢?就是因为软件自身是不可度量的。是io瓶颈,还是cpu瓶颈,负载到底多大?接口使用率,资源占用率,这些信息必须是软件自省的。只有这样才能提高运维的效率。

比如,二八定律,系统接口,无论是对外接口还是内部接口,肯定有些是频繁被调用的,有些甚至从来都没被用过,那么接口使用率就很重要,对后续优化,接口重构,都很有意义!

易分析,其实运维过程中,大部分的工作就是分析,包括系统诊断,问题检测,日志系统,业务跟踪系统,性能评估系统,资源统计系统。这些模块都不是必须的,但是有的话就会非常利于运维!

5 客户不懂软件

这里写图片描述

客户: 可用性,可靠性(稳定,安全,好用不贵),易用性

可用性,就是满足客户的功能性需求,解决客户的现实问题!是对软件开发人员最朴素、最坦诚的要求,恰如“女的,活的”这般的相亲需求。

可靠性,要求软件稳定、健壮,安全,正确,不要太娇贵了,有点压力就down;也不要太马虎了,时不时就给点错误数据;更不能太随便了,门户大开,对非法入侵毫无抵抗力!

易用性,是个相对高级的需求了,是种主观的、体验式的、却又极其重要的衡量标准。为什么大家更喜欢用支付宝,而不是各大银行的app客户端?

总结

本文主要是作为一个引子,来更接地气的说明什么是需求,有那些重要的需求。关于如何去完成这些需求,是一件非常复杂,困难的事情,网络上有很多资料,资源,用来说明如何实现扩展性?如何实现可维护性?易用性等等。只有结合自己的工作经验,与有针对性的思考,才能把网上的技术分享变成自己的知识财富!

接下来,我也会结合自己的理解逐个去总结。

阅读更多
换一批

没有更多推荐了,返回首页