| Formatted contents note |
Introducción, código limpio: hágase el código limpio, código incorrecto, el coste total de un desastre, el gran cambio de diseño, actitud, el arte del código limpio, concepto de código limpio, escuelas de pensamiento, somos autores, la regla del boy scout, precuela y principios, conclusión, nombres con sentido: introducción, usar nombres que revelen las intenciones, evitar la desinformación, realizar distinciones con sentido, usar nombres que se puedan pronunciar, evitar codificaciones, evitar asignaciones mentales, nombres de clases, nombres de métodos, no se exceda con el atractivo, una palabra por concepto, no haga juegos de palabras, usar nombres de dominio de soluciones, usar nombres de dominio de problemas, añadir contexto con sentido, no añadir contextos innecesarios, conclusión, funciones: tamaño reducido, hacer una cosa, un nivel de abstracción por función, instrucciones switch, usar nombres descriptivos, argumentos de funciones, sin efectos secundarios, separación de consultas de comando, mejor excepciones que devolver códigos de error, no repetirse, programación estructurada, cómo crear este tipo de funciones, conclusión, setupteardownincluder, comentarios: los comentarios no compensan el código incorrecto, comentarios de calidad, comentarios incorrectos, formato: la función del formato, formato vertical, formato horizontal, objetos y estructuras de datos: abstracción de datos, antisimetría de datos y objetos, la ley de Demeter, objetos de transferencia de datos, conclusión, procesar errores: usar excepciones en lugar de códigos devueltos, crear primero la instrucción try catch finally, usar excepciones sin comprobar, ofrecer contexto junto a las excepciones, definir clases de excepción de acuerdo a las necesidades del invocador, definir el flujo normal, no devolver null, no pasar null, conclusión, límites: utilizar código de terceros, explorar y aprender límites, aprender log4j, las pruebas de aprendizaje son algo más que gratuitas, usar código que todavía no existe, límites limpios, pruebas de unidad: las tres leyes del DGP, realizar pruebas limpias, pruebas limpias, una afirmación por prueba, F.I.R.S.T, conclusión, clases: organización de clases, las clases deben ser de tamaño reducido, organizar los cambios, sistemas: cómo construir una ciudad, separar la construcción de un sistema de su uso, evolucionar, proxies de java, estructuras AOP java puras, pruebas de unidad de la arquitectura del sistema, optimizar la toma de decisiones, usar estándares cuando añadan un valor demostrable, los sistemas necesitan lenguajes específicos del dominio, conclusión, emergencia: limpieza a través de diseños emergentes, primera regla del diseño sencillo, reglas de 2 a 4 del diseño sencillo, eliminar duplicados, expresividad, clases y métodos mínimos, conclusión, concurrencia: por qué concurrencia, desafíos, principios de defensa de la concurrencia, conocer las bibliotecas, conocer los modelos de ejecución, dependencias entre métodos sincronizados, reducir el tamaño de las secciones sincronizadas, crear código de cierre correcto es complicado, probar código con procesos, conclusión, refinamiento sucesivo: implementación de Args, Args: el primer borrador, argumentos de cadena, aspectos internos de JUnit: la estructura de JUnit, conclusión, refactorización de serialdate: primero, conseguir que funcione, hacer que sea correcta, conclusión, síntomas y heurística: comentarios, entorno, funciones, general, java, nombres, pruebas (test), conclusión. |
