¿Escribir software es más fácil que leerlo y entenderlo desde cero? [cerrado]

Un amigo mío y yo estábamos discutiendo ayer sobre las diferencias entre escribir un gran software C ++ y entenderlo como un nuevo recluta.

¿Es posible que, dado que un software se realiza una línea a la vez y este proceso se asemeja a cómo nosotros (los humanos) aprendemos cosas y construimos una cosa sobre otra, escribir un software grande es realmente más fácil que leerlo y entender lo que hace? (recorrer el código ayuda, pero necesita recordar varias clases / archivos fuente juntos, ni siquiera sabe para qué se han escrito, el código multiproceso agrega puntos de cálculo).

Esto suena extraño al principio, pero después de pensar un poco, parecía razonable

Según mi experiencia, clasificaría las siguientes actividades en orden de la más fácil a la más difícil.

1. Leyendo buen código
2. Escribir código incorrecto
3. Escribiendo buen código
4. Leer código malo

La clasificación anterior lleva a 2 conclusiones

1. Si bien es más fácil escribir código que leer código incorrecto, es más fácil leer código bueno que escribir su propio código
2. Escribir código incorrecto es más fácil que escribir código bueno, pero escribir código incorrecto lo prepara para leer código incorrecto, que es lo más difícil de todo. Sobre todo porque el código incorrecto se lee más de lo que se escribe.

Por supuesto, el código bueno y el código malo son generalizaciones amplias. Recomiendo Code Complete y Clean Code para más detalles sobre un buen código.

Esta pregunta apela a un falso consenso. http://en.wikipedia.org/wiki/False-consensus_effect

Diferentes personas aprenden y absorben información de manera diferente. Es similar a los estudiantes auditivos, los estudiantes visuales y los estudiantes cinéticos. Para algunos, leer código es más fácil, para otros, crear código es más fácil. Para mí, es lo último. Para otros en mi equipo, es el primero. No creo que sea útil encontrar algún tipo de consenso o mayoría. Es mejor entender cómo su cerebro absorbe y aprende información y usa ese conocimiento para mejorar y aprender a aceptar a otros que son diferentes.

diferencias entre escribir un gran software C ++ y entenderlo como un nuevo recluta

Esto no es lo mismo que la diferencia entre el software de lectura y escritura. Cuando eres nuevo en un proyecto (y especialmente cuando eres nuevo en una empresa) tienes mucho más que aprender que solo lo que hace el código. Comprender por qué el código hace lo que hace a menudo requiere una comprensión de cómo funciona el negocio y cómo el proyecto se relaciona con el resto de la organización. En resumen, leer el código sin el beneficio del conocimiento de fondo es una tarea más lenta y más difícil que leer el código cuando se comprende completamente el contexto en el que funciona el código.

No es una diferencia entre escribir nuevo código en un proyecto de nueva creación y la lectura y modificación de código existente, pero yo no diría que uno es necesariamente más fácil que el otro, simplemente diferente. Cuando crea algo nuevo, no tiene que preocuparse por cómo hacer que su código funcione con lo que ya existe, pero sí tiene que preocuparse por hacer que su proyecto sea lo suficientemente extensible y adaptable para que siga siendo útil en el futuro . Cuando trabajas en un proyecto existente, a menudo puedes usar lo que ya está allí como guía, pero primero debes entender lo que está allí.

Como "nuevo recluta", generalmente es mejor trabajar en un proyecto existente específicamente porque te ayuda a aprender todo lo que no sabes: cómo funciona el negocio, cómo funcionan los diversos proyectos juntos, codificando estándares y prácticas, e incluso (especialmente) lo que podría mejorarse.

Es una pregunta interesante, pero tendería a inclinarme hacia un lado para que sea más fácil de leer y entender que crearla.

Si usted es un programador veterano y experimentado, es probable que lea el código y diga "Sí, es una buena opción, compruebe, oh, podría haber hecho X en lugar de Y", etc. Puede modificar o modificar, pero eso sería Ahorre tiempo inmenso al escribir desde cero (a menos que haya razones para hacerlo)

