Once puntos que te definen como programador (Senior, Semi-Senior, Junior)

Una de las preguntas que todo desarrollador se hace en algún momento de su carrera es cómo determinar si realmente estoy programando bien ?, y más aún, en qué categoría estoy ?. Por lo general, nadie puede resolver esta pregunta en primera instancia de manera sencilla, y si lo hace, de seguro que la opinión estará sesgada por lo que conoce y lo que desconoce. Hace muchos años yo mismo me hacía esta pregunta y creía con toda firmeza que mi manera de codificar era sobresaliente. Sin embargo, en la actualidad creo que no pude haber estado más equivocado. Pero por qué ?, sigue leyendo este post y te darás cuenta por qué.

Qué se necesita para saber si se programa bien o no ?

Esta es la verdadera pregunta que debemos responder antes de realmente preguntarnos si programamos bien o no. Así que te voy a nombrar los aspectos que creo de manera firme que debes abordar para intentar responder de manera objetiva la pregunta que queremos responder.

1. Lógica de programación

Parece obvio pero muchos programadores aún llevando años en el oficio no tienen claro algunos conceptos esenciales. Pero cómo saber si tengo lo necesario ?. Por lo general los que hemos realizando algún curso de lógica de programación (serio) o introducción a las ciencias de la computación sabemos de qué nos están hablando. Es un curso que no llevará más de 1 o 2 meses depediendo de tu ritmo. Aún así, es fácil detectar falencias en este aspecto cuando le preguntas a un programador por Bubble Sort y jamás ha escuchado sobre ello. La manera más fácil de medir tu nivel de programación es resolver problemas como los que propone Hacker Rank.

2. Métricas de código

Aunque la forma de abordar un problema puede llegar a ser muy subjetiva, la manera de codificar siempre tiene un estándar. En PHP es el PSR, una serie de normas o reglas sobre cómo codificar para que tus programas sean estándar. No seguir estas recomendaciones no implica que tus programas sean de menor calidad en la mayoría de los casos, sin embargo, como desarrollador das a entender que te preocupas por que el código esté siempre ordenado, con lo cual tu manera de programar ya va por buen camino. Antes de conocer las métricas de código siempre realizaba los condicionales de la siguiente manera:

if (codition)
{
    // code block
}
else
{
    // code block
}

Después de seguir las PSR de PHP mi forma de hacer condicionales pasó a esto:

if (codition) {
    // code block
} else {
    // code block
}

Seguramente estarás pensando que esto es tan superficial que ni siquiera deberías prestarle atención. Sin embargo, supone una métrica aceptada por una comunidad mundial de desarrolladores que en su momento llegó a un concenso y determinó que la forma más legible era la segunda. Otras métricas indican que una línea de código no puede superar los 120 caracteres, lo cual por legibilidad suena más que lógico. También piensa que no es lo mismo leer un código ordenado y bien indentado que un código que esté todo desordenado. El punto es, si se va a seguir una métrica debe seguirse completa y esto hará que tu software sea más estándar.

3. Pruebas Unitarias y de Integración

Este es uno los aspectos más decisivos para determinar tu nivel como desarrollador al punto de que si realmente no haces prebas unitarias y de integración de tu código puedes clasificarte sin miedo a equivocarte como un desarrollador Junior. Las pruebas unitarias no solo demuestran que tu código funciona si no que además permiten la integración continua y evitan que un cambio o ajuste en el código afecte funcionalidad en otras partes del sistema. Un paquete de software con un coverage decente (>70%) indica que el software es menos propenso a errores y de cierta forma acorta la incertidumbre sobre si funciona o no. En PHP el paquete de software más común para realizar este tipo de pruebas es PHPUnit. Todo desarrollador Senior y Semi-Senior debería realizar pruebas untiarias.

4. Herramientas de análisis de código

