这篇文章主要围绕PythonCodingRule展开，旨在为您提供一份详细的参考资料。我们将全面介绍PythonCodingRule，同时也会为您带来68.26-95.44-99.74rule|emp

这篇文章主要围绕Python Coding Rule展开，旨在为您提供一份详细的参考资料。我们将全面介绍Python Coding Rule，同时也会为您带来68.26-95.44-99.74 rule|empirical rule、Business Facade 与 Business Rule、Coding 如何使用 Coding 开发 Coding、CODING 如何使用 CODING 研发管理系统来敏捷开发的实用方法。

• Python Coding Rule
• 68.26-95.44-99.74 rule|empirical rule
• Business Facade 与 Business Rule
• Coding 如何使用 Coding 开发 Coding
• CODING 如何使用 CODING 研发管理系统来敏捷开发

Python Coding Rule

介绍

• 这篇文档所给出的编码约定适用于在主要的Python发布版本中组成标准库的Python 代码.请查阅相关的关于在Python的C实现中C代码风格指南的描述. 这篇文档改编自Guido最初的《Python风格指南》一文. 并从《Barry''s style guide》中添加了部分内容. 在有冲突的地方，Guide的风格规则应该是符合本PEP的意图 (译注：就是当有冲突时，应以Guido风格为准) 这篇PEP也许仍然尚未完成(实际上，它可能永远不会结束).

一致性的建议

愚蠢得使用一致性是无知的妖怪(A Foolish Consistency is the Hobgoblin of Little Minds)

呆板的坚持一致性是傻的没边了!-- Zoomq

• 在这篇风格指导中的一致性是重要的. 在一个项目内的一致性更重要. 在一个模块或函数内的一致性最重要. 但最重要的是:知道何时会不一致 -- 有时只是没有实施风格指导.当出现疑惑时,
  • 运用你的最佳判断.看看别的例子,然后决定怎样看起来更好.并且要不耻下问!
• 打破一条既定规则的两个好理由:
  1. 当应用这个规则是将导致代码可读性下降,即便对某人来说,他已经习惯于按这条规则来阅读代码了.
  2. 为了和周围的代码保持一致而打破规则(也许是历史原因)
     • -- 虽然这也是个清除其它混乱的好机会(真正的XP风格).

代码的布局

(Code lay-out)

缩进

(Indentation)

• 使用Emacs的Python-mode的默认值:4个空格一个缩进层次. 对于确实古老的代码,你不希望产生混乱,可以继续使用8空格的制表符(8-space tabs). Emacs Python-mode自动发现文件中主要的缩进层次,依此设定缩进参数.

制表符还是空格?

(Tabs or Spaces)

• 永远不要混用制表符和空格. 最流行的Python缩进方式是仅使用空格, 其次是仅使用制表符.混合着制表符和空格缩进的代码将被转换成仅使用空格. (在Emacs中,选中整个缓冲区,按ESC-x去除制表符(untabify).) 调用python命令行解释器时使用-t选项,可对代码中不合法得混合制表符和空格发出警告(warnings). 使用-tt时警告(warnings)将变成错误(errors).这些选项是被高度推荐的. 对于新的项目,强烈推荐仅使用空格(spaces-only)而不是制表符. 许多编辑器拥有使之易于实现的功能.(在Emacs中,确认indent-tabs-mode是nil).

行的最大长度

(Maximum Line Length)

• 周围仍然有许多设备被限制在每行80字符;而且,窗口限制在80个字符 使将多个窗口并排放置成为可能.在这些设备上使用默认的折叠(wrapping)方式看起来有点丑陋. 因此,请将所有行限制在最大79字符(Emacs准确得将行限制为长80字符), 对顺序排放的大块文本(文档字符串或注释),推荐将长度限制在72字符. 折叠长行的首选方法是使用Pyhon支持的圆括号,方括号(brackets)和花括号(braces)内的行延续. 如果需要,你可以在表达式周围增加一对额外的圆括号, 但是有时使用反斜杠看起来更好.确认恰当得缩进了延续的行. Emacs的Python-mode正确得完成了这些.一些例子:

   1         class Rectangle(Blob):    2                 def __init__(self, width, height,    3                              color=''black'', emphasis=None, highlight=0):    4                         if width == 0 and height == 0 and \    5                            color == ''red'' and emphasis == ''strong'' or \    6                            highlight > 100:    7                                 raise ValueError, "sorry, you lose"    8                         if width == 0 and height == 0 and (color == ''red'' or    9                                                            emphasis is None):   10                                 raise ValueError, "I don''t think so"   11                         Blob.__init__(self, width, height,   12                                       color, emphasis, highlight)

