Tools

总体纲领 在coding之前 我们需要先有个draft(草案) 包含 背景 约束条件 设计的目的与折中 存在的问题以及改进这四个部分 背景 目标： 精准复现、定位并理解技术问题的本质、影响范围及业务上下文。 关键活动： 问题复现与场景描述 (Reproduce & Describe): 复现路径： 明确稳定复现问题的具体步骤、输入和环境（开发、测试、生产环境；特定用户/数据）。 异常表现： 清晰描述“不符合预期”的具体行为，包括错误日志、监控指标异常（延迟、错误率、资源使用率）、UI/API 表现等。 预期行为： 明确在同样场景下，系统 应该 表现出什么样的行为。 根因分析 (Root Cause Analysis - RCA): 信息收集： 收集相关日志、Metrics、Traces、Dump 文件、配置信息、代码版本、变更历史。 关联分析： 分析时间线，将问题现象与系统变更、流量波动、依赖服务异常等进行关联。 假设与验证： 提出可能的根因假设，并通过调试、日志分析、实验等手段进行验证或排除。 影响评估 (Impact Assessment): 业务影响： 评估问题对用户、业务流程、收入、SLA/SLO 的具体影响。 技术影响： 评估问题对系统其他模块、数据一致性、安全性的潜在影响。 现状审视 (Review Current State): 审视当前代码库、架构设计、技术文档中与问题相关部分。 了解是否存在已知的类似问题或临时的 Workaround。 产出： 一份详尽的 技术问题分析报告 (Technical Problem Report / RCA Report)，包含复现步骤、根本原因、影响范围和相关证据。 约束条件 目标： 明确解决方案必须遵守的技术边界和需要达成的技术/业务指标。 关键活动： 识别技术约束 (Identify Technical Constraints): 平台/语言/框架： 必须使用的编程语言、框架、操作系统、云平台等。 架构/兼容性： 必须兼容的现有系统架构、API 接口、数据格式、老版本等。 资源限制： CPU、内存、存储、网络带宽、预算等硬性限制。 规范/安全： 必须遵守的编码规范、安全标准、合规要求。 定义技术目标 (Define Technical Goals): 功能性目标： 解决方案需要实现的核心功能。 非功能性目标 (NFRs): 明确性能（延迟、QPS）、可用性 (Availability)、可靠性 (Reliability)、可伸缩性 (Scalability)、可维护性 (Maintainability)、可测试性 (Testability) 等方面的具体指标要求。 明确核心假设 (Identify Technical Assumptions): 方案设计所依赖的底层库行为、第三方服务承诺、网络环境稳定性等假设。 产出： 一份 技术规格与约束清单 (Technical Specifications & Constraints List)，作为设计方案的输入和评判标准。...

go 的代码风格 git commit 规范 git 教程 The Uber Go Style Guide

说明 文档中使用的关键字「MUST」,「MUST NOT」,「REQUIRED」,「SHALL」,「SHALL NOT」,「SHOULD」,「SHOULD NOT」,「RECOMMENDED」,「MAY」和「OPTIONAL」在 RFC2119 中有说明。 还未定稿，对规范中提及的点有不赞同的欢迎提出 issues（请添加 markdown 标签）讨论。 规则 后缀必须「MUST」使用 .md。 文件名必须「MUST」使用小写，多个单词之间使用-分隔。 文件编码必须「MUST」用 UTF-8。 文档标题应该「SHOULD」这样写。 Markdown 编写规范 ========================== 章节标题必须「MUST」以 ## 开始，而不是 #。 章节标题必须「MUST」在 # 后加一个空格，且后面没有 #。 // bad ##章节1 // bad ## 章节1 ## // good ## 章节1 章节标题和内容间必须「MUST」有一个空行。 // bad ## 章节1 内容 ## 章节2 // good ## 章节1 内容 ## 章节2 代码段的必须「MUST」使用 Fenced code blocks 风格，如下所示： ``` console.log(""); ``` 表格的写法应该「SHOULD」参考 GFM，如下所示： First Header | Second Header ------------- | ------------- Content Cell | Content Cell Content Cell | Content Cell | Left-Aligned | Center Aligned | Right Aligned | | :------------ |:---------------:| -----:| | col 3 is | some wordy text | $1600 | | col 2 is | centered | $12 | | zebra stripes | are neat | $1 | 中英文混排应该「SHOULD」采用如下规则：...

文档连接 语义化版本： 用于发版相关的规范 约定式提交（Conventional Commits）是一种用于写作提交消息的规范，它规定了一套标准化的提交消息格式，以使得项目的版本控制更加清晰和一致。采用这种规范的好处是能够帮助开发团队更好地理解代码的变更历史、生成变更日志（changelog），以及进行版本控制。 约定式提交的基本格式 <类型>(<范围>): <描述> <主体> <footer> 各部分说明 1. 类型（type）：用于说明提交的类型，例如是修复bug还是添加新功能。常见的类型包括： feat：新功能（feature） fix：修补bug docs：文档（documentation）变更 style：代码格式（不影响代码运行的变动） - refactor：重构（即不是新增功能，也不是修改bug的代码变动） - test：增加测试 - chore：构建过程或辅助工具的变动 2. 范围（scope）：可选项，用于说明提交影响的范围（例如模块、文件等）。 3. 描述（subject）：简要说明提交的内容。 4. 主体（body）：可选项，用于详细说明提交的内容，可以分成多行。 5. 脚注（footer）：可选项，用于说明重大变更，或者关联的issue。例如： - BREAKING CHANGE：说明重大变更 - Closes #123：关闭issue 示例 feat(auth): add login functionality Added login functionality with OAuth2 integration. Users can now log in using their Google account. Closes #45