¿Cómo logran las personas escribir y mantener código extremadamente complejo y difícil de leer? [cerrado]

Leer el código fuente de SQLite es una misión IMO imposible. Sin embargo, es una pieza utilizable de software bastante complejo (después de todo, es una base de datos integrada completa) que se puede descargar, compilar y usar desde el código de otros y se actualiza constantemente.

¿Cómo logran las personas escribir y mantener un código tan extremadamente complejo y difícil de leer?

Hay una gran diferencia entre complejo y complicado. El siguiente enlace sobre lo resume. :)

http://codebetter.com/blogs/dru.sellers/archive/2009/09/25/complex-vs-complicated.aspx

En una nota más personal, trabajo en una base de código de más de 1 millón de líneas de código. He estado en él desde la línea 1 hasta su estado actual. Cuanto más agrícola sea (lea más tiempo en el código), más fácil se vuelve. No puedo decirte qué hace cada línea, pero puedo decirte que debías comenzar a buscar una tarea o error determinado. Simplemente viene de forma natural.

La moraleja de la historia es que, como cualquier cosa en el mundo de la programación, lleva tiempo. Si espera mirar SQLite y simplemente conocerlo y comprenderlo, se está engañando a sí mismo. Va a tomar tiempo descubrir cómo funciona todo junto. La diferencia entre el código bueno y el código malo es cuánto tiempo lleva ese proceso.

Por último, algunos desarrolladores no tienen la capacidad de saltar a una base de código y comenzar a resolverlo. Muchos se sentirán abrumados por el tamaño o la arquitectura de la base del código. Otros no tendrán problemas simplemente saltando en él. Todo depende de las fortalezas de los desarrolladores.

En el caso específico de SQLite, la herramienta principal que han elegido usar en el desarrollo y mantenimiento son las pruebas automatizadas. Se enorgullecen de tener una cobertura del 100% (cobertura de sucursal, no cobertura de estado de cuenta) en su conjunto de pruebas. Según ellos, es uno de los productos de software mejor probados del mundo. Entonces saben de inmediato cuando algo que han agregado o cambiado causa una regresión, y pueden desarrollarse sin miedo como resultado de eso.

http://sqlite.org/testing.html

Números bastante asombrosos: tienen alrededor de 640 veces más líneas de código de prueba que de código de producción.

EDITAR: ¡Esta pregunta ha surgido de entre los muertos, parece! ¡Y poco más de un año después, esa misma página informa que tienen 1177 veces más líneas de código de prueba que producción!

• Las funcionalidades evolucionan con el tiempo.
  • Las nuevas funcionalidades son impulsadas por los nuevos requisitos del cliente.
  • El código antiguo se escribió de una manera que permite agregar funcionalidades futuras aún por implementar sin romper el código antiguo.
• expertos en dominios (en este caso, la base de datos es un dominio bien conocido en informática).
• comentarios de la comunidad
  • loco
• La curva de aprendizaje empinada no fue un problema para los bien preparados y perseverantes. Puede tomar 6 meses, 1 año o incluso más para sentirse cómodo, y eso es lo que algunas personas pueden soportar.
• Motivaciones comerciales. sin apoyo monetario, muy pocas personas pueden invertir el tiempo y la energía en la curva de aprendizaje empinada.

No necesita tener una comprensión íntima de todo el proyecto para poder mantenerlo. Por lo general, con un software grande y complejo, las personas tendrán sus propias "áreas" particulares que cuidarán y solo tendrán un conocimiento "pasajero" del resto del sistema.

SQLite es en realidad relativamente pequeño en la escala de "grandes proyectos de software", pero si observa algo como el sistema operativo Windows, tendrá personas que solo trabajan en el núcleo, personas que solo trabajan en el shell, personas que simplemente trabajan en Internet Explorer, las personas que solo trabajan en el administrador de Windows, etc. Alguien que trabaja en el "shell" no podrá corregir un error en el kernel en un abrir y cerrar de ojos.

También existe el beneficio de que estos proyectos evolucionan con el tiempo: no siempre comenzaron tan complicados. Eso significa que un desarrollador nuevo generalmente puede ser "entrenado" por desarrolladores más experimentados.

