『程序员』程序员为什么应该旗帜鲜明地反对“最佳实践”？ |Markdown|CSDN|设计|

让第一个版本的系统混乱一点，或许是件好事。

本文插图
作者 | 黄峰达， CSDN 博客专家 Phodal
责编 | 唐小引
头图 | 作者绘制并授权 CSDN 使用
出品 | CSDN（ID：CSDNnews）
最近，我在设计、开发、维护一个基于『文档代码化』思想的平台。因为丰富的 markdown 经验和文档化系统的设计经验，我在这个系统中实施了很多过去的一些想法。系统工作得很好，但是代码却显得一片混乱。而，我突然觉得这是一件好事。

本文插图
【『程序员』程序员为什么应该旗帜鲜明地反对“最佳实践”？】
最佳实践很浪费时间
对于敏捷开发来说，我只采纳了持续集成和持续部署的思想，即提交代码便发布到 GitHub Pages 。但是，这也浪费了我很多的时间，而且我觉得没有必要，因为我已经有一个本地可以部署的脚本。我只需要在本地运行一下 deploy ，那么就会在本地构建，并部署到服务器上。然而，为了最佳实践的理念，我还是花了半天的时间，研究了一下 GitHub Action ，然后让它实现自动部署。
系统的 UI 采用的 Angular 框架，因为我懒得搭建脚手架，而且我还有一些先前的代码可以复用。所以，我 copy / paste 大量的代码，这些代码大部分都是没有测试覆盖的。是的，你很少看到我的开源项目是没有测试覆盖的 —— 毕竟写单元测试也是要花时间的。过去，我们统计过一个相关的数据，在我们日常的开发中，我们差不多有 1/5 的时间花在了单元测试。所以，一周下来，我差不多一天的时间在写测试这件事上。

本文插图
一个问题，三种方法实现
如开头所说，整个系统的核心是一个基于 markdown 的多功能渲染引擎。这部分的组件可以让你用 markdown：

画出条形图、雷达图、思维导图
画出甘特图
画出特定的四象限
调用 Web Components
……

而为了实现这个功能，一共有三套不同的机制，当然了对于写 markdown 的人来说，它们是无感知的。这三种方法分别有：

创建占位符，渲染完成后，替换占位符；
直接生成最后要渲染的 HTML；
生成一个 ID ，在渲染的过程中，根据 ID 替换元素。

所以，整个过程就相当于，是解决一个问题有三个方法，然后我都用了这三种方法。

本文插图
起初，我只想创建个原型
起初，我只是想创建一个简单的系统，它只是一个简单的原型。而后，随着越来越多想法的产出，我创建了一个足够复杂的系统。所以，我起初设计的一系列要素都失效了。
我还有一堆糟糕的 SCSS 要管理，因为第一个版本设计的 CSS 体系，无法适用于新的架构。整个系统围绕在 markdown render 上，而这个 render 有大量的样式，就好像早期的多核 CPU 架构，只有一个 CPU 在工作，毕竟有大量的工作。
随着系统越来越复杂，我开始需要一个文档系统来管理这个文档系统，以便告诉我自己：系统里有什么功能？