En los últimos meses, vi a alguien recomendar este libro y, después de leerlo, sentí que los puntos clave estaban resumidos en su lugar y que tiene una gran importancia como guía y una referencia práctica para el trabajo diario. Escribir libros de extranjeros es bastante extenso, por lo que haré un breve resumen de lectura. Hay traducciones al chino en Internet , pero aun así recomiendo que lea la versión original. La experiencia de lectura en inglés de este libro es bastante agradable. No es el tipo de inglés avanzado con gramática oscura, oraciones largas y circuitos cerebrales anudados.
El autor de este libro, John Ousterhout, es el inventor del lenguaje Tcl y el protocolo Raft, y tiene una amplia experiencia en el mundo académico y la industria. Por lo tanto, este libro no es de ninguna manera una conferencia teórica, sino un alto grado de combinación de práctica y teoría.
El contenido central de este libro es decirle que la complejidad es el problema central del diseño de sistemas de software. Un mal diseño conducirá a una explosión de la complejidad del sistema, lo que generará una serie de problemas, como mayores costos de mantenimiento, menor rendimiento y operación inestable. . Para resolver el problema de la complejidad, primero debe saber cómo identificar los factores que harán que aumente la complejidad y luego qué medios se pueden utilizar para reducir la complejidad recurriendo a la referencia.
Algunas conclusiones de mi lectura personal:
- La complejidad del software se acumula con el tiempo, y si solo se parchea, algún día se saldrá de control. Puede tolerar un mal diseño al principio, pero luego intente optimizarlo un poco cada vez. Pero no pienses en las grandes noticias en todo momento, después de todo, también se debe considerar la estabilidad del negocio y la entrada y salida. Tienes que pensar en ello todo el tiempo, si todo es a corto plazo, la complejidad se te va de las manos.
- Los módulos y las clases tienen profundidad. Creo que este problema es particularmente obvio en el marco de Java, que es capa por capa. En teoría, es orientado a objetos, reutilizable y reemplazable, pero para el 99% de las aplicaciones, este requisito no existe en absoluto. Un módulo o clase, o incluso una función, resuelve un problema completo. Si se puede atomizar, no lo divida por dividir.
- Ocultación de información. Lo que debe exponerse en el nivel de la interfaz es qué hacer, y cómo hacerlo se deja en el nivel de implementación. La complejidad es lo más baja posible, y la persona que llama a la interfaz no debe pensar en ello, ni debe preocuparse por los detalles de la implementación subyacente.
- Intente proporcionar comportamientos predeterminados para escenarios comunes y no permita que los usuarios los entiendan por sí mismos. El siguiente código Java me está volviendo loco, por eso no me gusta Java. Ya sea C, C++ o Python, nunca había visto una forma tan complicada de escribir para operar un archivo.
FileInputStream fileStream = new FileInputStream(fileName); BufferedInputStream bufferedStream = new BufferedInputStream(fileStream); ObjectInputStream objectStream = new ObjectInputStream(bufferedStream); - No sobrediseñe el manejo de errores. Definir errores fuera de existencia ¿Realmente no sé cómo traducir para excluir errores innecesarios? El inglés es bueno para señalar. Los errores que el programa puede digerir deben ser digeridos por sí mismo y no arrojados al usuario. Por ejemplo, el reintento y la reescritura automáticos y las situaciones extremas que no se pueden manejar se acostarán en el acto, porque el usuario no sabe qué hacer en este momento. Aquí hay un ejemplo de Java, subString no es un buen diseño. Si el rango del índice no coincide, devolver una cadena vacía puede resolver la mayoría de los problemas y se debe lanzar una excepción IndexOutOfBoundsException. No arrojes errores a los usuarios para que los manejen, muchas veces los usuarios no saben cómo lidiar con ellos.
- Escribe comentarios, los comentarios deben ser útiles, para explicar cosas que no son fáciles de entender, no para traducir el código. Se recomienda escribir comentarios primero para que pueda concentrarse más en lo que está tratando de hacer. De lo contrario, después de escribir el código, la idea se solidificará y se convertirá en un comentario alrededor del código, y se convertirá en una cola que mueve al perro. El código debe comentarse tanto como sea posible, y una cosa debe escribirse claramente en un solo lugar. Si no funciona, se recomienda utilizar notas de diseño para la gestión centralizada. Por ejemplo, escribe un wiki, o en otro lugar, haz referencia a XXX en las notas.
- La coherencia, la denominación, el estilo de código y la lógica de procesamiento son lo más uniformes posible. Incluso un bajo nivel de unificación es mejor que separarse. Trate de no cambiar el estándar de consistencia a menos que haya una ganancia significativa. De lo contrario, unificar la consistencia de los sistemas existentes tiene un costo muy alto. Si la consistencia antigua y la nueva no son compatibles, causará más problemas.
- El desarrollo basado en pruebas es una proposición falsa. Estoy muy de acuerdo con este punto. La mayoría de las personas simplemente no tienen la capacidad de escribir casos de uso primero y luego codificar. Además, es imposible escribir el caso de uso correctamente al mismo tiempo, pero si el caso de uso está ahí, el código habrá pasado la prueba durante el desarrollo, lo que a menudo conduce a parches. Pero hay una situación en la que primero se deben escribir los casos de uso, que es tratar con el legado histórico. Los escenarios comerciales compatibles con el código actual y todas sus conjeturas sobre las funciones del código deben ser compatibles con los casos, de modo que pueda verificar rápidamente si las funciones existentes se ven afectadas después de que se complete la modificación.
- El rendimiento es una consideración de diseño. Priorice la ruta crítica al optimizar el rendimiento y cómo implementar la ruta crítica con el código menos y más eficiente. Esta no es la regla del 82, muchas veces es del 95% (o incluso más) del camino crítico al 5% del camino anormal. Incluso si el costo de la ruta anormal aumenta en un 100 %, el costo de la ruta crítica se puede reducir solo en un 20 % y el costo total se puede reducir en aproximadamente un 15 %.
- El principio más importante es matar tu primer pensamiento. Piense en al menos dos opciones, y solo cuando tenga una opción podrá compararlas.
Después de leer este libro, tengo dos sentimientos:
- Java es un lenguaje de programación para empresas de consultoría y empresas de subcontratación. Nací en un buen momento para ponerme al día con el gran salto adelante de Internet y atrapado en un nicho ecológico importante. Se siente como si hubiera pasado medio día escribiendo una función en PHP, y Java no ha terminado de escribir el código básico relacionado. al marco.
- Si realmente eres un programador que persigue la tecnología, evita los siguientes dos tipos de lugares: 1) el departamento de I+D de información de las empresas tradicionales, que se tira a la montaña de mierda todos los días, y el sabor permanece sin cambios durante miles de años; 2) El departamento de negocios de una gran fábrica, disfruta plenamente de la introversión extrema de 99.99 a 100, aunque está tirando en la montaña de mierda todos los días, pero acepta los cambios, ocasionalmente disfruta el sabor y ocasionalmente se pone en cuclillas en un nuevo hoyo. Sería una mejor opción ir a una empresa de tecnología dura o una empresa nueva con un rápido crecimiento comercial, lo que le dará la oportunidad de practicar la mayor parte del contenido de este libro.