Etiqueta: programación

Sobre por qué la programación orientada a objetos perdió relevancia

Erase una vez cuando se desarrollaban aplicaciones grandes, con decenas o incluso cientos de entidades. Era una época donde se esperaba que cada pieza de software viviera por muchos años y los ciclos de release podían extenderse por muchos meses excediendo incluso el año. Era una época donde la programación orientada a objetos y sobre todo un buen modelo de objetos podía marcar una diferencia relevante en la construcción, evolución y mantenimiento de una pieza de software[1].

Pero esa época ha quedado atrás, cada vez son más las demandas del negocio por dar respuestas rápidas a las situaciones cambiantes del mercado. Los ciclos de release se han acortado radicalmente y de mano de ello también alcance de cada aplicación. Los avances en virtualización y la popularización de los contenedores han habilitado el surgimiento de prácticas como infraestructura como código y continuous delivery. En este contexto, propuestas de diseño como la de microservicios han probado ser muy efectivas. Cada microservicio es una aplicación de un tamaño acotado, no hay un regla fija de esto pero se suele usar como referencia un bounded context [2]. En este hilo de razonamiento cada aplicación no tiene ya tantas entidades y tampoco se espera que un microservicio «viva por siempre». Dado que los microservicios son relativamente pequeños no resulta impensado que luego de un tiempo sea reemplazado por una nueva versión que podría estar incluso desarrollada con una tecnología distinta.

Esto me lleva a pensar que en cierto modo la importancia de la programación orientada a objetos ha perdido cierta importancia relativa. En un punto cuestiones como la arquitectura de runtime (que impactan en la posibilidad de escalar) han tomado mayor relevancia (posiblemente porque la necesidad de escalar está mucho más presente ahora que hace 15 años).

Sin embargo estoy convencido que los principios de la orientación siguen completamente vigentes porque muchos de ellos son aplicables más allá de la programación. De hecho, los principios de diseño de los microservicios no son más que «refraseos» de los principios de orientación objetos. Un caso es el principio de Responsabilidad Única (Single Responsibility Principle): un objeto debe hacer UNA cosa y hacerla bien, eso mismo aplica a los microservicios. De hecho creo que perfectamente uno podría tomar los principios de orientación a objetos, aplicarlos al diseño de microservicios y luego programar internamente el microservicio utitilizando objetos pero de una forma más «procedural» utilizando alguna estrategia del Transaction Script. en lugar de hacer un Domain Model.

Tal vez este razonamiento genere alguna crítica y ante ello debo aclarar que he estado enseñando Programación Orientada a Objetos por más de 15 años y aún lo hago. Pero desde hace un tiempo vengo con la sensación de que en la medida en que podamos hacer aplicaciones/servicios pequeños, con pruebas automatizadas y prácticas de configuración management, la forma interna en que programemos las aplicación, resulta menos relevante.

[1] Posiblemente en algunos contextos esto siga ocurriendo
[2] Bounded Context es una idea desarrollada por Eric Evans en su libro Domain-Driven Design

Un programador de otro pozo

Recientemente leí un artículo escrito por Hernán Wilkilson sobre las nuevas características incluidas en la versión 8 de Java. Más allá del interesante análisis que hace Hernán, creo que son muy valiosas las ideas compartidas en la conclusión del artículo (recomiendo tomarse unos minutos para leerlo) sobre todo el llamado a los programadores a «abrir a la mente». Profundizando en este llamado quiero sumar algunas impresiones.

Como dice la frase «el que tiene un martillo en la mano sólo ve clavos», las herramientas que utilizamos para resolver los problemas influyen de forma determinante en las soluciones que diseñamos. Si bien ya hace años que tomé conciencia sobre este hecho, me sorprendí muchísimo cuando hace unos meses me sumé a trabajar en un proyecto Java con un equipo de experimentados programadores que en su carrera profesional habían trabajado casi exclusivamente con Java. O sea, habían usado otros lenguajes pero muy por arriba. Por mi parte, he trabajado mucho con Ruby y C#, un poco menos con Smalltalk y Javascript y muy poco con Java, Python y Php. Estas diferencias de experiencia han hecho que a la hora de plantear soluciones nos encontremos con propuestas bastante distintas. Un ejemplo de esto que me resulta muy chocante, y que es muy común en el mundo Java, es la práctica de separar datos y lógica. Esto lleva a tener clases que son simples contenedores de datos y clases que sólo tienen métodos para manipular datos contenidos en otros objetos, algo bastante anti-POO.

