Notas acerca de desarrollo de software
Tiempo de exploración ↑
“El trabajo de un desarrollador de software es resolver problemas, no escribir código.”
Si agregas un tiempo de exploración, podrías mejorar la productividad del equipo de desarrollo.
Desarrollo Dirigido por LÉEME ↑
Leí acerca de esto en [@code-complete] y me pareció una buena idea que corresponde con la programación letrada [@literate-programming].
La idea es:
Escribir en lenguaje humano cómo se resuelve el problema.
Es mucho más barato que escribir en lenguaje de programación y es una manera de comenzar a hacer el diseño.
Solicitar retroalimentación sobre el diseño.
Esto permite iterar sobre el diseño de la forma más barata posible, encontrar problemas.
(En la práctica, algunos desarrolladores no ofrecen retroalimentación sobre el diseño si no hay código.)
Detallar el diseño en lenguaje natural hasta que sea posible traducir directamente a código.
Así los nombres de las variables, los tipos de datos, se definen pensando en la mejor forma de explicar a otros el problema y la solución.
Traducirlo para la computadora.
Las secciones del ensayo podrían convertirse en módulos, las descripciones del algoritmo en código en funciones (con el nombre de la descripción), y los pasos tienen que implementarse en lenguaje de programación.
Eliminar los comentarios redundantes o innecesarios.
Una buena forma de encontrarlos, es eliminando los que describen cómo y no por qué.
El cómo ya está descrito en el código y espero que hayas usado las explicaciones como nombres de módulos y funciones.
Desarrollo Dirigido por Pruebas (TDD) ↑
Diseño de software ↑
“Un buen diseño es más fácil de cambiar que un mal diseño.”
[@code-complete]
Integración Continua ↑
Vasilescu et. al describe la integración continua como «juntar todas las ramas de trabajo de desarrolladores con la rama principal p.e. varias veces al día» y explora cómo se usa esta práctica en GitHub.
Diseño Ágil ↑
Qué hacer:
- Ve dónde estás,
- Da un paso hacia donde quieres estar,
- Ajusta tu entendimiento con lo que aprendiste,
- Repite
Cómo hacerlo:
- Cuando haya más de una alternativa que genera el mismo valor, elige la que haga que el cambio futuro sea más sencillo.
SCRUM ↑
The ideas are powerful, they describe how to do it but not if you’re doing it right.
Herramientas para validar software mientras se desarrolla ↑
https://pre-commit.com/ tiene muchos quita pelusas.
- Revisar este bug tracker que funciona en git que parece que interactúa con otras opciones.
Evaluación de productos ↑
- Hablar con los usuarios
- Iterar
- Hacer las cosas más simples que funcionen
- Hazlo barato (finge), (para que puedas tirarlo). No «diseñes para tirar», «tira pruebas experimentales para diseñar».
- Involúcrate.
Una serie de consejos acerca de cómo desarrollar software
Cómo hacer revisiones de código
Hay que tomar tiempo para pensar sólo las decisiones importantes
Estrategias para productos maduros ↑
Conforme el producto madura se vuelve más importante pensar en los objetivos hacia los usuarios que en las características del producto.
Hay que mantener un registro de proyectos posibles (parte de la estrategia) y separado de eso, una lista de cosas que hacer para el desarrollo.
Hay que tener tiempo para medir, aprender y evaluar.
Versionado Semántico ↑
Hay algunas herramientas para actualizar la versión,
un sistema para versionado semántico escrito en js para nodejs
y un plugin para git.
Gestión de dependencias ↑
Una de las estrategias más efectivas para gestionar dependencias es usar contenedores:
Luego varios lenguajes de programación tienen gestores de paquetes.
En python:
Y los lenguajes más contemporáneos vienen con gestión de paquetes integrada, por ejemplo:
- Rust: cargo.
- Go: go install.
Bibliotecas para implementar interfaz gráfica ↑
Biblioteca en python para hacer apps móviles.
Optimización ↑
Valida los requerimientos, usa micro-servicios.
Ensayos específicos de lenguaje ↑
Para facilitar el testing, conviene hacer la lógica fuera de la función main en Go.
Lugares para aprender ↑
Evaluación de Expresiones Regulares
Conferencias de Robert C. Martin acerca de Código limpio
No usar switch (porque agrega dependencias y se requiere usar demasiado)
Mantener el sistema abierto para extensión y cerrado para modificación.
Encapsular los efectos secundarios con métodos que aceptan lambdas.
Los ciclos se convierten en funciones que aceptan lamdas.
Nunca comentar código en otro lugar.
Always check the code a little better.
You have the tests.
You believe them.
Fragile test project.
Code coverage.
Project Evaluation on Time.
Estimate: best case, nominal case (wife, meetings, etc), worst case
Es mejor entregar cada cierto tiempo que esperar a que todo esté hecho
2021-03-11 Comentarios Open Enchilada ↑
- ¿Podemos hacer release diario?
- ¿Cuánto tiempo lleva llevar un pull request a producción? (≤2h).
- Defectos introducidos en release.
- Tiempo para recuperarse.
State of DevOps Report. Accelerate, research GitHub
Notas de estilo ↑
Notas de programación de Rob Pike, cómo los nombres que revelan información del sistema causan problemas y una lista de malos nombres.
Guías de estilo de laboratorio del laboratorio del Imperial College para C, java
Guía de estilo de Nelson Padua, Department of Computer Science, University of Maryland
Guía de estilo de la Escuela de Información y Tecnología de Comunicación de Seneca
Compendio de estilos de identación en código (Wikipedia)
Arquitectura de software ↑
Los programas son administradores de detalles.
La arquitectura
¿Qué partes de la aplicación se tienen que probar?
Sólo prueba las partes de la aplicación que quieren que funcionan.
¿Cómo haces un coverage?
100% de código no puede probarse.
GUIs are very difficult to test.
Si tienes una parte del sistema que quieres probar y no sabes qué hace, no puedes probarlo.
-> La base de datos va afuera del código porque es un dispositivo de lectura/escritura.
Ejemplos interesantes de errores de programación
Hábitos inefectivos:
- Usar demasiadas palabras
- Demasiados comentarios
- Indentación que no refleja el estado del código
“As a programmer I want code to communicate directly and with intent so that I can spend less time determining the meaning of code and more time coding meaningfully.”
Kevlin Henney
Chreke opina que usar lenguajes especializados es el futuro de la programación.
Sin arquitectura es mejor que con una mala arquitectura.
Lecturas pendientes ↑
A Path to Better Programming ↑
Aprender a programar como los movimientos.
Mob Programming: aprender todos movimientos diferentes.
Lecturas recomendadas:
Los proyectos no son lo mejor ↑
A los programas les conviene pequeñas iteraciones y un flujo continuo: como las verdaderas cascadas.
En ocasiones, se toman decisiones contrarias a las mejores prácticas.
Cuándo la gente copia Stack Overflow.
Biblioteca de python para auto-versionar.
Algunos proponen diseño continuo.
La confianza es un activo económico ↑
Así como en otras áreas de la economía[@citation-needed], la falta de confianza también aumenta el costo de producción del software.
Para tener rendimiento, el diseño inicial es importante y tener un sistema rápido cambia cómo se usa.
Se puede compilar python para mejorar su rendimiento.
Se aprende a programar programando y no existen soluciones mágicas.
Conviene llamarle «carga de mantenimiento» a la “deuda técnica” y hablarle a los administradores en términos del trabajo de mantenimiento que se hace son características que no se están produciendo.
Revisiones de código ↑
Conviene tener cambios en porciones pequeñas, automatizar todo lo automatizable y hacer rápido el proceso de revisión. Para que esto funcione deben separarse las liendres (cambios que no aportan valor) y revisarse todos esos por separado, puede asignarse un rol para todos estos cambios.