10-31-2013, 06:58 PM
Pues vamos allá, que estos estan de Salón y estará parado el foro. Ademas en esquemático del que odia Guibuu.
Yumipost obvious edition:
"La clase que debía haberte dado tu jefe de proyecto."
1-El retoque puramente estético es absurdo. Si no puedes vivir sin él convence a tu jefe que ponga reflas de formateo en el repositorio (las tuyas) para todos. En el 99% de los casos a los demás del equipo se la sudará usar unas u otras y te dirán que si aunque sólo sea para que dejes de hacer lo que haces ahora. Tocando el código al tuntún por razones puramente estéticas trastoca la trazabilidad de los cambios en control de versiones.
2-Ahora vamos con las malas prácticas que tu crees que observas en clases/ficheros/paquetes/"bloques completos" que no son tuyos y te decides alegremente a "corregir".
2.1-Si el cambio pertenece a un miembro en activo de tu equipo, que es lo que dabas a entender en "soy el más nazi y cuadriculado con la limpieza del código de todos sin duda alguna".
Si se cumple esto NO DEBES tocar ese código. Debes abrir un ticket (o tarea, o como lo llameis) en vuestro sistema de gestión de proyectos y asignársela al "culpable". Redmine es sencillo y gratis por si no usais ninguno.
Si lo corriges tú, el culpable no va a aprender y tendrés a una rémora con problemas de formación repitiendo en tu proyecto y siguientes esas malas prácticas. En un equipo de devs no gigantesco en general todos deben saber hacer todo, auqnue luego haya grados de "expertise" (que queda mas chulo ponerlo en inglis)
Es muy probable que cuando le llegue el ticket el culpable argumente y te haga ver la idoneidad de su código (o a tu jefe). Entonces rechaza el ticket y el que aprende eres tú.
Tal y como lo haces ahora eso no pasa. Molestas al equipo y la formación de los "problemáticos" y la tuya no aumenta, pero si lo hace tu ego para liarla la próxima.
Aunque tenga asignado el ticket, puesto que funciona bien, esa tarea se planificará para cuando el JP quiera, o resto del equipo en plan democracia "ágil" y esas modas modernas, no cuando a tí te de la gana. Principalmente porque auqnue seas la caña programando y corrigiendo bugs y estás en un equipo de 3 o 5 personas, si tocas algo común lo lógico es que si teneis a alguien de pruebas (aunque seais vosotros mismos que os cambias la gorra) habrá que pasar una mínima mínima prueba de regresión. Eso es tiempo. No descoloques planificación por caprichos. Si es importante como dices, se abordará, pero no cuando a tí te de la gana.
Añadamos a este caso una excepción:
2.1.1-Si lo que es visto es un error = el código no funciona como debe (pensando en caja negra) y es bloqueante.
Entonces creas ticket y te lo asignas tú, añades al "culpable" y se lo dices a tu responsable, auqnue sea en una linea de mensajería instantánea y te pones a ello y avisas al "culpable". Si haces una cagada a ojos del culpable argumentará... mirar 2.1, a lo mejor aprendes orque es mejor no hacerlo como ibas a hacerlo tu. Y si llevas razón el "culpable" tiene un howto cuando se actualice el código.
2.2-Si el cambio pertenece a un miembro que no está en el equipo o en la empresa. En este caso el código heredado es TUYO pero con reservas.
Aplicar 2.1 integro sin la notificación al "culpable" y en responsable de ticket te pones tú.
Es sencillo de aplicar y no pierdes al día mas de 4 minutos rellenando esto en un redmine o un project server o lo que useis. Además sirve para formar a gente con carencias. El que tiene carencias puedes ser tu o puede ser tu compi.
Si además añades una previsión de tiempo de resolución (inicio) y de tiempo empleado (cuendo subas al repo) a lo mejor tu jefe no desbarra tanto con las planificaciones.
Y esto Reaper no es culpa tuya, ni te hace peor diseñador (las apis que dices) o programador, porque eres un junior y sólo indica que no sabes trabajar en equipo como muchos junior al principio de sus carreras.
Tu jefe debía haber dejado claro esto a todo el equipo desde el principio y si no lo hace, ya puede darle el framework ingresos por muchos chachidolares al mes que no pasa de ser un puto proyecto de juguete.
Licencia CC sin necesidad de cita (no se como se llama) para que tras reflexionar sobre los misterios que contiene lo imprimas y se lo pongas pegado en la pantalla del macbook al gañán que os gestiona.
Da igual que al él se la sude, da igual que repruebes mil veces tus cambios. NO se hace así y entorpeces al proyecto por las razones enumeradas. Es mejor que aprendas a trabajar así porque lo mismo cuando ya no seas junior y marches a trabajar a otro sitio con el mismo modus operandi, a lo mejor tu futuro jefe no te da ni el 1º aviso.
Yumipost obvious edition:
"La clase que debía haberte dado tu jefe de proyecto."
1-El retoque puramente estético es absurdo. Si no puedes vivir sin él convence a tu jefe que ponga reflas de formateo en el repositorio (las tuyas) para todos. En el 99% de los casos a los demás del equipo se la sudará usar unas u otras y te dirán que si aunque sólo sea para que dejes de hacer lo que haces ahora. Tocando el código al tuntún por razones puramente estéticas trastoca la trazabilidad de los cambios en control de versiones.
2-Ahora vamos con las malas prácticas que tu crees que observas en clases/ficheros/paquetes/"bloques completos" que no son tuyos y te decides alegremente a "corregir".
2.1-Si el cambio pertenece a un miembro en activo de tu equipo, que es lo que dabas a entender en "soy el más nazi y cuadriculado con la limpieza del código de todos sin duda alguna".
Si se cumple esto NO DEBES tocar ese código. Debes abrir un ticket (o tarea, o como lo llameis) en vuestro sistema de gestión de proyectos y asignársela al "culpable". Redmine es sencillo y gratis por si no usais ninguno.
Si lo corriges tú, el culpable no va a aprender y tendrés a una rémora con problemas de formación repitiendo en tu proyecto y siguientes esas malas prácticas. En un equipo de devs no gigantesco en general todos deben saber hacer todo, auqnue luego haya grados de "expertise" (que queda mas chulo ponerlo en inglis)
Es muy probable que cuando le llegue el ticket el culpable argumente y te haga ver la idoneidad de su código (o a tu jefe). Entonces rechaza el ticket y el que aprende eres tú.
Tal y como lo haces ahora eso no pasa. Molestas al equipo y la formación de los "problemáticos" y la tuya no aumenta, pero si lo hace tu ego para liarla la próxima.
Aunque tenga asignado el ticket, puesto que funciona bien, esa tarea se planificará para cuando el JP quiera, o resto del equipo en plan democracia "ágil" y esas modas modernas, no cuando a tí te de la gana. Principalmente porque auqnue seas la caña programando y corrigiendo bugs y estás en un equipo de 3 o 5 personas, si tocas algo común lo lógico es que si teneis a alguien de pruebas (aunque seais vosotros mismos que os cambias la gorra) habrá que pasar una mínima mínima prueba de regresión. Eso es tiempo. No descoloques planificación por caprichos. Si es importante como dices, se abordará, pero no cuando a tí te de la gana.
Añadamos a este caso una excepción:
2.1.1-Si lo que es visto es un error = el código no funciona como debe (pensando en caja negra) y es bloqueante.
Entonces creas ticket y te lo asignas tú, añades al "culpable" y se lo dices a tu responsable, auqnue sea en una linea de mensajería instantánea y te pones a ello y avisas al "culpable". Si haces una cagada a ojos del culpable argumentará... mirar 2.1, a lo mejor aprendes orque es mejor no hacerlo como ibas a hacerlo tu. Y si llevas razón el "culpable" tiene un howto cuando se actualice el código.
2.2-Si el cambio pertenece a un miembro que no está en el equipo o en la empresa. En este caso el código heredado es TUYO pero con reservas.
Aplicar 2.1 integro sin la notificación al "culpable" y en responsable de ticket te pones tú.
Es sencillo de aplicar y no pierdes al día mas de 4 minutos rellenando esto en un redmine o un project server o lo que useis. Además sirve para formar a gente con carencias. El que tiene carencias puedes ser tu o puede ser tu compi.
Si además añades una previsión de tiempo de resolución (inicio) y de tiempo empleado (cuendo subas al repo) a lo mejor tu jefe no desbarra tanto con las planificaciones.
Y esto Reaper no es culpa tuya, ni te hace peor diseñador (las apis que dices) o programador, porque eres un junior y sólo indica que no sabes trabajar en equipo como muchos junior al principio de sus carreras.
Tu jefe debía haber dejado claro esto a todo el equipo desde el principio y si no lo hace, ya puede darle el framework ingresos por muchos chachidolares al mes que no pasa de ser un puto proyecto de juguete.
Licencia CC sin necesidad de cita (no se como se llama) para que tras reflexionar sobre los misterios que contiene lo imprimas y se lo pongas pegado en la pantalla del macbook al gañán que os gestiona.
Da igual que al él se la sude, da igual que repruebes mil veces tus cambios. NO se hace así y entorpeces al proyecto por las razones enumeradas. Es mejor que aprendas a trabajar así porque lo mismo cuando ya no seas junior y marches a trabajar a otro sitio con el mismo modus operandi, a lo mejor tu futuro jefe no te da ni el 1º aviso.
![[Imagen: IUmqKJR.png]](https://i.imgur.com/IUmqKJR.png)