Cuando se une a un gran equipo de desarrolladores, se le dará un aspecto particular del proyecto en el que trabajar (tal vez un error o una nueva característica) y tendrá otro desarrollador que sea su "amigo" durante las primeras iteraciones. Tu amigo comprenderá bien el área en la que estás trabajando y puede ayudarte a orientarte.

Para proyectos de código abierto como SQLite, en realidad es un poco más difícil porque no hay motivación para que los desarrolladores existentes "capaciten" a los nuevos desarrolladores. Entonces descubrirás que estás solo un poco más. Pero aún puede encontrar ayuda en foros de desarrolladores o listas de correo (por ejemplo, simplemente publicando una pregunta como "Me gustaría implementar tal y tal característica" o "Encontré el error XYZ, ¿dónde empiezo a buscar?" Y es probable que obtenga alguna forma de ayuda

Hay una diferencia entre proyecto difícil de leer y complejo. Si una persona no comprende profundamente el idioma en que se escribió el proyecto o el dominio del proyecto, no significa que el código esté mal escrito.

Mi consejo:

• Asegúrese de entender el idioma del proyecto. No es suficiente saber el idioma.
• Conozca todos los detalles sobre el dominio antes de poner el código en sus manos.

Para mí, SQLite está lejos de ser complejo y nada complicado. El dominio de este proyecto exige una comprensión profunda sobre conceptos amplios.

Una cosa que no se menciona en las otras respuestas es "Es algo natural para ellos". La mayoría de la gente quiere escribir un buen código, pero están sintonizados para escribir un código malo. Algunos de los programadores que he conocido son, naturalmente, pensadores LINEALES + algunas veces, muy ingeniosamente, encuentran soluciones complejas. La mayoría de esas personas no pasan tiempo leyendo o aprendiendo del libro que aprenden cuando el trabajo lo exige.

¿Cómo logran las personas escribir y mantener un código tan extremadamente complejo y difícil de leer?

Si son los codificadores originales y siguen manteniéndolo, no lo ven como "complejo y difícil de leer". Probablemente lo vean como "simple y fácil de leer", ya que lo escribieron ellos mismos.

Cualquier código lleva tiempo para entenderlo. Es solo que algunos tardan más que otros :)

Puede comprender cualquier base de código si tiene: perseverancia, paciencia y un enfoque metódico, pero principalmente perseverancia :-)

La gestión se vuelve mucho más fácil si se hacen las cosas siempre de la misma manera. No conozco el código SQLite, pero estoy trabajando en un entorno donde hay múltiples proyectos. Además de comprender el caso de negocio (lógica de ecualización), ya que todo se hace básicamente de la misma manera en todas partes (acceso a la base de datos, etc.) es relativamente fácil comenzar a trabajar en otro proyecto. Texto largo corto: las pautas de codificación, de manera apropiada, hacen que la vida y dicho código sean mucho más fáciles. Este podría ser uno de los ayudantes para los codificadores SQLite.

• Si usted es el autor original del software, y ha trabajado con él durante más de 10 años, y es un genio, es posible que pueda comprenderlo todo. Las grandes piezas de software complejo (como SQLite o el kernel de Linux) generalmente tienen exactamente un autor original que tiene una comprensión completa y profunda de él, incluso si otras personas han contribuido.
• Si la arquitectura del software es sensata (alta cohesión, bajo acoplamiento), comprender todo esto no es un requisito previo para realizar adiciones y modificaciones útiles.
• Comprender un RDBMS o un SO son casos algo especiales, que requieren una comprensión profunda de los principios subyacentes de CS. No es así con las aplicaciones de software "ordinarias".

Intentan escribirlo de una manera simple pero no simplista.

Ir lo más simple posible hace que las cosas sean más rápidas de entender / leer, incluso si puede tomar algo de tiempo.

El algoritmo que se está implementando establece un límite inferior de cuán simple puede ser el código para una implementación. Si una descripción abstracta del algoritmo que se implementará es extremadamente complicada y requiere que toneladas de datos diferentes se acoplen entre sí, entonces el código que implementa dicho algoritmo no puede ser simple, sin importar quién lo escriba.

En otras palabras, una razón por la que a veces escribo código inescrutable es porque, dado el algoritmo que quiero implementar, no tengo otra opción.