Creo que lo ideal para todo equipo sería contar con programadores «políglotas» pero me parece que no es algo muy común. Mi impresión es que en general las empresas muchas veces apuntan a sacar el mayor provecho de sus «recursos» y eso provoca que «los recursos» se especialicen y «encierren» en una única tecnología. Ojo, no es algo que pase sólo en las empresas, muchos veces quienes trabajan en forma independiente también deciden enfocarse/encerrarse tecnológicamente, ya sea por cuestiones de comodidad y/o rentabilidad.

Dada esta situación y desde el punto de vista de equipo creo que puede resultar interesante contar con un un programador de otro pozo, o sea, integrar en el equipo un programador que tenga experiencia en otros lenguajes/tecnologías pues puede aportar una visión diferente y enriquecer al equipo.

Curso: Aprendiendo a programar con Python

Durante el segundo cuatrimestre de este año voy estar dictando este curso de introducción a la programación. El mismo surge de una iniciativa conjunta del FIUBA y el programa EmplearTec.

Tanto la currícula como en enfoque de enseñanza del curso están basados en el curso de Algoritmos y Programación 1 (FIUBA) de Rosita Wachenchauzer, del cual fui parte hace algunos años. Esto implica que quienes tomen el curso deberán asistir a dos clases semanales de 3 horas cada una y deberán dedicar otras tantas horas para estudio extra clase.

Los interesados pueden encontrar más información y detalles de la inscripción en la página de FIUBA.

Recomendaciones idiomáticas para programadores

Las recomendaciones que comparto en esta sección han surgido principalmente de mi experiencia personal como programador y como docente de programación. Decidí ponerlas por escrito cuando me dí que cuenta que las repetía una y otra vez para los distintos alumnos que pasaban por mis clases.

Aprende inglés

Nos guste o no el inglés es la lenguaje universal es esta profesión, todos los lenguajes de programación de escala industrial parten de la lengua inglesa. (he sabido de lenguajes de programación basados en otros idiomas, pero todos ellos era experimentales o bien para uso educativo).

Si bien parte de la bibliografía es traducida al castellano, las traducciones siempre tienen un tiempo de defasaje respecto de la publicación original que la mayoría de los casos es en inglés. Incluso cuando la publicación original no sea en inglés, es casi seguro que será antes traducida al inglés que al castellano.

Al mismo tiempo la evolución de las herramientas es cada vez más rápida, haciendo que los tiempos entre las distintas versiones sea cada vez más corto. Esto hace que una traducción tardía pierda sentido pues queda rápidamente desactualizada.

Es cierto que también exiten publicaciones originales en castellano, pero sinceramente son sólo un pequeño porcentaje.

Adicionalmente existe un riesgo con las traducciones que es la potencial pérdida de cierto sentido del término original o peor aún, la ambiguedad.

Más allá de la necesidad del inglés para el acceso a los recursos, exite otra cuestión: los clientes. En este contexto cada vez más globalizado no es raro que termines trabajar con un cliente que no hable castellano. Aún cuando dicho cliente no sea un pais de habla inglesa ¿en qué lenguaje crees que pretenderá comunicarse contigo? Y podemos ir aún más allá, puede que incluso parte de tu equipo este distribuido y te tengas que trabajar con un compañero que no hable castellano.

Resumiendo: debes tener cierta soltura para comunicarte en inglés. ¿cuanta soltura? Mi heurística es: debes sentirte cómodo leyendo y escribiendo y debes ser capaz de entender los díalogos de la serie IT Crowd en idioma original sin necesidad de leer los subtitulos.

