7 prácticas de codificación clave para desarrolladores ágiles

El desarrollo de software ágil no se trata solo de principios y prácticas ágiles. Para tener éxito en el lanzamiento de software que tenga un impacto positivo en los usuarios finales, aborde la deuda técnica y se implemente de manera confiable, el equipo de desarrollo también debe considerar sus prácticas de codificación y estándares de arquitectura que impulsan la agilidad.

Una consideración aún más importante está en juego para las organizaciones de tecnología. Por más difícil que sea desarrollar software, es aún más difícil implementar mejoras y actualizaciones con regularidad durante un período prolongado. Las prácticas de Devops CI / CD e IAC (infraestructura como código) abordan parcialmente un factor crítico ya que la automatización permite formas confiables y repetibles de implementar aplicaciones. Agregue pruebas continuas y los equipos de desarrollo tienen una forma de validar que los cambios en el código no afecten la funcionalidad existente.

Sin embargo, a medida que las aplicaciones envejecen, los desarrolladores originales pasan a otros proyectos y, a veces, a otras empresas. Cuando nuevos desarrolladores se unen al equipo, deben aprender la arquitectura del software y comprender el código antes de poder cambiarlo de manera confiable y eficiente.

Además, los desarrolladores que crean aplicaciones a menudo quieren desarrollar otras nuevas. Puede sentirse cómodo y seguro permanecer conectado a las aplicaciones que desarrolla, pero estar atado a su código no es saludable para su carrera ni para la organización.

La mejor manera de avanzar hacia iniciativas de desarrollo de software nuevas y emocionantes es hacer que su arquitectura, aplicación y código sean fácilmente compatibles con otros desarrolladores. Los equipos y desarrolladores ágiles deben establecer y hacer cumplir las prácticas de codificación que sustentan el desarrollo continuo de software.

1. No reinventes la rueda

La primera regla de la codificación: ¡No codifique algo que no necesite ser codificado! ¿Cómo?

  • Considere hacer preguntas sobre los requisitos. ¿Por qué es importante una característica? ¿Quién se beneficia? Más específicamente, explore las opciones sin codificación para resolver el problema. A veces, la mejor solución no es ninguna solución.
  • ¿Alguien de su organización ya ha codificado una solución similar? ¿Quizás hay un microservicio que solo necesita una mejora o una biblioteca de software que necesita una actualización menor? Asegúrese de revisar el código base de su organización antes de codificar algo nuevo.
  • ¿Existen soluciones de terceros, incluidas herramientas SaaS asequibles u opciones de código abierto, que cumplan con los requisitos mínimos?
  • ¿Ha buscado en repositorios de codificación abiertos como GitHub ejemplos de código y fragmentos que cumplan con los requisitos de cumplimiento de su organización?

2. Considere opciones de desarrollo de código bajo

Si necesita codificar una solución, entonces quizás plataformas alternativas de bajo código puedan permitir desarrollar las capacidades de manera más eficiente en comparación con la codificación en lenguajes de desarrollo como Java, .Net, PHP y JavaScript.

Las plataformas de código bajo como Caspio, Quick Base, Appian, OutSystems y Vantiq proporcionan herramientas para desarrollar aplicaciones con poco código y, a veces, incluso sin codificación. Cada plataforma se especializa en diferentes capacidades y, por lo tanto, es adecuada para una clase específica de aplicaciones. Caspio, por ejemplo, facilita la inserción de formularios y flujos de trabajo en sitios web. Quick Base tiene sólidas capacidades de automatización y flujo de trabajo, y la arquitectura basada en eventos de Vantiq es adecuada para IoT y otras aplicaciones de datos en tiempo real.

Hay ocasiones en las que se requiere codificación, pero los desarrolladores también deben dominar una o más opciones de desarrollo de código bajo y considerarlas para casos de uso apropiados.  

3. Automatizar las pruebas

Más allá de escribir código que cumpla con los requisitos, una de las cosas más importantes que deben hacer los desarrolladores es probarlo. Las prácticas de desarrollo basadas en pruebas y las herramientas de prueba automatizadas han madurado, y los equipos de desarrollo deben incluir pruebas de unidad, regresión, rendimiento y seguridad como parte de sus estimaciones ágiles.

