Tenía este tema en mi lista de pendientes desde que inicié el blog. Y dado que en breve cumpliré un año viviendo en Londres, creo que ahora es un buen momento para contar el proceso que seguí a la hora de buscar trabajo aquí desde España.
Es bastante importante recalcar este aspecto, porque los pasos a seguir si vives en Londres son algo diferentes a los que tienes que dar si vives fuera.
Vamos a abordar un tema polémico. ¿Son necesarias las reuniones? ¿Tienen un claro ROI (retorno de la inversión) o son el mayor ladrón de tiempo para un desarrollador de software? ¿Podemos rechazar alegremente una convocatoria de reunión si la consideramos innecesaria?
¿Son necesarias las revisiones de código? ¿No revisamos ya el código al mismo tiempo que desarrollamos? Si ya utilizo el refactoring como práctica habitual, ¿qué sentido tiene revisar el código de nuevo?
Son muchas las preguntas que pueden surgir en un equipo de desarrolladores en referencia a las revisiones de código. Pero peor aún que las preguntas son las inquietudes o recelos (“¡si se revisa mi código tirarán por tierra mi trabajo!”). Antes de nada, empezaremos definiendo qué es una revisión de código (Code review).
Mi intención con este post es dar un poco de luz a toda la confusión que parece que existe en torno a dos conceptos/principios:
Principio de Inversión de Dependencias (Dependency Inversion principle - DIP)
Inyección de Dependencias (Dependency Injection - DI)
Como bonus comentaré además el Principio de Inversión de Control (Inversion of Control - IoC), que muchas veces se confunde con la inyección de dependencias.
Modificar un sistema legacy es, quizás, una de las labores más desagradables de nuestra profesión, sobre todo cuando nos es completamente ajeno. El motivo es, sin discusión, la ausencia de tests.
En efecto, hasta hace unos años, la norma de la industria venía a ser, “desarrollar lo más rápido posible para salir a producción”. Dentro de esa filosofía, la implementación de tests (unitarios, de integración, de sistema, etc) parecía entenderse como una pérdida de tiempo total. El concepto de deuda técnica era desconocido (o parecía serlo), y nadie pensaba en las consecuencias posteriores, tan sólo en el “sálvese quién pueda”.