开发者效率的几个瓶颈点

逸言 | 逸派胡言

所有编程工具的最大公约数是最终都要被“开发者”所用。所有工具解决的问题，本质上还是人类在环导致的问题。当哪天人类不在环中了，机器能够自举了，也就不再需要开发者工具了。

陶文，ThoughtWorks毕业生，从事过软件开发，敏捷咨询，项目管理，测试研发，运维平台等多个领域的工作。曾任滴滴出行平台技术部首席架构师，现从事滴滴的平台治理和客服系统的改进工作，致力于为大家提供一个更好的出行生态。

我认为开发者效率的模型是这样的：

我认为目前存在这么几个瓶颈点：

• 对于 logic programming 而言：从运行时没有提供足够的feedback来更新开发者的认知
• 对于 machine learning 而言：从运行时没有提供足够的feedback来更新开发者的认知。模型几乎是黑盒，人类难以获得直觉。
• 难以维护文档：维护测试和文档是两倍工作量，文档总是滞后
• 开发者从文档和运行时获取信息太慢，而且零散的知识容易遗忘
• 开发者心中所想和源代码的承载形式有很大Gap，无法直白地表达意图

问题一：logic programming 的 feedback

这个问题的主要的症状就是出了问题，经常要靠猜。没有人知道在运行时实际的执行情况。

造成问题的主要原因是打日志仍然是一门艺术，而不是科学。对于 observability 的投入不足。什么叫 observability？

monitoring tells you it is not working

observability tells you why it is not working

日志，metrics，错误处理，distributed tracing。这些东西应该有一个更可视化，更少人工干预，代码写起来更漂亮的解决方案。

问题二：machine learning 的 feedback

machine learning 和 logic programming 是两种完全不同的驱动机器的方式。machine learning 本质上是用数据反向生成可执行的程序。深度神经网络可以理解为基于动态规划的模式匹配程序，只是这个程序不是人手写源代码得来的。

在人类灭亡之前的很长一段时间，machine learning 仍然需要人类的干预。如果我们无法从模型的实际行为获得直觉，这些干预都是盲目的猜测，而不是educated guess。对机器学习的模型进行可视化分析，增强人对其的认知和理解会是一个非常重要的方向。

问题三：文档维护

我们有大量的单元测试，但是仅仅看测试很难知道测的是什么东西，体现了什么意图。

我们有大量的文档，但是文档的更新总是滞后的。和实际行为不相符的文档更是具有误导性。

测试和文档应该是一个东西。在这个领域应该来一场类似前后端分离那样的革命。

问题四：知识管理

人类的生理缺陷是固有的，它限制了获取信息的带宽，以及能够存储和检索的知识规模。

如何提高开发者的知识管理能力是一个很大的问题。这不仅仅是提供更多的运行时反馈，提供更多的文档能够解决的。就算提供的再多，再快，开发者消化不了也是信息过载，无济于事。

面向StackOverflow编程，不是一句笑谈，而是科技带来的进步。本质上是用脑内关键字索引，把知识外溢到StackOverflow上做冷加载。

当我们面对一个命令行工具有100多个参数，一个gradle有几十个配置选项的时候，你是感觉非常无力的。很多时候我们宁愿重写，也不去复用。本质上是因为复用的前提是你先去理解复用的东西自身，然后才能游刃有余的调整那么参数。这个理解一个“可复用”的东西的成本的最大障碍，在人类自身。

问题五：所书非所想

核心的问题在目前主流编程语言的两个缺陷上：

• 无法直白地表达超过500ms的因果关系。表现形式就是有状态的业务逻辑总是最终变得支离破碎。
• Nominal Typing 鼓励了面向实现编程，而不是面向接口编程。而且单变量单一分类系统不足以处理真实业务中的“个性化”需求，从而无法“平台化”复用。表现形式就是 if/else 堆砌，咋写咋别扭。

开发者工具

所有编程工具的最大公约数是最终都要被“开发者”所用。所有工具解决的问题，本质上还是人类在环导致的问题。当哪天人类不在环中了，机器能够自举了，也就不再需要开发者工具了。在那天到来之前，如何用工具来武装开发者的大脑、双手和双眼，仍然是一个非常重要的课题。