Si eres un programador más nuevo, entonces "no sabes lo que no sabes", por lo que tendrás que inventar / aprender todas las pequeñas cosas, y es muy probable que tengas algunas ineficiencias en el código. Sin embargo, es probable que desarrolles una mayor comprensión del idioma.

Pero en ambos casos, será más fácil leer el código e ir desde allí que escribirlo completamente desde cero.

A la mayoría de los programadores les resulta más fácil entender el código que escribieron ellos mismos en comparación con el código que escribieron otras personas. Esto se debe tanto al aprendizaje línea por línea que mencionó, como a una cuestión de estilo y talento individual. Es por eso que ocurre tanta reinvención de la rueda.

Sin embargo, esa es la vista de los árboles. La vista del bosque es que es mucho más fácil leer el código que escribirlo desde cero. Por ejemplo, ¿es más fácil escribir un nuevo procesador de textos desde cero o aprender una base de código existente lo suficientemente bien como para hacer mejoras?

Cuando comience a leer el código, puede pensar en miles de millones de maneras de facilitar la lectura del código. Pasas el primero mientras trazas el código, tratando de descubrir la disposición de la tierra, a veces en una arquitectura completamente anatema de cómo te gustaría hacerlo. Pero incluso en bases de código realmente grandes, pasará unas 40-80 horas haciendo girar sus ruedas, en comparación con los cientos de miles de horas hombre que ya se invirtieron en la creación de esa aplicación.

La persona que escribe el software casi siempre tendrá la mejor comprensión del programa simplemente porque conoce la lógica y su proceso de pensamiento mientras lo escribe.

No creo que escribir código pueda compararse en absoluto con leer código en términos de facilidad de comprensión. Por un lado, simplemente escribir software proporciona una mayor comprensión de ese software específico debido al conocimiento del contexto asociado con cada sección de código, biblioteca utilizada, etc. Sin embargo, leer el código que otros han escrito puede ser difícil de entender en términos de la pieza de software real, pero en términos de comprensión del lenguaje, puede proporcionar información sobre nuevas formas de hacer cosas o usos de una biblioteca que quizás no haya considerado usar, lo que puede hacer que su vida sea más fácil escribir código.

En términos de conocimiento de construcción, creo que la lectura de código y la escritura de código están muy conectadas y, en muchos sentidos, se basan entre sí. La experiencia en la escritura de códigos facilita la comprensión del código de otros, y la lectura del código le permite tener más facilidad para escribir el código (a través de nuevos conceptos lógicos, uso de la biblioteca, etc.).

Esto es algo que personalmente he sentido evidente, pero nunca he estado completamente seguro de que sea válido para toda la población de programación. Por ejemplo, he conocido a codificadores muy talentosos que, en lugar de leer la documentación, pueden leer el código de otras personas y comprenderlo como si fuera propio.

Esto lleva a la pregunta: ¿importa esto?

Si está leyendo el código, entonces es probable que esté haciendo un cambio en lugar de reescribirlo. Incluso si lo está reescribiendo, es probable que esté escribiendo esto en un nuevo idioma / versión y, por lo tanto, no necesariamente cree el código de la misma manera. Lo que quiero decir es que no siempre es necesario entender todo el código todo el tiempo.

Todo esto es cierto, las nuevas metodologías de desarrollo, por ejemplo, BDD , reconocen que es importante que la lógica de negocios sea clara desde el código en lugar de que el código sea simplemente un medio para conducir la máquina. Por supuesto, esto no es nada nuevo: el concepto ha existido desde el trabajo seminal de Donald Knuth: la programación literaria .

Estoy en la respuesta de StMotorSpark, solo agrego:
depende de tantos factores que no puede ser una pregunta de sí o no, por ejemplo:

• ¿El código existente está bien documentado y bien escrito o parece un espagueti sin ningún sentido o comentario?
• ¿Es una aplicación pequeña con situaciones muy raras que le cuesta un tiempo infinito para encontrar la solución, o una aplicación más grande pero simple?
• etc.