Hace veinte años trabajé en el campo de la tecnología, diez años después pasé al puesto directivo y ahora he vuelto a la tecnología, esta vez en el rol de consultor. Algunos de los cambios me hicieron muy feliz, mientras que otros me sorprendieron tanto. A continuación, hablaré brevemente sobre las cosas principales que casi me matan en la flor de la vida.
Agradable primero: Unix y desarrolladores reunidos
A lo largo de la década de 1980 y principios de la de 1990, la mayor parte del desarrollo de software profesional se realizó en costosas estaciones de trabajo Unix como Sun Sparc o NeXT. En los noventa, WinTel capturó el mercado y todos comenzaron a codificar en Windows utilizando herramientas de grandes proveedores como MS Visual Studio, o algunas opciones gratuitas como Eclipse. Linux en ese momento todavía se consideraba algo más para los aficionados al mundo del escritorio.
En 2001, trabajé en una startup. Solo había un desarrollador de Linux para todo nuestro equipo, y tuvo dificultades para cortar el acceso a las herramientas de control de versiones y al cliente de correo electrónico de Outlook. Por lo general, nos enviaba un código por cartas y nos pedía que lo completara. Recuerdo que yo mismo usaba XEmacs en ese entonces, eh, los buenos viejos tiempos.
Avance rápido hacia el presente. Unix se ha convertido en una plataforma muy popular entre los desarrolladores, especialmente aquellos en Mac, debido al hecho de que usa el kernel de Unix. Además, existe Linux en Windows. En este sentido, a diferencia de muchos otros, mi regreso a TI no estuvo plagado de dificultades. Es curioso que muchos de mis jóvenes colegas apenas manejen Windows y que en Linux se sientan mucho más seguros.
La gestión de versiones ya no es una profesión
Érase una vez, ramificar, fusionar y resolver conflictos era un trabajo increíble que a menudo requería la intervención de un especialista en lanzamiento dedicado. En los días en que ClearCase reinaba en el mercado de control de versiones, había suficiente trabajo de bifurcación, fusión y lanzamiento para un gran equipo, al menos en mi experiencia en HP en 2002.
La idea de que un desarrollador pueda enviar solicitudes de cambio por sí mismo es bastante reciente. Aparentemente, se le dio el comienzo de la transición del desarrollo a Linux y una nueva ola de sistemas de control de versiones distribuidos: BitKeeper, Git, etc. Los sistemas heredados como ClearCase, CVS, SVN o PerForce no tenían la capacidad de realizar sus propios cambios para que se reflejaran en todos los involucrados en el flujo de trabajo. O el propietario del repositorio lo hizo, o la persona a cargo de la administración de versiones, o cada desarrollador organizó todo por sí mismo. Ahora el proceso se ha simplificado enormemente y ahora es posible establecer un trabajo conjunto en un equipo sin participantes adicionales.
¿Dónde están los equipos de control de calidad? Pruebas unitarias e integración continua
Escuché por primera vez sobre las pruebas unitarias y la integración continua de Kent Beck, uno de los autores del Manifiesto Ágil y creador de la metodología de programación extrema . Hace veinte años, sus ideas eran revolucionarias, pero no alcanzaron de inmediato el estatus de estándar en desarrollo que tienen ahora.
En mi opinión, es una pena que no haya más énfasis en la integración continua en Agile y Scrum. Pero ya me alegro de que esta práctica se haya vuelto bastante popular en la actualidad. Asistí a esa conferencia y recuerdo que Joshua Bloch, autor de Java Collections, subió al escenario para hablar sobre la integración continua y dijo: "Gracias (Agile o JUnit) por darle un encanto a la integración continua". Y tenía razón. En los viejos tiempos, las pruebas de redacción se consideraban aburridas y pocas personas las hacían. Por lo tanto, los jefes contrataron a personas especiales, ingenieros de control de calidad, ¡que buscaban errores para los desarrolladores! Vuélvete loco, esa lafa era ...
Las pruebas unitarias y la integración continua casi han eliminado la necesidad de estas personas; ahora los desarrolladores son responsables de escribir las pruebas ellos mismos, y la infraestructura de integración continua lanza todo a tiempo e informa errores. Esto hace que el software sea más confiable y acorta el ciclo de desarrollo. Además, las innovaciones ayudaron a los desarrolladores a obtener una visión más holística de las cosas y a aprender a escribir código para que se pueda probar fácilmente.
Docker: no más desorden en el camino a la producción
Los contenedores, a saber, Docker, han eliminado todo el material innecesario de la gestión de paquetes y han minimizado los problemas medioambientales que surgen cuando el código pasa las pruebas y entra en producción. Sin embargo, previamente deberá contratar a un buen ingeniero de DevOps para configurar el ecosistema de Docker.
En los viejos tiempos, sucedía que el sistema se creaba en un entorno completamente diferente en el que se suponía que debía implementarse (bueno, es decir, por ejemplo, escribieron código en Windows y lo implementaron en Unix). Esto inevitablemente causó errores y acumuló trabajo adicional en cada ciclo de lanzamiento de prueba.
Además, en el pasado, un especialista en versiones, pruebas o DevOps tomaba el código de una etiqueta en el control de fuente y decidía qué hacer con la compilación, las pruebas y la migración. Por lo general, esto revelaría un montón de rutas y variables codificadas de forma rígida, bibliotecas y archivos faltantes que debían ser reelaborados o ajustados para que funcionen correctamente.
Docker simplificó el proceso y creó las condiciones para la integración y el despliegue continuos poniendo, nuevamente, las funciones relevantes en manos de los programadores.
Código abierto: demasiadas posibilidades
En el mundo del software de código abierto, la elección es ahora, francamente, abundante. Estaba configurando Jenkins aquí y quería integrarme con BitBucket. Una búsqueda de complementos para “bitbucket” arrojó más de cuatrocientos resultados, muchos de los cuales son de código abierto.
Esto crea dos problemas:
- Es más difícil elegir entre una gran cantidad de opciones.
- Con tal abundancia, algunos de los instrumentos definitivamente se extinguirán y su apoyo cesará.
Pero también hay ventajas: casi no hay necesidad de crear la infraestructura y las herramientas básicas usted mismo: encuentre lo que necesita de los listos para usar y úselo. Hace veinte años, tenía que escribir bibliotecas y estructuras de datos para las operaciones más comunes, e incluso era divertido en alguna parte. Hoy en día, hay tantas bibliotecas y marcos diferentes para cada idioma que el 99% de los desarrolladores pueden vivir sin escribir un solo árbol B, una tabla hash o incluso un conector OAuth.
Agile y Scrum se han apoderado del mundo
Hace veinte años, Agile ya estaba vivo y coleando (el Manifiesto Agile se publicó en 2001), pero su popularidad comenzó a crecer más tarde, incluso fuera de TI, y a veces de forma distorsionada. Se convirtió en un adagio favorito en los círculos ejecutivos: "Las empresas deben permanecer ágiles, de lo contrario no sobrevivirán".
Recuerdo los momentos en que el ciclo de lanzamiento se prolongó durante bastante tiempo (tres meses, y esto es una puesta en marcha). Después de regresar de la reunión, en la que analizó las especificaciones línea por línea, el desarrollador pudo sentarse a la mesa y jugar en silencio durante varias semanas sin preocuparse de tener que informar sobre cómo iban las cosas. Y ahora todos los días en los mítines de pie, cada dos semanas en los sprints, ¡realmente no puedes relajarte!
Agile también redistribuyó las funciones administrativas: ahora los desarrolladores se comunican directamente con los usuarios o los gerentes de producto. Siéntese en silencio ya no funcionará. En consecuencia, la capacidad de comunicarse se ha vuelto mucho más valiosa que antes.
Finalmente, el ritmo de desarrollo se ha acelerado con Agile. Ni siquiera se trata de reuniones de pie y otras empresas de Scrum. Las herramientas en sí mismas comenzaron a ahorrarnos tiempo: pizarras en Jira, solicitudes de cambio, herramientas para el desarrollo y la implementación continuos, todo lo cual hace posible trabajar más rápido. Por un lado, esto se suma a las preocupaciones cotidianas y, por otro, siente el retorno del hecho de que implementa los productos en poco tiempo y completa las tareas de manera integral.
Finalmente
Si también dejaste IT y estás pensando en volver, te apoyo y te deseo mucha suerte. Personalmente, con mucho gusto actualicé mis habilidades (aunque casi muero en el camino). Los principios fundamentales de la programación siguen siendo los mismos, así que creo que lo superaré de alguna manera. Pero el conjunto de herramientas ha cambiado mucho y esto afecta la productividad.
Probablemente captó un tema recurrente en el artículo: un desarrollador moderno tiene una gama de tareas mucho más amplia que hace veinte años. Escribe código, controla versiones, prueba lo que escribió, trabaja con contenedores, etc. Por supuesto, el cerebro a veces hierve, pero ya no es necesario que usted mismo haga listas vinculadas.