空行

(Blank Lines)

• 用两行空行分割顶层函数和类的定义,类内方法的定义用单个空行分割.
• 额外的空行可被用于(保守的(sparingly))分割一组相关函数(groups of related functions). 在一组相关的单句中间可以省略空行.(例如.一组哑元(a set of dummy implementations)).
• 当空行用于分割方法(method)的定义时,在''class''行和第一个方法定义之间也要有一个空行.
• 在函数中使用空行时,请谨慎的用于表示一个逻辑段落(indicate logical sections). Python接受contol-L(即^L)换页符作为空格;Emacs(和一些打印工具) 视这个字符为页面分割符,因此在你的文件中,可以用他们来为相关片段(sections)分页.

编码

(Encodings)(PEP 263)

• Python核心发布中的代码必须始终使用ASCII或Latin-1编码(又名 ISO-8859-1). 使用ASCII的文件不必有译码cookie(coding cookie). Latin-1仅当注释或文档字符串涉及作者名字需要Latin-1时才被使用; 另外使用\x转义字符是在字符串中包含非ASCII(non-ASCII)数据的首选方法. 作为PEP 263实现代码的测试套件的部分文件是个例外.

Python 2.4 以后内核支持 Unicode 了！不论什么情况使用 UTF-8 吧！这是王道！

--ZoomQuiet

导入

(Imports)

• 通常应该在单独的行中导入(Imports),例如:

No:  import sys, os                Yes: import sys                     import os

• 但是这样也是可以的:

from types import StringType, ListType

• Imports 通常被放置在文件的顶部,仅在模块注释和文档字符串之后,在模块的全局变量和常量之前.Imports应该有顺序地成组安放.
  1. 标准库的导入(Imports )
  2. 相关的主包(major package)的导入(即,所有的email包在随后导入)
  3. 特定应用的导入(imports)
• 你应该在每组导入之间放置一个空行.
• 对于内部包的导入是不推荐使用相对导入的.对所有导入都要使用包的绝对路径.
• 从一个包含类的模块中导入类时,通常可以写成这样:

from MyClass import MyClass                from foo.bar.YourClass import YourClass

• 如果这样写导致了本地名字冲突,那么就这样写

import MyClass           import foo.bar.YourClass

• 即使用"MyClass.MyClass"和"foo.bar.YourClass.YourClass"

空格

(Whitespace in Expressions and Statements)

• Guido不喜欢在以下地方出现空格:

• "spam( ham[ 1 ], { eggs: 2 } )".  Always write this as "spam(ham[1], {eggs: 2})".

  • 紧挨着圆括号,方括号和花括号的,如:"spam( ham[ 1 ], { eggs: 2 } )". 要始终将它写成"spam(ham[1], {eggs: 2})".

  "if x == 4 : print x , y ; x , y = y , x". Always write this as "if x == 4: print x, y; x, y = y, x".

  • 紧贴在逗号,分号或冒号前的,如:

  "if x == 4 : print x , y ; x , y = y , x". 要始终将它写成 "if x == 4: print x, y; x, y = y, x".

  • 紧贴着函数调用的参数列表前开式括号(open parenthesis )的,如"spam (1)".要始终将它写成"spam(1)".

  slicing, as in: "dict [''key''] = list [index]". Always write this as "dict[''key''] = list[index]".

  • 紧贴在索引或切片(slicing?下标?)开始的开式括号前的,如:

  "dict [''key''] = list [index]".要始终将它写成"dict[''key''] = list[index]".

  • 在赋值(或其它)运算符周围的用于和其它并排的一个以上的空格,如:

   1                   x             = 1    2                   y             = 2    3                   long_variable = 3

• 要始终将它写成

   1                  x = 1    2                  y = 2    3                  long_variable = 3

• (不要对以上任意一条和他争论 --- Guido 养成这样的风格超过20年了.)

其它建议

(Other Recommendations)

• 始终在这些二元运算符两边放置一个空格:赋值(=), 比较(==, <, >, !=, <>, <=,>=, in, not in, is, is not), 布尔运算 (and, or, not).

* 按你的看法在算术运算符周围插入空格. 始终保持二元运算符两边空格的一致.

