Clean Developer

Antes de que sigas leyendo me gustaría que supieras que lo que cuento en este artículo es una opinión muy personal que me he ido formando con el paso de los años como programador, empecé allá por el 2002. Es muy posible que no tengas la misma opinión así que me gustaría que la compartieras en los comentarios del artículo.

Un poco de historia

En mi primera empresa entre como programador en prácticas y me quedé 8 años. Tuve la suerte de tener un tutor llamado Pablo Conesa, que me enseño muy buenas bases de programación orientada a objetos y buenas prácticas. En aquella empresa programábamos en Visual Basic 6. Con el tiempo fuimos descubriendo conceptos nuevos juntos como patrones de diseño, testing, scrum, arquitectura de software etc... Por situaciones que suceden en las empresas él se marchó de la empresa y al poco tiempo esta cerro por malos resultados. Al principio me vi bastante perdido, en mi primera empresa me había quedado un poco obsoleto en cuanto a lenguajes y frameworks que habían surgido con los años como .Net y c# por ejemplo.
Me puse a estudiar como loco y en los siguientes trabajos siempre se daba la misma situación, mis nuevos compañeros sabían un montón de cosas que yo no conocía. Pero también siempre se cumplía que con el paso de las semanas y meses me iba ganando la confianza de mis compañeros porque lo que yo sabía, en lo que yo tenía mucha experiencia, se podía aplicar a cualquier lenguaje y tecnología. Daba igual que fuera .Net, Java, Android, iOS, Web o mobile la base que yo tenía era muy útil en cada proyecto en el que estaba. A la vez no me resultaba especialmente complicado aprender lenguajes, frameworks etc.. Lo que intento explicar es que es mucho más difícil y valioso, según mi experiencia, tener una buena base de programación que saberse de arriba a abajo un lenguaje, framework o tecnología que esta de moda, porque las modas pasan.

Martin Fowler, dice que todas las arquitecturas caducan pero yo pienso que los frameworks caducan mucho más rápido, sino que se lo digan a la gente de JavaScript.

Analogía con Clean Arquitecture

Clean architecture es una arquitectura de software que representa los componentes divididos en capas, las capas internas son las más importantes, son el dominio de tu aplicación, tu lógica de negocio y las capas externas son herramientas utilizadas por tu aplicación y de las que no depende tu aplicación sino que las utiliza. Si hacemos una analogía entre lo que pienso sobre qué conocimiento es más valioso para un programador y Clean architecture la idea es bastante parecida.

Si pensamos en los conocimientos que un programador va adquiriendo con la experiencia, se pueden dividir en tipos de conocimientos y estos se pueden ver como capas de conocimientos circulares como en Clean Architecture. Del mismo modo los círculos internos son más importantes y core de nuestro conocimiento. A medida que avanzamos en las capas hacia el exterior esos conocimientos son menos estables y es fácil que tengamos que sustituirlos por otros con el paso del tiempo. Sin embargo los conocimientos de los círculos internos son más longevos, útiles y sobreviven a lenguajes, tecnologías, frameworks y por qué no, a las modas.

Conocimiento base

Esta es la parte más valiosa que puede tener un programador, es la parte más interna de las capas de conocimiento, el core, la que te va a proporcionar beneficios más a largo plazo y donde a mi me gusta invertir en mejorar y seguir aprendiendo priorizándolo sobre otras capas más externas. Estos conocimientos van a permitir a un programador adaptarse a cualquier lenguaje o tecnología de una forma mucho más rápida. Porque seamos realistas, a mi me puede gustar mucho Android pero quién me dice que siempre va a estar esa plataforma para que yo trabaje sobre ella o quién me garantiza que siempre voy a tener trabajo en esa plataforma, nadie.
Hace mucho tiempo que solo me compro libros que tengan que ver con esta parte del conocimiento porque estoy seguro que me van a ser muy útiles durante muchos años y no se van a convertir en unos años en unos adornos de la estantería.
Os dejo un enlace de algunos de los libros más importantes sobre esta parte del conocimiento de software.

