¿Es esto lo que la gente llama golpear a un caballo muerto ?
Últimamente, hay una nueva generación de gerentes de ingeniería que creen que la documentación es inútil. No estoy en desacuerdo con ellos.
Sin embargo, también en los últimos tiempos hay una nueva generación de gerentes de ingeniería que creen que es inútil llevar a cabo el diseño de software. Estos surgieron de las filas de los programadores PHP o Python cuya actitud es “solo git’r done”. Estos son pretenciosamente informados twits mal informados.
- ¿Cuál es la mejor manera para que un cambiador de carrera se prepare para convertirse en desarrollador de software?
- ¿Cómo trato con un compañero de trabajo lento que está comiendo demasiado de mi tiempo?
- ¿Cuándo es demasiado tarde para despedir a los desarrolladores de software? Se suponía que el proyecto estaría completo en 4 meses, pero han pasado 10 meses. Hay muchos errores en la aplicación y parece barata. ¿Qué tengo que hacer?
- En Google, ¿cuál es la diferencia entre un desarrollador de aplicaciones y un desarrollador de software general?
- Cómo obtener una visa para el trabajo de un desarrollador de software en Canadá, ser ciudadano de la UE y no tener un título relevante
El estado mental más importante para un programador
- Es comprender las reglas de negocio y proceso del entorno para el que está codificando.
- Debe comprender el modelo de datos y el flujo de datos.
- Debe codificar en patrones. Debe poder reconocer un patrón de codificación o diseño cuando vea uno.
- Comentarios solo cuando innova fuera de un patrón.
- Es mejor que todo tipo de documentación.
- Esto puede ser muy duro para los nuevos programadores. Pero lo siento, esto es lo que tienes que aprender y acostumbrarte.
- Debe codificar funcionalmente. El módulo que está codificando
- Debe estar diseñado y especificado para proporcionar una función minimalista. Debe proporcionar la menor cantidad de funcionalidad posible, sin afectar el rendimiento de la aplicación en general.
- Tiene API como contrato autorizado. El módulo o la función hace exactamente lo que dice la API. Sin efectos secundarios,
- Sin manipulación de variables estáticas / globales.
- Las interfaces estáticas, globales, constantes son de solo lectura con sus propios contratos API.
- Toda la configuración de inyección también debe tener contratos especificados.
- No tiene transacciones bajo el mostrador ni comunicación oculta. Deben realizarse a través de canales aprobados y comprobables.
- la firma polimórfica habitual
- un bus de mensajes, canal o cola, con especificación contratada para solicitud-respuesta o suscripción.
- Un modelo de evento contratado.
- No deben depender de la retención del estado.
- Cualquier comportamiento dirigido por el estado debe diseñarse como una máquina de estado.
- Incluso la máquina de estado en sí misma no debe depender de la retención de estado. Es decir, la respuesta de estímulo y la transición de estado siempre deben ser consistentes y no dependientes de un estado retenido.
Los módulos funcionales contractuales son muy útiles y ahorran tiempo, ya que un programador a menudo podría reutilizar un módulo fácilmente.
Lo que acabo de describir es la RESPONSABILIDAD de parte del programador.
Sin embargo, los gerentes de ingeniería y arquitectos lamentablemente no cumplen con su parte de RESPONSABILIDAD.
- No practica ni comprende el concepto de normalización del modelo de datos.
- No tiene una perspectiva integral y modular del flujo de datos entre los actores / actores, procesos y entidades involucradas.
Todo el mundo sabe qué es la normalización de datos, ¿verdad? Sabes cómo hacerlo para tus bases de datos. Pero, ¿normalizó los modelos de datos que pasan por todos los procesos, servicios y aplicaciones bajo su competencia?
La normalización del modelo de datos es el primer paso hacia el diseño funcional. La normalización del modelo de datos define los módulos y la granularidad de esos módulos.
- La normalización de datos garantiza la integridad de la unicidad. Hace exactamente lo que dice que hace con los datos.
- Evita la dependencia que un módulo tiene de un estado que se supone que no debe tener.
- Evita tener una funcionalidad duplicada y superpuesta, ya sea en servicios web o en funcionalidad de código.
¿Ni siquiera se dan cuenta de que un modelo de datos normalizado proporciona a sus programadores una comprensión completa de lo que necesitan hacer sin mucha documentación excesiva?
Deja de dibujar todos esos diagramas de cajas y rectángulos tontos. Simplemente arregle sus modelos de datos.
Una vez que tenga un modelo de datos normalizado, el programador podrá diseñar el diagrama de secuencia sin esfuerzo y luego con la API y las pruebas. No se necesita más documentación.