| name | senior-developer |
| description | Mentalidad y convenciones base de un developer senior — calidad de codigo, TypeScript estricto, naming consistente, tipos vs clases, manejo de complejidad y dependencias reproducibles. Reglas transversales que aplican tanto a backend como a frontend, agnosticas de framework. Usar como referencia base antes (o junto con) cualquier skill especifica de stack como `/api-nestjs-quick` o `/app-angular-quick`. |
| author | Cristian 'pusher' Bietti |
| linkedin | https://www.linkedin.com/in/crystian/ |
Senior Developer
Convenciones transversales de senior developer que aplican a cualquier proyecto
TypeScript moderno (backend o frontend). Las skills especificas de stack
(/api-nestjs-quick, /app-angular-quick, etc.) asumen estas reglas y solo
documentan lo que es propio del framework.
Mentalidad
- Sin parches. Codigo de calidad productiva, encontrar las causas raiz. Nunca
encadenar edits especulativos esperando que algo ande.
- Codigo legible > codigo clever. Nombres explicitos, funciones cortas, early
returns. Otra persona (o vos en seis meses) tiene que entenderlo a la primera.
- Reusabilidad sobre duplicacion. Greppear antes de implementar. Si la
funcionalidad podria existir, buscar primero.
Calidad de Codigo
- Complejidad ciclomatica maxima: 8. Extraer helpers, separar responsabilidades.
- Seguir el
.editorconfig y la config de ESLint del proyecto — no pelearse con el linter.
- Nada de TODOs que se "resuelven despues" — hacelo ahora o decilo explicitamente
en el reporte.
TypeScript
- Modo strict completo, validar params/vars sin uso (prefijo
_ para args sin uso).
- Evitar
any — usar unknown cuando el tipo es incierto y restringir con type guards.
- Preferir inferencia de tipo cuando el tipo es obvio.
- Orden de imports: deps externas primero, despues imports del proyecto.
- Conversion a string:
String(value) — nunca value + ''.
- Comparaciones de enum: usar el enum directamente — nunca constantes numericas
locales o numeros magicos.
Naming
| Elemento | Convencion | Ejemplo |
|---|
| Interfaces | prefijo I | ICoreOptions, IApiResponse |
| Types | prefijo T | TUserProfile, TBackupResult |
| Archivos | kebab-case minuscula | admin-user.service.ts, user-profile.ts |
| Clases | PascalCase | AdminUserService, UserProfile |
| Variables/Funciones | camelCase | getUserById |
| Handlers | nombrados por accion | saveUser, deleteItem — no handleClick, onSubmit |
Types vs Classes
TYPE cuando: estructuras de datos puras (sin decoradores), payloads de eventos,
formas de API, return types, objetos de configuracion, estructuras complejas (≥3 props).
CLASS cuando: necesita decoradores (DI, validacion, ORM), runtime/metaprogramacion,
metodos o logica en el constructor.
Estructuras de Datos Complejas
- ≥3 propiedades inline → DEBE extraerse a un type nombrado con prefijo
T.
- Co-locar al consumidor primario (
<module>.types.ts, models/<name>.ts,
dto/<name>.dto.ts segun el stack).
- Para exports type-only:
export type { ... }.
- Re-exportar desde el barrel del module si lo consume mas de un archivo.
Constantes
- Identificadores string especificos del dominio (config keys, nombres de eventos,
audit actions, permission codes, codigos de error, etc.) DEBEN centralizarse
en un objeto de constantes o enum.
- Greppear antes de crear uno nuevo — probablemente ya exista.
- Nada de strings inline para algo que se va a referenciar desde mas de un lugar.
Reusabilidad
- Antes de implementar, buscar funciones/utilities existentes.
- Nombres auto-descriptivos. JSDoc cuando el helper o flujo lo amerite (no para
documentar lo obvio).
Dependencias
- Preferir versiones fijas en
dependencies y devDependencies (sin ^ ni ~)
para builds reproducibles.
- Instalar con
--save-exact.
- Instalaciones deterministicas en CI:
npm ci.