Más allá de utilizar métricas y realizar pruebas unitarias están las herramientas de integración continua y análisis de código. Básicamente estas herramientas te ayudan a verificar si tu software tienen el performance y la lógica adecuada. Si haz utilizado Git debes haber visto una que otra vez herramientas como Travis CI, Scrutinizer CI y Circle CI integradas en los repositorios más pupulares. Estas herramientas son llamadas de integración continua, y verifican si en el código se utilizan por ejemplo funciones obsoletas o inseguras, variables no utilizadas, importacinoes no usadas, detectan bugs, documentación de código faltante, analizan si un bloque puede tener mejor perfomanace realizado de otra manera, etc. Si estás por el lado de repositorios privados ya sea en Git, o Bitbucket, también verás herramientas somo SonarQube y Codacy.

5. Versionamiento (Git, Subversion, ...)

El versionamiento es otro de estos aspectos decisivos pero no tiene tanto que ver con cómo programas si no más bien con cómo controlas los cambios en tu código. Los VCS (Version control system) son paquetes de software que te ayudan a llevar ese histórico de cambios realizados en un software de manera organizada. Pero no solamente es el hecho de llevar el histórico lo que importa, sino el hecho de que permite trabajar de manera ordenada con un grupo de desarrolladores que desean corregir bugs, sacar nuevas funcionalidades, hacer forks o versiones alternativas del sistema, etc. 

Este aspecto, incluye todo lo relacionado con el flujo de desarrollo (Git Flow), es decir, las ramas que se manejen (master, staging, develop, ...), la corrección de bugs, creación de nuevas funcionalidades (hotfix, bugfix, feature) y la estrategia que se utilice para crearlas.

6. Conocimiento de patrones y paradigmas

El paradigma de moda hoy en día es el orientado a objetos ya que ha demostrado resolver la mayoría de problemas con un enfoque similar a cómo se resolvería en el mundo real. Este punto, implica que no solamente debes conocer ciertos paradigmas sino también cuando aplicarlos. Resuelto el tema del paradigma, debes conocer una serie de patrones de diseño que podrás aplicar casi en cualquier proyecto con el que te encuentres. Sin embargo, esto no quiere decir que en todo proyecto debas aplicar TODOS los patrones de diseño y arquitectura que conoces. Más bien, la estrategia está nuevamente en saber cuando utilizarlos. Seguramente habrás escuchado algunas vez patrones como el Singleton, Adapter, Factory method, Repository, entre otros. La norma por lo general, está en el libro Design Patterns creado por un grupo denominado The Gang of Four (GoF), el cuál lista una serie de patrones que son los que mayormente hoy se utilizan.

Conocer sobre patones de diseño es uno de los puntos que más se tarda en aprender ya que suelen ser demasiados y van llegando poco a poco, por lo que yo diría que todo desarrollador Semi-Senior y Senior debería dominar un número considerable de patrones. El saber cuándo aplicarlos, podría ser un determinante para saber si eres Senior o Semi-Senior.

7. Conocimiento de la infraestructura

Un programador debe ser consciente del entorno en el cuál su aplicación va a funcionar. Te coloco un ejemplo, si desarrollaste un chat en tiempo real con PHP en Apache, deberías preocuparte por la cantidad de hilos que puede manejar no solo PHP sino también el servidor Apache, debes poder encontrar en determiando momento la razón por la cuál tu aplicación pueda llegar a tener un bajo desempeño. Vamos con otro ejemplo, si tu aplicación utiliza un certificado SSL para firmar documentos PDF, debes saber cómo generar y configurar un certificado SSL en apache y tener nociones básicas de cómo se realiza esa negociación entre el servidor Apache y PHP. Si como programador no eres conciente de esto, un error como el siguiente puede crear una indisponibilidad del servicio que jamás imaginaste.

[error] SSL Re-negotiation in conjunction with POST method not supported!

Error 525: SSL handshake failed, Error 525 indicates that the SSL handshake between Cloudflare and the origin server failed

