软件系统的4大技术本质

川长思鸟来 2022-06-18 03:00 161阅读 0赞

**软件系统的4大技术本质**

**![0_13165289760AY0.gif][]**

**需求**  
软件定位在哪些用户，能帮用户解决什么问题，给用户带来多少价值，选择放弃的成本。  
需求是一个软件最重要的东西，如果你的软件不能帮用户解决问题，那就是没有意义的软件。  
一个软件服务的用户范围及给每个用户带来的价值决定着这个软件的前景。每个开发人员一定要想清楚软件服务的用户范围，从而得知软件的用户规模。  
比如你做一个类似QQ的即时通讯工具，那用户范围将是所有的网民。如果你做的是一个浏览器的脚本调试插件，那用户范围是开发浏览器软件的程序员，普通网民根本不可能用你这个软件。经常有一些程序员活在自己的世界里，对自己做的软件没有清醒的认识。所以我们需要关心一些宏观统计数据，比如，网民数量，使用某种软件的用户数，使用某种语言的程序员数，以前这些数据的变化趋势预估。  
软件能帮用户解决什么问题，这是一个发展的过程，初始版本一般解决的问题有限，随着用户的反馈及软件升级，软件能帮用户解决的问题会越来越多。  
有人说做软件开发最怕需求变化，最好能前面就把需求明确好，责任人员签字，防止变化，但实际上很少有人能精确描述需求，更难预估软件的需求变化，所以如何做好需求分析，首先要定位软件的用户范围，计划解决的用户需求是什么，软件发展过程中及时收取用户反馈，使软件能解决客户的问题越来越多，敏捷与迭代开发更具有可操作性。  
除了一些大型基础软件，现在也很少看到几年开发一个软件的事情。Google的Chrome浏览器是版本帝，一年内发布几个大版本，市场点有率一直在上升，相比之下IE的步伐实在太慢了。  
在互联网公司更是有系统天天发布的现象，因为系统发布相比客户端软件成本低，并且互联网公司的软件需求大部份来自于用户使用的反馈，所以如果没有很好的系统升级及时性，客户满意度会大大下降。  
  
**界面与操作流程**  
你的软件界面友好吗？操作及流程简单清晰吗？  
你的软件界面是不是只是一个信息保存工具，提供了大量增、删、改、查功能，如果软件要求用户输入的信息比给于用户的信息还多，那这个软件的价值何在。没有人喜欢用几十个文本框的输入或查询界面的软件，如果有这样的界面说明我们没有深入了解客户需求，我们只是堆积更多的功能让这些用户不要来烦我，让用户感觉“我已经提供了这么多，你还想怎么样”的结果。  
你能设计一个如Google一样的简便的软件吗？你的操作界面能如iPhone一样简单和绚丽吗？ 像Google与iPhone这种的界面也许只有天才能会敢想并实现出来，再看看我们的软件界面吧，估计要无地自容。  
你是否会思考软件布局清晰，操作流程简单。你的软件是否经常要给客户培训操作，并且培训后还有很多人不会用。  
你是否会思考用户使用一个功能的操作成本，包括键盘输入字符数，鼠标的总体移动时间，点击次数，鼠标键盘切换次数、提示文字思考时间、错误操作概率等等。想想这些，感觉我的软件可能不是在为用户解决需求，更多是在折磨用户，甚至是考验用户智商。  
一个好的软件界面及操作流程应该是不太需要给客户培训，客户就直接会用了。  
  
  
**架构与性能**  
软件需求包括已知需求和未知需求，实现需求的成本主要包括硬件成本及软件成本，而软件架构与性能的本质是让人与机器发挥最大的生产力，让实现需求的性价比最优。  
软件的性能是硬件成本的一个主要因素，越好的性能当然需要的硬件越少或者配置更低。不同的程序员开发的软件性能相差巨大，有时甚至达上万倍，也就是说你用一台大型机做事，别人用一台上网本可能比你还快。  
软件成本包括软件开发成本及第三方软件采购及学习使用成本，好的架构师在选择好合适的第三方软件的同时，会重点考虑软件开发架构。我认为软件开发架构最终的目标是让成员能高效工作，要让成员高效工作，软件架构应该能通过提取公共需求来减少重复工作，将复杂的问题简单化，定义清晰的接口规范，通过分模块及分层次的架构实现并行工作并减少沟通成本，在实现已知需求的情况下考虑未知需求对软件变更的成本。为了节约成本，软件架构设计一定会考虑成员的技能水平及新架构技术的学习成本，所以选择何种架构很大因素是当前团队熟悉的或市场通用的技术架构，也不排除一些架构师个人喜好用新技术架构尝试。  
选择软件架构没有最优的说法，因为每个团队的技能基础都不一样，因此也可以看到各个大公司的技术架构千差万别。好的软件架构肯定不是为了满足牛人程序员的需求，因为大部分程序员并不是牛人，不可能都是算法高手，也不可能是工作经验非常丰富的人，大部份程序员都是普通开发人员，架构师设计软件架构的目的就是能利用这些普通程序员的能力就可以更快的实现需求。  
  
