Pero quizás sin se hack hubieras estado días, la release no salía y los que ponen la tarasca se ponían tristes.
O quizás no. Quizás lo sacabas en 3 patadas y no te comías años de puteadas
Igual si fuera por la mayoría de los "jefes" sería chorizear 24/7. Por algo son "jefes", hace rato que no les preocupan esas cosas hippies como "claridad de código". Si no tenes una estimación del costo de mantenimiento futuro por el pedazo que chorizeas, tu argumento tiende a no tener peso, y te dejan "hacer las cosas bien" más para que estés contento.
(20-11-2012 01:39)Dem0 escribió: [ -> ]Igual si fuera por la mayoría de los "jefes" sería chorizear 24/7. Por algo son "jefes", hace rato que no les preocupan esas cosas hippies como "claridad de código". Si no tenes una estimación del costo de mantenimiento futuro por el pedazo que chorizeas, tu argumento tiende a no tener peso, y te dejan "hacer las cosas bien" más para que estés contento.
En mi caso mis jefes pasaron por eso (de hecho uno de los capos es licenciado en CS) y lo entienden. Pero creo que la claridad de codigo es un argumento en si mismo.
Usar buenas practicas afecta la legibilidad y aún mas la mantenibilidad. Si estas 2 semanas para cambiar un codigo que escribiste en 1 claramente hay algo fallando. Y ese "algo" que fallo (escribir codigo inmantenible) afecta directamente a el timepo que lleva cambiar un metodo y eso repercute en las horas/hombre lo cual a su vez repercute en el bolsillo de los que ponen la tarasca.
Por ahi eso solo es una preocupación cuando la empresa es chica, pero aún asi...
(20-11-2012 01:39)Dem0 escribió: [ -> ]Pero quizás sin se hack hubieras estado días, la release no salía y los que ponen la tarasca se ponían tristes.
O quizás no. Quizás lo sacabas en 3 patadas y no te comías años de puteadas
Igual si fuera por la mayoría de los "jefes" sería chorizear 24/7. Por algo son "jefes", hace rato que no les preocupan esas cosas hippies como "claridad de código". Si no tenes una estimación del costo de mantenimiento futuro por el pedazo que chorizeas, tu argumento tiende a no tener peso, y te dejan "hacer las cosas bien" más para que estés contento.
Yo pensaba asi hasta que me cruce con los lideres tecnicos de siemens alemania y me explicaron que lo barato/atado con alambre sale caro a la larga
3000 hrs de paint tarde , masomenos estos era su estudio interno que me explicaron
(20-11-2012 01:39)Dem0 escribió: [ -> ]Igual si fuera por la mayoría de los "jefes" sería chorizear 24/7. Por algo son "jefes", hace rato que no les preocupan esas cosas hippies como "claridad de código". Si no tenes una estimación del costo de mantenimiento futuro por el pedazo que chorizeas, tu argumento tiende a no tener peso, y te dejan "hacer las cosas bien" más para que estés contento.
En mi caso mis jefes pasaron por eso (de hecho uno de los capos es licenciado en CS) y lo entienden. Pero creo que la claridad de codigo es un argumento en si mismo.
Usar buenas practicas afecta la legibilidad y aún mas la mantenibilidad. Si estas 2 semanas para cambiar un codigo que escribiste en 1 claramente hay algo fallando. Y ese "algo" que fallo (escribir codigo inmantenible) afecta directamente a el timepo que lleva cambiar un metodo y eso repercute en las horas/hombre lo cual a su vez repercute en el bolsillo de los que ponen la tarasca.
Por ahi eso solo es una preocupación cuando la empresa es chica, pero aún asi...
Exacto , hay sistemas donde el cliente no come vidrio y no paga costes de mantenimiento superiores al doble de desarrollo del release. Despues tienen que pagar 24 horas de desarrollo para arreglar un bug que con otra metodologia capaz en 2 horas lo sacabas
Ojo, el pensamiento que describo me parece profesionalmente una cagada. Coincido con los 2.
Pero no me parece mal chorizear conscientemente. Por ahí necesitas que las cosas estén andando hoy, porque sino es lo mismo a que no hubieras hecho nada. O sea, si tenes que chorizear hacelo siempre y cuando seas consciente de que estas pateando "deuda técnica" a futuro.
PD: Y obviamente todo esto es 100% diseño. Si conviene sacar, o no, un buen hack estratégico y saber si/cuando arreglarlo dependerá de cada caso particular.
Pero en esos casos , esta bien chorizearla cuando vas a tener una ventaja en el mercado o con el cliente .. para despues tirar la mierda al tacho y reescribirlo. Hacerlo porque es la costumbre es algo que noto que pasa muy seguido y es una cagada laburar asi
Se, pero es así. La eficacia y eficiencia de cualquier actividad productiva se mide por el valor que genera, y la única forma que se tiene para "medir" el valor es $$$$. Si no hay un profesional con peso en la mesa alta defendiendo estas cosas, siempre se va a buscar optimizar el $$$$ a corto plazo, independientemente de si esto pueda significar pérdidas al largo plazo.
UStedes ponen int esta_variable, o int estaVariable... yo pongo
int A;
y si necesito mas variables...
int a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,w,x,y,z,aa,a1,bb,s,w;
y no olvidemos al nombre mas representativo en mis codigos:....
int sarasa = 0;
AJJAJAJAJJA hace mucho tiempo, se habia puesto de moda, usar softwares, que transformaban a tu codigo... vos le ponias como input tu codigo en lo que carajo sea, y te devolvia el mismo codigo, pero remplazando las variables, nombre de metodos y funciones en nombres realmente cortos como los que acabo de poner, acuerdense que en una epoca, tener un disco de 200 megas, era tener la pija gigante.
