软件项目规范（1）：README文件的基本写作规范

看Github的开源项目，我们都能看到README.md文件的身影。

有不少同学都喜欢将自己的项目上传到Git托管起来，但是总能发现一个问题：明明自己这个项目挺有市场的啊，怎么这个代码放上去，就显得很“非官方”！

通常，笔者都会从文件结构，代码风格等来入手，解决这个项目形象问题。

一个有价值的项目，不仅要从功能上体现出这个价值，也要从文本的风格，字里行间体现这个价值。有一说一，几块钱买来的代码和几百块钱、几千块钱买来的代码风格差距确实大。看着文件的形象，就要让消费者觉得这钱花得值。

---

对于陌生人而已，README是项目程序的黑盒之窗。读者大概会花30秒左右的时间，捕捉项目内容的要点。因此，README应该是介绍项目整体的一个概览。其实这个静态文件是有约定成俗的规范，这个规范也就是众多开源开发者相互磨合所形成的。

1. 项目介绍

2. 代码实现了什么功能?

3. 该如何使用? (系统环境参数，部署要素，操作说明等)

4. 代码组织架构是什么样的?（目录结构说明等）

5. 版本更新内容摘要（这个非常重要）

---

如果你的README包括上面的内容，那么当使用者拿到代码,打开README后，基本就知道该如何下手了。

通常大家采用markdown语法来书写README文件（即README.md），当然也有txt（即README.txt）。笔者呢更偏向markdown语法，主要是因为它能进行简单的排版。

这里摆上我自己项目的README.md作为示例吧：

# 项目介绍
    本项目是针对代码工具链生成的DDS服务文件所建立的。

    能够将多个DDS服务文件进行合并，构建DDS基本服务端以及客户端程序框架。包含生成server.cpp、client.cpp、CMakeLists.txt

# 环境依赖


# 目录结构描述
    ├── ReadMe.md           // 帮助文档
    
    ├── AutoCreateDDS.py    // 合成DDS的 python脚本文件
    
    ├── DDScore             // DDS核心文件库，包含各版本的include、src、lib文件夹，方便合并
    
    │   ├── include_src     // 包含各版本的include、src文件夹
    
    │       ├── V1.0
    
    │           ├── include
    
    │           └── src
    
    │       └── V......
    
    │   └── lib             // 包含各版本的lib文件夹
    
    │       ├── arm64       // 支持arm64系统版本的lib文件夹
    
    │           ├── V1.0
    
    │           └── V......
    
    │       └── x86         // 支持x86系统版本的lib文件夹
    
    │           ├── V1.0
    
    │           └── V......
    
    ├── target              // 合成结果存放的文件夹
    
    └── temp                // 存放待合并的服务的服务文件夹

# 使用说明



# 版本内容更新
###### v1.0.0: 
    1.实现gen文件的拷贝、合并
    
    2.实现common文件的合并
    
    3.实现指定版本的include、src、lib文件的拷贝

实现的效果如下：

 这种风格是一种比较简约的风格。当开发者熟练后，也会逐渐形成自己的代码风格。

文本规范，对于一个程序员来说非常重要，可以说是一个程序员的形象，说“字如其人”毫不过分。在团队中，大家如果彼此熟悉，基本上是能通过这些字里行间的蛛丝马迹，知道这些文本或者代码出自哪位成员之手。