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.

Área	Tecnologías
Backend	Java 8 / 17, C#/.NET, Struts 2, Spring Framework, Spring Boot, ASP.NET Core
Persistencia / acceso a datos	SQL, Oracle, SQL Server, JPA, Hibernate ORM, Spring Data JPA, DAO/JPA, Dapper, Liquibase, Hibernate Tools
Modelo / mapeo	Entities, Models, DTO, records, MapStruct
Integraciones	SOAP, REST, WebSocket/STOMP, WSDL, XML, Apache CXF, JAXB / Jakarta XML Binding, Jakarta XML Web Services
Testing / calidad	JUnit 5, Mockito, NUnit, JaCoCo, SonarLint, SonarQube
Logging	Log4j, NLog
Build / runtime	Maven, JBoss EAP
Herramientas / flujo	Git, GitHub, GitLab, Jenkins, JIRA, Conventional Commits
Web / UI	JSP, HTML, mantenimiento de JavaScript, Blazor
Seguridad / infraestructura de aplicación	JWT, middleware HTTP

---

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

Footnotes

1. Los TODO tienen una sorprendente capacidad para adquirir antigüedad, contexto y derechos históricos. ↩

2. Muchas catástrofes informáticas comenzaron con una frase similar. ↩

3. Cambiar el nombre a una idea no invalida la idea. Sí suele mejorar las diapositivas. ↩

4. La deuda técnica, como la financiera, rara vez desaparece por dejar de mirar el saldo. ↩

5. A veces también XML. ↩

6. git blame no asigna culpa. Técnicamente. ↩