作者在参与多个大型项目的初期阶段后，总结出在项目中应具备的一系列重要事项，包含以下主要观点、关键信息和重要细节：

• READMEs：项目应有一页左右的简短自述文件，主要是指向更详细文档的链接，常见失败是自述文件随意增长，难以重构，信息虽有价值但无处可移。
• Developer Docs：开发者文档应放在仓库的docs文件夹中，包含描述文档结构的简短首页，常见失败模式包括无地方存放新文档、只有高度结构化文档或只有无结构堆积文档。
• Users Website：大多数项目受益于针对用户的专用网站，常见失败模式有不同团队管理网站导致开发人员无法直接贡献、选择复杂的 web 堆栈导致问题、过度承诺等。
• Internal Website：除公共网站外，可考虑内部工程网站，可能需要数据存储，如用 GitHub 仓库中的 JSON 文件。
• Process Docs：明确项目代码进入主分支的方式，如特征分支的推送方式、分支命名约定、代码审查流程等，并鼓励贡献过程文档。
• Style：风格指南很有价值，应明确项目特定的风格规范，优化可扩展性，指定风格负责人。
• Git：记录与 Git 相关的风格细节，如area:前缀、可接受的行长度、禁止添加大文件、合并与变基事宜等。
• Not Rocket Science Rule：维护一组始终在主分支通过的自动化检查，这能让代码视为可随时更改且有价值的，还能优化构建和测试基础设施，避免半检查和模糊性。
• Build & CI：构建系统是引导过程、开发者 UI 和命令集合，应简单、可重复，避免构建系统蔓延到 CI，保持 O(1)的入口点，支持自由形式的自动化。
• Testing：测试是主要架构关注点，应数据导向，避免测试架构错误导致软件难改，要有零容忍的不稳定测试、快速测试、慢测试和快照测试，同时要有基准测试。
• Benchmarking：确保每个基准测试也是测试，通过输入大小参数化，用小输入快速运行测试，用makebelieve test运行，也可使用nyrkio.com跟踪宏指标。
• Fuzz Testing：虽难以有效集成到开发过程，但可运行孤立种子测试，以固定种子和小参数运行模糊逻辑测试，以仪表盘形式显示连续模糊测试结果。
• Releases：发布流程与软件是否准备好生产无关，更快、更频繁的发布更易且风险低，每周发布节奏较好。

总结为一系列方便参考的要点：README 作为着陆页、开发者文档、用户文档、结构化和非结构化开发者文档、用户网站、内部网站、元文档过程、明确的代码审查协议、Git 大文件检查、非火箭科学规则、无半测试、无不稳定测试、单命令构建、可重复构建、固定数量入口点、CI 委托给构建系统、主语言的自由自动化空间、整体测试基础设施、快慢测试分离、快照测试、基准测试是测试、宏指标跟踪、模糊测试是测试、水平触发的连续模糊测试结果显示、逆三角不等式、每周发布。