• 一些例子:

   1                   i = i+1    2                   submitted = submitted + 1    3                   x = x*2 - 1    4                   hypot2 = x*x + y*y    5                   c = (a+b) * (a-b)    6                   c = (a + b) * (a - b)

• 不要在用于指定关键字参数或默认参数值的''=''号周围使用空格,例如:

   1                   def complex(real, imag=0.0):    2                           return magic(r=real, i=imag)

• 不要将多条语句写在同一行上.

No:  if foo == ''blah'': do_blah_thing()                  Yes: if foo == ''blah'':                                   do_blah_thing()                  No:  do_one(); do_two(); do_three()                  Yes: do_one()                           do_two()                           do_three()

注释

(Comments)

• 同代码不一致的注释比没注释更差.当代码修改时,始终优先更新注释! 注释应该是完整的句子. 如果注释是一个短语或句子,首字母应该大写, 除非他是一个以小写字母开头的标识符(永远不要修改标识符的大小写). 如果注释很短,最好省略末尾的句号(period?结尾句末的停顿?也可以是逗号吧,) 注释块通常由一个或多个由完整句子构成的段落组成,每个句子应该以句号结尾. 你应该在句末,句号后使用两个空格,以便使Emacs的断行和填充工作协调一致 (译按:应该说是使这两种功能正常工作,". "给出了文档结构的提示). 用英语书写时,断词和空格是可用的. 非英语国家的Python程序员:请用英语书写你的注释,除非你120%的确信 这些代码不会被不懂你的语言的人阅读.

我就是坚持全部使用中文来注释，真正要发布脚本工具时，再想E文的；开发时每一瞬间都要用在思量中，坚决不用在E文语法，单词的回忆中！

-- ZoomQUiet

• 约定使用统一的文档化注释格式有利于良好习惯和团队建议！-- CodeCommentingRule

注释块

(Block Comments)

• 注释块通常应用于跟随着一些(或者全部)代码并和这些代码有着相同的缩进层次. 注释块中每行以''#''和一个空格开始(除非他是注释内的缩进文本). 注释块内的段落以仅含单个''#''的行分割. 注释块上下方最好有一空行包围(或上方两行下方一行,对一个新函数定义段的注释).

行内注释

(Inline Comments)

• (inline?内联?翻成"行内"比较好吧)
  • 一个行内注释是和语句在同一行的注释.行内注释应该谨慎适用. 行内注释应该至少用两个空格和语句分开. 它们应该以''#''和单个空格开始.

x = x+1                 # Increment x

• 如果语意是很明了的,那么行内注释是不必要的,事实上是应该被去掉的. 不要这样写:

x = x+1                 # Increment x

x = x+1                 # Compensate for border

• 但是有时,这样是有益的:

x = x+1                 # Compensate for border

文档化

(Documentation Strings)

• Conventions for writing good documentation strings (a.k.a. "docstrings") are immortalized in

  PEP 257. 应该一直遵守编写好的文档字符串(又名"docstrings")的约定(?实在不知道怎么译)

Documentation Strings-- 文档化字符 ;为配合 pydoc;epydoc,Doxygen等等文档化工具的使用,类似于MoinMoin 语法,约定一些字符,以便自动提取转化为有意义的文档章节等等文章元素!-- Zoomq

• 为所有公共模块,函数,类和方法编写文档字符串.文档字符串对非公开的方法不是必要的,但你应该有一个描述这个方法做什么的注释.这个注释应该在"def"这行后.

• PEP 257 描述了好的文档字符串的约定.一定注意,多行文档字符串结尾的""" 应该单独成行,例如:

"""Return a foobang          Optional plotz says to frobnicate the bizbaz first.          """

• 对单行的文档字符串,结尾的"""在同一行也可以.

实际上Python 自个儿就使用文档化编码维护着所有内置对象的使用说明\不信的话常试:        #python>>> import time>>> dir(time)[''__doc__'', ''__file__'', ''__name__'', ''accept2dyear'', ''altzone'', ''asctime'', ''clock'', ''ctime'', ''daylight'', ''gmtime'', ''localtime'', ''mktime'', ''sleep'', ''strftime'', ''strptime'', ''struct_time'', ''time'', ''timezone'', ''tzname'', ''tzset'']>>> help(time.time)Help on built-in function time in module time:time(...)        time() -> floating point number        Return the current time in seconds since the Epoch.        Fractions of a second may be present if the system clock provides them.

