Proxy en Android

[Reaper45]

Creo que el problema es que por algún motivo te crees que liberamos código inestable o algo así. Joder, que yo también le tengo respeto a producción y cualquier cambio debe hacerse gradualmente. Eso ya está aprendido y sí que me ha costado sangre. Ahora mismo estoy al cargo del framework de Android.

También eso que dices queda muy bonito cuando haces aplicaciones cerradas. No estás teniendo en cuenta que cualquier aplicación que vaya sobre nuestro framework se va a ver afectada por los cambios y que tengo que preocuparme de los malditos detalles en todo. ¿Cómo cojones va a ir una aplicación sobre nuestro framework fluida si no me preocupo por los detalles? Que no es una aplicación, es un puto motor de desarrollo. Igualmente, si un partner actualiza el framework y pone la aplicación en producción directamente es un completo gilipollas. Es frecuente esperar que haga yo todas las malditas pruebas, sean de partners o clientes. Y no veas los lloros al deprecar cosas. Me cago en la puta, se deprecan porque se cometió un error y hay que solucionarlo, me importa una mierda el partner sea un vago integral, que se joda, que lo cambie y lo pruebe, si genuinamente falta algo, gustosamente le echaré un cable.

Y en absoluto creo que me puedas criticar por querer todo o nada.

[Yumichan]

...
[marmota day]

A ver... lee. Critico al puto inutil de tu gestor por consentírtelo, lo tuyo son cosas absurdas de junior que se te pasarán.

[Reboot]

Yo tengo que dar un voto a favor del código elegante, o como mínimo, legible. Que por algo me tiré casi dos años parcheando la mierda que parieron unos tíos que cobraron "minolles" y que quebraron antes de terminar del todo la aplicación.

Las zonas bien hechas y documentadas siempre eran más rápidas de modificar que los parches caóticos que surgieron después.

[Reaper45]

(10-31-2013, 03:09 PM)Yumichan escribió: ...
[marmota day]

A ver... lee. Critico al puto inutil de tu gestor por consentírtelo, lo tuyo son cosas absurdas de junior que se te pasarán.

Por favor explica la ridiculez de mis métodos sin caer en argumentación barata. Prometo escuchar.

P.D.: Yo en cambio critico al maldito vago que no me haga ni puto caso bajo ninguna circunstancia.

[Yumichan]

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.

[Nosfer]

(10-31-2013, 03:53 PM)Reboot escribió: Las zonas bien hechas y documentadas siempre eran más rápidas de modificar que los parches caóticos que surgieron después.

Un código bien escrito no debería necesitar apenas documentación, o como mucho para indicar condiciones especiales.
Un proyecto que respete una estructura de ficheros, codigo que siga unas guías minimas, funciones que realicen tareas bien definidas y utilizar nombres descriptivos es más que suficiente para tener un código que no de muchas complicaciones a la hora de mantenerlo.


PD: Los comentarios de Reaper45 me parecen tan surrealistas que es que no me atrevo ni a entrar en debate XD.

[Reaper45]

(10-31-2013, 06:58 PM)Yumichan escribió: 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.

Me importa una mierda la regla que se use, si es necesario, pongo la que sea de común acuerdo y tan felices.

Con todos mis respetos, señor profesor, si tan inaguantable le parece la consistencia en el código dudo muchísimo de su capacidad de hacer un diseño medio bueno, no digamos ya cambiarlo cuando le explote en la cara. Se me quitan a mí las ganas siquiera de empezar algo.

Siento que me repito, pero lo diré una vez más. El autoformato es el primer paso.

El resto de la lección... Qué bonito todo. Lástima que no me lo trague ni harto de vino.

(10-31-2013, 08:40 PM)Nosfer escribió:

(10-31-2013, 03:53 PM)Reboot escribió: Las zonas bien hechas y documentadas siempre eran más rápidas de modificar que los parches caóticos que surgieron después.

Un código bien escrito no debería necesitar apenas documentación, o como mucho para indicar condiciones especiales.
Un proyecto que respete una estructura de ficheros, codigo que siga unas guías minimas, funciones que realicen tareas bien definidas y utilizar nombres descriptivos es más que suficiente para tener un código que no de muchas complicaciones a la hora de mantenerlo.

PD: Los comentarios de Reaper45 me parecen tan surrealistas que es que no me atrevo ni a entrar en debate XD.

Por dios bendito y jesucristo redentor. Tienes toda la razón, al fin y al cabo lo que yo quería es código mal escrito, sin documentar, nombres de instancias salidos de una función aleatoria y sin ninguna clase ni estructura, puesto que me encanta perder horas en gilipolleces y en mentar a gente de dudosa procedencia.

Me he quedado sin habla, ni siquiera estoy cabreado ya.

[LoKo]

(10-31-2013, 10:01 PM)Reaper45 escribió: El resto de la lección... Qué bonito todo. Lástima que no me lo trague ni harto de vino.

¿Solo tragas un poco?
¿o es que escupes?

[Yumichan]

En fin, peor para tí: junior con malas prácticas y poco propósito de enmineda. Mal asunto...
Espero que al menos recuerdes una palabra: Redmine. Llevo utilizándolo (o clones de pago) desde 2007.

[Reaper45]

No. No hay nada que enmendar porque no pido nada más que lo razonable. No te culpo porque es la misma mierda de siempre.

Redmine, es una buena idea y queda bienvenida.