为什么我在被指出后开始结构化我的开发笔记 😅

Source: Dev.to

在我作为软件工程师的职业早期，我的笔记简直是一团乱麻。
我的主管指出它们四处分散，她说得没错。

我的笔记遍布各处：

• 笔记本
• 便利贴
• 截图
• Slack 消息
• ChatGPT 对话

每当在开发中解决了某个问题，我都会把它记下来，但“记下来”的位置从来不固定。当同样的问题再次出现时，我必须到处搜索——或者更糟，重新向主管请教。

---

问题：笔记分散

我的主管拥有超过 20 年的架构师、工程师和解决方案分析师经验，她从不在聊天记录里搜索或滚动查看信息。她只会打开相应的文档：

• FRS
• 技术文档
• 系统笔记

一切都有结构且可追溯。需要检查系统流程？打开文档。需要确认需求？打开文档。需要理解逻辑？打开文档。看起来轻而易举，我感到非常惊讶。

观察到的更佳实践

观察其他开发者时，我发现了一个简单却强大的工具：Google Keep。它可以创建整洁、分区的笔记——项目搭建、调试步骤、配置、实用命令——全部可搜索。

真正的问题不是忘记，而是找不到已经学到的东西。

我的结构化笔记系统

我改掉了一个小习惯：每当 ChatGPT 帮我解决了某件事（调试错误、理解框架、修复配置），我就把有用的部分提取出来，保存到自己的结构化笔记中。

示例布局

• 项目搭建 – 环境配置和安装步骤
• 常见错误 – 错误信息、根本原因及解决方案
• 调试笔记 – 出现的问题以及我是如何修复的
• 架构理解 – 服务流和系统逻辑
• 数据库笔记 – 重要表和查询语句
• 实用命令 – 终端命令和脚本

差别非常大。当我在项目上间隔几天或几周后再次回来时，我只需搜索自己的笔记，而不必从头开始。这样也减少了我向主管询问“我们上次是怎么解决的？”的次数。整理笔记让我更像是一个随时间积累知识的工程师，而不是一次又一次地重复解决同样的问题。

优秀的开发者不仅仅写代码——他们构建系统来记住所学。有时成长只需要一句简单的评论：“你的笔记太散了。”这句话悄然改变了我的工作方式。

工具与参考

• Google Keep –
• Notion –
• Obsidian –

进一步阅读

• 功能需求规格说明（Functional Requirement Specification）解释 –
• 软件文档指南 –

我仍在不断改进自己的文档方式。你是如何组织自己的开发知识的？笔记应用、文档系统、个人维基，还是其他方式？期待了解其他开发者的做法。