版本注记

(Version Bookkeeping) (我觉得叫"注记"更好)

• 如果你要将RCS或CVS的杂项(crud)包含在你的源文件中,按如下做.

   1                 __version__ = "$Revision: 1.4 $"    2                 # $Source: E:/cvsroot/python_doc/pep8.txt,v $

• 这个行应该包含在模块的文档字符串之后,所有代码之前,上下用一个空行分割.

对于CVS的服务器工作标记更应该在代码段中明确出它的使用如：在文档的最开始的版权声明后应加入如下版本标记：# 文件：$id$# 版本： $Revision$这样的标记在提交给配置管理服务器后，会自动适配成为相应的字符串，如：# 文件：$Id: ussp.py,v 1.22 2004/07/21 04:47:41 hd Exp $# 版本： $Revision: 1.4 $----HD

命名约定

(Naming Conventions)

• Python库的命名约定有点混乱,所以我们将永远不能使之变得完全一致--- 不过还是有公认的命名规范的. 新的模块和包(包括第三方的框架)必须符合这些标准,但对已有的库存在不同风格的, 保持内部的一致性是首选的.

描述:命名风格

(Descriptive: Naming Styles)

• 有许多不同的命名风格.以下的有助于辨认正在使用的命名风格,独立于它们的作用. 以下的命名风格是众所周知的:
• b (单个小写字母)
• B (单个大写字母)
• 小写串 如:getname
• 带下划的小写串 如:_getname
• 大写串 如:GETNAME
• 带下划的大写串 如:_GETNAME

