Así que vas a ahorrar tiempo a las personas haciendo documentación. Y como dije, la táctica dentro del código y la estrategia principalmente en torno a tu perspectiva. Así que el modelo C4 de Simon Brown, que lleva el TechRadar al mapear la tecnología que utilizamos dentro de nuestras organizaciones. Adjunta tus registros de decisiones. De esta manera, puedes asegurarte de que tomaste la decisión, conoces la razón, puedes medir esa decisión mediante compensaciones. Y el último es naturalmente hacer una comunicación clara con foros, canales de Slack y cosas así. Recuerda, menos reuniones, a veces es código.
Y cuando hablamos del modelo de madurez, necesito hablar rápidamente aquí. Por lo general, comenzamos con la documentación conocida, y luego puedes avanzar para hacer la documentación del código, luego la documentación de la etapa del repositorio, adjunta tu documentación, y finalmente explora más el DocOps. ¿Qué significa DocOps? Básicamente, tan pronto como fusiono mi documentación, mi documentación está disponible para ver y leer. Por ejemplo, puedes usar AskDoc dentro de tu archivo Readme para ayudar a las personas a comprender cómo usar y cómo dar estilo a ese código. dentro de tu organización. De acuerdo, pasemos al siguiente tema, en torno al código y al diseño del código.
Hay este increíble libro llamado La Filosofía del Diseño de Software, y tiene una buena definición sobre la principal diferencia entre un programador que se enfoca más en lo táctico, lo que significa trabajar para lograr que las cosas se hagan, y la forma estratégica. Así que el libro llama a esa persona un tornado táctico, porque puede hacer un código más rápido y más rápido, pero nadie entiende más el código que esta persona toca. Así que se convierte en una pesadilla. Y a largo plazo, es imposible leer y comprender cualquier código relacionado con eso. Entonces, ese es el objetivo principal de evitar la complejidad dentro de tu repositorio, dentro de tu arquitectura. Así que es natural que comencemos con patrones, queremos aprender, queremos aplicar tanto como sea posible, pero al final, nuestro objetivo debe ser luchar por obtener cada vez más simplicidad en nuestro código.
De acuerdo, en cuanto a la madurez del diseño del código, tendré que ir rápido aquí, así que a veces no me importa. Y luego puedo pasar a la simplicidad o la etapa final de sofisticación de Leonardo Da Vinci. Entonces, la simplicidad es el camino a seguir, escribir un buen y simple código tanto como sea posible. Luego tenemos las tareas, es una cosa que puedes hacer y explorar como profesor dentro de nuestra organización. No se trata solo de la cobertura de tareas, porque es importante, es crucial, pero debes medir qué tan eficiente es esa tarea. De acuerdo, puedes combinar eso con las pruebas de mutación. Como desarrollador de Java, mi experiencia es en Java, así que estoy usando PyTask, pero naturalmente, en tu herramienta, puedes usar lo que quieras, pero mi consejo para ti es combinar la cobertura de tareas con las pruebas de mutación. No se trata solo de la cobertura, sino, por supuesto, de qué tan eficientes son esas tareas. Y hablando rápidamente sobre el modelo de madurez de las tareas, así que tareas conocidas, desafortunadamente, sucede, así que puedes pasar a las tareas unitarias, tareas de integración, cobertura de tareas, y finalmente, las tareas optimizadas. Eso significa la combinación de la cobertura de tareas con las tareas de mutación. De esta manera, puedes definir el requisito mínimo para avanzar con tu código.
Comments