Comentó Bill Gates que: “Medir los avances de un programa utilizando como base el número de líneas de código es como medir el avance en la construcción de un avión por el peso”.
#1 Yo debo ser muy vago, porque no suelo hacer mas de 100-150 lineas de diarias.
Eso si, me siento muy satisfecho con las lineas que escribo. Mis jefes tambien valoran muy positivamente lo que escribo, de modo que aparte de la "vagancia", todos contentos.
Hay que mirar la calidad de esas líneas, no la cantidad.
#1 Si escribes la documentación de cada método/función creada, haces test unitarios y de integración, te aseguras de que el código está bien comentado y claro para otros programadores y de que está todo correctamente identado, 150 líneas de calidad no son pocas. Hablo de un proyecto serio, no de un "proyecto bicicleta" en el que primero se tiran líneas de código y luego se hace el análisis funcional y después se escriben los casos de uso, si hay tiempo (estos ojos han visto esos horrores)
#4 Eso creo yo, que la calidad es lo mas importante.
Hay dias que puedo hacer 300 o 400 lineas, pero cuando salgo del trabajo me voy con la idea de que lo que he escrito es una mierda. Normalmente suele ser asi y al dia siguiente tengo que rehacerlo.
Por regla general, calculo que hago unas 110 lineas de codigo al dia, pero luego raramente veo motivos para reescribirlas, ni siquiera con el paso de los años.
Y arreglando bugs no creo que llegue a mas de 10 lineas.
Depende del software que se este creando 150 lineas al dia es una burrada o poquisimo.
Por lo que tambien se podria decir que medir el trabajo de un programador solo por las lineas de codigo escritas seria como medir la calidad de una empresa por el numero de empleados en plantilla.
En cualquier caso creo que lo importante es que el avance en los proyectos no se debe medir en líneas de código ya que no todo cuesta el mismo trabajo realizarlo y lo mismo al inicio de la codificación se saca mucho código (sobre todo si se utilizan generadores de código) pero después la cosa puede variar mucho y lo mismo en determinadas fases de la construcción (o al final) hay que tirar módulos completos del programa.
Comentarios
"si en un mes se han desarrollado, pongamos por ejemplo, tres mil líneas de código más en el programa..."
Entonces va siendo hora de despedir al programador... por vago (¿150 líneas de código al día?).
(A no ser que esté arreglando bugs, refactorizando, etc.)
#1 Yo debo ser muy vago, porque no suelo hacer mas de 100-150 lineas de diarias.
Eso si, me siento muy satisfecho con las lineas que escribo. Mis jefes tambien valoran muy positivamente lo que escribo, de modo que aparte de la "vagancia", todos contentos.
Hay que mirar la calidad de esas líneas, no la cantidad.
#1 Si escribes la documentación de cada método/función creada, haces test unitarios y de integración, te aseguras de que el código está bien comentado y claro para otros programadores y de que está todo correctamente identado, 150 líneas de calidad no son pocas. Hablo de un proyecto serio, no de un "proyecto bicicleta" en el que primero se tiran líneas de código y luego se hace el análisis funcional y después se escriben los casos de uso, si hay tiempo (estos ojos han visto esos horrores)
#4 Eso creo yo, que la calidad es lo mas importante.
Hay dias que puedo hacer 300 o 400 lineas, pero cuando salgo del trabajo me voy con la idea de que lo que he escrito es una mierda. Normalmente suele ser asi y al dia siguiente tengo que rehacerlo.
Por regla general, calculo que hago unas 110 lineas de codigo al dia, pero luego raramente veo motivos para reescribirlas, ni siquiera con el paso de los años.
Y arreglando bugs no creo que llegue a mas de 10 lineas.
#1 Con lenguajes como Python 150 lineas son una verdadera pasada .
Depende del software que se este creando 150 lineas al dia es una burrada o poquisimo.
Por lo que tambien se podria decir que medir el trabajo de un programador solo por las lineas de codigo escritas seria como medir la calidad de una empresa por el numero de empleados en plantilla.
En cualquier caso creo que lo importante es que el avance en los proyectos no se debe medir en líneas de código ya que no todo cuesta el mismo trabajo realizarlo y lo mismo al inicio de la codificación se saca mucho código (sobre todo si se utilizan generadores de código) pero después la cosa puede variar mucho y lo mismo en determinadas fases de la construcción (o al final) hay que tirar módulos completos del programa.
Creo que más o menos estamos todos de acuerdo que el número de líneas no es lo más acertado para indicar cómo va el proyecto.