10k

设计模式之美-课程笔记47-开源实战2-从UNIX上学习大型复杂项目开发

从Unix开源开发学习应对大型复杂项目开发

从设计原则和思想的角度来看如何应对大项目开发

封装与抽象

  1. 一切皆文件。所有的文件都可以当成文件使用read write标准函数访问。
  2. 这个哲学就是封装与抽象。封装了不同类型的设备的访问细节,抽象为统一的文件访问方式。隔离底层的复杂性,上层代码的编写更简单,也更容易复用。也能防止复杂的蔓延。

分层与模块化

  1. 复杂系统通过分层和模块化,可以方便的管理和集中开发各个模块,各个模块除了在交互的时候,内部的逻辑互不干涉。

基于接口通信

  1. 模块和层在暴露接口的时候要隐藏实现,接口的命名和定义要抽象一些,少涉及具体的实现细节。

高内聚、松耦合

  1. 高内聚,低耦合的代码可以让我们在阅读和修改的时候更聚焦,避免了过多的对其他模块的修改。

为扩展而设计

  1. 满足开闭原则:封装和抽象,基于接口编程。
  2. 识别可变部分和不可变部分,将可变部分封装隔离变化,提供抽象化的不可变接口。

KISS首要原则

  1. 避免过度设计、过早优化。扩展性和可读性冲突的时候首选可读性。

最小惊奇原则

  1. 遵循项目的整体开发规范,避免反直觉的开发(奇技淫巧)。

从研发管理和开发技巧的角度看

1. 严格执行编码规范

2. 高质量单元测试

3. 好的Code Review

4. 开发未动,文档先行

5. 持续重构

6. 对项目和团队进行拆分

如何通过Code Review保持项目的代码质量

  1. Google Code Review Developer Guide

Why Code review

1. 三人行必有我师

代码经过多人的推敲仍然可能有改进的空间

2. 超越个人智慧

代码不应该依赖个人智慧和能力,通过review可以集合团队的最好水平。

3. 可读性

第二视角。

4. 技术传递

知识讲解,技术分析和分享。

5. 让更多人看到代码

保证不止一个人熟悉代码

6. 技术氛围
7. 技术沟通
8. 提升团队自律

个人知道自己的代码要被review会提升出品。

如何执行

  1. 当成工作一部分,留时间。
  2. 提升大家的重视。
Thoughts? Leave a comment