Pautas y convenciones para “Code QA”

Cada vez es más común ver trabajar a equipos multidisciplinares en proyectos IT. Como cada trabajador usa una terminología concreta y tiene una forma de pensar y unas habilidades de análisis diferentes, la comunicación entre los miembros del equipo puede volverse un proceso complejo.

Una realidad que se da, sobre todo, en aquellos proyectos más importantes y demandados por las compañías, en los que se incluyen IA o procesos automatizados integrados en plataformas o aplicaciones web. Este tipo de proyectos requieren una gran variedad de perfiles, como diseñadores UI/UX, desarrolladores, expertos en análisis de datos y arquitectos.

Cada uno de los perfiles mencionados, contribuye a diferentes actividades con distintas herramientas y lenguajes de programación. La cocreación es esencial para la entrega de valor, pero también puede llevar a malentendidos que pueden retrasar el proceso de desarrollo; a no ser que se establezcan unas pautas de comunicación con el objetivo de reducir las diferencias que aparecen entre el vocabulario y la forma de pensar o de codificar.

Por ejemplo, imaginemos el caso de un proyecto llevado a cabo por un equipo multidisciplinar. Este proyecto consiste en una aplicación web con algunos gráficos en su interfaz que muestran datos computados por IA en el servidor. El equipo está intentando implementar dos nuevas funcionalidades, -y es aquí donde podrían aparecer problemas de comunicación-.

La primera es lanzar modelos de IA desde el servidor que está ejecutando la aplicación web. Para ello, el desarrollador y el experto en datos, tendrán que acordar el formato que deberá recibir la orden, la cual vendrá del backend de la aplicación, para lanzar los modelos con los inputs adecuados. Luego, para implementar una funcionalidad que muestre algunos gráficos en la aplicación, el desarrollador y el diseñador UI/UX tendrán que hablar sobre las limitaciones gráficas para poder representar los datos sin perder experiencia de usuario y continuar mostrando información de utilidad.

Así, este es un claro escenario de cómo la interacción, intereses y visión de los diferentes roles podrían afectar la productividad por problemas de comunicación.

¿Cómo optimizar un equipo multidisciplinar?

En un departamento de I+D+i, como SogetiLabs en España, distintos profesionales de campos y ámbitos muy diversos trabajan juntos para crear cooperativamente ideas innovadoras con una producción de calidad.

Para que esto ocurra es necesario promover la comprensión y tomar consciencia del trabajo hecho por cada uno de los miembros de un equipo en un proyecto. Como en proyectos IT, el trabajo incluye programación en mayor parte, deberíamos ser capaces de entender el código escrito por nuestros compañeros. Si queremos que este proceso sea lo más fácil posible, se necesita un conjunto de reglas básicas para alinear la manera en la que codificamos. Con estas reglas, el análisis de la calidad y rendimiento podrá priorizarse por encima de los aspectos de estilo y legibilidad.

En este contexto, hemos definido un conjunto de pautas y convenciones de codificación, acordadas después de largos y disputados debates sobre las diferencias entre los estilos de programación de nuestros desarrolladores.

Así, nuestro objetivo es apostar por la industrialización de código bajo estas convenciones, de acuerdo con las nuevas arquitecturas que estamos aplicando, y mejorar la comprensión de código en nuestro contexto Agile/DevOps. De esta forma, todos los miembros de un equipo podrán alcanzar un conocimiento común, sean cuales sean sus campos de especialización.

Para lograrlo, presentamos una serie de artículos que se publicarán regularmente en este blog. En ellos, discutiremos y presentaremos distintos puntos de debate sobre estilo de codificación. Después de numerosas reuniones, hemos llegado a los siguientes puntos a tratar:

• Naming (nombramiento) de ficheros, carpetas/packages, clases, métodos, variables y constantes, así como los diferentes tipos de casing (combinación de mayúsculas o minúsculas) que deberíamos usar en cada caso.
• Documentación de código en forma de comentarios, documentación API del lenguaje, y anotaciones.
• Estructuras, conocidas como bloques de código encabezados por una palabra reservada y cerradas por llaves.
• Buenas prácticas y consejos generales sobre consistencia del código escrito, mezcla de lenguajes.
• Plugins de IDEs o extensiones de editores útiles o interesantes para ayudar a los programadores a escribir código de mayor calidad mientras siguen las convenciones de formato específico.

Somos conscientes de que estos temas producen muchos debates interesantes, por eso os invitamos a dejar un comentario en cada artículo para encontrar juntos las mejores prácticas para escribir mejor código.

Aun así, recordamos que nuestra intención no es reinventar ninguna de las reglas que ya existen en cada lenguaje o los estándares que ya están ampliamente establecidos en la comunidad, sino que solo estableceremos aquello que creemos que aplica en contextos similares al nuestro, donde equipos multidisciplinares trabajan de forma conjunta.

Para concluir, recordad echar un vistazo regularmente a nuestro blog para no perderos ningún capítulo de esta serie. ¡Os esperamos!