48 meneos
2997 clics
Envío erróneo o controvertido, por favor lee los comentarios.
Esto es lo que pasa cuando intentas medir la productividad de un programador por las líneas de código que escribe al día
Muchos equipos de desarrollo han sufrido los intentos de medir la productividad de sus programadores. Ya sea con cualquier métrica que el manager responsable haya decidido o con algún plugin instalado en el gestor de tareas que arroje números sin ningún contexto. Todo ello, con la buena intención de saber la velocidad del equipo, aunque a veces se desvia hacia dónde pierden el tiempo los desarrolladores.
|
comentarios cerrados
La frecuencia de commits y las líneas de código de un programador junior es normalmente mayor que la de uno senior, por supuesto, aquí lo que cuenta es la relevancia y la solución adoptada.
Dim Conocimiento_Jefe as Integer
Conocimiento_Jefe = 0
Dim Conocimiento_Jefe as Integer
Conocimiento_Jefe = 0
Dim Conocimiento_Jefe as Integer
Conocimiento_Jefe = 0
Dim Conocimiento_Jefe as Integer
Conocimiento_Jefe = 0
Dim Conocimiento_Jefe as Integer
Conocimiento_Jefe = 0
Dim Conocimiento_Jefe as Integer
Conocimiento_Jefe = 0
Dim Conocimiento_Jefe as Integer
Conocimiento_Jefe = 0
Un ejemplo más desafortunado es el de los falsos positivos en colombia.
Los sistemas de puntuación están muy bien para los juegos, pero en la vida real el trabajo no se puede reducir a un número. El propio concepto de productividad del empleado es falaz porque no tiene en cuenta las condiciones, la calidad o el ajuste correcto entre costes y plusvalía producida.
Apple es matemáticamente una empresa súper productiva para el número de empleados en nómina que tiene. Esto está muy bien para engañar a padefos que creen saber de números para que traigan financiación a la empresa. Pero Apple no se cree su cálculo de la productividad porque sabe que en realidad sus productos se están fabricando en una subcontrata china que es una de las empresas con más empleados del mundo.
¿Cuando se debería hacer una confirmación (commit)? Más o menos.
PS: No soy desarrollador pero de vez en cuando hago algunas cosillas.
www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt
Depende mucho como tengas organizado todo, generalmente tienes una rama/s de desarrollo donde es normal que se vayan subiendo y probando cosas a menudo y otra/s de release desde donde se publica a producción las diferentes versiones y que se suele tocar menos. Pero vamos depende mucho de la metodología y ciclos de trabajo que tengan definidos, no hay una regla universal.
Un cambio lógico no tiene por qué estar reducido a un fichero, pueden ser 20 ficheros diferentes y siete mil líneas de código. Pero tienes que ser capaz de describir el cambio sin utilizar la conjunción "Y" o "además".
En realidad es bastante peor. Por lo menos en el avión sabes cuanto va a pesar al final.
El alimento de todo programador que se precie.
Pero, no hay alimento peor que el que me acabas de poner. Bueno, es ideal para una resaca, en mi caso. Ya que me ayudaría a expulsar todas las toxinas por la boca
www.elconfidencialdigital.com/articulo/defensa/sobrepeso-submarino-S-8
Normalmente no quieres volver a cosas a medias porque ni te vas a acordar de cómo continuarlas, y normalmente quieres que si hay un bug y vuelves atrás, puedas volver a un punto lo más cercano posible a cuando se introdujo el fallo.
Así que se suele hacer commit cada poco tiempo siempre que todo esté en un estado consistente.
Un commit público (un push) se hace cuando quieres compartir tu trabajo con el resto de desarrolladores. Generalmente lo antes posible que sea útil. Es decir, cuando funcione y sea poco probable que vayas a romper el API. Aunque si estás en tu propia rama pues ya es un poco más arbirario.
Esto es en el general. Luego depende de cómo tengas organizado tu repositorio y tu flujo de desarrollo. Hay metodologías pre-hechas (como GitFlow) que dan una serie de pautas más concretas de cómo organizar todo. Pero en última instancia esto son herramientas y cada cual las usa un poco como más le conviene.