基于 Go 语言谈软件开发效率

这个帖子的目的不是对比不同编程语言开发效率的高低。

这个帖子实际上讨论的是以下内容：

0x10 定义和量化生产力

以代码行数来衡量程序员的产出是非常可笑的指标，同理，以代码复杂度、语法糖支持来评价开发效率也很离谱。

如果一定要找一个量化指标来评价开发效率，那就是相同开发需求下所消耗的总人力。

实际上，从理解业务需求开始，到构思实现方式和架构占据了写代码这个过程中绝大部分时间。

如果考虑团队协作的一般场景，沟通成本又占据了团队人力消耗的一半（个人估计）。

也就是说，纯代码层面的效率提升即便优化到极致，对于整个开发成本的改善贡献可能远低于 10%。

能看代码不求人才是最节省沟通成本的方式。

这里的反例就是互联网与工程化兴起之前的各种语言，需要通过外部工具、团队规则才能保证有效协作的各种脚本语言。

开发者讨厌屎山的深层原因还是代码不好读、不好改。

影响可读性的因素很多，这里简单列举几个：

人脑的栈空间是非常有限的，间接、隐藏信息越多，理解成本越高。

往小的方面说，直接复制其他代码引入项目算是复用。往大的方面说，包引入机制也是复用。

这里的重点是语言的官方仓库和工具链系统来一致化、规范化这个过程。

缺少官方包管理、没有官方工具链的各种语言都深受其苦。

面向对象的思想就是某个阶段编程语言带来的巨大进步。

在工程化成为现代语言标配的今天，组合替代继承也是巨大进步。

关于这一点我在其他帖子里有零散的论述，这里就不展开了。

我觉得这个部分是误解最多的，大多数的讨论都没有关注到真正的重点。

Go 最重要的贡献之一是基于 chan 的思维模型：Share memory by communication。

日常反复被强调的 goroutine 其实不重要，很多语言也可以有样学样。

通过 chan/goroutine 的结合，初学者即便不理解 race/signal/thread/shared memory 等等概念，一样可以快速、准确地写出并发逻辑。

没有魔法就是编程语言对开发者最大的尊重。

Debug 浪费的生产力往往会远超写代码的节省。

在网络编程的时代，原生 tls 才是真正的跨平台。

技术上跨平台的核心是交叉编译，工程上，保证一条命令构建全平台、全指令集，最后的障碍就是原生 tls 。

这里节省的是构建系统，一旦有了外部依赖，语言自身的工具链就不够用了。

Go 从非常早期就是手搓编译器，而不是转换成 IL 交给通用编译器。缺点是各种语言特性、语法糖都会影响编译器的编写，优点是编译很快。

人类的多线程能力很差，现实任务频繁上下文切换会极大降低工作效率。

如果你曾经被 webpack 构建或者 rust 编译支配，你会理解快速编译、即时反馈的意义。

PS

这个帖子实际价值也就最后一个章节，还没有展开说。权当抛砖引玉，欢迎斧正。特地放到 Go 节点也是不想让话题沦为口水争论。