菜鸡互啄队——软件需求规格说明书

一、引言

1.1 编写目的

编写此文档的目的是进一步定制软件开发的细节问题,希望能使本软件开发工作更具体。为了使用户、软件开发者及分析和测试人员对该软件的初始规定有一个共同的理解,它说明了本软件的各项功能需求、性能需求和数据需求,明确标识各项功能的具体含义,阐述实用背景及范围,提供客户解决问题或达到目标所需要的条件或权能,提供一个度量和遵循的基准。具体而言,编写软件需求说明的目的是为所开发的软件提出:

  1. 软件设计总体要求,作为软件开发人员、软件测试人员相互了解的基础。
  2. 功能、性能要求,数据结构和采集要求,重要的接口要求,作为软件设计人员进行概要设计的依据。
  3. 软件确认测试的依据。

1.2 背景

开发的软件名称: Pit:分布式版本控制系统

如今程序员在开发的过程都要面对一个问题:如何进行代码版本管理?此问题的答案便是开源Git分布式版本控制系统。对于开发者的我们来说,深入理解git的内部原理是必要的,有助于我们在开发过程中更好地熟练使用Git管理器,所以我们利用Python语言实现一个类似Git分布式版本控制系统。

二、项目概述

2.1 概述

本产品和目前热门的Git版本管理类似,git使用C语言实现,本产品利用python实现,git是用于Linux内核开发的版本控制工具。与CVS、Subversion一类的集中式版本控制工具不同,它采用了分布式版本库的作法,不需要服务器端软件,就可以运作版本控制,使得源代码的发布和交流极其方便。针对此特性,项目组决定重新实现git功能,并在此基础上加入自己的想法和扩展Git现有功能。

系统的流程图层次关系:

2.2 Pit的功能

目前拟定的功能:

  • 创建仓库
  • 提交commit信息
  • 推送本地修改到远程Git服务器(暂定是Github)
  • 分支管理 (待定)
  • 版本管理 (待定)

2.3 实现语言

Python

2.4 用户特点

程序开发者、维护人员和系统工作人员等

预期用户量:1000人

2.5 运行环境

Windows

2.6 代码规范

2.6.1 编码

  • 如无特殊情况, 文件一律使用 UTF-8 编码
  • 如无特殊情况, 文件头部必须加入#-*-coding:utf-8-*-标识

2.6.2 代码格式

2.6.2.1 缩进

  • 统一使用 4 个空格进行缩进

2.6.2.2 行宽

每行代码尽量不超过 80 个字符(在特殊情况下可以略微超过 80 ,但最长不得超过 120)

理由:

  • 方便在控制台下查看代码
  • 太长可能是设计有缺陷

2.6.2.3 空行

  • 模块级函数和类定义之间空两行;
  • 类成员函数之间空一行;
  • 可以使用多个空行分隔多组相关的函数
  • 函数中可以使用空行分隔出逻辑相关的代码
class A:

    def __init__(self):
        pass

    def hello(self):
        pass


def main():
    pass   

2.6.3 注释

2.6.3.1 块注释

“#”号后空一格,段落件用空行分开(同样需要“#”号)

# 块注释
# 块注释
#
# 块注释
# 块注释

2.6.3.2 行注释

至少使用两个空格和语句分开,注意不要使用无意义的注释

# 正确的写法
x = x + 1  # 边框加粗一个像素

# 不推荐的写法(无意义的注释)
x = x + 1 # x加1

2.6.3.3 建议

  • 在代码的关键部分(或比较复杂的地方), 能写注释的要尽量写注释
  • 比较重要的注释段, 使用多个等号隔开, 可以更加醒目, 突出重要性
app = create_app(name, options)


# =====================================
# 请勿在此处添加 get post等app路由行为 !!!
# =====================================


if __name__ == '__main__':
    app.run()

2.6.3.4 文档注释(Docstring)

作为文档的Docstring一般出现在模块头部、函数和类的头部,这样在python中可以通过对象的__doc__对象获取文档. 编辑器和IDE也可以根据Docstring给出自动提示.

  • 文档注释以 """ 开头和结尾, 首行不换行, 如有多行, 末行必需换行, 以下是Google的docstring风格示例
# -*- coding: utf-8 -*-
"""Example docstrings.

This module demonstrates documentation as specified by the `Google Python
Style Guide`_. Docstrings may extend over multiple lines. Sections are created
with a section header and a colon followed by a block of indented text.

Example:
    Examples can be given using either the ``Example`` or ``Examples``
    sections. Sections support any reStructuredText formatting, including
    literal blocks::

        $ python example_google.py

Section breaks are created by resuming unindented text. Section breaks
are also implicitly created anytime a new section starts.
"""
  • 不要在文档注释复制函数定义原型, 而是具体描述其具体内容, 解释具体参数和返回值等
#  不推荐的写法(不要写函数原型等废话)
def function(a, b):
    """function(a, b) -> list"""
    ... ...


#  正确的写法
def function(a, b):
    """计算并返回a到b范围内数据的平均值"""
    ... ...
  • 对函数参数、返回值等的说明采用numpy标准, 如下所示
def func(arg1, arg2):
    """在这里写函数的一句话总结(如: 计算平均值).

    这里是具体描述.

    参数
    ----------
    arg1 : int
        arg1的具体描述
    arg2 : int
        arg2的具体描述

    返回值
    -------
    int
        返回值的具体描述

    参看
    --------
    otherfunc : 其它关联函数等...

    示例
    --------
    示例使用doctest格式, 在`>>>`后的代码可以被文档测试工具作为测试用例自动运行

    >>> a=[1,2,3]
    >>> print [x + 3 for x in a]
    [4, 5, 6]
    """
  • 文档注释不限于中英文, 但不要中英文混用
  • 文档注释不是越长越好, 通常一两句话能把情况说清楚即可
  • 模块、公有类、公有方法, 能写文档注释的, 应该尽量写文档注释

2.7 项目地址

Pit分布式版本控制系统

三、团队计划

posted @ 2018-10-19 21:16  Dandelion-L  阅读(246)  评论(0编辑  收藏  举报