确定分工

代码规范和编码原则

代码规范

代码规范可以分成两个部分:

  • 代码风格规范,主要是文字上的规定;
  • 代码设计规范,牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。

代码风格规范

  • 代码风格的原则是:简明、易读、无二义性。

  • 缩进:将Tab键扩展定义为4个空格。不直接使用tab键的原因是它在不同的情况下会显示不同的长度。4个空格可读性高;

  • 行宽:行宽必须限制,建议100字符;

  • 括号:在复杂的条件表达式中,用括号清楚地表示逻辑优先级;

  • 断行与空白的{}行:

  • 分行:不要把多中不同的操作放在同一行(书中建议“不要把多个变量定义在一行”,可能会使代码不够简洁);

  • 命名:“匈牙利命名法”;

  • 下划线:分隔变量名字中的作用域标注的变量的语义;

  • 大小写:全部大写、小写会导致不易读,所有的类型/类/函数名用 Pascal 形式(每个单词首字母大写),所有变量都用 Camel (第一个单词小写,后面用 Pascal );

  • 注释:解释程序做什么,为什么这样做。复杂的注释放在函数头,解释参数,要不断更新(书中建议使用ASCII码以增强可移植性,但实际操作复杂,我们不做这方面的要求);

代码设计规范

  • 函数:只做一件事,做好一件事;
  • goto:可使用goto实现函数的单一出口(但也要尽量少使用),助于程序逻辑的清晰体现
  • 错误处理:参数处理、断言。在Debug版本中,所有参数都要验证其正确性,在正式版本中,对外部转递就俩的参数要验证其正确性;
  • 运算符:一般情况下不需要自定义操作符,运算符不要做标准语义以外的任何动作。运算符的实现必须非常有效率,如有复杂的操作,应定义一个单独的函数;
  • 单一职责原则 Single Responsibility Principle
  • 一个类或者一个接口,最好只负责一项职责。
  • 遵循单一职责原则。分别建立新的类来对应相应的职责;这样就能避免修改类时影响到其他的职责。

里氏替换原则 Liskov Substitution Principle

在使用基类的地方可以任意使用其子类,能保证子类完美替换基类;这一种精神其实是对继承机制约束规范的体现。在父类和子类的具体实现中,严格控制继承层次中的关系特征,以保证用子类替换基类时,程序行为不发生问题,且能正常进行下去。
对于继承来说,父类定义了一系列的规范和契约,虽然不强制所有的子类必须遵从,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破环。

依赖倒置原则 Dependence Inversion Principle

高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象,其核心思想是依赖于抽象;
问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来完成;这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原则操作;假如修改类A,会给程序带来不必要的风险。
在实际中,我们一般需要做到以下三点:

  • 低层模块尽量都要有抽象类或者接口,或者两者都有
  • 变量的声明类型尽量是抽象类或者接口
  • 使用继承时遵循里氏替换原则
    解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I来间接与类B和类C发生联系,则会降低修改类A的几率。

接口隔离原则 Interface Segregation Principle

客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上,否则将会造成接口污染;类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现它们不需要的方法。
原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少;就是说,我们要为每个类建立专用的接口,而不要试图去建立一个庞大的接口供所有依赖它的### 类去调用
如何实施接口隔离,主要有两种方法:

  • 委托分离,通过增加一个新的接口类型来委托客户的请求,隔离客户和接口的直接依赖,注意这同时也会增加系统的开销;
  • 多重继承分离,通过接口的多重继承来实现客户的需求。

迪米特法则

一个对象应该对其他对象保持最少的了解,其核心精神就是:不和陌生人说话,通俗之意就是一个对象对自己需要耦合关联调用的类应该知道的少;这会导致类之间的耦合度降低,每个类都尽量减少对其他类的依赖。

合成复用原则

原则是尽量使用合成/聚合的方式,而不是使用继承。

开闭原则

一个软件实体如类、模版和函数应该对扩展,对修改关闭。
解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是修改已有的代码来实现变化。

  • 单一职责原则:实现类要职责单一
  • 里氏替换原则:不要破坏继承体系
  • 依赖倒置原则:面向接口编程
  • 接口隔离原则:设计接口的时候要精简单一
  • 迪米特法则:降低耦合
  • 开闭原则:总纲,对扩展开放,对修改关闭

代码复审

  • 形式:自我复审、同伴复审、团队复审
  • 目的:找出代码错误、发现逻辑错误、发现算法错误、发现潜在的错误和回归性错误、发现可能需要改进的地方、传授经验
  • 代码复审后把记录整理出来:
  • 更正明显的错误
  • 记录无法很快更正的错误
  • 把所有的错误记在自己的一个“我常犯的错误”表中,作为以后自我复审的第一步

通过Powerdesigner完成团队项目的数据库设计,并在随笔中提供相应ER图

进行项目的后端架构设计

利用象限法确定各个核心需求的优先级,依据需求优先级确定团队Alpha 版本需要实现的功能,在博客中叙述并给出相应的WBS图

燃尽图

分工情况

组员 任务
李阳 后端架构设计
王聪 数据库设计及ER图
李高佳 wbs
瞿王驰 燃尽图
任峰皓 代码规范
徐铭泽 编码原则
posted @ 2022-11-06 22:17  任峰皓  阅读(56)  评论(0编辑  收藏  举报