Alrededor de marzo de 2017, me pidieron que revisara el código del producto antes del lanzamiento. Esa compañía tuvo problemas con pérdidas de memoria, bloqueos espontáneos, carga lenta, picos en el consumo de CPU y se planeó un lanzamiento en unas pocas semanas. Es posible que ya haya escuchado esta historia, no de mí ni de esta compañía. Ella es sorprendentemente típica.
Nos reunimos el fin de semana y comenzamos a mirar el código juntos. Después de aproximadamente medio día, se descubrió una fuente de problemas conocidos, y otro medio día tardó en escribir un documento de solución para los desarrolladores. El lanzamiento fue un éxito, pero la historia me hizo pensar: ¿cómo llegó el producto a ese estado?
Cuando hablé con los desarrolladores, parecían personas inteligentes. El único problema obvio fue la falta de experiencia. Me he encontrado con esto antes. Este es un fenómeno común y bastante normal. Pero en este caso, se observó un defecto atroz: la experiencia no fue suficiente para
todos los desarrolladores.
Recientemente se creó un departamento de desarrollo y se contrató un equipo en ausencia de un director técnico. Incluso un técnico está en apuros para probar a otro programador; ni siquiera puedo imaginar una prueba sin conocimientos técnicos. Contrataron al primer desarrollador, él verificó al segundo desarrollador, y así sucesivamente, hasta que se formó un equipo.
Si tienes suerte y el primer desarrollador tiene una experiencia significativa y un deseo de entrenar, entonces estás en las damas. Pero si no tiene suerte, y las posibilidades de esto son muy altas, obtendrá un equipo de rápido movimiento que crea un software muy frágil.
"Actúa rápido y rompe todo", dicen. Pero esta es una idea bastante mala si el negocio depende de un pequeño número de grandes clientes. Los productos rotos generalmente los ahuyentan, lo que a su vez afecta su negocio. Puede describir la estrategia efectiva de diferentes maneras, pero la frase "avanzando lenta y constantemente hacia la meta" claramente no es impresionante.
De hecho, hay un equilibrio entre cámara rápida y lenta. Es difícil encontrar este equilibrio, porque cada producto tiene su propio equilibrio. Supongo que la intuición se basa en la experiencia, y esta es una respuesta terrible para un principiante.
¿Qué hacer con el nuevo desarrollador?
Parece natural buscar una respuesta en Internet. Resulta que es
increíblemente efectivo .
Pero también es
increíblemente peligroso .
Colaboré con esa compañía después del lanzamiento del producto. Miré a través de una cantidad significativa de código, ayudé en la capacitación de desarrolladores y creé nuevos proyectos para ellos. Todo salió a la perfección.
Una vez mi atención fue atraída por una pieza de código. Podría haber jurado que lo vi antes. Por supuesto, buscando en Google la línea, encontré una copia exacta del código en una publicación de blog. Naturalmente, leí todo el artículo, hasta el párrafo que decía:
"No hagas esto en producción" .
Pero estas líneas me miran directamente desde la base del código en producción.
No tardó mucho tiempo en encontrar muchas piezas de código de artículos similares. Se escribió un descargo de responsabilidad en casi todas partes, o claramente no era suficiente. Todos resolvieron una pequeña parte del problema, pero permitieron muchas libertades para facilitar la lectura del código. Esto se puede entender. La mayoría de los lectores aprecian la brevedad cuando aprenden un concepto.
El código de estas entradas de blog se propagó a través de la base del código como una infección, causando problemas aquí y allá sin ningún motivo o patrón. Y no había una cura obvia aparte de leer todo el código en una fila y solucionar manualmente los problemas uno por uno. Sin pruebas unitarias y despliegue automático, tomó
casi un año . Estoy bastante seguro de que el costo de arreglar el código excedió el costo de escribirlo.
Pero, ¿qué opción tenían estos desarrolladores? Necesitaban lanzar algo, y nunca antes habían lanzado una aplicación en producción. Por lo tanto, hicieron lo que cualquier persona en su sano juicio intentaría hacer, y aprendieron en el camino.
Los sistemas de producción fallan en un número increíble de formas. Sin experiencia o conocimiento teórico de estas fallas, es difícil comprender intuitivamente cómo prevenir o resolver tales problemas. Es difícil requerir un nuevo equipo para lograr un resultado perfecto, especialmente sin algún tipo de liderazgo.
Antes de continuar, quiero señalar que cada persona que participó en este caos tenía buenas intenciones. Los desarrolladores querían crear un buen producto y desarrollarlo. Los gerentes querían lo mismo. Los autores del blog querían compartir soluciones útiles. Todos intentaron ayudarse unos a otros, y es importante recordar esto.
El problema no está en las personas.Simpatizo mucho con los desarrolladores que están en esta posición. Tienen más información de la que necesitarán, pero está completamente desorganizada. Esto es similar a tratar de armar un rompecabezas de diez piezas, solo necesita encontrarlas en un montón de 10,000,000 piezas, donde todas las piezas son cuadradas, y el resultado final es desconocido. Buena suerte
Si lees aquí esperando una respuesta, lo siento: no tengo una respuesta simple. Este problema es difícil de resolver. La solución es demasiado grande para un artículo, cambia todos los días y difiere en los matices de cada proyecto.
Este problema me llevó a comenzar un blog. Tuve la suerte de aprender de mentores, escritores y colegas increíblemente talentosos durante casi veinte años. Sin el consejo de estas personas, todavía estaría escribiendo directivas
GOTO en QBasic (brrr). Es hora de tomar la pelota y pasar a la ofensiva.
Para resumir.
Este blog está dedicado a todos los aspectos del desarrollo de aplicaciones listas para usar: desde la automatización de infraestructura hasta las pruebas, el diseño, la depuración, la documentación, el proceso de desarrollo y la seguridad. Cada artículo es independiente y adecuado para su uso en el mundo real,
adecuado para su uso en producción .