I. Introducción
Como desarrollador técnico, especialmente senior, desarrolladores senior, arquitectos, etc., a menudo se encuentran escribiendo soluciones técnicas basadas en requisitos. Entonces, cómo escribir un buen diseño de solución técnica, hablemos de este tema hoy.
2. ¿Es necesaria la solución técnica?
La respuesta es sí.
He visto demasiados proyectos debido a una planificación previa insuficiente (o incluso sin diseño técnico, un seminario técnico para comunicarse verbalmente y luego evaluar directamente el período de construcción), y hay muchos proyectos con períodos de construcción muy largos. Al final, cuando llegó la etapa de depuración conjunta, los diversos grupos no pudieron conectarse entre sí. Lo que es aún más ridículo fue que no hubo una comunicación clara entre el producto y los estudiantes del producto. Como resultado, al final fue muy pasivo, cavando hoyos y llenando agujeros en todas partes, y tomó más tiempo y energía, e incluso provocó retrasos en el proyecto, expansión de seguimiento débil y otros problemas.
Así que creo que las soluciones técnicas son una parte esencial. A menudo se pueden evitar muchas trampas en esta etapa.
Los antiguos decían: “No es lo mismo afilar un cuchillo que cortar leña por error”, la solución técnica es el proceso de afilar el cuchillo.
3. Cómo redactar un buen plan técnico
-
Es la dirección general para satisfacer las necesidades y satisfacer las necesidades.
-
puede ser implementado. Es necesario considerar si se puede desembarcar en las condiciones actuales, tales como:
-
Aceptabilidad de los miembros del equipo: al seleccionar la tecnología, se debe considerar la capacidad de aceptación de los miembros del equipo. La introducción ciega de nuevas tecnologías puede causar problemas impredecibles.
-
Costo de tiempo: en términos generales, para proyectos back-end de Java o PHP (los proyectos de lenguaje C pueden demorar un año o incluso más), el período de tiempo de 3 meses es relativamente largo. Si se sigue este plan, tomará medio año o más. incluso más tiempo Eso también podría ser poco práctico.
-
Costo de recursos: por ejemplo, es posible que el proyecto deba introducir recursos básicos como Redis, Mysql, ES, MongoDB, etc., si la empresa puede proporcionar estos recursos (los servidores cuestan dinero). De lo contrario, al escribir una solución técnica, es posible que deba considerar si existen alternativas.
Manejo de emergencias y garantía de confiabilidad Siempre que las personas puedan pensar en los problemas, definitivamente ocurrirán y no debería haber una mentalidad de casualidad. Entonces, para hacer un buen trabajo de estrategias de afrontamiento de problemas, aquí debe hacerse de la siguiente manera:
-
esquema de escala de grises
-
plan de degradación
-
manejo de excepciones
-
evaluación de la capacidad
4. Plantilla de plan técnico
La siguiente es la plantilla de diseño de solución técnica que resumí y espero que sea útil para todos.
1. Antecedentes
El estado de fondo actual, explique brevemente los problemas encontrados en el negocio anterior, dé las razones de esta iteración del proyecto y resuelva los puntos débiles técnicos o los puntos débiles comerciales
2. Objetivo
Qué tipo de indicadores comerciales se deben lograr a través del subplan, por ejemplo, cuánto QPS se admite y cuántas veces se mejora el rendimiento en comparación con el nivel actual, allanando el camino para una expansión horizontal posterior.
3. Plan general
1) Diagrama de arquitectura 2) Diagrama de flujo 3) Diagrama de secuencia 4) Diagrama de enlace de llamada
4. Diseño de almacenamiento
Como el diseño de estructura de tabla Mysql, diseño de caché, diseño de almacenamiento ES, etc., explique el esquema, el tipo de campo, el valor predeterminado, la información de descripción, etc.
5. Definición de interfaz
Enumere la estructura de la interfaz, los parámetros, el valor de retorno, etc.
6. Esquema de escala de grises
De acuerdo con qué método de escala de grises, cómo hacer un plan de escala de grises, enumere la escala de grises en varias etapas en forma de tabla y el tiempo aproximado de cada etapa.
7. Plan de degradación
Cómo degradar la operación y cómo retroceder cuando hay un problema. Minimice el riesgo.
8. Impacto de los sistemas relacionados (funciones)
Los puntos clave que necesitan la atención de cada grupo, el personal relevante debe prestar especial atención y confirmarlos uno por uno.
9. Asignación de recursos
-
Recursos humanos: Cuánta mano de obra (mano de obra de desarrollo, mano de obra de prueba, mano de obra de operación y mantenimiento) se necesita para realizar el plan, etc.
-
Recursos de hardware: para implementar la solución anterior, enumere los recursos físicos de la máquina necesarios y el personal de operación y mantenimiento que debe prepararse con anticipación.
10. Nodos de duración y tiempo estimados
Enumere el período de construcción y los nodos de tiempo clave, como cuándo unirse a la depuración, cuándo generar la prueba, cuándo iniciar la escala de grises en línea y el plan de mejora iterativo posterior.
5. Consejos
También resumí los documentos de diseño de soluciones técnicas que escribí para la refactorización del sistema (versión real en línea, insensibilizado) y resumí 2 conjuntos para usted. Los amigos que lo necesiten pueden dejar un mensaje "plan" en el fondo de la cuenta oficial. Consíguelo, y damos la bienvenida a amigos que estén interesados en intercambiar y aprender juntos.
