告别JSON的括号地狱：我用Human格式，让配置文件和笔记“说人话”，效率飙升！

老码小张
220 阅读8分钟

JYM，不知道你是否也曾被密密麻麻的JSON括号和YAML那“多一空格愁，少一空格恼”的缩进搞得头昏眼花？尤其是在团队协作或者需要非技术人员偶尔介入配置时，那简直是一场灾难。

“代码是写给人看的，顺便给机器执行。” 这句话同样适用于配置文件和数据。

今天，我想跟你聊聊一个让我眼前一亮的发现——Human格式 ，以及我是如何用它来简化我的配置文件管理，甚至优化我的个人笔记系统的。

痛点回顾：那些年，我们一起“跪”过的JSON和YAML

作为一名开发者，我们每天都在和数据打交道。JSON以其简洁和广泛的语言支持，成为了API交互和配置文件的首选。YAML则因其相对更友好的可读性（至少初衷是这样）在DevOps领域广受欢迎。但它们真的完美吗？

  • JSON的“括号地狱”：多一个逗号，少一个括号，解析器就无情报错。对于复杂嵌套结构，一眼看过去全是符号，可读性实在堪忧。
  • YAML的“缩进敏感”：虽然去掉了大部分符号，但对缩进的严格要求，尤其是在复制粘贴或多人协作时，很容易引入肉眼难以察觉的错误。
  • 非技术人员的噩梦：让产品经理或者运营同学去修改一个JSON或YAML配置项？那画面太美我不敢看。

我一直在想，有没有一种数据格式，既能保持结构化的优势，又能像自然语言一样易于人类阅读和编写呢？

意外邂逅：Human格式带来的“柳暗花明”

// 这是一个Human格式的简单示例
person "Alice"
  age is 30
  city is "New York"
  skills has "programming" and "design"
  projects has
    project "Alpha"
      status is "completed"
    project "Beta"
      status is "in progress"

对比一下等效的JSON：

{
  "person": {
    "name": "Alice",
    "age": 30,
    "city": "New York",
    "skills": ["programming", "design"],
    "projects": [
      {
        "name": "Alpha",
        "status": "completed"
      },
      {
        "name": "Beta",
        "status": "in progress"
      }
    ]
  }
}

是不是感觉Human格式就像在描述事物，而不是在编写冷冰冰的数据结构？

好的工具，应该让我们更专注于“表达”，而非“格式”。

Human格式技术解决方案详解

Human格式的核心理念就是用接近自然语言的语法来描述数据结构。它借鉴了自然语言中的主谓宾结构、列表、以及描述性短语。

核心特性：

  1. 键值对（Key-Value Pairs）:
    • name is "John Doe"
    • age is 30
    • isEnabled is true
  2. 列表（Lists/Arrays）:
    • colors has "red" and "green" and "blue"
    • 或者更结构化的： 
      fruits has
  fruit "apple"
  fruit "banana"
  3. 嵌套对象（Nested Objects）:
    • 通过缩进和新的“主语”来定义。
    user "admin"
  email is "admin@example.com"
  preferences
    theme is "dark"
    notifications is true
  4. 注释（Comments）:
    • 使用 // 进行单行注释，非常直观。

它与JSON/YAML的主要区别：

  • 可读性：Human > YAML > JSON。Human几乎没有多余的符号。
  • 易写性：对于初学者或非技术人员，Human的学习曲线更平缓。
  • 容错性（理论上）：虽然任何格式都需要解析器，但Human的语法设计似乎更能容忍一些自然书写的小瑕疵（具体取决于解析器实现）。
  • 工具链成熟度：JSON > YAML > Human。这是Human目前最大的挑战，生态系统还在建设中。

我的实践：从项目配置到个人笔记

当我发现Human格式后，我迫不及不及待地在两个场景中进行了尝试：

场景一：小型项目的配置文件

我有一个个人博客项目，配置项不多但偶尔需要调整，比如站点名称、备案号、社交链接等。之前用的是JSON，每次修改都小心翼翼。

改造前 (config.json):

{
  "siteName": "我的技术小站",
  "author": "TechSharer",
  "socialLinks": {
    "github": "https://github.com/user",
    "twitter": "https://twitter.com/user"
  },
  "postsPerPage": 10
}

改造后 (config.human):

siteName is "我的技术小站"
author is "TechSharer"

socialLinks
  github is "https://github.com/user"
  twitter is "https://twitter.com/user"

postsPerPage is 10

