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

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

1 软件的理想

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

那么到底需求是什么/p>

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

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

既然，谈到了理想，那么什么样的理想关心这些理想/p>

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

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

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

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

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

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

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

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

5 客户不懂软件

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

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

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

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

总结

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

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

来源：墨城之左