code-metrics - fuente - metricas de codigo visual studio 2017
¿Qué tan malo es SLOC(líneas de código fuente) como métrica? (13)
¿Por qué no entienden que SLOC no ha cambiado, pero el software hace más que ayer porque ha agregado nuevas funciones o solucionado errores?
Ahora explícales esto de esta manera. Medir la cantidad de trabajo que se hizo en su código comparando las líneas de código es lo mismo que medir cuántas características hay en su teléfono celular comparándolas por tamaño. Los teléfonos celulares han disminuido de tamaño en más de 20 años al agregar más funciones debido a las mejoras tecnológicas y técnicas. El buen código sigue este mismo principio, ya que podemos expresar la misma lógica en cada vez menos líneas de código, lo que hace que su ejecución sea más rápida, más fácil de mantener y más fácil de entender a medida que mejoramos nuestra comprensión del problema e introducimos nuevas técnicas de desarrollo.
Me gustaría que se centraran en el valor comercial devuelto a través del desarrollo de funciones, el mantenimiento y la solución de errores. Si quien está contento con el software dice que puede ver una mejora, no se preocupe por el SLOC.
Ve a leer esto:
https://stackoverflow.com/questions/3800707/what-is-negative-code
Estamos documentando nuestro proceso de desarrollo de software. Para los técnicos, esto es bastante sencillo: desarrollo iterativo con hitos internos cada cuatro semanas, externo cada 3 meses.
Sin embargo, el propósito de este ejercicio es exponer las cosas para nuestra gestión de proyectos en términos que puedan entender. Específicamente, estos gerentes no técnicos necesitan métricas que puedan entender.
Entiendo bien nuestras opciones de métricas y he propuesto un conjunto completo (los requisitos cumplidos y los costos reales frente a los costos presupuestados son dos de mis favoritos). Sin embargo, tenemos algunas manos viejas involucradas y tienden a aferrarse a métricas como SLOC.
Entiendo la tentación de SLOC: parece fácil de entender para las personas que no tienen software y parece ser el análogo más cercano de una cosa física (¡es como contar las tarjetas perforadas en los viejos tiempos!).
Así que aquí está la pregunta: ¿cómo puedo explicar los peligros de SLOC a una persona no técnica?
Aquí hay una motivación concreta: trabajamos en un sistema implementado bastante maduro que tiene años de historia detrás. A medida que agregamos características, SLOC tiende a mantenerse aproximadamente al nivel o incluso a disminuir (la refactorización elimina el código antiguo / muerto, las nuevas características son solo ajustes de los existentes, etc.). Para un gerente no programador, un SLOC no creciente en un proyecto de desarrollo es, en el mejor de los casos, desconcertante ...
Aclarando en respuesta a una respuesta reciente a continuación: recuerde, estoy argumentando que SLOC es una mala métrica para medir el progreso del proyecto. No estoy argumentando que es un número que no vale la pena recolectar. Requiere un contexto extenso para hacer algo útil con él y la mayoría de los administradores de programas no tienen ese contexto.
Alguien dijo :
"Usar SLOC para medir el progreso del software es como usar kg para medir el progreso en la fabricación de aviones"
Es totalmente inapropiado ya que alienta malas prácticas como:
Copiar-pegar-síndrome
Desalentar la refactorización para facilitar las cosas.
Relleno de comentarios sin sentido.
...
El único uso es que puede ayudarlo a calcular la cantidad de papel que debe colocar en la impresora cuando imprima todo el árbol de fuentes.
Bastante mal (-:
Una idea mucho mejor sería cubrir los casos de prueba, en lugar de codificar.
La idea es esta: un desarrollador debe confirmar un caso de prueba que falla, luego confirmar la corrección en la siguiente compilación, y el caso de prueba debería pasar ... solo mide cuántos casos de prueba agregó el desarrollador.
Como bono adicional, recopile las estadísticas de cobertura (la cobertura de sucursales es mejor que la cobertura de línea aquí).
Creo que SLOC es una gran métrica. Te dice qué tan grande es tu sistema. Eso es bueno para juzgar complejidad y recursos. Y te ayuda a preparar al próximo desarrollador para trabajar en un código base.
Pero el recuento de SLOC se debe analizar solo DESPUÉS de que se hayan aplicado otros indicadores de calidad de código apropiados. Asi que...
- NO escriba 2 líneas de código cuando 1 lo hará, a menos que la versión de 2 líneas haga que el código sea más fácil de mantener 2 veces.
- NO pegue el código con comentarios innecesarios solo para suavizar el conteo de SLOC.
- NO pagar a las personas por cuenta de SLOC.
Llevo 30 años gestionando proyectos de software. Uso el conteo SLOC todo el tiempo, para ayudar a entender los sistemas maduros. Nunca me ha resultado útil ni siquiera echar un vistazo al recuento de SLOC hasta que un proyecto se acerca a la versión 1.0.
Básicamente, durante el proceso de desarrollo, me preocupo por la calidad, el rendimiento, la facilidad de uso y la conformidad con las especificaciones. Haz lo correcto y el proyecto probablemente será un éxito. Cuando el polvo se asiente, mira el recuento de SLOC. Puede que te sorprenda saber que obtuviste MUCHO de las 5,000 líneas de código. ¡Y puede que te sorprenda que tengas TAN poco! (Pero el conteo de SLOC no afecta la calidad, el rendimiento, la facilidad de uso y la conformidad con las especificaciones).
Y siempre el código como la persona que estará trabajando en tu código a continuación es un psicópata violento que sabe dónde vives.
Saludos, tío Chip
El problema con SLOC es que es una métrica fácil de jugar. Ser productivo no equivale a producir más código. Así que la forma en que lo expliqué a la gente que descubrió lo que dijo Skilldrick es la siguiente:
- Cuantas más líneas de código hay, más complicado se vuelve.
- Cuanto más se complica algo, más difícil es entenderlo.
- Antes de agregar una nueva característica o corregir un error, necesito entenderlo.
- La comprensión lleva tiempo.
- El tiempo cuesta dinero.
Código más pequeño -> más fácil de entender -> más barato agregar nuevas funciones
Los contadores de frijoles pueden entender eso.
Explique que SLOC es una excelente medida de las líneas de código en la aplicación, nada más .
El número de líneas en un libro, o la longitud de una película no determina qué tan bueno es. Puede mejorar una película y acortarla, puede mejorar una aplicación y reducir las líneas de código.
Incluso las herramientas modernas de métricas de código critican la contingencia de SLOC, me gusta el punto señalado en las preguntas frecuentes de ProjectCodeMeter:
Muéstrales la diferencia entre:
for(int i = 0; i < 10; i++) {
print i;
}
y
print 0;
print 1;
print 2;
...
print 9
Y pregúnteles si 10 SLOC o 3 SLOC son mejores.
En respuesta a los comentarios:
No lleva mucho tiempo explicar cómo funciona un bucle
for.Después de mostrarles esto, diga "ahora necesitamos imprimir números hasta 100: así es como se hace ese cambio". y muestra cuánto tiempo se tarda en cambiar el código no DRY.
No estoy de acuerdo con que SLOC sea una mala métrica. Puede ser discutible pasar a una pregunta de hace once años con once respuestas, pero igual agregaré otra.
La mayoría de los argumentos lo llaman una métrica errónea porque no es adecuado para medir directamente la productividad . Ese es un argumento extraño; asume que la métrica se utiliza de forma insana. Con este razonamiento, uno podría llamar a Kelvin una unidad defectuosa porque no es adecuado para medir la distancia.
La longitud del código es una medida viable de lastre.
La cantidad de líneas de código sin comentario se correlaciona con:
- errores no detectados
- costos de mantenimiento
- Tiempo de entrenamiento para nuevos contribuyentes.
- costos de migración
- nuevos costos de funciones
y muchos otros tipos de costos similares, como el costo de la optimización.
Por supuesto, el conteo de SLOC no es una medida precisa de ninguno de estos. El código puede estar en cualquier lugar entre muy agradable y muy feo de administrar. Pero se puede suponer que la longitud del código rara vez es libre, y por lo tanto, el código más largo suele ser más difícil de administrar.
Si estuviera administrando un equipo de programadores, me gustaría mucho seguir el lastre que crea o elimina.
No juzgas qué tan bueno (cuántas características, cómo se realiza ...) un avión se basa en su peso (sloc).
Cuando quieres que tu avión vuele más alto, más largo y tenga un mejor rendimiento, no le agregas peso. Reemplaza partes de ella con materiales más ligeros / mejores. Usted quita las partes que no necesita para no agregar peso innecesario.
SLOC se puede cambiar dramáticamente al colocar líneas vacías adicionales ("para facilitar la lectura") o al poner o eliminar comentarios. Así que confiar en SLOC solo puede llevar a confusión.
Por qué SLOC es mala como métrica individual de productividad.
Piense en el código como un bloque de arcilla / piedra. Necesitas tallar, digamos 10 estatuas. No es la cantidad de estatuas que usted talla lo que cuenta. Es lo bien que lo has tallado lo que cuenta. Del mismo modo, no es la cantidad de líneas que ha escrito, sino su funcionamiento. En caso de que el código LOC pueda ser contraproducente como métrica de esta manera.
La productividad también cambia cuando se escribe una pieza compleja de código. Se necesita un segundo para escribir una declaración impresa, pero mucho tiempo para escribir una lógica compleja. No todos los dedos son iguales.
Cómo se puede utilizar SLOC para su beneficio
Creo que SLOC para% de defectos es una buena métrica. Sí, el nivel de dificultad entra en juego, pero este es un buen parámetro que los gerentes pueden usar mientras hacen negocios. Intenta pensar también desde su perspectiva. No te odian ni a ti ni a tu trabajo, pero necesitan decirles a los clientes que eres el mejor y para eso necesitan algo tangible. Dales lo que puedas :)