实施过程与关键步骤：

  1. 学习Human语法。
  2. 寻找/编写解析器：这是关键。当时官方提供的解析器还比较初级，我用Python写了一个简单的解析器，将Human格式转换为字典对象供程序使用。
    • （注：现在官网可能已有更完善的解析器或第三方库，建议优先查找官方推荐。）
  3. 替换配置文件：将原有的 .json 文件内容用Human格式重写，并修改程序读取配置的逻辑。

成果与收获：

  • 修改配置变得轻松愉快：不再担心少个逗号或括号。
  • 配置内容一目了然：即使过段时间再看，也能迅速理解每个配置项的含义。
  • 减少了错误：因为可读性强，修改时更不容易出错。

启示：技术的选择，最终是为了服务于“人”的效率和体验。

场景二：个人知识管理与笔记

我喜欢用纯文本记录一些结构化的笔记，比如读书笔记、会议纪要等。Markdown很棒，但对于纯数据结构的表达，Human似乎更胜一筹。

例如，记录一本书的信息：

book "Designing Data-Intensive Applications"
  author is "Martin Kleppmann"
  publishedYear is 2017
  keywords has "distributed systems" and "data engineering" and "scalability"
  chapters has
    chapter "Reliability, Scalability, and Maintainability"
      keyTakeaways has
        takeaway "Understand the different types of faults."
        takeaway "Scalability is not just about handling more load, but also complexity."
    chapter "Data Models and Query Languages"
      keyTakeaways has
        takeaway "Relational vs. Document models."

这种方式比纯Markdown列表或嵌套列表更清晰地表达了数据的层级和关系。当然，这需要配合相应的脚本来解析和利用这些数据，比如生成读书报告摘要等。

你也可以尝试的Human格式实用技巧

  1. 简单的应用配置：对于小型个人项目或内部工具，如果配置项不多且需要人工编辑，Human是个不错的选择。
  2. 与非技术人员协作的数据：如果需要市场、运营同学提供一些结构化数据（例如活动信息、产品特性列表），Human格式可以大大降低他们的学习和使用门槛。
  3. 原型设计或API定义初稿：在团队讨论API结构或数据模型初期，用Human格式勾勒草稿，比写JSON或画图更快，也更容易聚焦在数据本身。
  4. 个人结构化笔记：如果你也喜欢用文本管理知识，并且需要表达一些层级关系，Human值得一试。

思考一下：你目前工作或学习中，有哪些场景可能会因为引入Human这样的格式而受益呢？

主流观点与我的“异见”

很多人可能会说：“已经有JSON和YAML了，为什么还要一个新的？”或者“工具链不成熟，怎么用？”

  • 主流观点局限性：过于强调机器处理的便利性，而忽略了在很多场景下，数据首先是给人看的，其次才是给机器处理的。JSON和YAML的流行，部分原因也是因为“大家都这么用”。
  • 我的改进方案/视角：
    1. 从小处着手：不求完全替代，但在特定场景（如上述配置、笔记）中尝试，可以立即获益。
    2. 推动生态：如果更多人认识并使用它，社区和工具链自然会发展起来。对于有能力的同学，甚至可以贡献解析器或编辑器插件。
    3. 关注设计哲学：Human格式背后“以人为本”的设计哲学，比格式本身更重要。它启发我们思考，如何让技术工具更符合人类的直觉和习惯。

我尝试过的一些“失败”或不那么理想的场景：

  • 大型复杂系统配置：如果配置项成百上千，且高度动态，Human格式可能因为缺乏成熟的校验和管理工具而显得吃力。此时，完善的JSON Schema或YAML工具链可能更有优势。
  • 高性能API交互：在纯机器到机器的通信中，JSON的解析效率和广泛支持仍然是王者。

关键思维转变：不要为了用新技术而用新技术，而是看它能否真正解决你的痛点，提升你的体验。

一些思考

Human格式为我们提供了一种在“机器友好”与“人类友好”之间取得更好平衡的数据表示方式。它并非要取代JSON或YAML，而是在特定场景下提供了更优选。

我的关键收获：

  1. 数据可读性的重要性：尤其是在人机频繁交互的场景。
  2. 工具服务于人：技术发展的方向应该是让工具更适应人，而不是强迫人去适应工具。
  3. 拥抱新思路：即使是一个小众的技术，也可能蕴含着解决特定问题的闪光点。

希望这篇文章能给你带来一些启发！如果你对Human格式有任何想法，或者有其他类似提升开发体验的好工具，欢迎在评论区分享和讨论！也别忘了点个“在看”和“赞”支持一下哦！

avatar
文章
阅读
粉丝