Tiempo para entender un programa de LOC

Question

¿Hay reglas generales, demasiado generalizadas y en su mayoría inútiles acerca de cuánto tiempo se tardará en comprender un programa basado en el número de LOC (líneas de código)?

(entiendo las reglas serán amplios, demasiado generalizadas y sobre todo inútil. Eso está bien.)

(El idioma en cuestión es Delphi, pero eso no debería importar porque estoy en busca de reglas generales, demasiado generalizadas y en su mayoría inútiles.)

Answer 1

Algunos documentos relativos a la revisión de código pares dicen que debería estar en alguna parte entre 100 y 400 líneas de código por hora.

Answer 2

No es el número de LOC que determina el tiempo que se necesita para entender un programa, es más la complejidad.

Si mi programa tenía 100.000 líneas de declaraciones de impresión, creo que el programa es bastante claro de entender. Sin embargo, si tuviera un programa con fines de bucles anidados de diez en fondo, creo que tendrá mucho más tiempo para entender.

Ciclomática complejidad puede dar una indicación BRUTO de la fuerza con la código es de entender, y puede señalar algunas otras banderas de advertencia, así acerca de su código.

Answer 3

Tengo la teoría de que es O (n ² ) (porque hay que entender cada línea en conjunto con cada línea).

Pero, como es habitual cuando se usa la notación de orden O para obtener un valor numérico real, esta respuesta es amplia, demasiado generalizadas y sobre todo inútil.

Answer 4

No se puede buscar en Google esto porque habrá un número aproximado de programación diferente para cada persona individual en un idioma específico.

Usted está tratando de escribir el de Drake ecuación para la escritura del programa.

Esto es lo que quiero decir.

Sobre los escritores del programa.

• cada persona tiene un estilo diferente de escritura y código de comentar
• cualquier lenguaje de programación tiene diferentes matices y la legibilidad
• algoritmos se pueden implementar de muchas maneras, incluso en el mismo idioma
• estructuras de datos utilizadas por diferentes personas tienden a ser bastante variada
• la decisión de cómo el código se distribuye en los archivos de origen también cambia con el gusto personal

Mover a la persona que lee el código.

• la familiaridad de la persona con las cuestiones de idioma
• familiaridad con los algoritmos y los patrones de la estructura de datos utilizados asuntos
• cantidad de información de contexto que la persona puede retener en un tiempo es importante

El cambio de enfoque para el medio ambiente, las cosas que importan sería.

• la cantidad de distracción (tanto para el programador y la persona que intenta leer el programa)
• cercanía a tiempo de liberación de código para el programador
• actividades y motivación pendiente en la parte del lector
• proximidad de eventos populares (vacaciones, eventos deportivos, fechas de lanzamiento de la película!)

Answer 5

métricas de la revisión de códigos (que no es la misma cosa, pero casi comparable) ponen el número en el intervalo de aproximadamente 50-100 LoC por hora, para un revisor código experimentado.

Por supuesto, esto depende también de lo que están buscando en la revisión, el idioma, la complejidad, la familiaridad, etc .... Pero que te pueden dar una generalización excesiva general, de todos modos.

Answer 6

  

Busco reglas generales, demasiado generalizadas y en su mayoría inútiles.

Me parece que usted está tratando de encontrar una manera de estimar el tiempo que se necesita para aprender un nuevo código base a la gestión o algo así. En ese caso, encontrar un fragmento de código en línea, y medir el tiempo que le lleva a entenderla. Dividir por el número de líneas en el fragmento. Añadir un poco de relleno. Bam! Ahí está su regla.

Answer 7

Mira las COCOMO ecuaciones. Contienen reglas generales, demasiado generalizadas y en su mayoría inútiles basado en Fuente líneas de código.

Answer 8

Además de "cómo complicado es el programa?", Otras variables incluyen cosas como "¿cómo y Qué entiende él?" y "¿qué tan bien entiende otro cosas, como las especificaciones funcionales del programa?"

Cuando comienzo a trabajar con un nuevo programa, trato de entender como poco de ella como sea posible! Específicamente Intento:

• Comprender la especificación funcional del cambio que alguien quiere que yo haga (si nadie quería que cambiar el programa, entonces no tendría que entenderlo en absoluto)

• Buscar y comprender el más pequeño subconjunto posible del programa existente, lo que me deja hacer ese cambio sin romper ninguna otra, la funcionalidad anterior / existente.