Lenguajes

Esta capa de conocimiento es donde se encuentran los lenguajes que utilizamos para realizar nuestro trabajo pero sin ninguna librería ni framework, el lenguaje puro y duro. Muchas veces una falta de conocimiento del lenguaje con el que trabajamos nos hace realizar peor nuestro trabajo o recurrir a librerías, cuando podría no ser necesario con un mejor conocimiento del lenguaje. No estoy en contra de utilizar librerías, es cierto que no hay que reinventar la rueda, pero tampoco estoy a favor de utilizar librerías de terceros o frameworks de forma masiva como ocurre en JavaScript por ejemplo. En muchas ocasiones con el propio lenguaje se consiguen mejores soluciones.

Esta capa de conocimiento es la segunda más importante. Mezclando una buena base y un buen nivel de JavaScript te vas a desenvolver sin problemas a corto plazo con AngularJS, ReactJS, o NodeJS. Da igual que sea front-end o back-end tienes una base sólida que es lo más difícil, con lo que aprender la técnología o framework no te va a costar en exceso y seguro que harás un uso más apropiado.

Tecnologías y plataformas

Aquí es donde las capas de conocimiento empiezan a ser un poco más volátiles y bajo mi punto de vista pierden importancia. Es fácil ver a una persona que empieza programando en .Net y ahora están programando en Android o iOS. A partir de esta capa es donde empieza a verse que el conocimiento que se aprende en ella son más bien herramientas que utilizamos para realizar un trabajo. Es cierto que puede haber programadores, como yo por ejemplo, que trabajamos con .Net habitualmente, pero en ciertos momentos he trabajado puntualmente con Android, iOS, Node.js, por eso pienso que el conocimiento sobre las plataformas, en este concepto de capas circulares de conocimiento, son más bien herramientas que conocimiento principal de un programador.

Frameworks

Esta es la capa que considero menos importante, seguro que es importante saber angular si estas en un proyecto de ese tipo pero dentro de muchos años cuando mires atrás lo recordarás como una herramienta que utilizaste no como la base de conocimiento de toda tu carrera. Son herramientas que utilizas para hacer un trabajo concreto y a lo mejor en lugar de Angular en otro proyecto lo mejor es utilizar React, quien sabe, o ninguno de los dos por eso centrarte es ser un experto en un framework dejando a un lado mejorar en las capas internas, creo que te da beneficios a corto plazo pero no a largo plazo y desde mi punto de vista es un error. Claro que debes conocer React si se utiliza en tu proyecto y lo mejor que puedas pero no hagas que tu carrera dependa de React, no seas programador React sé un programador con muy buena base que utiliza React o Angular según las características del proyecto.

¿Solo cuatro círculos?

Al igual que Uncle bob explica en su famoso artículo sobre Clean Architecture, no son solo cuatro círculos, puedes poner los que quieras. Por ejemplo se podría añadir otro para tipo de proyecto, en esta capa podrían estar tipos de proyecto como aplicaciones web, de escritorio o REST API.

Conclusiones

Según mi experiencia tener una buena base es el conocimiento más importante que vas a adquirir como programador y que te servirá para siempre. Las plataformas y frameworks sin embargo son conocimientos volátiles.

No estoy en contra de la especialización en plataformas, de hecho hace tiempo que sigo la pista gente que son expertos en Android pero si hay algo común en todos ellos es que los conocimientos que tienen de las capas más internas es muy importante, por eso les sigo la pista y seguro que no les costaría programar en iOS por ejemplo. No es mi intención decir que solo hay que aprender conocimiento base, pero si creo que debe ser el pilar central de tu conocimiento, hay mejorarlo y ampliarlo.

Es imposible saber de todo pero creo que si hay que poner prioridades tengo claro que lo más importante es ir desde círculos internos a externos, esa es mi opinión.

¿Me cuentas tu opinión y abrimos el debate?.