Además de tener pruebas para validar versiones y versiones, estas pruebas también ayudan a que el código sea más compatible. Las pruebas son documentación y establecen un contrato de cómo se supone que debe comportarse el código. Cuando nuevos desarrolladores se unen a equipos e implementan inadvertidamente un mal cambio, las pruebas continuas detienen la compilación y brindan comentarios significativos al desarrollador para abordar rápidamente el problema.

4. Externalizar todos los parámetros de configuración

No debería haber ninguna excusa para que los desarrolladores codifiquen de forma rígida configuraciones a nivel de sistema, nombres de usuario y contraseñas u otra información de configuración en el código. He visto a los desarrolladores tomar atajos mientras desarrollan prototipos que encuentran su camino hacia los entornos de producción. En las arquitecturas actuales, esto nunca debería hacerse. La codificación dura no es una deuda técnica, sino una práctica de codificación perezosa e irresponsable que puede tener consecuencias importantes. Si el código se vuelve accesible accidentalmente, crea una vulnerabilidad de seguridad si se exponen los puntos finales o las credenciales de acceso.

Yendo un paso más allá, cuando se está trabajando en código heredado, abordar cualquier configuración y parámetro codificados debe ser una prioridad de deuda técnica no negociable.

5. Siga las convenciones de nomenclatura e incluya comentarios para que el código sea legible

Una vez trabajé con un desarrollador increíblemente talentoso que no sabía bien inglés y no era el mejor mecanógrafo. Él instancias de objetos con nombres como un , b, y c y luego crear variables locales llamado zz , aa , xx . Se comprometería a limpiar esto antes del lanzamiento, pero rara vez lo cumplía.

No debería ser necesario que se instituya una programación en pareja o en grupo para reconocer que esta es una práctica terrible.

Los equipos deben adoptar convenciones de nomenclatura, como la Guía de estilo JavaScript y la Guía de estilo Java de Google, y comprometerse a comentar el código al menos a nivel modular e idealmente a nivel de clase. Además, las organizaciones deberían considerar el uso de herramientas de análisis de código estático que proporcionen comentarios a los desarrolladores cuando el código necesite refactorización para factores de estructura y legibilidad.

6. Verifique el código en el control de versiones con frecuencia

Si no comprueba el código en el control de versiones a diario o con mayor frecuencia, puede crear conflictos y otros bloqueos que afecten al equipo. Un pequeño error puede hacer que los equipos ágiles no cumplan con sus compromisos de sprint o crear trabajo adicional para resolver dependencias.

Los equipos deben acordar las convenciones para verificar el código que no está listo para la producción. Los enfoques convencionales incluyen marcas de características y ramificación de Git.

7. Evite codificar heroicidades y complejidades

La mayoría de los desarrolladores que conozco se convirtieron en ingenieros de software profesionales porque les encanta resolver los desafíos de codificación. La codificación es un arte, una ciencia y un oficio, y los mejores desarrolladores buscan asignaciones de codificación que inviten a la reflexión e implementaciones elegantes.

Excepto que existe una línea gris entre la resolución de tareas comerciales y técnicas desafiantes y la codificación heroica que deja a los próximos desarrolladores con un código difícil de entender y complicado de mantener.

Para aquellos de nosotros que hemos estado codificando por algún tiempo, recordamos la conveniencia de las frases sencillas de Perl o el uso de plantillas anidadas en C ++. A veces hay buenas razones para usar estos enfoques, pero si un nuevo grupo de desarrolladores no comprende estas técnicas, es más difícil cambiar el código. A veces, las prácticas de codificación simples pero menos elegantes son mejores.

Impulsando la agilidad en el desarrollo ágil de software

Los rituales integrados en scrum y desarrollo ágil, incluidos compromisos, standups, revisiones de sprint y retrospectivas ahora son prácticas comprobadas para permitir la colaboración en equipo e impulsar una implementación exitosa. Pero para demostrar agilidad durante mucho tiempo, los desarrolladores deben asumir responsabilidades y prácticas de codificación que permitan el soporte a largo plazo y la extensión del código que desarrollan.

Los equipos de desarrollo deben tener una visión crítica de sus prácticas de codificación. No solo es lo suficientemente bueno para hacer una demostración y lanzarlo hoy; también es crucial permitir que otros mantengan fácilmente la aplicación y el código.