Portada
mis comunidades
otras secciones
#3:
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:
Sin mirarlo: la gente que no tiene ni puta idea de programar, que copia y pega todo, que te mete cosas dentro de loops que NO deberían de ir ahí, jodiendo el rendimiento de la aplicación y haciendo el código en imposible de entender, ésos son los más productivos.
Comentarios
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”.
#3 Ahora las lineas de montaje del A-350 y B787 deben haber pegado una bajada de productividad
xdxd
#3
En realidad es bastante peor. Por lo menos en el avión sabes cuanto va a pesar al final.
#20 Como lo pesen con la bascula de los submarinos...
https://www.elconfidencialdigital.com/articulo/defensa/sobrepeso-submarino-S-80-consultora-norteamericana/20130612010000069181.html
Sin mirarlo: la gente que no tiene ni puta idea de programar, que copia y pega todo, que te mete cosas dentro de loops que NO deberían de ir ahí, jodiendo el rendimiento de la aplicación y haciendo el código en imposible de entender, ésos son los más productivos.
#1 Ya lo dice el artículo:
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.
#2 Hacer commits está sobrevalorado, con uno basta para hacer deploy a producción después de aprobarse uno mismo el pull request
#13 Una pregunta seria.
¿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.
#16 Cuando sabes que lo que subas no va a romper nada
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.
#16 Un commit en una rama pública debe comprender un único cambio lógico, completo y que compile correctamente, aunque no funcione.
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".
#16 Independientemente de metodologías y filosofías varias, un commit es un punto en la historia de tu código al que vas a poder volver en el futuro. A partir de ahí ya haz lo que quieras...
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.
El Quijote en comentarios por cada línea de código = Principal engineer en 2 meses
Es una gilipollez hacer algo asi, hoy se te puede dar de muerte, y mañana estar atascado por el motivo que sea.
No es por vagueza. Programar a cierto nivel no es tan facil como muchos quieren hacer creer.
""" Cómo aunmentar la productividad"""
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
Siempre que se habla de estas cosas recuerdo lo que leí sobre el tema:
https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt
#17 No conocía la historia. Genial 😂
De los mismos que deciden que un código tiene que tener un % determinado de cobertura de test, al final la gente hace test de los Beans, algo completamente estúpido a la hora de la verdad
#5 Beans!!! Telita
#5 #6 Beans? Qué es/son Beans?
#15
El alimento de todo programador que se precie.
#21 mmm, ok, no lo pillo
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
#21 alimento "técnico" para sobrevivir
#5 cierto… estos ojitos vieron una aplicación con una lógica de negocio complicadísima y… ¿qué tenía testeado? Los setters y los getters. Supongo que cortesía de Netbeans.
Eso pasa siempre en toda lógica capitalista. Los rentistas (gente que tiene dinero y espera que ese dinero se multiplique mágicamente sin que ellos tengan que trabajar) siempre están convencidos de que hay una ecuación que permite a su empresa ser rentable sin tener que arrimar el hombro, comprender el trabajo de los empleados y hablar con ellos.
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.
Esto tiene que ver con un problema muy general, siempre que pones una métrica, una ley, o lo que sea, estás perturbando la realidad. Si premias a los que matan ratas en una época de plaga de ratas, no faltará el que crie ratas para que le paguen por matarlas.
Un ejemplo más desafortunado es el de los falsos positivos en colombia.
En mi gráfica de Github me di cuenta que en los meses de verano mi cantidad de aportes bajaba descaradamente. El calor mata.