开发过程中如何理解好一个项目的需求

曾经终败给现在 2022-05-09 20:20 137阅读 0赞

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

## 1 软件的理想 ##

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

那么到底需求是什么？

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

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

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

![这里写图片描述][SouthEast]

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

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

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

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

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

## 3 做一名高尚的开发人员 ##

![这里写图片描述][SouthEast 1]

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

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

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

![这里写图片描述][SouthEast 2]

易理解很重要！

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

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

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

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

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

## 4 运维人员的忧伤 ##

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

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

![这里写图片描述][SouthEast 3]

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

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

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

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

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

## 5 客户不懂软件 ##

![这里写图片描述][SouthEast 4]

客户： 可用性，可靠性（稳定，安全，好用不贵），易用性

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

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

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

## 总结 ##

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

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

本文借鉴博主为[墨城之左][Link 1]的博客文章。

[SouthEast]: /images/20220510/692c3e8b5b304b26bd15a3739454b835.png
[SouthEast 1]: /images/20220510/74f66251782b41c6a24fe35632284e1e.png
[SouthEast 2]: /images/20220510/ce0c810821ed4157972703dc0a9e25ff.png
[SouthEast 3]: /images/20220510/aa8a5cf07d9645828d522df52f8e7cde.png
[SouthEast 4]: /images/20220510/61a7a53dca7a4ea89109554e2f14ebc4.png
[Link 1]: https://blog.csdn.net/antony1776