Cómo escribir un documento de diseño de software

Java Geek | Autor / Keng Ran Yiye Este es el artículo original número 91 de Java Geek

Lectura relacionada:

El camino de rápido crecimiento de Mengxin
Ideas de programación JAVA (1) Aumentar la escalabilidad a través de la inyección de dependencias
Ideas de programación JAVA (2) Cómo programar orientada a la interfaz
Ideas de programación JAVA (3) Eliminar el incómodo si, el modo de estrategia de autorregistro cumple con elegancia el principio de apertura y cierre
Programación JAVA Pensamiento (4) ¿Cómo elegir el paradigma clásico de modo Builder y modo fábrica?
Ideas de programación Java (5) Proceso de desacoplamiento del modo de notificación de eventos
Ideas de programación Java (6) Proceso de desacoplamiento del modo de notificación de eventos
Ideas de programación Java (7) Escenarios que utilizan combinación y herencia
Conceptos básicos de JAVA (1) Comprensión simple y completa de las clases internas y los componentes internos estáticos Clase
JAVA Conceptos básicos (2) Optimización de la memoria: uso de referencias de Java como cachés Conceptos básicos de JAVA ( 3
de carga en caliente
) ClassLoader realiza el código fuente HikariPool de Blade (2) Ideas de diseño para referencia [Código fuente Geek] Código fuente JetCache (1) Apertura [Fuente Geek Código] Código fuente de JetCache (2) Vista superior Personas en el lugar de trabajo (1) Reglas de supervivencia de las empresas de TI





0. Prefacio

Este artículo se utiliza principalmente como referencia para los desarrolladores que no saben cómo escribir documentos de diseño de software y no saben cómo empezar; es solo un resumen, no un documento de guía detallado.

El diseño de software cubre muchos puntos, aquí solo se describen algunos puntos comunes y clave del sistema de software de aplicación.

1. Determinantes del contenido del documento de diseño de software

1.1 Tipos de sistemas de software

不同软件系统类型会影响影响软件设计文档的内容,例如应用软件系统、嵌入式软件系统、大数据分析软件系统的内容;云化和非云化系统的内容也可能不同。

1.2 软件设计文档的读者

不同的读者关注的设计文档内容不同,例如CIO、CTO、架构师、设计师,开发者、测试人员、服务人员,关注点不同,就会通过不同的文档来体现,或者通过一个文档的不同章节来体现。

1.3 软件设计文档的分类

软件设计文档的分类不同,其内容也会不同,例如架构设计、系统设计、功能设计、实现设计。

例如架构设计体现方案、系统关系、系统接口、技术选型;实现设计体现类关系,类职责等等。

1.4 软件组织

软件系统越复杂,功能越多,软件组织就越大,就越需要完善的设计文档来保证软件质量,用于设计评审、知识传递、避免理解偏差等等。如果一个软件系统就3、4个人开发(包含验证),且每个人都很有经验,此时往往会省略很多软件设计文档,通过Issue简单描述跟踪则可,当然Issue单中可能会有一些关键点的设计描述。

1.5 软件成熟度

组织对软件成熟度要求越高,对软件的交付件要求越高,随之对软件设计文档的要求也越高。

1.6 小结

没有一个通用的软件设计模版适用所有系统和场景,需要根据实际情况进行选择和裁剪。

是否需要软件设计文档,文档包含哪些内容,要根据软件项目、软件系统,组织等因素决定,并非总是需要软件设计文档,不需要为了写设计文档而写,但总的来说,设计文档有助于提升软件质量,及早发现设计问题。

2. 软件设计文档包含的内容

不同软件公司都有自己的软件设计文档模版,不一而同,这里仅描述一些常见内容,至于归属哪一类设计文档(架构设计、系统设计、功能设计、实现设计),可自行定义。

2.1 文档目的

说明文档的目的,做什么用。

2.2 范围

说明文档描述的范围,用于澄清哪些在范围内,哪些不在范围内。

2.3 约束和声明

描述系统中的约束以及声明,例如软件依赖(只支持Chrome)、XXX系统依赖等等。

此章节主要目的也是为了提前声明软件受限提供能力,属于一种保护措施。

2.4 目标

