Intentando que el código haga lo que dice, que ya sería bastante

Sobre mí

Soy desarrollador backend, principalmente con Java.

Tengo facilidad para ver estructuras: responsabilidades, dependencias, límites y esas decisiones diminutas que nacen como un inocente TODO y, si nadie interviene, terminan gobernando provincias enteras de la aplicación.¹

Me gusta el software elegante, legible y bien proporcionado. Cada capa debería conocer sus asuntos, ignorar educadamente los ajenos y abstenerse de atravesar fronteras sin una razón bastante mejor que «era más cómodo».²

Me interesan especialmente las ideas clásicas de abstracción, modularidad y contratos —Liskov y compañía ya habían pensado bastante antes de que muchas de ellas recibieran nombres nuevos, logotipos y conferencias—.³

Primero entiendo el problema. Luego los datos, los modelos y el flujo. Después aparece la arquitectura, que consiste principalmente en poner cada cosa donde debería haber estado desde el principio y fingir que era evidente.

En legacy uso bisturí. En sistemas nuevos refactorizo pronto. Y la deuda técnica puede existir, por supuesto; solo procuro mantenerla localizada, identificada y lejos de cualquier institución dispuesta a concederle crédito.⁴

Una buena estructura parece obvia cuando está terminada.
La estructura, naturalmente, no considera necesario explicar cuánto costó conseguirlo.

Buena parte de mi trabajo profesional es confidencial, así que este GitHub contiene sobre todo proyectos personales, formación y laboratorios técnicos.

📎 LinkedIn — Samuel Althaus

Stack

No todo lo de aquí ha vivido la misma vida. Algunas tecnologías pagan facturas; otras han sobrevivido a proyectos suficientemente serios como para ganarse un sitio en la mesa.

Arquitectura y diseño

Patrones de diseño / aplicación

Repository · Service Layer · Facade · Factory · Strategy · Command · Singleton · Adapter · Dependency Injection

Patrones y estilos arquitectónicos

Arquitectura por capas · MVC · MVVM

Me gustan los patrones. Me gustan especialmente cuando solucionan algo.

Una interfaz que no representa un contrato, una capa que no separa nada y una abstracción que obliga a abrir seis archivos para averiguar dónde se suma dos más dos no son arquitectura. Son burocracia con llaves y punto y coma.⁵

La arquitectura debe reducir el misterio, no institucionalizarlo.

Cómo trabajo

Entender qué hace
  ↓
Entender qué debería hacer
  ↓
Encontrar quién es responsable
  ↓
Separar lo que no debería conocerse
  ↓
Implementar y probar
  ↓
Refactorizar
  ↓
Negociar con Sonar
  ↓
Documentar y entregar

El objetivo es que el siguiente desarrollador pueda entender el código sin necesidad de arqueología, espiritismo ni una sesión particularmente rencorosa de git blame.⁶

Estadísticas