Elige un idioma

Un dilema común para muchos programadores de habla no inglesa es ¿en que idioma programar? O sea, más allá del lenguaje de programación que elijas utilizar, en un punto tendrás que crear tu clases/funciones/variables y deberás decidir cómo nombrarlas.

Podrias nombrarlas en inglés para así mantener uniforme el código fuente ya que las construcciones nativas del lenguaje de programación están en inglés.

Pero si tu cliente es de habla castellana, entonces podrías decidir nombras tus clases/funciones en castellano, para así tener un mapeo más directo entre los conceptos del dominio y tu código.

A mi parecer ambos criterios son válidos y creo que la decisión mas apropiada requiere de un análisis del contexto particular de cada caso.

Más allá del análisis y la decisión que uno tome, creo que lo importante es hacer el análisis, tomar decisión y respetarla. Obviamente esta no es un decisión individual, sino que es que debe decidirse a nivel de equipo.

Utiliza el alfabeto inglés

Es común en la actualidad encontrarse con lenguajes de programación que permiten el uso de caracteres no pertenecientes al alfabeto inglés. Por ejemplo en Java es posible definir una variable “año”, una clase “Interés”. En mi experiencia esto tarde o temprano suele traer algún tipo de problema, sobre todo si los ambientes de desarrollo de cada miembro del equipo no estan totalmente estandarizado.

Utiliza software de base en inglés

Es común que cuando se produce un error en una aplicación, se muestre mensaje de error al usuario y al mismo tiempo se genere una nueva entrada en el log de la aplicación. En algunos casos esos errores se muestran en el idioma actual de la aplicación y/o del sistema operativo.

Dado que hay mucha más información en internet en inglés que en castellano, siempre recomiendo utilizar software de base en inglés, o sea, al instalar tu sistema operativo, elige inglés como idioma por defecto. Lo mismo recomiendo para los IDEs y los SDKs. De esta forma en caso de encontrarte con un error, el mismo estará en inglés y al ponerlo en el buscador encontrarás muchos más resultados que si el error estuviera en castellano.

¿Cómo enseñamos a programar?

Cada vez estoy más convencido que la programación es un oficio y como todos los oficios se aprende haciendo. Pero no haciendo en soledad sino con un maestro. Pensemos en un carpintero ¿cómo se forma? ¿leyendo libros? Tal vez, si, es posible que lea algún libro, pero no es su principal formación. Su principal formación es trabajando la madera junto a un carpintero ya experimentado, quien le va enseñando los gajes del oficio. Pero si miramos la forma en que suele enseñarse a programar lejos está de esto.

No hay diferencia entre universidades, institutos terciarios o centros de capacitación privados, en general todos siguen el mismo esquema. El alumno asiste a un curso donde el docente ofrece algún tipo de explicación inicial y luego le dá a los alumnos ejercicios para que resuelvan. Luego se hace una resolución general en el pizarrón o usando un proyector. Puede que también se entregue algún material de lectura. Pero sentarse a programar con el alumno, no, nunca. En el mejor de los casos, mientras los alumnos trabajan en la resolución de los ejercicios, puede que un docente se acerque para responder alguna consulta o para destrabar a un alumno que no logra avanzar en la resolución.

¿Por qué es esto así? no lo sé a ciencia cierta. Creo que puede haber diversos motivos.

En sus comienzos la programación surgió vinculada a la matemática y por ello puede que haya heredado su didáctica. También puede ser que los docentes no vean la programación como un oficio. En algunos casos podría argumentarse que la masividad de algunos cursos hace imposible que el docente se siente a programar con los alumnos. En fin, cada cual tendrá sus argumentos. En lo que a mi respecta, estoy convencido que la programación es un oficio y si bien en Algo3 tenemos cursos masivos y recursos acotados, intentamos programar con los alumnos haciendo dojos en clase o incluso algo de «community-programming» al desarrollar el trabajo final, donde cada docente puede sentarse con grupos de 3 o 4 alumnos a programar conjuntamente.