metrics - mítico - el mitico hombre mes capitulo 2
Mítico hombre mes 10 líneas por día desarrollador: ¿qué tan cerca están en grandes proyectos? (15)
¿Cómo están otras personas?
Soy el único desarrollador a tiempo completo en nuestra empresa y he escrito 500,000 líneas de código OCaml y F # en los últimos 7 años, lo que equivale a cerca de 200 líneas de código por día. Sin embargo, la gran mayoría de ese código son ejemplos de tutoriales que consisten en cientos de proyectos separados, cada uno de unos pocos cientos de líneas de largo. Además, hay mucha duplicación entre OCaml y F #. No mantenemos ninguna base de código interno mayor que 50kLOC.
Además de desarrollar y mantener nuestro propio software, también he consultado a muchos clientes de la industria durante los últimos 7 años. Para el primer cliente , escribí 2.000 líneas de OCaml durante 3 meses, que son 20 líneas de código por día. Para el próximo cliente , cuatro de nosotros escribimos un compilador que generó millones de líneas de código C / C ++ / Python / Java / OCaml, así como documentación en 6 meses, que es de 2.000 líneas de código por día por desarrollador. Para otro cliente, reemplacé 50kLOC de C ++ con 6kLOC de F # en 6 meses, lo que equivale a -352 líneas de código por día. Para otro cliente más , estoy reescribiendo 15kLOC de OCaml en F #, que tendrá el mismo tamaño y 0 líneas de código por día.
Para nuestro cliente actual , reemplazaré 1,600,000 líneas de código C ++ y Mathematica con ~ 160kLOC de F # en 1 año (escribiendo un compilador a medida) que serán -6,000 líneas de código por día. Este será mi proyecto más exitoso hasta la fecha y le ahorrará a nuestro cliente millones de dólares al año en costos continuos. Creo que todos deberían intentar escribir -6,000 líneas de código por día.
Todo el mundo siempre dice que puede vencer a las "10 líneas por desarrollador por día" del "Mes del hombre mítico", y al comenzar un proyecto, normalmente puedo obtener un par de cientos de líneas en un día.
Pero en mi anterior empleador, todos los desarrolladores eran muy astutos, pero era un proyecto grande, más de un millón de líneas de código, con requisitos de certificación muy onerosos e interconectados con otros proyectos de líneas de millones de dólares. En algún momento, como un ejercicio de curiosidad, tracé líneas de código en el producto de envío de mi grupo (sin contar las herramientas que desarrollamos), y de hecho, incrementalmente, llegó a alrededor de 12 líneas de agregación neta por desarrollador por día. Sin contar los cambios, el código de prueba o el hecho de que los desarrolladores no estaban trabajando en el código del proyecto real todos los días.
¿Cómo están otras personas? ¿Y a qué tipo de requisitos se enfrenta (me imagino que es un factor)?
Buena planificación, buen diseño y buenos programadores. Obtienes todo eso junto y no pasarás 30 minutos para escribir una línea. Sí, todos los proyectos requieren que te detengas y planees, pienses, discutas, pruebes y depure, pero en dos líneas por día, cada compañía necesitaría un ejército para hacer que tetris trabaje ...
En pocas palabras, si estuvieras trabajando para mí en 2 líneas por horas, será mejor que me consigas un montón de cofres y mis mensajes para que no te despidan.
Creo que el número de líneas agregadas depende en gran medida del estado del proyecto, la tasa de adición a un nuevo proyecto será mucho más alta que la tasa de un proyecto inicial.
El trabajo es diferente entre los dos: en un proyecto grande, generalmente pasas la mayor parte del tiempo calculando las relaciones entre las partes, y solo una pequeña cantidad para realmente cambiar / agregar. mientras que en un nuevo proyecto, escribes principalmente ... hasta que es lo suficientemente grande y la tasa disminuye.
Creo que el tamaño del proyecto y la cantidad de desarrolladores involucrados son factores importantes en esto. Estoy muy por encima de esto en mi carrera, pero he trabajado solo todo ese tiempo, por lo que no hay inconveniente en trabajar con otros programadores.
Creo que esto viene de los días de desarrollo de la cascada , donde la fase de desarrollo real de un proyecto podría ser tan poco como 20-30% del tiempo total del proyecto. Tome el total de líneas de código y divida por todo el tiempo del proyecto y obtendrá alrededor de 10 líneas / día. Divida solo por el período de codificación, y se acercará a lo que las personas están citando.
Debe dejar de usar esta métrica, no tiene sentido en su mayor parte. La cohesión, el acoplamiento y la complejidad son métricas más importantes que las líneas de código.
En uno de mis proyectos actuales, en algunos módulos, me enorgullece haber contribuido con un conteo negativo de líneas a la base de códigos. Identificar qué áreas de código han crecido complejidad innecesaria y se pueden simplificar con un diseño más claro y más limpio es una habilidad útil.
Por supuesto, algunos problemas son intrínsecamente complejos y requieren soluciones complejas, pero en la mayoría de los grandes proyectos las áreas que han tenido requisitos poco definidos o cambiantes tienden a tener soluciones demasiado complejas con un mayor número de problemas por línea.
Dado un problema que resolver, prefiero la solución que reduce el conteo de líneas. Por supuesto, al comienzo del proyecto pequeño, puedo generar muchas más de diez líneas de código por día, pero tiendo a no pensar en la cantidad de código que he escrito, solo lo que hace y qué tan bien lo hace. Ciertamente no intentaría vencer diez líneas por día o considerarlo un logro hacerlo.
Es fácil obtener un par de cientos de líneas de código por día. Pero trate de obtener un par de cientos de líneas de código de calidad por día y no es tan fácil. Encima de eso, con la depuración y pasando por días con pocas o ninguna líneas nuevas por día y el promedio bajará bastante rápido. Pasé semanas depurando problemas difíciles y la respuesta fue 1 o 2 líneas de código.
Me gusta esta cita:
Si deseamos contar líneas de código, no deberíamos considerarlas como "líneas producidas" sino como "líneas gastadas". - Edsger Dijkstra
Algunas veces ha contribuido más eliminando el código que agregando
No hay tal cosa como una bala de plata.
Una métrica única como esa es inútil por sí misma.
Por ejemplo, tengo mi propia biblioteca de clase. Actualmente, las siguientes estadísticas son verdaderas:
Líneas totales: 252.682
Líneas de código: 127.323
Comentarios: 99.538
Líneas vacías: 25.821
Supongamos que no escribo ningún comentario, es decir, 127.323 líneas de código. Con su proporción, esa biblioteca de códigos me llevaría alrededor de 10610 días para escribir. Eso es 29 años.
Ciertamente no pasé 29 años escribiendo ese código, ya que es todo C #, y C # no ha durado tanto.
Ahora, puedes argumentar que el código no es tan bueno, ya que obviamente debo haber sobrepasado tus 12 líneas al día, y sí, estaré de acuerdo, pero si voy a llevar la línea de tiempo a cuando se lanzó 1.0 (y no comencé a hacerlo realmente hasta que se lanzó 2.0), que es 2002-02-13, alrededor de 2600 días, el promedio es de 48 líneas de código por día.
Todas esas líneas de código son buenas? Diablos no. ¿Pero hasta 12 líneas de código por día?
Diablos no.
Todo depende
Puede tener un programador de primera clase que genera código en el orden de miles de líneas por día, y un programador medio que produce código en el orden de cientos de líneas por día, y la calidad es la misma.
Y sí, habrá errores.
El total que quieres es el saldo. Cantidad de código cambiado, versus la cantidad de errores encontrados, versus la complejidad del código, versus la dificultad de corregir esos errores.
Nuestra base de código es de aproximadamente 2.2MLoC por un esfuerzo de aproximadamente 150 años-hombre. Eso hace que sea alrededor de 75 líneas de c ++ o c # por desarrollador por día, durante toda la vida del proyecto.
Sería mucho mejor darse cuenta de que hablar de líneas físicas de código no tiene sentido. El número de Líneas de código físicas (LoC) depende tanto del estilo de codificación que puede variar de un orden de magnitud de un desarrollador a otro.
En el mundo de .NET hay una forma conveniente de contar el LoC. Punto de secuencia Un punto de secuencia es una unidad de depuración, es la porción de código resaltada en rojo oscuro al poner un punto de ruptura. Con el punto de secuencia podemos hablar de LoC lógico , y esta métrica se puede comparar a través de varios lenguajes .NET. La mayoría de las herramientas de .NET incluyen la métrica del código VisualStudio, NDepend o NCover.
Por ejemplo, aquí hay un método 8 LoC (los puntos de secuencia de corchetes iniciales y finales no se tienen en cuenta):
La producción de LoC debe contarse a largo plazo. Algunos días escupirás más de 200 LoC, otros días pasarás 8 horas solucionando un error al no agregar ni un solo LoC. Algunos días limpiarás el código muerto y eliminarás LoC, algunos días pasarás todo el tiempo refaccionando el código existente y sin agregar ningún LoC nuevo al total.
Personalmente, cuento con un solo LoC en mi propio puntaje de productividad solo cuando:
- Está cubierto por pruebas unitarias
- está asociado a algún tipo de contrato de código (si es posible, no todos los LoC pueden verificarse mediante contratos).
En esta condición, mi puntaje personal en los últimos 5 años al codificar la herramienta NDepend para desarrolladores de .NET es un promedio de 80 LoC físicos por día sin sacrificar de ninguna manera la calidad del código . El ritmo se mantiene y no veo que disminuya en el corto plazo. Con todo, NDepend es una base de código C # que actualmente pesa alrededor de 115 K de LoC físico
Para aquellos que odian contar LoC (vi muchos de ellos en comentarios aquí), doy fe de que una vez calibrado adecuadamente, contar LoC es una excelente herramienta de estimación . Después de codificar y medir docenas de características logradas en mi particular contexto de desarrollo, llegué al punto en el que puedo estimar con precisión el tamaño de cualquier función TODO en LoC, y el tiempo que me llevará entregarlo a producción.
Sin consultar realmente mi copia de "The Mythical Man-Month" (todos los que leen esto deberían tener una copia disponible), hubo un capítulo en el que Brooks analizó la productividad por líneas escritas. El punto interesante, para él, no era el número real de líneas escritas por día, sino el hecho de que parecía ser aproximadamente el mismo en ensamblador y en PL / I (creo que era el lenguaje de nivel superior utilizado).
Brooks no estaba dispuesto a arrojar una especie de cifra arbitraria de productividad, pero estaba trabajando a partir de datos sobre proyectos reales, y por todo lo que recuerdo, podrían haber sido 12 líneas / día en promedio.
Sí señaló que la productividad podría variar. Dijo que los compiladores eran tres veces más duros que los programas de aplicación y que los sistemas operativos eran tres veces más duros que los compiladores. (Parece que le gustó usar multiplicadores de tres para separar categorías).
No sé si apreciaba entonces las diferencias individuales entre la productividad del programador (aunque en un argumento de orden de magnitud, postuló un factor de diferencia de siete), pero como sabemos la productividad superior no es solo una cuestión de escribir más código, pero también escribe el código correcto para hacer el trabajo.
También está la cuestión del medio ambiente. Brooks especuló un poco sobre qué haría que los desarrolladores fueran más rápidos o más lentos. Como mucha gente, cuestionó si las modas actuales (depuración interactiva usando sistemas de tiempo compartido) eran mejores que las anteriores (preplanning cuidadoso para una toma de dos horas usando toda la máquina).
Teniendo eso en cuenta, haría caso omiso de cualquier número de productividad real que se le ocurriera como inútil; el valor continuo del libro está en los principios y lecciones más generales que las personas persisten en no aprender. (Oye, si todo el mundo los hubiera aprendido, el libro sería de interés histórico solamente, al igual que todos los argumentos de Freud de que hay algo así como una mente subconsciente).
Steve McConnell brinda una estadística interesante en su libro "Estimación de software" (p62 Tabla 5.2). Distinguió entre tipos de proyectos (Aviónica, Comercial, Telco, etc.) y el tamaño del proyecto 10 kLOC, 100 kLOC, 250 kLOC. Los números se dan para cada combinación en LOC / StaffMonth. EG Avionic: 200, 50, 40 Intranet Systems (interno): 4000, 800, 600 Embedded Systems: 300, 70, 60
Lo que significa: ej. para el proyecto Avionic 250-kLOC hay 40 (LOC / mes) / 22 (días / mes) == <2LOC / día!
Uno sospecha que este perenne pedazo de manager-candy se acuñó cuando todo era una aplicación de sistema escrita en C porque, de no ser así, el número de magia podría variar en órdenes de magnitud dependiendo del idioma, la escala y la naturaleza de la aplicación. Y luego tiene que descontar comentarios y atributos. Y, en última instancia, ¿a quién le importa la cantidad de líneas de código escritas? ¿Se supone que debes terminar cuando alcances 10K líneas? 100 K? Tan arbitrario.
Es inutil.