Entrevista a David Heinemeier Hansson
Introducción
David Heinemeier Hansson es el creador de Ruby on Rails, cofundador y director de tecnología de Basecamp, autor de superventas, conductor de coches de carreras en Le Mans, padre de familia, invitado habitual a pódcast e inspirador ponente de conferencias.
David creó Ruby on Rails en 2003. Desde el mismo día en que se fundó Evrone en 2008, hemos usado a diario el marco web de código abierto Rails. Nos ha ayudado a escribir excelente código miles de veces para nuestros proyectos. Además de crear una de las herramientas más útiles en el desarrollo de software, David ha conseguido otras impresionantes hazañas, desde escribir los libros «It Doesn't Have To Be Crazy At Work», «REWORK» y «REMOTE: Office Not Required», hasta participar en el Campeonato Mundial de Resistencia de la FIA. En 2014, fue el primero en su categoría en la edición 82 del 24 Horas de Le Mans, la carrera de resistencia de coches deportivos más prestigiosa del mundo. También ganó el campeonato de WEC en la categoría GTE-Am ese mismo año.
En 2020, invitamos a David como ponente en RubyRussia, la undécima conferencia sobre programación anual celebrada por Evrone en Moscú. Antes del evento, pudimos hablar con David sobre el mundo del desarrollo de software y su método para escribir código de excelente calidad.
La entrevista
Evrone: Hola, David. Es un placer tenerte hoy con nosotros. Empecemos la entrevista. ¿Cuál crees que es la mejor forma para que un desarrollador medio decida si tiene que empezar con un método de «JavaScript de nivel bajo» y hacer evolucionar más tarde su aplicación, o bien necesita usar Angular, React o Vue desde el principio? ¿Qué estrategia de toma de decisiones recomendarías?
David: Si estás creando algo que se parece a una aplicación web de Vanilla, como Basecamp, GitHub, Shopify o similar, creo que minimal-JS es la mejor opción. De lo contrario, nada de JavaScript, solo minimal. Si estás desarrollando algo que es muy interactivo (como un juego, una aplicación de edición de fotos o algo con una pantalla y muchos estados), tiene sentido usar un SPA completo.
Evrone: A medida que crecen la base de código y el equipo, ¿qué partes de la aplicación de Rails recomendarías para introducirte en los microservicios? Digamos que un negocio quiere una buena organización de desarrollo de código, pero reescribir todo el producto desde cero no es una opción.
David: Si no escribes software lo suficientemente bien para evitar un desastre la primera vez, es un engaño pensar que lo harás mejor la segunda vez. Tienes que aprender nuevos hábitos y, después, aplicarlos allí donde vivas. Sarah Mei dio una gran charla sobre esto en RailsConf 2018. Hablaba sobre cómo la base de código no era algo que desarrolláramos actualmente. La base de código es un lugar donde vivimos, y nuestro objetivo es conseguir que siga albergando vida por nosotros y por el resto de la gente que vive allí. Cuando escribimos código, nuestro objetivo no es terminarlo y continuar: el objetivo debe ser conseguir que sea sostenible y habitable para el equipo que lo usa.
Puedes reescribir todas las líneas de código que quieras; pero, si no cambias ese pequeño aspecto que te llevó allí en primer lugar, acabarás con una red enmarañada de microservicios, igual que tenías una red enmarañada de definiciones de clase en tu monolito. Tu código es literalmente un espacio interior, ocupado por personas. La parte importante del software es el sistema. Es el código y las personas en su conjunto, y son inseparables. Cuanto más piensas sobre el software como un sistema interconectado de código y personas, más cerca estarás de conseguir un gran avance. Más cerca estaremos de alcanzar una revolución, un cambio de paradigma. Y puede que sea más importante aún para nosotros el hecho de que estemos más cerca de crear bases de código en las que nos entusiasmará trabajar.
Evrone: Vaya, eso suena alucinante, ¡y no podríamos estar más de acuerdo! ¿Qué método recomendarías al elegir entre revisiones rutinarias y otros patrones de composición de código? ¿Qué deberíamos tener en cuenta para no convertir las revisiones libres en un desastre de reemplazos en conflicto?
David: Las revisiones libres se usan para crear dialectos de uso general del lenguaje. Active Support está lleno de revisiones libres. No sirve para crear cambios específicos de aplicaciones.
Evrone: Seguro que has visto muchos ejemplos de código de Ruby. En tu opinión, ¿qué crees que hace que un código sea bueno o malo? ¿Hay algo que te resulte obvio a primera vista?
David: Si el código no está bien escrito, se nota antes ni siquiera de examinar la lógica. La sangría no es uniforme, los estilos están mezclados y queda claro que no se ha cuidado el código. Más allá de eso, aprender a escribir código de calidad es un objetivo para toda la vida. Como ya dije en mi presentación de RailsConf 2014, no somos ingenieros de software, sino escritores de software. «Escribir» es una metáfora mucho más adecuada para lo que hacemos la mayoría del tiempo que un término como «ingeniería». Escribir tiene que ver con la claridad y con presentar la información de una forma fácil de seguir para que cualquiera pueda comprenderla.
No existe una lista de principios y procedimientos que alguien puede aprender y, automáticamente, producir siempre una escritura clara. Si quieres convertirte en buen escritor, no es suficiente simplemente con memorizar el diccionario. Saberte las palabras que hay disponibles y conocer los patrones de desarrollo no va a hacer que seas un buen desarrollador. Tienes que desarrollar un ojo crítico. Tienes que decidir que la parte más importante de tu sistema es la claridad. Una vez has tomado esa decisión, ya puedes empezar a desarrollar un ojo crítico.
La única forma de convertirse en buen programador (y, en mi opinión, defino a un buen programador como alguien que escribe software con claridad) es leer mucho software y escribir mucho software.
Evrone: Tienes toda la razón. Normalmente, a los empresarios que no son programadores les resulta complicado comprender la idea de «deuda técnica», «arquitectura» y reescribir la misma aplicación varias veces para mejorar el código. Como programador y empresario, ¿cómo recomendarías vender estas ideas a empresarios que no tengan conocimientos de programación?
David: En la gran mayoría de los casos, no creo que sea necesario reescribir una aplicación por motivos técnicos. La presentación de Sarah Mei explica el motivo. Pero sí que creo que es necesario reescribir el código si quieres que la aplicación haga algo completamente distinto. Hablé bastante sobre eso en una charla en Business of Software Conference USA.
Hemos reescrito el código de Basecamp varias veces; no una ni dos, sino cada vez que lanzamos una nueva versión. Sin duda, es bonito hacerte viejo con tus clientes. Eso tiene muchas ventajas, pero también muchos inconvenientes. Necesitas algún tipo de renovación, porque las cosas dejan de moverse y, en algún momento, te encuentras con una base de clientes muy antigua, una base de nuevos clientes cada vez más pequeña y «un cubo». Los clientes cambian de trabajo y abandonan tu software.
El problema es que, si no añades nueva agua, finalmente no quedará agua en el cubo. Tienes que realizar cambios mientras las cosas van bien, que sin duda es el momento más complicado para realizar algún cambio.
Nadie va a seguir interesado en trabajar para siempre en la misma implementación exacta de sus ideas de hace 15 años. Eso no funciona así. Pero, si sigues renovándolo, si continúas para que tus mejores ideas tengan una salida, en su forma más pura, podrás tener una nueva pradera y una preciosa casa sobre esta, y todo será maravilloso. Así que pido a todos que reescriban su software.
Evrone: ¡Y nuestra pregunta especial sobre «viajes en el tiempo»! Si pudieras retroceder en el tiempo hasta el momento en que empezaste a extraer Rails de Basecamp, ¿qué consejo técnico le darías a tu yo más joven?
David: No querría saber nada. A veces, eres más feliz si no sabes las cosas.
Estamos encantados de darle la bienvenida a David para hablar en la conferencia RubyRussia en 2020. Nuestro equipo de Evrone también está deseando conocer la continua evolución de Basecamp y, por supuesto, de Ruby on Rails. Cuanto más avanzado es el marco, mejores son las soluciones que podemos diseñar para nuestros clientes y socios. Si tiene alguna idea para un proyecto y quiere usar Ruby on Rails, nuestros desarrolladores estarán encantados de hablar con usted sobre las posibilidades. No importa en qué fase se encuentre del desarrollo de su proyecto: díganos cómo ponernos en contacto con usted y le ayudaremos a hacer realidad su proyecto.