• CapitalizedWords(首字母大写单词串) (或 CapWords, CamelCase -- 这样命名是由于它的字母错落有致的样子而来的.

  • 这有时也被当作StudlyCaps. 如:GetName

• mixedCase (混合大小写串)(与首字母大写串不同之处在于第一个字符是小写如:getName)

• Capitalized_Words_With_Underscores(带下划线的首字母大写串) (丑陋!)

• 还有一种使用特别前缀的风格，用于将相关的名字分成组.这在Python中不常用,
• 但是出于完整性要提一下.例如,

  os.stat()函数返回一个tuple, 他的元素传统上有象st_mode, st_size, st_mtime等等这样的名字.X11库的所有公开函数以X开头.

(在Python中,这个风格通常认为是不必要的, 因为属性和方法名以对象作前缀,而函数名以模块名作前缀.)

• 另外,以下用下划线作前导或结尾的特殊形式是被公认的(这些通常可以和任何习惯组合(使用?)):
• _single_leading_underscore(以一个下划线作前导): 弱的"内部使用(internal use)"标志.
  • (例如,"from M import *"不会导入以下划线开头的对象).
• single_trailing_underscore_(以一个下划线结尾): 用于避免与Python关键词的冲突,例如.

  • "Tkinter.Toplevel(master, class_=''ClassName'')".

• __double_leading_underscore(双下划线): 从Python 1.4起为类私有名.

• __double_leading_and_trailing_underscore__: 特殊的(magic) 对象或属性,存在于用户控制的(user-controlled)名字空间, 例如:__init__, __import__ 或 __file__. 有时它们被用户定义, 用于触发某个特殊行为(magic behavior)(例如:运算符重载); 有时被构造器(infrastructure)插入,以便自己使用或为了调试. 因此,在未来的版本中,构造器(松散得定义为Python解释器和标准库) 可能打算建立自己的魔法属性列表,用户代码通常应该限制将这种约定作为己用. 欲成为构造器的一部分的用户代码可以在下滑线中结合使用短前缀,例如. __bobo_magic_attr__.

说明:命名约定

(Prescriptive: Naming Conventions)

应避免的名字

(Names to Avoid)

• 永远不要用字符`l''(小写字母el(就是读音,下同)),

  O''(大写字母oh),或I''(大写字母eye)作为单字符的变量名. 在某些字体中,这些字符不能与数字1和0分开.当想要使用''l''时，用''L''代替它.

模块名

(Module Names)

• 模块应该是不含下划线的,简短的,小写的名字. 因为模块名被映射到文件名, 有些文件系统大小写不敏感并且截短长名字, 模块名被选为相当短是重要的---这在Unix上不是问题, 但当代码传到Mac 或Windows上就可能是个问题了. 当一个用C或C++写的扩展模块有一个伴随的Python模块,这个Python模块提供了
  • 一个更高层(例如，更面向对象)的接口时,C/C++模块有一个前导下划线(如：_socket)
  Python包应该是不含下划线的,简短的,全小写的名字.

类名

(Class Names)

• 几乎没有例外，类名总是使用首字母大写单词串(CapWords)的约定.

异常名

(Exception Names)

• 如果模块对所有情况定义了单个异常,它通常被叫做"error"或"Error". 似乎内建(扩展)的模块使用"error"(例如:os.error), 而Python模块通常用"Error" (例如: xdrlib.Error).

  趋势似乎是倾向使用CapWords异常名.

全局变量名

(Global Variable Names)

• (让我们希望这些变量打算只被用于模块内部) 这些约定与那些用于函数的约定差不多.被设计可以通过"from M import *"来使用的
  • 那些模块,应该在那些不想被导入的全局变量(还有内部函数和类)前加一个下划线).

函数名

(Function Names)

• 函数名应该为小写,可能用下划线风格单词以增加可读性.

  mixedCase仅被允许用于这种风格已经占优势的上下文(如: threading.py) 以便保持向后兼容.

方法名和实例变量

(Method Names and Instance Variables)

• 这段大体上和函数相同:通常使用小写单词,必要时用下划线分隔增加可读性. 使用一个前导下划线仅用于不打算作为类的公共接口的内部方法和实例变量. Python不强制要求这样; 它取决于程序员是否遵守这个约定. 使用两个前导下划线以表示类私有的名字. Python将这些名字和类名连接在一起:

  如果类Foo有一个属性名为 __a, 它不能以Foo.__a访问. (执著的用户(An insistent user)还是可以通过Foo._Foo__a得到访问权.) 通常,双前导下划线应该只用来避免与类(为可以子类化所设计)中的属性发生名字冲突.

继承的设计

(Designing for inheritance)

• 始终要确定一个类中的方法和实例变量是否要被公开. 通常,永远不要将数据变量公开,除非你实现的本质上只是记录. 人们总是更喜欢给类提供一个函数的接口作为替换 (Python 2.2 的一些开发者在这点上做得非常漂亮). 同样,确定你的属性是否应为私有的.私有与非公有的区别在于: 前者永远不会被用在一个派生类中,而后者可能会. 是的,你应该在大脑中就用继承设计好了你的类. 私有属性必须有两个前导下划线,无后置下划线. 非公有属性必须有一个前导下划线,无后置下划线. 公共属性没有前导和后置下划线,除非它们与保留字冲突, 在此情况下,单个后置下划线比前置或混乱的拼写要好, 例如:class_优于klass. 最后一点有些争议; 如果相比class_你更喜欢klass,那么这只是一致性问题.

设计建议

(Programming Recommendations)

• 同象None之类的单值进行比较,应该永远用:''is''或''is not''来做. 当你本意是"if x is not None"时,对写成"if x"要小心 -- 例如当你测试一个默认为None的变量或参数是否被设置为其它值时. 这个其它值可能是一个在布尔上下文中为假的值!
• 基于类的异常总是好过基于字符串的异常. 模块和包应该定义它们自己的域内特定的基异常类(base exception class), 基类应该是内建的Exception类的子类. 还始终包含一个类的文档字符串.例如:

   1                 class MessageError(Exception):    2                         """Base class for errors in the email package."""

• 使用字符串方法(methods)代替字符串模块,除非必须向后兼容Python 2.0以前的版本. 字符串方法总是非常快,而且和unicode字符串共用同样的API(应用程序接口)
• 在检查前缀或后缀时避免对字符串进行切片. 用startswith()和endswith()代替, 因为它们是明确的并且错误更少. 例如:

No:  if foo[:3] == ''bar'':                Yes: if foo.startswith(''bar''):

• 例外是如果你的代码必须工作在Python 1.5.2 (但是我们希望它不会发生!).
• 对象类型的比较应该始终用isinstance()代替直接比较类型.例如:

No:  if type(obj) is type(1):                Yes: if isinstance(obj, int):

• 检查一个对象是否是字符串时,紧记它也可能是unicode字符串! 在Python 2.3, str和unicode有公共的基类,basestring,所以你可以这样做:

   1                 if isinstance(obj, basestring):

• 在Python 2.2 类型模块为此定义了StringTypes类型, 例如:

   1                 from types import StringTypes    2                 if isinstance(obj, StringTypes):

• 在Python 2.0和2.1,你应该这样做:

   1                 from types import StringType, UnicodeType    2                 if isinstance(obj, StringType) or \    3                    isinstance(obj, UnicodeType) :

• 对序列,(字符串(strings),列表(lists),元组(tuples)), 使用空列表是false这个事实,因此"if not seq"或"if seq"比 "if len(seq)"或"if not len(seq)"好.
• 书写字符串文字时不要依赖于有意义的后置空格. 这种后置空格在视觉上是不可辨别的,并且有些编辑器(特别是近来,reindent.py) 会将它们修整掉.
• 不要用 == 来比较布尔型的值以确定是True或False(布尔型是Pythn 2.3中新增的)

No:  if greeting == True:                Yes: if greeting:                No:  if greeting == True:                Yes: if greeting:

68.26-95.44-99.74 rule|empirical rule

Business Facade 与 Business Rule

Business Facade 和 Business Rule 都是 Business Logic 的细分层，它们共同协作完成特定的商业逻辑处理。

但Business Facade是Business Rule的前一个层次，负责接收Web Service或都Web UI的请求，并验证请求的正确性，参数格式是否合法，一切验证结束后，再将请求交给Business Rule层，主要完成对Business Rule的调用前的一些校验，在接收到Business Rule层的处理结果之后，根据不同的请求客户端将结果格式化成请求客户端想要的格式。

同时，一些常用的简单的判断处理也可以交给Business Facade层处理，而不用在Business Rule层上实现，从而实现更清晰的结构化。各司其则，有利于架构的扩展及维护。另外，如果是小型的项目，可以将其合并为一个层次。

我干脆这样来理解：Business Facade 与客户端有关，Business Rule 与客户端无关。

Coding 如何使用 Coding 开发 Coding

Coding Anytime Anywhere

Coding 团队有 70 多人，分布在全国各地（深圳，北京，上海，成都），我们使用 Coding 作为云端办公室，以云端协作的方式管理事务，文件等，我们的日常工作（包括但不限于产品，研发，市场）都是在其上完成的。Coding 的 全平台支持 让大家可以随时随地进行同步与协作，我们一直在践行 “Coding Anytime Anywhere”。

我们使用 Coding 团队功能管理团队成员和私有项目，只需要在 Coding 创建一个团队，选择迁入私有项目并添加人员，即可完成对成员，团队与项目的管理。（项目内也可以 设置不同成员的权限）

Push Everytime，Review Everything

Coding 的工作流（从需求到产品原型到开发）都是在项目内进行的：我们使用讨论和任务功能管理需求，使用文件功能管理产品原型，使用代码功能进行开发，这也便于每个人随时 Follow 或 Review 任务，文件或代码。

需求

我们使用 Coding 的 公开项目讨论功能 收集用户反馈，提炼核心需求并定期 Review 进行取舍。

为什么要 Review 产品需求？
软件缺陷并不只是在开发阶段才产生，需求和设计阶段同样可能会产生缺陷。

产品

当产品研究决定我们要实现某功能时，我们会以任务形式发布该需求，然后进行技术评审（如果是重大新功能还需要进行设计评审），评审完成且结果为肯定时我们会继续细化（修改）该任务，进行产品设计及排期。

在产品设计过程中，我们使用 Coding 的文件管理功能进行对产品原型的管理和版本管理。

开发

Coding 的开发方式，更像是一个大型的开源项目协作。当需求及产品原型以任务形式确定后，开发人员就开始基于自己的功能分支进行开发，其后的代码评审是也是通过项目内提交 MR （合并请求）进行的。

我们使用了 Feature Branch Workflow，即团队成员共用一个私有项目仓库进行管理协作，开发者在各自的 feature-branch 中进行开发，开发完成后通过提交 Merge Request 进行代码评审，通过代码评审后 merge 进入 master 分支（ master 分支是可部署到 staging/生产环境的分支）。

工作流（Workflow），是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。合理选择并使用一套工作流可以让技术团队开发更高效，更简单！

Workflow 没有银弹 ，如果你的：

• 生产环境有多个版本，需要持续支持旧版本的软件服务如操作系统，自定义应用程序等，可使用 Gitflow

• 生产环境只有一个版本，如网站，网络服务等，可使用 Feature Branch Workflow

• 生产环境只有一个版本但软件很复杂，需要 CI/CD 后才能进入生产环境的如 Gmail，Twitter 等，可使用 Gitlab-flow

测试与上线

当开发人员 push 代码后会触发 Webhook，我们的 Jenkins 会自动编译并测试该 commit。

你的部署工具应该支持你部署分支是很重要的。一旦你确认你的性能没有波动，没有稳定性问题，功能可用性在预期内，你就可以 merge 它了。这么做的原因不是为了确保事情可行，而是防止事情不可行。当其出错时，你的解决方案应该是单调，直接且无压力的：重新部署 master 分支即可。就是这样，你回到了“没问题”的状态。—— 《如何部署软件》

当测试通过时，我们会更新代码到 Staging 环境，更新好后由测试人员进行相关测试。Staging 环境测试没问题后，我们会以 Feature Flags （内部测试新功能）的形式发布其到生产环境，通知相关的产品或设计人员开启 Feature Flags 进行内部 Review，如果存在问题或缺陷，我们会新建一个任务进行修复，确保功能及设计细节的正确性。

如果经测试新功能确认没问题后，我们会开放该 Feature Flags，将该功能开放给全体用户。

结语

Coding 始终认为开发工具应该足够简单，开发人员的生成力应该被解放出来，我们使用 Coding 这个开发工具进行开发，旨在不断优化提升 Coding 的体验，让开发更简单。当然，如果你有任何需求或建议，请不要忘了 提交给我们 ；）

Happy Coding!

感谢 @summer ，@rexskz Review 了本文并提出修改意见，感谢 @tankxu 设计的图片（How Coding uses Coding to build Coding）

CODING 如何使用 CODING 研发管理系统来敏捷开发

之前我们分享过《CODING 如何使用 CODING 开发 CODING》的文章，时过境迁，现在 CODING 研发管理系统已经上线了如持续集成、缺陷管理、测试管理等 DevOps 中的重要功能，并增加了对 SVN 的支持。借此机会我们以自身的研发流程为例，来展示一下 How CODING uses CODING to build CODING 2.0。

企业级一站式软件研发协作平台

CODING 现在的团队有 100 多人，分布在全球各地（深圳、北京、成都、西雅图等），均使用 CODING 研发管理系统作为云端协作平台。在 CODING，不仅研发相关的团队使用 CODING 来进行研发管理，市场、运营、行政的部门也同样使用 CODING 进行任务分配与追踪、文件分享等日常工作。

同时通过 CODING 的企业微信/微信小程序，还能实现随时随地同步与协同任务，小程序可以直接查看任务详情、评论任务，还能实现代码合并（MR）等功能，真正做到 Coding Anytime Anywhere。

CODING 研发管理系统是基于项目进行的，我们依据组织架构建立了相关项目并使用【成员管理】添加相应部门的人员。通过项目这种扁平化的管理形式，帮助企业加快反应速度，提高自身敏捷性。

下周即将上线的 CODING 权限管理功能，可以帮助项目管理员方便地根据项目成员角色来分配相应的权限，减少误操作带来的安全隐患。同时支持自定义用户组，增加研发管理的灵活性。

Push Everything,Review Everything,CI Everything

workflow

CODING 研发部门的工作流都是在项目内进行：我们使用任务功能来管理需求，使用文件来保存产品原型，使用代码功能进行开发，使用持续集成来进行自动化测试，使用缺陷管理来收集反馈，同时还使用 wiki 模块对知识进行储存与共享。通过在任务中添加关注者的方式来方便相关同事随时 follow 和 review 任务动态。

CODING 强大的任务系统支持标签、跨项目引用、版本控制等多项功能，并会实时记录用户的每一次操作。同时 CODING 需求管理功能也即将上线，将在任务系统之外为用户提供更细分更场景化的使用方式。

产品

CODING 的产品经理在正常的产品功能排期之外，会定期在缺陷管理中查看用户的使用反馈并对相关问题的修复进行排期。

当产品经理研究决定我们要实现某一个功能/修复缺陷时，会以任务的形式发布该需求。但是在发布需求之前有几件事情需要先做。

给任务定性

产品经理会把任务放入“需求反馈池”看板，并给任务定性：

• 纯技术问题（含纯技术 Bug），则指派给研发负责人进行跟进。
• 纯设计问题，则指派给设计负责人进行跟进。
• （真）产品问题，则准备与发任务的源头沟通分析此问题。

问题分析

• 伪需求，或者反馈方理解有误，则直接在相关任务中回复，并关闭任务即可。
• 真需求，则完善对应的背景信息，并将任务拖入“已分析需求池”。
• Bug 类，可以内部请测试人员来尝试复现此问题。如果可复现，则给此任务打上“Bug 池”、“已确认”标签，再将任务放入“已分析需求池”。

分析完需求后即可创建任务，如该任务涉及大型产品改动，则会由相应产品经理撰写完整的产品说明文档和必要的原型图等文件；方案完成之后，产品经理会根据任务的紧急程度给任务设定优先级，方便后续设计和开发的同事更方便的安排工作。

在产品设计过程中，我们使用 CODING 的文件管理功能对产品进行原型管理和版本管理。

功能开发完成后，产品经理还会配合研发进行 Staging 环境的验收。如在 Staging 环境中发现问题，则需要与发布负责人协商回退或是重新发版，成功完成验收则通知运维上生产环节。

开发

在产品经理完成原型图和产品说明后，便会把任务移交给研发负责人，进行评估和排期，完成排期后研发负责人会根据任务情况安排里程碑。

开发人员开始基于自己的里程碑任务进行开发，其后的代码评审也是通过项目内提交 MR （合并请求）进行的。

CODING 使用了 Feature Branch Workflow，即团队成员共用一个私有项目仓库进行管理协作，开发者在各自的 feature-branch 中进行开发。

Code Review

开发完成后通过提交 Merge Request 进行代码评审，通过代码评审后 merge 进入 master 分支（master 分支是可部署到 staging/生产环境的分支）。

持续集成

当开发人员 push 代码时，将会自动触发已设置好的持续集成，CODING 的持续集成会自动编译并测试该 commit。CODING 持续集成支持在任意阶段触发并支持 cvm 模式。

当测试通过后，我们会更新代码到 Staging 环境。

测试

更新 Staging 的代码后，测试人员开始进行相关测试。现在 CODING 的测试管理功能由 18 年收购的专业测试工具飞蛾（ FEIE.WORK）承载，已实现了企业账号打通，可直接在测试管理中点击跳转到飞蛾的工作界面。

接到测试任务后，测试的同时会先在飞蛾中制定相应的测试计划。

制定好测试计划后，即可开始编写相关测试用例并开始执行测试计划。

Staging 环境测试无问题后，该功能会以 Feature Flags（内部测试新功能）的形式发布其到生产环境，通知相关的产品或设计人员开启 Feature Flags 进行内部 Review，如果存在问题或缺陷，我们会新建一个任务进行产品反馈，确保功能及设计细节的正确性。

运营

产品正式上线后，CODING 的运营同事会开始收集用户反馈，通过各个渠道反馈的问题都会在 CODING 缺陷管理功能中以创建缺陷的方式进行归纳。

运营会定期将收集来的缺陷进行分析，将 Bug 类的缺陷转给产品经理进行排期。如在生产环节发现重大 Bug 则会立即和产品经理沟通并通知运维，协商回退版本或者临时修复。

市场

在确认功能顺利上线后，产品经理会在 CODING Wiki 中更新 Roadmap，提示功能已经上线。方便市场部进行 Campaign 的计划。

市场部的同事使用 CODING 任务管理中的讨论功能，可以实时讨论和跟踪项目进度。

让开发更简单

工欲善其事，必先利其器，在现在数字化的商业环境中，企业对于软件的依赖已经达到了前所未有的高度。如何选择一套适合中国软件研发团队的开发工具和高效的研发流程，以解放开发人员的效能，打造更好的产品，已经成为每个企业必须要思考的问题。逆水行舟，不进则退，我们自身使用 CODING 进行开发，旨在不断完善 CODING 的功能，优化提升 CODING 的使用体验，让 CODING 成为最适合中国式敏捷的研发管理系统，真正做到让中国的软件研发团队开发更简单！

欢迎试用 CODING 研发管理系统，同时我们也欢迎各种反馈，如果你有任何需求或建议，请不要忘了提交给我们 :D

官方反馈渠道：
联系电话：400-930-9163
邮箱：enterprise@coding.net

今天关于Python Coding Rule的介绍到此结束，谢谢您的阅读，有关68.26-95.44-99.74 rule|empirical rule、Business Facade 与 Business Rule、Coding 如何使用 Coding 开发 Coding、CODING 如何使用 CODING 研发管理系统来敏捷开发等更多相关知识的信息可以在本站进行查询。