软件系统的目标,例如商业目标,架构目标(满足未来XXX年的技术演进),降低成本目标,SaaS化目标,云化目标等等,通过目标牵引,软件设计需要围绕目标达成而设计。

2.5 上下文

系统上下文描述,描述系统的边界。

2.6 核心业务模型

业务上的核心模型描述,参与人,核心业务实体关系。

2.7 技术选型

技术选型,例如:
1)开发语言(Java,Go,Vue,React)
2)中间件选型(ETC/Zookeeper,Nacos/阿波罗)
3)平台选型(阿里云,腾讯云,华为云)
等等。

2.8 备选方案

对于复杂业务,同时考虑上市时间,成本等各种因素,并非所有方案都十全十美,有的演进能力有优势,有的成本有优势,提供备选方案用于综合评估使用哪种方案。

2.9 逻辑架构

逻辑架构体现系统的组成,系统、子系统、服务、组件、模块,以及它们之间的关系。

开发视图中服务、组件和代码仓关系。

构建视图中代码仓和构建的二进制包,部署包的关系。

2.10 组网

具体的部署组网,例如安全域、逻辑域划分,部署节点,哪些容器化哪些物理机部署,副本数,容灾等。

2.11 设计思路

说明为什么要如此设计的思路,让人对方案更容易理解。

2.12 特性设计

特性是从外部视角来看,是对功能的包装,例如微信支持消息在多终端同步,这是一个特性,围绕消息同步,后面会有很多细分功能。

因此特性通常是对客户而言的,或者对客户来说可以售卖的,例如印象笔记不同账户下体现的这些就是特性:

imagen.png

2.13 功能设计

具体的功能设计,例如文件上传,日志打印,充值异常充正的处理。

2.14 可靠性

保证可靠性的设计,例如冗余设计,容错设计。

2.15 可用性

系统可用性设计,例如优雅停机、滚动升级、降级、bypass。

2.16 可服务性

Por ejemplo, instalación, actualización, mantenibilidad y puesta en marcha.

2.17 Sustituibilidad

Si se puede reemplazar fácilmente sin depender de una pila de tecnología específica, como reemplazar el centro de configuración de nacos a Apollo, reemplazar zookeeper con etcd y reemplazar oracle con mysql.

2.18 Rendimiento

Diseño relacionado con el rendimiento, como concurrencia, paralelismo, indicadores de rendimiento a alcanzar y requisitos de hardware basados ​​en indicadores de rendimiento.

2.20 Seguridad

El diseño relacionado con la seguridad involucra una amplia gama de áreas, como la seguridad de la transmisión de datos, la seguridad del contenedor docker, la seguridad web, la seguridad del código Java, las vulnerabilidades del software de código abierto, etc.

2.21 Diseño de experiencia de usuario

La creación de prototipos de interfaz, tanto de baja como de alta fidelidad, generalmente la realizan los gerentes de producto y los diseñadores de UX.

2.22 Privacidad por diseño

En la actualidad, ya sea un sistema interno o un sistema externo, los datos del usuario estarán involucrados, lo que implica un diseño relacionado con la privacidad, incluida la declaración de privacidad, el alcance del uso de datos, el propósito, el tiempo de retención, etc.

2.23 Software de código abierto

Diseño relacionado con software de código abierto, como selección de software de código abierto, selección de versión y diseño para el uso de diferentes licencias de software de código abierto.

3. Sugerencias

Aunque muchos desarrolladores no están dispuestos a escribir documentos de diseño y sienten que consume mucho tiempo o es innecesario, sigo recomendando escribir, al menos se puede recortar y se conservan las partes importantes del núcleo. Escribir documentación tiene al menos los siguientes beneficios:

  • Transferencia de conocimiento (por ejemplo: vista global, si el front-end conoce todo el sistema de red o solo se preocupa por la página; cómo garantizar que los probadores diseñen correctamente los casos de prueba; cómo los recién llegados comienzan rápidamente).
  • Las funciones complejas pueden reducir la repetición del trabajo y mejorar la eficiencia del desarrollo a través de la revisión del diseño.
  • Mejore sus capacidades de análisis y diseño.

fin.


<--¡Después de leer la marca, dale me gusta a la izquierda!


Supongo que te gusta

Origin juejin.im/post/7266249095869628427
Recomendado
Clasificación