架构不仅是要评估软件的成本，还需要评估硬件成本，有时还需要平衡软件与硬件互换的成本，还需要预估硬件的发展速度是否可保证实现未来需求。  
架构不仅要评估现在团队资源的技能，还需要评估团队资源技能学习的成本，新增团队资源成本等等。  
架构不仅要满足已知需求实现的可行性，还需要考虑实现未知需求的成本。人所掌握的知识是有限的，对已知需求的合理性都无法完全评估，未知需求就更难预测，所以一般架构师都是优先满足已知需求，再从已知需求来分析未知需求产生的可能性，对于发生可能性非常高的未知需求，并且会增加大的变更成本时，才考虑适当的架构基础。  
所以说架构是一种平衡艺术，她需要平衡各种资源，还需要平衡已知需求与未知需求，从而达到一定时间范围内资源最优的生产力。  
架构还有一种艺术是隔离已知需求与未知需求，自己团队只实现已知需求，对未知需求进行抽象并形成实现规范，自己做一些简单实现示例，最终让未知资源来实现未知需求。这类架构的代表作是Eclipse和Facebook，还有MySQL的存储插件引擎接口，这类软件架构的目的是提供解决需求的基础架构，提供非常方便解决需求的方法，可以让更多的人能参与进来，让别人来免费为你实现未知需求，从而达到更高一级的性价比。  
  
**安全与稳定性**  
没人愿意使用一个不安全的系统，没人愿意把重要信息放在一个经常丢数据的系统里，也没人愿意把机密信息放在一个别人可以轻易得到的系统里。  
没人愿意使用隔三岔五停机维护的系统，也没人愿意在使用系统时经常出现异常错误。  
当你的软件缺乏安全性与可用性时，即使你的其它方面都很好，客户也会很快流失，因为你没办法让他认为是一个值得依赖的东西，他随时会抛弃你。  
所以如何让软件稳定运行是值得思考的，安全性除了软件本身的缺陷外，还需要注意设计好数据网络通讯及主机部署相关的安全性方案，随着系统的扩大，很多都属于系统运维技术。  
在可用性方面也更多是系统运维能力的考验，包括如何保证系统的高可用性，负载均衡，容灾切换，如何规范系统变更流程及操作规范，变更风险识别及应急预案准备等等。  
  
简单来说：  
 **需求决定你的客户范围，系统价值，也代表着系统潜力  
架构与性能决定你的建设成本  
界面与操作流程主要决定你客户增长的速度  
安全与稳定性主要决定你客户流失的速度**  
  
  
当然，上面几点只是软件一些的主要技术方面，软件要成功还需要很多其它重要因素，如人力资源、市场营销、竞争对手分析等等。  
  
  
我的新浪微博:[http://weibo.com/yzsind][http_weibo.com_yzsind]

[0_13165289760AY0.gif]: /images/20220618/d1ace684ec6c4ea685e804fd082d7934.png
[http_weibo.com_yzsind]: http://weibo.com/yzsind