编码之道（三）：编码的困境，失衡的价值
学习一个现代编程语言，简单！
用学会的语言，编码出能运行的代码，容易！！
一个团队，用代码去打造一个高质量易于维护的产品，突然就变难了！！！
这究竟是为什么？
本周，继续阐述自己对编码之道的分析与理解，这是第三篇，本系列其它文章为：
写出可运行的代码，这个基本上没有程序员做不到。那一群人，把自己写的代码结合起来，构建成一个高质量的产品，却突然一下子变得很难了。
原因在于：
编码是一个人的事，而项目或产品则是一群人的事情
在数学上的等式是：1+1=2
而团队合作我们期望的是：1+1>2
但实际上一群人的工作实际情况是：1+1<2
一群人编码这个事究竟有多难，从我们行业中一些非常著名的书上就可以得知了
类似的书挺多的，总之
所以，我也提出一点我的看法吧，我认为，导致编码出现困境的一个最主要的原因在于：
对业务价值与技术价值的认知与重视程度出现了偏差与失衡
编码并不单纯是技术上的事，这个想必所有程序员都是承认的。
在编码的世界是，如果以技术这个维度来区分人群，很明显有两个人群：
如我上一篇文章所讲，软件的价值是由业务价值与技术价值构成。
那以此继续推论，如果编码能保障业务价值与技术价值，那当然软件的价值，也就是质量就会有所保证了。
但现在可能大多是：
对业务价值的重视与保障程度远胜于对技术价值的重视与保障
在上面所说的两个人群中，很显然非技术人员天然地站在业务价值一边，并且是软件干系方中有重要影响力或决策者，而更可惜的是，连很多技术人员都没有意识到技术价值的重要性，有意无意的也在伤害技术价值。
应该保持平衡的天平，失去了平衡。
这源于几个原因
业务价值是可见的，技术价值是不可见的
我们更容易看到可见的东西，对于看不到的东西，理所当然地会忽略或不去考虑它。对于编码也是同样的道理，软件的功能，需求，用例，这些是实实在在可见的东西。
有决策能力的人更关心的是这些可见的功能是否如期完成，完成的功能是否与期望一致，至于背后的技术是怎么回事，所谓的维护性，灵活性，健壮性等，有多少非技术人员能"看见"这些东西。
估计只有我们技术人员能知道有这些东西的存在，对于我们，它们才有可能是『可见的』
业务价值是可衡量的，技术价值难以衡量
软件在业务上的质量，其实相对容易衡量，比如测试工作，测试提的BUG，几乎可以说绝大部分是对软件业务价值实现质量的测试。
功能点完成时间如何，完成程度如何，与需求或原型是否一致，这些是实实在在可以通过数据衡量与评判的。
而技术价值则完成不同，首先不说技术价值种类繁多，性能，可维护性，代码风格，单元测试，架构的灵活性，服务的健壮性等等众多维度的价值点。
而很多技术价值点压根没法衡量，比如，对于非技术人员来说，怎么去理解可维护性，什么样的数据或标准能证明可维护性是好的？
甚至可能有相当一部分技术人员都没法说出个评价标准。
业务价值是当下，技术价值是未来
技术人员非常容易听到的一句话可能是，以后再花时间来优化，先实现功能再说。
而大家都知道，事实是：以后等于永久，可能永远没有优化的那一天，因为新的功能或需求变更会源源不断地进来。
背后的一个事实就是: 业务价值是当下，当下是最重要的，而技术价值这种看不见摸不着的东西影响的更多不是当下，而是未来。
不好的技术，也能支撑当下的功能正常运行，它影响的可能是未来，因为会导致可维护性越来越差，但它毕竟是未来，而不是当下。
当下永远比未来更紧急，不是吗？
未来看似就意味着，还有更多的时间，但其实我们都知道，在技术价值上，并不是这么一回事，所以有个专业的词来描述这个现象： 技术债务
所以，呼之欲出的一个问题是，谁能保障技术价值？
当然就是我们程序员了。
所以，做为程序员，我们在职业上的最高的使命是什么，我的定义就是：
维护软件的业务价值与技术价值
而这其中，尤其以技术价值更为重要，因为它是容易被忽略，被轻视的价值。我们不可能期望那些不从事技术的参与方，能理解并主动积极地去保障技术价值，但我们有责任尽我们的能力与手段，尽量去保障技术价值。
但程序员也要切记：过犹不及
我们中一些人员，过于看重技术，反而去轻视业务价值，这其实也是一种不好的现象。
就像我说的，如同天平一样，业务价值与技术价值在天平的两端，维系他们的平衡，才是上上之策。
做为程序员，想要维系技术价值，首先要掌握的能力就是：把代码写好
但是把代码写好这件事，并没有想象中的容易。
我认为要写好代码的第一件事就是：理解编码中的道与编码中的术，只有很好的理解它，才有可能真正成为一个杰出的程序员，写出好的代码。
那究竟什么是编码的道，什么是编码的术？
下一篇，我们继续聊，编码之道（四）：编码的道与术
Jackyzhu
2025-03-03 广告
