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:50)rulo escribió:  

(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.

Cita:Gonnza , no seas croto. Hace bien las cosas.

A menos que tu jefe quiera que comentes EN EL CODIGO metadata que corresponde al sistema de versionado (en cuyo caso , tu jefe es un carnicero

quiero decir:

obvio, si , cuando hacemos codigo nuevo comentamos, pero es a criterio de cada uno. No hay una "homogeneidad"

como si tiene que haberlla cuando hacemos cambios, que son fecha + nombre y, si no es obvio, motivo

---

Cita:Scrumm? TDD? Nada?

metodologia "que ande"

utilizar underscore es hacer choriceada?

ah, no, no estabamos hablando de eso, cierto

(20-11-2012 12:19)Imakuni escribió:  utilizar underscore es hacer choriceada?

ah, no, no estabamos hablando de eso, cierto

 public void putear_imakuni()

{

   // Code goes here.

}

contra

 public void putearAImakuni()

{

  // Code does NOT go here.

}

Mismo char, menos apretar shift en el primer caso.
Winning.

rulo, modificaste a proposito el metodo en underscore.

sería putear_a_imakuni.

De todas formas, me parese una guasada. tendría que ser putear(objeto).

Te mereces una recursada de PdeP, ya va la segunda vez que cometes el mismo error, y siempre en "putear".

putear_imakuni es suficiente legibiliad para mi. La convención verbo_persona es perfecta. EL "a" no es necesario.

De todas formas mi programa solo tiene un metodo y es putear_imakuni()....¿Porque voy a querer putear a otra persona?

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.

int eresante = 0

long long ago;

 #define sebastian (int) 0.0;