程序员为什么不写文档?

更新日期: 2021-04-30阅读: 1.3k标签: 文档

为什么程序员不写文档?是不想写吗?最近,资深软件工程师 Kislay Verma 分析了背后的深层原因。

他认为软件工程师不写文档有以下两个主要原因。


写作太难了

和所有人一样,软件工程师不写文档的原因是写作非常难。

写作本身是一件要求很高的任务,需要写作者将想法清晰地组织起来,进行批判性思考,最后再清楚表达出来。

在编程世界中,最佳答案等所有事情都基于一定程度的权衡,这也就使得写作更加困难。程序员在写作时需要先说明背景,证明决策的正确性,再将低级思考引入代码。这类写作如果做好的话往往很有用,但想做好并非易事,甚至有时候仅仅完成写作就已经很困难了。糟糕的代码还能运行,但糟糕的文档不会。

这就是许多人针对代码注释的价值和自文档化代码(self-documenting code)展开争论的原因。《程序员应该知道的 97 件事》的作者 Kevlin Henney 曾说,为复杂代码添加注释是徒劳的,用代码里都无法表达清楚,怎么可能用文字表达清楚呢?


不写文档不影响开发进程

开发者不写文档,并不耽误工作进程,起码不会立刻带来什么负面影响。而事实上,不将技术决策文档化带来的影响是一直在累积的。

写作是一件关乎思考和分析的事。大多数情况下,写代码可以摸着石头过河。组织结构欠佳的代码或许也能运行,但胡乱堆砌的文字和段落很难让人读懂。写作必须清晰,才能有用。而代码只要能够运行就可以(一定程度上)被接受。由于大部分组织只关注如何使产品推进,于是那些不会影响开发进程的事情就理所当然被忽略了。

在很多团队中,单元测试也面临类似的问题。要想测试代码,我们需要首先理解它,但这要比写代码费工夫多了,而且不做单元测试也不影响工作进程。于是,很多团队不重视对代码做单元测试。

还有一个问题:过时。即使优秀的文档也会过时,因此工程师在构建系统时,必须不断地重复「思考 - 分析 - 表达」这一过程。

总之,放弃写文档太容易了。


工欲善其事,必先利其器

毫无疑问,目前用于文档撰写的工具并不足够。我们并不以文档的角度思考问题,而是从 idea 和目标的角度考虑,一次性拼凑好几个概念。文档是思考过程的反映,这样形成的文档质量就可想而知了。我们需要一些工具,帮助我们梳理不同时间的想法,进而解决手边的问题。对于这类写作而言,Google Docs、Confluence、Markdown 并不足够。

不过,新一代工具(如 Notion、Roam)正在解决「网络化思想」的问题。这些工具有助于将思考转化为文档。

但是,缺少工具绝非不写作的借口。工具当然有用,但是否具备写作意愿才是问题的关键。


如何撰写文档?

Kislay Verma 表示:「写软件教会了我一件事。想要用户做某件事,你必须使这件事成为使用产品过程中必不可少的一步。」写作也是如此。将文档作为代码的点缀不会奏效,甚至是无用的。

写作关乎批判性思考,需要你向自己和读者解释思考过程和意图。思考过程为文档 / 写作增加了价值,而不只是静态地记录已经实现的代码。

Mob 编程 / 成对编程和极限编程的支持者通常看轻文档写作。但除了那些类型之外,写作和 review 技术文档是团队共同理解自己所创建产品的唯一方式,这对团队和代码库的长期健康发展非常关键。

原文链接:https://kislayverma.com/


链接: https://www.fly63.com/article/detial/10254

docsify - 生成文档网站简单使用教程

docsify 是一个动态生成文档网站的工具。不同于 GitBook、Hexo 的地方是它不会生成将 .md 转成 .html 文件,所有转换工作都是在运行时进行。

DTD文档模型是什么?

DTD文档模型是DOCTYPE文档声明,是Doucument Type Definition的英文缩写,是文档类型定义;制作一个标准的页面,声明一个正确的DOCTPYE,HTML里面的标识和CSS才能正常生效.

撰写后台需求文档需要注意的那些事儿

很多产品经理在撰写后台的需求文档时会一脸懵,很多时候不知道怎么开始,这篇文章主要根据自己工作中对后台的理解和需求文档撰写经验进行分享。人员较小的公司,会要求产品经理后台管理和前台界面一起进行撰写。

docsify一个神奇的文档生成工具

在开发项目时,我们或许需要一份精致的开发文档,那么使用docsify是不错的选择,docsify是一个文档生成工具,它直接加载 Markdown 文件并动态渲染,同时还可以生成封面页。所以我们只需要写完 Markdown 文

React新文档:不要滥用Ref哦~

React新文档有个很有意思的细节:useRef、useEffect这两个API的介绍,在文档中所在的章节叫Escape Hatches(逃生舱)。显然,正常航行时是不需要逃生舱的,只有在遇到危险时会用到。

程序员应该写文档吗?

80% 的文档都是无效的,所以多数情况下,程序员都不用写文档,原因如下:多数文档都是代码的点缀或者静态的记录已经实现的代码,懂代码的开发人员会直接看代码,不懂代码的开发人员压根不会看。

为什么几乎所有技术文档读起来都非常难受?

我们学习一个新接触的文档时,常常觉得非常难受,而自己消化了再写教程就非常舒服,这会让人产生一种错觉,就是官方文档没好好写。那么实际上,官方文档为什么长期以来,难以代替第三方教程的存在呢?

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!