Parẹ́
Preferir eliminación, estado directo, propiedad local, módulos profundos, capacidad nativa y YAGNI. Rechazar complejidad reubicada.
Modos:
audit— auditoría de simplificación de un sistema/subsistema de software acotado; solo lectura; sin pruebas/compilaciones.review— un candidato de software fijo; solo lectura; sin proveedor/veredicto.
Mantener los veredictos de defectos/paridad de estado, la implementación y la arquitectura técnica fuera de este resultado de simplificación de solo lectura.
Evidencia
Fijar el sistema/candidato de software, la línea base, las instrucciones y las exclusiones. Inspeccionar únicamente los consumidores actuales, la implementación/configuración, el historial, la alcanzabilidad generada/del framework y la evidencia nativa del sistema necesaria para distinguir afirmaciones de simplificación sustanciales. La ausencia de búsqueda o herramienta por sí sola nunca es prueba de eliminación, y la salida de herramienta/métrica es evidencia, no el veredicto de simplificación.
Cuando el flujo de control/espacio de estado/anidamiento/fan-out/ciclo de vida/complejidad/volumen de pruebas controle materialmente la investigación, leer complejidad y prueba. Cuando los patrones recurrentes de mantenibilidad/propiedad sean relevantes, leer patrones de mantenibilidad. Los patrones y métricas son señales, nunca hallazgos.
Escalera de simplificación
Tomar la primera reducción sólida después de entender el flujo/consumidores/contratos reales:
- Eliminar — el mecanismo no necesita existir, o un elemento existente no tiene comportamiento, contrato, consumidor o propietario requerido.
- Reutilizar — capacidad de implementación/sistema actual → stdlib/framework/plataforma → dependencia/herramienta instalada.
- Derivar — eliminar estado almacenado/duplicado preservando temporización/propiedad/costo.
- Localizar — poner la política/estado con su propietario real/módulo profundo.
- Reducir — mecanismo directo mínimo; sin variación especulativa.
No recomendar extracción/indirección meramente porque un archivo/función es grande o una puntuación es alta. Una nueva abstracción no es simplificación a menos que elimine carga semántica neta y sea propietaria de una variación actual o un límite independientemente real.
Auditoría
Inventariar subsistemas no superpuestos de fuente, punto de entrada, compilación, prueba, herramientas, plataforma, ejecución/configuración y generados. Clasificar artefactos de implementación/dependencias/config/soporte como conservar | eliminar-seguro | bloqueado. Ejecutar pases separados de eliminación, representación, propiedad, algoritmo, complejidad-cuando-relevante y prueba.
La seguridad de eliminación requiere más que la ausencia de búsqueda: verificar llamadores, alcanzabilidad dinámica/del framework/generada, config/datos, compilaciones, consumidores, historial, contratos y propietarios de prueba. Preservar contratos públicos/seguridad/integridad de datos/concurrencia/recuperación/adaptador/ejecución/interacción/accesibilidad cuando no exista un propietario completo más fuerte.
Auditar pruebas por valor de contrato duradero en lugar de por cantidad/cobertura. Una prueba es candidata a simplificación cuando la evidencia muestra que no puede falsear independientemente un contrato material, recalcula/refleja lógica de producción, verifica mocks/coreografía en lugar de comportamiento, protege estructura privada, prueba comportamiento de framework/biblioteca que el proyecto no posee, duplica una prueba más sólida, requiere andamiaje desproporcionado, o sobrevive solo como historial de construcción. No recomendar eliminación cuando la prueba protege de forma única un invariante estable material aunque su implementación sea pequeña.
Clasificar las reducciones materiales por impacto/riesgo/esfuerzo/dependencia y expresar fragmentos de implementación; no ejecutarlos. Cuando el conocimiento disperso del llamador, capas de reenvío, política duplicada o uniones superficiales indiquen una oportunidad de profundización, identificar la responsabilidad mal ubicada y la carga del llamador. Si seleccionar el módulo/interfaz/unión de reemplazo es en sí mismo una pregunta de arquitectura relevante, usar architect en lugar de diseñar el reemplazo dentro de pare.
Revisión
Fijar el candidato proporcionado; de lo contrario, usar el límite de cambio actual exacto. Verificar cohesión, acoplamiento, reutilización, YAGNI, vocabulario, estado inválido/duplicado, propiedad, profundidad, prueba y complejidad semántica material.
También verificar:
- desviación del alcance del cambio: subsistemas/archivos/contratos tocados que no tienen una razón concisa de comportamiento solicitado o prueba;
- expansión del alcance a través de nuevas dependencias, implementaciones paralelas, rutas de compatibilidad, abstracciones especulativas o limpieza no relacionada;
- arquitectura de producción introducida principalmente para testabilidad sin un límite de producción independientemente real;
- maquinaria de casos límite que podría desaparecer eliminando/fortaleciendo el estado o propietario causal; y
- pruebas duraderas contra unión estable, oráculo independiente, falseabilidad, prueba existente más sólida y carga de mantenimiento.
Tratar las pruebas que pasan, la cobertura, la reducción de líneas o las puntuaciones de herramientas solo como evidencia. El código demostrablemente muerto o redundante puede ser señalado como recomendación de limpieza cuando la eliminación segura esté respaldada por evidencia; su mera presencia no es un hallazgo bloqueante. Enrutar posibles defectos a atunwo; vocabulario conflictivo de proyecto/dominio a amose. Cuando un hallazgo de simplificación material requiera un nuevo diseño de módulo/interfaz/unión relevante, dejar esa forma técnica a architect y conservar solo la necesidad de simplificación respaldada por evidencia aquí.
Cuando una simplificación deliberada tenga un límite documentado/disparador de revisión, preservarla si la evidencia actual la respalda. Una limitación deliberada material sin un disparador de revisión observable es una preocupación de mantenibilidad, no una razón para fabricar un sistema de deuda separado.
Hallazgos
Usar etiquetas como delete, native, yagni, state, owner, scope, test, shrink, proof e informar:
<etiqueta> <costo/consecuencia>. <forma más pequeña>. [ubicación]
Riesgo: <riesgo material>
Prueba: <evidencia / futuro propietario de prueba>
Confianza: <nivel>
Revisar identidad, alcanzabilidad, propiedad, prueba, migración y estado relevante del espacio de trabajo antes de recomendar. Expresar verificación/ autoridad futura sin ejecutar pruebas/compilaciones o mutar.
Devolver alcance/identidad, reducciones clasificadas, contratos conservados, propietarios de prueba, bloqueadores, fragmentos de implementación, autoridad de ejecución requerida, verificación futura y riesgo residual.