Este aspecto es uno de los que yo considero que diferencia un programador Senior de un Semi-Senior.

8. Metodologías Ágiles (SCRUM)

El proceso de desarrollo suele ser mucho más efectivo cuando se utilizan metodologías como Scrum. Tal vez estarás pensando de antemano que esto no tiene nada que ver con ser un buen programador, sin embargo, cuando desarrollas sobre Scrum te das cuenta si en realidad tienes la capacidad para dividir tu trabajo en historias de usuario. Recuerda que el fin último de un sistema de información es siempre suplir la necesidad de un usuario, si eres lo suficientemente conciente de esto, podrás realizar tu software pensando en el usuario final y no como si fuera para vos.

Scrum también permite que cada vez mejores tu capacidad para afrontar problemas, resolverlos y estimar en cuánto tiempo podrías hacerlo. Esto último, está directamente realacionado con los deadlines y como desarrollador te permite aprender a visualizar un problema y discriminarlo  para poder solucionarlo. Ahora piensa esto, si en realidad eres tan bueno como dices, deberías poder determinar en la mayoría de los casos cuánto tardas en realizar una solución de software, esto te da un poco de respeto y te evita inconvenientes con las entregas.

9. Seguridad

La seguridad es un aspecto crítico en el software. Una empresa que maneje datos sensibles de sus usuarios, que procese transaciones bancarias, que maneje sistemas críticos (médicos, en tiempo real, en otros), por colocar solo unos ejemplos podría verse gravemente afectada si no se tienen en cuenta los aspectos de seguridad del software. Un buen programador, debería conocer al menos OWASP (Open Web Application Project) si es el caso de un programa en web, y debería estar documentado de los riesgos específicos a los cuáles está expuesto un sistema dependiendo del lenguaje, entorno, usuarios, etc. Hace poco relicé un post sobre Qué es OWASP y por qué todo desarrollador debería conocerlo, te invito a que lo revises y te empapes un poco más del tema. Este aspecto es un requisito fundamental para un desarrollador Senior.

10. Reviews y mejora de código

Un buen programador debería estar en la capacidad de revisar el código de otro programador y detectar posibles mejoras y corrección de bugs. Esto suena más que obvio, pero los desarrolladores que nunca han revisado un pull request de un cambio en algún sistema de versionamiento, se encontrarán con que no es tan fácil realizar una revisión de código (por lo menos comenzando). Este aspecto no es un punto aparte separado de todos los anteriores, por el contrario, require que el desarrollador conozca las buenas prácticas de programación (como los principios SOLID), métricas, patrones, y herramientas para poder determinar mejoras y errores en el código.

11. Comunicar ideas de software

La comunicación con las personas es esencial para lograr un sinergia en tu equipo de trabajo. Debes poder ser capaz no solamente de tener una serie de conocimientos técnicos sino también de poder comunicar estos aspectos con tu grupo de trabajo. Las bases de un paquete de software no son la programación en sí, esa es una labor mayormente técnica, la base está en el diseño y arquitectura que se planteó al comienzo. Qué clases crear, cómo dividirlas, qué patrones utilizar en el camino, qué librerías utilizar y muchas otras desiciones son aspectos que definen la calidad de tu proyecto. Más aún, cuando se discuten estos temás con tu equipo debes tener los argumentos necesarios para defender tu punto de vista, no es solamente el hecho de proponer por proponer. Una actitud propositiva va de la mano con este punto, conoces aquellos programadores a los cuáles les has escuchado una o dos veces la voz en lo que llevas en la empresa ?.

Tal vez me haya faltado uno que otro aspecto por abordar, pero creo que los mencionados son los más relevantes del caso. Espero que puedas abordar este post como una opción de mejora y en caso de que no cumplas uno que otro aspecto te recomiendo de la manera más sincera que lo abordes ya que esto te hará crecer como desarrollador. Hasta pronto!.

---