El software de dispositivos médicos es muy diverso. Desde controladores de firmware de bajo nivel hasta análisis de datos e inteligencia artificial, pasando por desarrollo web y ciberseguridad, las tecnologías son muy variadas y cada una con sus propias peculiaridades.

En toda esta variedad, una tecnología está omnipresente: ¡Git! Su sistema de control de versiones (VCS) siempre está ahí y vale la pena tomarse un poco de tiempo para conocerlo realmente. Si va más allá de lo básico, Git le ayudará a desarrollar software para dispositivos médicos más rápido sin sacrificar la trazabilidad.

El software de dispositivos médicos requiere niveles adicionales de responsabilidad más allá de las mejores prácticas habituales de software. Un ejemplo está relacionado con la gestión de la configuración y el mantenimiento de un registro de lo que cambió entre versiones de software, lo que implica mantener un historial claro del desarrollo del software.

Necesitas dedicar un poco de tiempo para crear tu propio modelo mental de cómo funciona Git para aprovecharlo al máximo. Profundicemos en tres descubrimientos reveladores que me ayudan a usar Git mejor.

1. ¡No tienes que comprometerlo todo!

En el mejor de los casos, Git se quita del camino. El lugar donde quiero estar como programador es en el “modo código”, donde pierdo la noción del tiempo pirateando una nueva característica, o solucionando un error, o tal vez ambas cosas. Aquí existe una tensión entre escribir el código y construir una historia sensata para futuros revisores. Lo último que quiero hacer es interrumpir mi programación para pensar en VCS y en cómo buscará un revisor los cambios. Después de todo, es una buena práctica realizar compromisos pequeños y autónomos.

Supongamos que se deja llevar por la programación y realiza un par de cambios no relacionados sin cometer ninguno de ellos. ¿A qué te dedicas? Git separa la "copia de trabajo", donde se encuentran todos los cambios locales no confirmados, del "área de preparación", donde add cambios que desea que se realicen.

A continuación se muestra un ejemplo para ilustrar cómo utilizar el área de preparación cuando se trabaja en un proyecto con un controlador SPI, un controlador de pantalla y algo de lógica empresarial. Quizás las fuentes estén organizadas así:

Ha estado felizmente construyendo su controlador SPI, pero en el camino, tiene una idea para representar páginas con mayor fluidez en su pantalla. Introduce algunos cambios en el controlador de pantalla y ahora tiene cambios tanto en spi.c como en display.c. Si lo confirmas todo a la vez (“git add”) entonces estás enredando cambios que no están relacionados, lo cual no es una buena higiene de git. ¿Qué pasaría si introdujera un error al intentar ser inteligente con su controlador de pantalla? Tendría que revertir este parche y luego seleccionar las partes que solo están relacionadas con SPI para evitar que se eliminen. ¡Retorcido!

En su lugar, utilice el poderoso de Git. área de ensayo para extraer cambios atómicos de la copia de trabajo. Al agregar primero solo cambios relacionados con SPI, confirmarlos, luego Al agregar cambios en el controlador de pantalla, has creado dos confirmaciones que son agradables e independientes, ¡pero que provienen de la misma copia de trabajo!

Observe cómo no tiene que pensar en cuál será su próximo compromiso antes tú haces los cambios. En su lugar, puedes volver a codificar y crear confirmaciones a partir de tus cambios más adelante. Git no te castiga por perderte en la programación; te ayuda a recuperarte después de una sesión de corrección de errores alimentada con cafeína.

Cuando los cambios atómicos se localizan en archivos individuales, es fácil generar cambios independientes en diferentes confirmaciones. Pero, ¿qué pasa si hay cambios en app.c que se aplican a ambas ¿SPI y cambios de visualización? Una vez más, Git lo tiene cubierto.

2. Agregar cambios individuales con –patch

Aprender sobre el área de preparación es una cosa, pero darse cuenta de que puedes filtrar los cambios desde dentro de un solo archivo abre un nuevo mundo de capacidades. El comando “git add” tiene una opción “–patch/-p” que lo lleva fragmento por fragmento a través de los archivos que le ha pasado, permitiéndole extraer solo lo que necesita para la confirmación. Puede ser muy específico con adiciones, dividiendo los fragmentos proporcionados e incluso seleccionando líneas manualmente editándolas. Una ventaja de crear confirmaciones pieza por pieza es que probablemente escribirás un mejor mensaje de confirmación, porque los cambios estarán frescos en tu mente.

Consejo: utiliza el Opción de configuración “singleKey” para hacer que la navegación de los trozos sea más rápida (git config –global Interactive.singleKey true). Necesitará el módulo Term::ReadKey para que esto funcione.

