En la empresa en la que trabajo actualmente (RocketROI) como premio a una especie de competencia interna, me han regalado una entrada a la Java Barcelona Conference. Esta conferencia tuvo una duración de 3 días, siendo los primeros 2 días exclusivos para las charlas y el último día dedicado a los workshops. Debido a que todas las charlas se ejecutaban de forma simultanea, era necesario elegir con antelación “el camino” que querías seguir. A continuación, quiero contarles brevemente lo que aprendí de la primera de ellas, The Art of Simplicity.
Lo que aprendí
Speaker: Venkat Subramaniam
Venkat comenzó esta charla explicándonos que NO es la simplicidad. Además de ofrecernos variadas recomendaciones, de esas que muchos sabemos pero igualmente pocos aplicamos. Recomendaciones como: usar nombres de variables que tengan sentido, documentar nuestro código, evitar la mutabilidad, entre otras.
Imperative Code < Declarative Code. El código es menos complejo y mantenible si en lugar de especificar qué hacer y cómo hacerlo, solo tenemos que definir qué hacer.
Simple code it is not clever. El código debe ser claro, entendible. El buscar una solución “ingeniosa” dificulta el desarrollo para otro programador, ya que primero deberá entender lo que está hecho. Además, el código ingenioso suele ser más propenso a bugs que el código simple.
Simple code it is not necessarily familiar. La forma en la que explica este punto me parece genial aunque debatible. Muestra en la presentación un par de letras chinas y pregunta si alguien sabe que significan, nadie responde. Son las letras en chino para “Simple”, y nos demuestra que el hecho de que no estemos familiarizados con el idioma no quiere decir que no sea simple. El punto a destacar acá es que en muchas ocasiones hay formas más simples de solucionar ciertos problemas, pero al no ser familiares para nosotros, pensamos que es complejo. El hecho es que una vez entendemos el código, que aunque no nos sea familiar en un principio, sí que es simple y nos facilita su futuro mantenimiento o mejora.
Simple code it is not overengineer. Venkat nos comenta que es una mala practica desarrollar pensando en solucionar la “madre de los problemas” cuando podemos solucionar simplemente el problema que tenemos. Nos cuenta una anécdota en la que habla en persona con un desarrollador que buscaba solucionar la “madre de los problemas” y quería convencerlo de que era una buena idea. Entonces Venkat le pide que lo disculpe un minuto y se retira para llamar al mismo desarrollador con el que hablaba a su teléfono móvil y éste le pregunta “¿Porque me llamas? Si estamos a pasos de distancia.” y Venkat le responde “Aunque estemos cerca, si quisiéramos estar lejos, pudiéramos seguir hablando.”. Demostrando que no hay que buscarle la quinta pata al gato, cuando queremos solucionar un problema que de por sí es simple.
Simple code it is not terse. Existe una diferencia entre código conciso y código breve o corto. El código breve, en la búsqueda de ser corto puede dar espacio a bugs o comportamientos no esperados, además de ser difícil de comprender. En cambio, el código conciso hace lo que debe hacer sin boilerplate y buscando mantener la simplicidad, lo que facilita su comprensión.
Para finalizar, les comento de una de las frases que dijo que me gustó mucho: “Existen 2 formas de hacer software, la primera es hacerlo tan simple que sea obvio que no tiene deficiencias. La segunda es hacerlo tan complejo que no sea obvio que tiene deficiencias.”