【转】软件的价值

程序员最主要的一个工作就是编码&＃xff0c;编码只是个过程而已&＃xff0c;最终编码的目的就是产生一个能提供服务的有价值的软件。

不管你负责的是后端编码&＃xff0c; 产生的是可部署运行的服务&＃xff0c;或是移动端构建了一个App&＃xff0c;也许是前端&＃xff0c;编写了页面等&＃xff0c;也许可能是类库或框架等。所有这些产物&＃xff0c;如果我们用一个词来归纳它们&＃xff0c;那就是软件

那做为程序员&＃xff0c;你有没有思考过&＃xff0c;软件究竟有什么价值&＃xff1f;

为什么要谈价值

可能有些人觉得谈论软件的价值是有点多余&＃xff0c;因为软件一定是有价值的&＃xff0c;客户需要一个软件&＃xff0c;肯定它能满足客户一定的需求。

所以这个点并无太多谈论的必要。

这也正是我想要写这篇文章的原因&＃xff0c;这正是因为软件的利益方&＃xff0c;包括客户&＃xff0c;程序员&＃xff0c;管理人员&＃xff0c;公司等各方角色&＃xff0c;在识别软件价值上都存在误差。

而这种误差&＃xff0c;正在造成现在软件行业困境的一个很重要的原因。

我们软件行业的最大困境就是难以产生高质量易于维护的软件

所以我们程序员&＃xff0c;是否能清晰的理解软件的价值&＃xff0c;这是我们能写好代码的一个基础。

因为&＃xff1a;

软件有看得见的价值与看不见的价值

而在编码中&＃xff0c;很多问题的频繁出现的关键就在于&＃xff1a;

对于软件看不见的价值&＃xff0c;各方缺少可度量的共识

在这里插入图片描述

如上图所示&＃xff0c;软件的价值显而易见的分两部分&＃xff0c;一部分是各方角色可见的有共识的价值&＃xff0c;这部分在水面上&＃xff0c;我将其称为业务价值&＃xff0c;而另一部分几乎是各方角色难以看见并缺少共识的价值&＃xff0c;我将其称为技术价值

业务价值

看的见并且各方能有共识的价值

软件一定是在业务上有价值的&＃xff0c;它一定为某些人群提供了一些服务&＃xff0c;这些服务就会带来价值。

业务价值就是软件在水面上的价值&＃xff0c;任何一个软件都通常会有自己在业务上的功能&＃xff0c;比如电商软件是支撑网上购物的软件&＃xff0c;股票交易软件能让人进行股票交易&＃xff0c;这种明面上可见并且软件利益各方有共识的价值&＃xff0c;就是可见价值。

几乎软件利益的方方面面&＃xff0c;对于业务价值没有冲突与不一致&＃xff0c;产品需求书会详尽的描述需求的细节&＃xff0c;测试用例文档会描述如何在业务上进行测试&＃xff0c;而项目管理的几乎所有管理的重心都是在如期实现这些业务价值及保障这些业务价值的质量上面。并且从开发到产品&＃xff0c;客户等&＃xff0c;对业务价值是有共识的&＃xff0c;不存在理解上的差异。

业务价值也是可度量的&＃xff0c;比如从Bug数&＃xff0c;或是否完全满足需求&＃xff0c;操作体验如何&＃xff0c;以及功能在什么时间开发完成&＃xff0c;这些都是可度量的。

保障业务价值如期实现及其质量当然是非常必要的&＃xff0c;这一块的工作并无问题&＃xff0c;问题在于软件的另一个价值&＃xff0c;就是技术价值&＃xff0c;这是看不见并且难以达成共识的价值&＃xff0c;大多数编码的问题也多出现在这个上面。

技术价值

看不见并且各方难以达成共识的价值

仔细探究软件&＃xff0c;会明白它背后有一些隐藏的不易被查觉的特性&＃xff1a;

业务价值的质量&＃xff0c;并不反馈出实现业务价值后面的实现&＃xff0c;也就是代码的质量

软件大多是需要持续迭代或维护的&＃xff0c;但这种特性难以直观的感受且各方缺少共识

这些特性背后反应的实质就是&＃xff1a;软件是有技术价值的。