La opción “–parche” está disponible en más comandos además de solo “agregar”. ¿Quiere eliminar un comentario particularmente pasivo-agresivo de un archivo? “git reset –parche”! ¿O quieres guardar sólo una o dos líneas en tu reserva para más tarde? “git stash –parche”!

3. Historial de Git

"La historia será amable conmigo, porque tengo la intención de escribirla".

• Tú, abriendo tu próximo PR

Ahora que está reuniendo fácilmente confirmaciones atómicas, puede ver el panorama más amplio de la historia que está contando con el historial de Git. Por ejemplo, ha estado trabajando en una nueva función durante un par de días siguiendo el patrón familiar de “dos pasos adelante, un paso atrás” de incorporar nuevas funciones al software.

Introduces un nuevo módulo en tu código base, pero sin darte cuenta provocas un error en otro lugar. Entonces, corrige este error y confirma aquellos cambios. Este patrón de introducir código nuevo y luego corregir errores o regresiones que introdujo anteriormente continúa por un tiempo. Finalmente, lo ha parcheado todo y su nueva y brillante función está lista para fusionarse nuevamente en la rama "principal".

Quizás la rama de características se parezca un poco a esto:

Cuando fusiones esta rama, llevará consigo toda esta historia. Esa es la historia que a nadie le importa. Dentro de 5 años, cuando revises el historial del proyecto, a nadie le importarán los errores que se introdujeron en una confirmación y se corrigieron en la siguiente. Te preocuparás por estos compromisos como puntos de control durante el desarrollo, pero tan pronto como todo funcione, no necesitarás recordar cómo llegaste allí. Los revisores solo quieren ver el conjunto de cambios mínimo que hace que el proyecto pase de la función previa a la función posterior, tal vez con un par de hitos importantes en el medio. Entonces, ¿cómo lidias con esto? Puede esperar para confirmar cualquier cosa hasta que la función esté 100% escrita y funcionando, pero es un punto peligroso estar a mitad de camino del desarrollo.

Git vuelve al rescate con “git rebase –interactive”, que permite a los usuarios editar interactivamente el historial de confirmaciones. Puede reordenar, editar, eliminar o “aplastar” confirmaciones del historial. Tenga en cuenta que el rebase interactivo cambia tu historial de Git. Eso los hace potencialmente muy peligrosos. Puedes dañar gravemente tu repositorio aquí si no tienes cuidado.

Recomiendo configurar el host remoto de git para permitir solo permisos de "rebobinado" a los desarrolladores en ramas que coincidan con una plantilla como "dev/*". Esto mantendrá intactas la rama principal y otros puntos de control importantes sin importar lo que hagan sus desarrolladores. En mis proyectos, el "rebobinado" sólo está permitido en ramas que coincidan con "tmp/*" y "dev/*". Una vez que los cambios estén en una rama de función compartida o "principal", ¡el historial ya no cambiará! Cuando sea posible, lleve esta idea a su conclusión lógica prohibiendo cualquier envío a la rama "principal" a menos que provenga de una solicitud de extracción aceptada.

Revisando nuestra rama de funciones de ejemplo, así es como se ve el historial después de una limpieza:

Las dos confirmaciones de corrección de errores se agruparon en sus confirmaciones principales. Esto crea un historial limpio y agradable que muestra claramente la introducción de una nueva característica en el código base, sin el ruido de los errores de desarrollo de características.

Mantener un historial confiable es una de las razones para utilizar un VCS: la gestión de la configuración es un requisito clave de IEC 62304 para el software de dispositivos médicos. Utilice el cambio de base interactivo para que su historial sea claro y fácil de ver cómo progresó el software entre dos versiones.

Conclusión

Mantener un historial claro es un aspecto crítico del desarrollo de software para dispositivos médicos. Al desarrollar una funcionalidad interesante y de amplio alcance para productos de dispositivos médicos, la poderosa área de preparación de Git y las funciones interactivas de rebase lo mantendrán moviéndose rápido y rompiendo menos.

Imagen: Adobe Stock

Levi Puckett es un Ingeniero de Software en Starfish Medical. Licenciado en Ingeniería Eléctrica, cierra la brecha entre la electrónica y el software integrado de alta calidad. Levi trabaja en todos los niveles del software de dispositivos médicos, ayudando a las empresas a desarrollar software eficaz, innovador y seguro para sus nuevos dispositivos médicos.



• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://starfishmedical.com/blog/3-git-tips-to-improve-medical-device-software/