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

12

Un amigo mío y yo estábamos discutiendo ayer sobre las diferencias entre escribir un gran software de 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 parece a cómo los humanos aprendemos y construimos una cosa sobre otra, escribir un software grande es realmente más fácil que leerlo y entenderlo? ¿Qué hace (repasar el código ayuda pero necesita recordar varias clases / archivos de origen juntos, ni siquiera sabe para qué se han escrito, el código de multiproceso agrega puntos de malus)?

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

    
pregunta Makane Elhay 07.06.2013 - 16:14

8 respuestas

40

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. Escribiendo código malo
  3. Escribiendo buen código
  4. Leyendo código malo

El ranking anterior lleva a 2 conclusiones

  1. Si bien es más fácil escribir un código que leer un código incorrecto, es más fácil leer un buen código que escribir su propio código
  2. Escribir un código incorrecto es más fácil que escribir un buen código, pero escribir un código incorrecto te ayuda a leer un código incorrecto, que es lo más difícil de todo. Sobre todo porque el código malo se lee más de lo que está escrito.

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

    
respondido por el Aaron Kurtzhals 07.06.2013 - 16:39
13

Esta pregunta apela a un falso consenso. enlace

Diferentes personas aprenden y absorben información de manera diferente. Es similar a los aprendices auditivos, visuales y cinesté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 utilizar ese conocimiento para mejorar y aprender a aceptar a otros que son diferentes.

    
respondido por el mawcsco 07.06.2013 - 16:44
7
  

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

Esto no es lo mismo que la diferencia entre la lectura y la escritura del software. 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 la empresa y cómo el proyecto se relaciona con el resto de la organización. En resumen, leer el código sin el conocimiento previo es una tarea más lenta y difícil que leer el código cuando comprendes completamente el contexto en el que funciona el código.

Hay una diferencia entre escribir un código completamente nuevo en un proyecto greenfield y leyendo y modificando el código existente, pero no diría que uno es necesariamente más fácil que el otro, solo diferente. Cuando está creando algo nuevo, no tiene que preocuparse por cómo hacer que su código funcione con lo que ya está allí, 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 estás trabajando en un proyecto existente, a menudo puedes usar lo que ya está allí como una guía, pero primero debes entender lo que hay.

Como un "nuevo recluta", generalmente es mejor trabajar en un proyecto existente específicamente porque le ayuda a aprender todo lo que no sabe: cómo funciona la empresa, cómo trabajan en conjunto los distintos proyectos, los estándares de codificación y las prácticas. , e incluso (especialmente) lo que podría mejorarse.

    
respondido por el Caleb 07.06.2013 - 17:43
4

Es una pregunta interesante, pero tiendo a inclinarme hacia un lado porque es más fácil de leer y entender que crearla.

Si usted es un programador veterano y experimentado, entonces es probable que lea el código y diga "Sí, buena elección, verifique, oh, podría haber hecho X en lugar de Y", etc. Puede modificar o modificar, pero eso ahorraría un tiempo inmenso en la escritura 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 cosas pequeñas, y es muy probable que tengas algo. 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.

    
respondido por el JohnP 07.06.2013 - 16:24
2

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 mencionaste, como a una cuestión de estilo y talento individual. Por eso 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 realizar mejoras?

Cuando comienzas a leer el código, puedes pensar en varias formas de hacer que el código sea más fácil para ti. Pasa el primer tiempo solo rastreando el código, tratando de descubrir el terreno, a veces en una arquitectura completamente anatómica a cómo le gustaría hacerlo. Pero incluso en bases de código realmente grandes, pasará quizás de 40 a 80 horas haciendo girar sus ruedas, en comparación con los cientos de miles de horas de trabajo ya invertidas en la creación de esa aplicación.

    
respondido por el Karl Bielefeldt 07.06.2013 - 17:39
1

La persona que escribe la pieza de software casi siempre tendrá la mejor comprensión del programa, simplemente sabiendo la lógica y su proceso de pensamiento al escribirlo.

No creo que la escritura de código se pueda comparar con la lectura de códigos en términos de facilidad de comprensión. Por un lado, simplemente escribir software proporciona una mayor comprensión de esa pieza específica de software 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 real del software, 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 tal vez no haya considerado usar, lo que puede ayudar a facilitar la escritura del código de su vida.

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

    
respondido por el StMotorSpark 07.06.2013 - 16:30
1

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

Esto lleva a la pregunta: ¿esto importa?

Si estás leyendo el código, es probable que estés haciendo un cambio en lugar de reescribirlo. Incluso si está reescribiéndolo, 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 estoy señalando es que no siempre es necesario entender todo el código todo el tiempo.

Todo esto es cierto, nuevas metodologías de desarrollo, p. ej. BDD reconocen que es importante que la lógica empresarial esté clara en el código en lugar de que el código sea simplemente un significa conducir la máquina. Esto, por supuesto, no es nada nuevo; el concepto ha existido desde el trabajo seminal de Donald Knuth: Programación Literate .

    
respondido por el Robbie Dee 07.06.2013 - 16:30
1

Estoy en la respuesta de StMotorSpark, simplemente agregando:
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 te cuesta mucho tiempo encontrar una solución o una aplicación más grande pero simple?
  • etc.
respondido por el JoseTeixeira 07.06.2013 - 16:44

Lea otras preguntas en las etiquetas