但在实际的过程中&＃xff0c;软件的技术价值难以被重视&＃xff0c;并且非常难以度量&＃xff0c;导致几乎这个价值是被忽视的&＃xff0c;而且处于被业务价值的压制&＃xff0c;也就是决策方通常会为了看的见的业务价值去牺牲他们理解或不理解的技术价值&＃xff0c;导致短期内看起来业务上的价值得到保障&＃xff0c;但实际时间稍微拉长一点&＃xff0c;就发现完全是害人害已的行为。

想必很多程序员陷入一些有困境的编码中&＃xff0c;这些代码难以继续下去&＃xff0c;代码的质量极差&＃xff0c;修改一个BUG极易引发一堆新的BUG&＃xff0c;添加一个新的功能需要的时间越来越难以评估及稳定下来&＃xff0c;业务价值越来越没有保障&＃xff0c;整个团队陷入一种恶性循环。

这就是软件技术价值出现问题的表现&＃xff0c;这种情况在软件开发中非常普遍。

技术价值的普遍出现问题的点在于&＃xff1a;

非技术人员对所谓的代码质量&＃xff0c;可维护性缺少概念与理解&＃xff0c;由于他们并不是直接编码的人员&＃xff0c;但通常掌握决策权&＃xff0c;要求这样的人群重视技术价值&＃xff0c;实在有点强人所难了。

技术人员虽然明白技术价值&＃xff0c;他们本身知道代码实现的是好还是坏&＃xff0c;但通常他们不是决策者&＃xff0c;并且普遍受进度压制&＃xff0c;在很多情况下&＃xff0c;他们别无选择&＃xff0c;会选择牺牲技术价值。

技术价值几乎是难以度量的&＃xff0c;很难用某种标准来判定技术价值的优劣&＃xff0c;虽然有类似的性能测试或代码扫码等&＃xff0c;但这些也几乎只能反应一个方面而已。

基于上述的原因&＃xff0c;技术人员很多时候虽然有心&＃xff0c;但实质对保障技术价值是无力的。

使用Sonar管控软件质量

如上图所示&＃xff0c;我通常会用Sonar去评估分析代码&＃xff0c;这是衡量技术价值的少有的手段之一&＃xff0c;但它的能力也非常有限。能完整的并且可度量的评估技术价值的方式似乎难以找到。

一个可以想像的事实是&＃xff0c;如果技术人员向决策者建议说&＃xff1a;“给我两个月时间&＃xff0c;我去重构下这份代码&＃xff0c;让它更好&＃xff0c;但在业务功能上完全没有任何改变”&＃xff0c;很难想像那些决策者&＃xff0c;也就是大多非常技术出身的人群&＃xff0c;会如何去理解与同意这种事情。

也许一个他们可能的想像是&＃xff1a;让整个团队浪费两个月时间&＃xff0c;然后啥东西都没有&＃xff1f;

软件价值

因此&＃xff0c;我对于软件价值的定义是&＃xff1a;

软件的价值是由业务价值与技术价值两部分组成的&＃xff0c;它们相互合作与依赖&＃xff0c;缺一不可

没有业务价值&＃xff0c;再好的技术价值也是白搭&＃xff0c;甚至变成技术人员的孤芳自赏。而没有技术价值&＃xff0c;业务价值则完全是空中阁楼&＃xff0c;不可能稳固与长久。

业务价值与技术价值&＃xff0c;如同太极的两仪一样&＃xff0c;它们理当同等重要。

因此&＃xff0c;做为一个程序员&＃xff0c;你必须得知道软件的价值&＃xff0c;也明白自己对软件的价值担负何等的责任&＃xff0c;特别是在技术价值这个方面&＃xff0c;程序员是几乎唯一有能力保障这一块价值的群体&＃xff0c;不可能期望产品或客户来保障这一块的价值。

这也是我这篇文章的目的所在。

编码的困境

如我在上面所总结的&＃xff0c;软件的两种价值&＃xff0c;即业务价值与技术价值是相互依赖与合作&＃xff0c;才构成了软件真正的价值。

而在现实中&＃xff0c;一个突出的表现是业务价值更被重视&＃xff0c;因为它是可见的&＃xff0c;可度量的&＃xff0c;是各方都能理解&＃xff0c;存在共识的价值。而与之完全相反的则是技术价值普遍受到轻视&＃xff0c;因为它是不可见的&＃xff0c;不可度量的&＃xff0c;非技术人员不理解的&＃xff0c;没有共识的价值。

而对技术价值的轻视成为软件各种问题频繁出现的一个很重要的原因。