如何编写软件程序怎样编写简单的代码( 二 ) _怎样

这说明了一些问题，因为 Eric Normand 是一名函数式编程方面的专家。如果你的代码过于简洁，以至于即使是领域专家也很费劲才能理解它，那么这可能不是你应该追求的目标。在同一期播客中，Normand 反思函数式编程语言/代码是否过于简洁。
这让我想起 EliezerYudkowsky 在《Explainers Shoot High. Aim Low!》中写的有些东西：

【如何编写软件程序怎样编写简单的代码】几年前，一位著名的科学家曾告诉我，他是如何以比平时低得多的技术水平为自己的领域撰写一篇解释性文章的。他认为这对该领域以外的学者，甚至报道者，都会有用。这篇论文最终成为他所在领域最受欢迎的论文之一，被引用次数超过了他所写的其他任何文章。并不是他的同行科学家都很愚蠢，而是我们往往大大低估了正确理解事物所需的努力。

我认为在编写代码时记住这一点是一件好事。
降低水平？
“了解你的受众”并不一定意味着你需要将所有东西都降低水平。
想想大学教授教本科生。在学期开始的时候，可能需要慢慢来，在解释事物时要非常慎重。但是，随着特定术语和概念开始为全班所熟悉，自由地使用这些术语可能就更好。
同样，当有一些术语和概念很难被人们理解时，慢慢介绍这些概念而不是完全避免使用这些概念可能更有意义，这样学生们就可以学习这些概念并在将来使用它们。
我认为问题的关键是，像往常一样，这涉及到权衡问题，你需要意识到这些问题并在你的决策中加以考虑。
可视化
教育者使用什么工具来教学？幻灯片、教科书、讲座视频、演示、测验、办公时间、家庭作业、图表、模拟，等等。当我们编写代码时，这些工具对我们开发者还有使用意义吗？
其中一些是不适用的。例如，一个完整的教学视频。其它则是有点儿傻。例如，测验。但是，我认为至少有些工具是可以使用的。
录像
让我们重新考虑一下讲座视频。对于你写的每个 10 行函数代码，进行一个深入的讲解是不现实的。但是对于更大的代码块呢？对于一个 lambda 函数或者一个重要的模块进行深入的讲解，我认为是有意义的。
事实上，我认为类似的事情已经发生了。当处理代码库中一些自己不太熟悉的部分时，我最喜欢的一个小技巧是使用git blame来增进自己对代码的理解。我会看到大部分代码是谁写的，在 Slack 上交流，然后他们会花费大约 20 分钟时间给我进行大致的讲解。我觉得这非常有用。那么，为什么不像这样记录一份讲解，并在文件头部以代码注释的形式链接到这份讲解呢？
我认为最大的原因是可维护性。随着代码库的演变，视频将变得陈旧过时。当代码注释这样的东西变得过时了，很容易编辑它们，但是对于一个视频，你不能真正地编辑从 17:34 到 21:40 的片段。至少不太容易。
我对这个观点有一些反对意见。是的，它最终会变得陈旧，但那又怎样？如果代码更改很小，视频就仍不会过时，其收益大于成本。如果代码变化很大，那么你可以再花 20 分钟录制一份讲解。即使出于任何原因，团队没有同步，最终导致在代码变化很大时没有更新视频，我也不认为这会造成任何重大伤害。如果有人点击它并开始观看，他们会很快意识到这个视频过时了并停止观看。
另一个我反对的观点是录制视频很费时。那简直是胡说八道。我们已经花费了大量时间来尽量产出高质量的代码：前期工作、重构、代码评审，等等。花 20 分钟时间，以一种随意的意识流的方式对着镜头进行讲解，与你花的其它时间相比是微不足道的。我认为这种观点真正要表达的是，录制视频给人的感觉像是要做一件大事。