La frustración de continuar el código de un becario

Yo también me he encontrado cosas increíbles que hacen que me ponga de muy mala leche. Es trabajo que hay que hacer y te encuentras el código completamente enmierdado. Te toca hacer cualquier mejora y no tienes más remedio que seguir enmierdando porque reescribirlo todo te podría llevar días o semanas y si un cliente lo necesita ya, es que lo necesita ya, no va a entender que el código debe mejorarse.

http://codecrap.com/

Alecs7k escribió:Yo también me he encontrado cosas increíbles que hacen que me ponga de muy mala leche. Es trabajo que hay que hacer y te encuentras el código completamente enmierdado. Te toca hacer cualquier mejora y no tienes más remedio que seguir enmierdando porque reescribirlo todo te podría llevar días o semanas y si un cliente lo necesita ya, es que lo necesita ya, no va a entender que el código debe mejorarse.

Es justo esa sensación. Lo que ves es para tirarlo, pero no hay lugar a hacerlo porque en su lugar te están pidiendo mantenimiento evolutivo y claro, el cliente no va a pagar una refactorización completa del proyecto. Lo peor es que el código es tan ilegible que a veces cuesta horrores hacer cosas que serían triviales en un código bien estructurado.

Me sigo preguntando qué puede tener un programador en la cabeza para programar así...

AxelStone escribió:Es justo esa sensación. Lo que ves es para tirarlo, pero no hay lugar a hacerlo porque en su lugar te están pidiendo mantenimiento evolutivo y claro, el cliente no va a pagar una refactorización completa del proyecto. Lo peor es que el código es tan ilegible que a veces cuesta horrores hacer cosas que serían triviales en un código bien estructurado.

Me sigo preguntando qué puede tener un programador en la cabeza para programar así...

Es cuestión de experiencia, creo yo. Por eso nunca hay que dejar a nadie experimentado que haga cosas importantes. Si se ponen con un proyecto grande que estén supervisados y que hagan pequeñas cosas.

Yo tengo ciertos conocimientos sobre programación y sobre como hacer las cosas. Cuando me piden hacer algo en mi cabeza me planteo como hacerlo en base a esos conocimientos que tengo y a la experiencia previa. Y claro, si tienes una experiencia sólida y conocimientos sobre arquitectura del software, estructuras de datos, etc, a la hora de hacer algo lo harás bien estructurado, entendible para otros programadores y escalable.

Si ahí metes a una persona que no sabe, simplemente la va a cagar, pero no porque quiera, sino porque no sabe. Y una vez hecho el mal, la teoría de las ventanas rotas dices que tenderá a empeorar, porque si el código es malo, cuando vayas a tocarlo lo harás sin cuidado y sin preocuparte lo más mínimo por como quede.

Esto se repite mucho porque las empresas quieren ahorrar dinero y tiran solo de becarios. Al final el resultado es el mismo.

AxelStone escribió:El único propósito de este hilo no es otro compartir mi frustración de las últimas semanas. Me está tocando revisar y arreglar un código fuente que ha sido íntegramente generado por 2 becarios y la verdad, es justamente esto:

Me quedo con el GIF. Te entiendo, es frustrante, no solo por el codigo si no porque algo ha fallado estrepitosamente en la formacion de ese becario y eso no es culpa sólo de el, sino de sus profesores y de la metodos que usan para enseñar a programar. Y también por el supervisor que no ha controlado la calidad del código.

A mi me pasa exactamente con mi propio código. Llevaré como 4 años trabajando en esto. Y cuando empece me pusieron directamente con web, php y javascript. Cosa que no tenía ni jodida idea. Ni siquiera lo había estudiado en el módulo.

Según van pasando los años voy aprendiendo, pero sobre todo, con ejemplos de código y porque me gusta trastear un montón. Cuando me toca repasar funciones o algún script viejos de los míos... lo reescribo entero. No tienen ni pies ni cabeza. Cosas sin sentido, todo duplicado, y un largo etc...

Todavía recuerdo cuando una función en php me llevo hacerla 4 días y cuando fallaban cosas y tenía que ir metiendo código como si fuera cinta aislante en una fuga xD. Hace poco me toco modificarla para añadir más cosas y decidí borrarla y empezar. No me llevó mas de media mañana.

Y mi primer TPV con la rural... jojojo prefiero no comentarlo.

Pero yo creo que lo que más cuenta es la experiencia. Si tienes una buena base de saber como estructurar todo, al final la experiencia lo es prácticamente todo.

Y estoy seguro que dentro de 4 años repasando el código de hoy, y me reiré por no darme cabezazos contra la pared

Los becarios son eso becarios... cobran menos por ello y se supone que se les tiene que formar, el problema viene cuando quieres un senior o arquitecto con sueldo de becario o junior... He trabajado con muchos becarios y los hay como en todo mejores o peores, pero ojo que al final no sólo los becarios hacen cosas de estas, te encuentras senior con años de experiencia igual... al final lo que se tiene que hacer es intentar enseñar a los que menos saben, que todos creo que hemos sido junior y hemos tenido y tenemos algunas dudas

Por poner un ejemplo.... mi primer curro, no de becario pero con sueldo de ingeniero en prácticas, habíamos 3 personas iguales en la cárnica, nos encargabamos de todas las incidencias de una aplicación en vb6 y de otra de oracle developer, no podíamos preguntar o se nos tiraban al cuello... teníamos un superior que lo único que hacía era copiar nuestro código en cliente (no existían los branchs ), allí un día en una incidencia encontramos un procedimiento de oracle con el siguiente comentario: "No tocar, no sabemos que hace pero es como dios, si lo tocas la aplicación falla" 3000 y pico lineas de código sin comentario y siendo el nucleo nadie quería tocarlo jajajaja

Ánimo AxelStone no te copio código similar porque no se puede por contrato

Entiendo perfectamente al autor del hilo. En esos casos a mi me ocurre exactamente esto:



Por comentar algunos casos que he visto, y que recuerdo ahora...

- Convertir una variable de tipo String a String (?¿?)
- Para comprobar si el valor de una variable "y" era positiva, al programador no se le ocurrió otra cosa que multiplicar "y" por -1 y luego comprobar si (y < 0). Al principio pensé hacia eso porque luego se utilizaría "y" pero... no, ni se utilizaba ni tenia sentido hacer eso en ese contexto
- Un código en C que tenía que almacenar 100 números enteros y el programador, en lugar de crear un array con 100 posiciones, creó 100 variables diferentes. MUERTE

Waninkoko escribió:Entiendo perfectamente al autor del hilo. En esos casos a mi me ocurre exactamente esto:



Por comentar algunos casos que he visto, y que recuerdo ahora...

- Convertir una variable de tipo String a String (?¿?)
- Para comprobar si el valor de una variable "y" era positiva, al programador no se le ocurrió otra cosa que multiplicar "y" por -1 y luego comprobar si (y < 0). Al principio pensé hacia eso porque luego se utilizaría "y" pero... no, ni se utilizaba ni tenia sentido hacer eso en ese contexto
- Un código en C que tenía que almacenar 100 números enteros y el programador, en lugar de crear un array con 100 posiciones, creó 100 variables diferentes. MUERTE

Ostia lo del array ha hecho que me tronchara jajajaja

Yo estuve apañando el software de contratación de una operadora digamos... famosa... en la que había procedimientos con bucles anidados y mucha parafernalia para asignar un valor a una variable y 2 líneas más abajo de la llamada al procedimiento se machacaba el valor con una constante.
Este maravilloso sistema se comía el 80% de los recursos de la infraestructura.

Pla2 escribió:Los becarios son eso becarios... cobran menos por ello y se supone que se les tiene que formar, el problema viene cuando quieres un senior o arquitecto con sueldo de becario o junior... He trabajado con muchos becarios y los hay como en todo mejores o peores, pero ojo que al final no sólo los becarios hacen cosas de estas, te encuentras senior con años de experiencia igual... al final lo que se tiene que hacer es intentar enseñar a los que menos saben, que todos creo que hemos sido junior y hemos tenido y tenemos algunas dudas

Por poner un ejemplo.... mi primer curro, no de becario pero con sueldo de ingeniero en prácticas, habíamos 3 personas iguales en la cárnica, nos encargabamos de todas las incidencias de una aplicación en vb6 y de otra de oracle developer, no podíamos preguntar o se nos tiraban al cuello... teníamos un superior que lo único que hacía era copiar nuestro código en cliente (no existían los branchs ), allí un día en una incidencia encontramos un procedimiento de oracle con el siguiente comentario: "No tocar, no sabemos que hace pero es como dios, si lo tocas la aplicación falla" 3000 y pico lineas de código sin comentario y siendo el nucleo nadie quería tocarlo jajajaja

Ánimo AxelStone no te copio código similar porque no se puede por contrato

Está claro que todos hemos tenido que aprender y que un becario está para aprender, pero igualmente está claro que no todos los becarios son iguales. Como digo he trabajado con chavales muy apañados, que daba gusto ver cómo tecleaban con tan corta experiencia. Simplemente los hay que no valen para esto, siento ser duro...Y bueno lo que omentas del núcleo divino...pa'llorar vamos.

Venga ya que lo estamos convirtiendo en un hilo didáctico de "qué cosas no debes hacer si eres becario", aquí va otra de las buenas. Los que trabajeís en web sabreís que para recuperar un listado se hace mediante una única consulta con los join, where y demás cláusulas que requieras para traer de una sola consulta los campos requeridos. Pues bien, uno de los becarios que hemos tenido era el señor de las querys anidadas. Para componer un listado de elementos que usara varias tablas, ¡¡¡¡lo hacía con miles de querys!!!!

Os pongo un ejemplo ficticio, pero que se ajusta a su modus operandi. Digamos una web de una agencia de viajes donde quiero recuperar un listado de hoteles. Apenas necesito 5-6 campos que se extraen fácilmente de varias tablas con join, y luego cuando pincho en detalle ya amplío información. Aquí va el código de la muerte:

• Select * from hotel (¡¡¡nos traemos todos los campos de todos los hoteles, en una tabla que puede tener decenas de campos!!!). Recuperamos por ejemplo 1200 registros completos, cuando solo necesito el nombre y la categoría.
• Ahora iteramos en los 1200 y lanzo ¡¡¡un select * from cadena_hotelera para cada uno!!! 1200 querys una tras otra, cuando SOLO NECESITO EL MALDITO NOMBRE DE LA CADENA.
• Y para cada cadena hotelera, ¡¡¡select * from temporada para extraer SOLO EL PRECIO!!!

El resultado es un crecimiento exponencial de querys que tumba cuaquier SQL Server. Ni que decir tiene que con todos sus fragmentos no hubo otra que refactorizar, echando horas extra, porque es inmantenible.

Nunca he hecho nada serio en informatica, soy químico y más o menos he aprendido todo autodidacticamente. Me sorprende mucho algunas cosas que ponéis, pero mucho xD

Animo!
Leer esto me sirve para saber lo que me espera
Pero vaya que lo de los querys he quedado
Esta bien que las consultas a veces son muy largas pero nada que un inner join y un par de relaciones no solucione. Creo que SqlServer podía generar hasta las consultas solo pasandole los atributos. (No estoy seguro)

Lo único "serio" que he realizado fue un proyecto junto con 2 colegas, y realmente cuesta si no conoces con quien trabajas.

Aun me queda un año, y esto de la programación es solo practica y leer mucho código. En mi caso solo se java
Me han dicho que python es facil u otros lenguajes, pero prefiero dedicarme solo a uno.

En fin animo y mucho aguante.
Un saludo

amchacon escribió:

void get_tomorrow_date( struct timeval *date )
{
    sleep( 86400 ); // 60 * 60 * 24
    gettimeofday( date, 0 );
}

ARTE

amchacon escribió:

void get_tomorrow_date( struct timeval *date )
{
    sleep( 86400 ); // 60 * 60 * 24
    gettimeofday( date, 0 );
}

L L

WTF?!

Como bien dicen más arriba, los becarios son eso becarios y ojo que no todos cobran pasta, muchos la única beca que tienen es de transporte y para de contar.

Siento que te haya tocado reestructurar el código hasta el punto de tener que rehacer el trabajo, pero el/la iluminado/a que se le ocurrió la gran idea de encargar un proyecto tan importante a un becario dice mucho de la calidad de los que dirigen una empresa y que en este país muchas de ellas suspiran porque llegue la temporada de becarios para que hagan el trabajo sucio, de ahí la famosa frase "es culpa del becario", todos hemos sido becarios o gente en prácticas y todos hemos hecho el trabajo de un asalariado con las mismas responsabilidades y poca o ninguna remuneración por ello.

Como educador, programador y asalariado que pasó primero por individuo en prácticas y luego con una beca de 150€ para transporte no se me ocurre otra cosa que el problema está en la mentalidad de las empresas y esa actitud chupóptera de querer mamar y morder gratis a cuenta de los recién salidos de la facultad, todo esto hablando desde la experiencia y la precariedad no sólo laboral que todos vivimos sino de situaciones de auténtica vergüenza ajena.

Dicho esto, sólo deseo ánimo y que el proyecto salga adelante, pero deberías cagarte en el que encargó dicho proyecto comercial a esos becarios y no en estos últimos que a fin de cuentas y con lo miserables que se han vuelto algunas becas como ADE que en mi comunidad este año ni las han convocado... es mejor mirar desde el punto de vista de que casi todos fuimos becarios.

PD: Ojo, sería lamentable que el trabajo como programadores no hubieran cumplido las más básicas normas de programación, añadiendo anotaciones y creando un manual, que eso sí es totalmente vergonzoso.

Saludos y suerte con el proyecto.

gordon81 escribió:Dicho esto, sólo deseo ánimo y que el proyecto salga adelante, pero deberías cagarte en el que encargó dicho proyecto comercial a esos becarios y no en estos últimos que a fin de cuentas y con lo miserables que se han vuelto algunas becas como ADE que en mi comunidad este año ni las han convocado... es mejor mirar desde el punto de vista de que casi todos fuimos becarios.

Saludos y suerte con el proyecto.

Justo por eso no echo toda la culpa a los becarios, y siempre dejo un pequeño margen alegando lo de "todos hemos sido becarios". Pero insisto, hay becarios y becarios. Yo he trabajado con algunos chavales que la verdad, da gusto lo bien que estructuran el código siendo recién titulados, estos sí que tienen futuro. Sin embargo estos otros becarios destrozacódigos, siento ser duro, pero de verdad que se dediquen a otra cosa.

Para que me entiendas, está claro que un plato necesita cocinarse, no se va a hacer solo. Pero para que salga un plato sabroso, la materia prima debe acompañar. Si te piden cocinar un manjar y te dan comida podrida, difícilmente podrás hacer un buen plato. En cambio si te dan buen género, a nada que le dediques cariño te saldrá un plato exquisito.

Gracias por los ánimos, poco a poco va saliendo, pero está costando un esfuerzo tremendo ya que además del desarrollo adicional estoy refactorizando más de la mitad del código ya existente. Y la otra mitad no lo hago por falta de tiempo, no porque esté bien .

gordon81 escribió:Como bien dicen más arriba, los becarios son eso becarios y ojo que no todos cobran pasta, muchos la única beca que tienen es de transporte y para de contar.

Siento que te haya tocado reestructurar el código hasta el punto de tener que rehacer el trabajo, pero el/la iluminado/a que se le ocurrió la gran idea de encargar un proyecto tan importante a un becario dice mucho de la calidad de los que dirigen una empresa y que en este país muchas de ellas suspiran porque llegue la temporada de becarios para que hagan el trabajo sucio, de ahí la famosa frase "es culpa del becario", todos hemos sido becarios o gente en prácticas y todos hemos hecho el trabajo de un asalariado con las mismas responsabilidades y poca o ninguna remuneración por ello.

Como educador, programador y asalariado que pasó primero por individuo en prácticas y luego con una beca de 150€ para transporte no se me ocurre otra cosa que el problema está en la mentalidad de las empresas y esa actitud chupóptera de querer mamar y morder gratis a cuenta de los recién salidos de la facultad, todo esto hablando desde la experiencia y la precariedad no sólo laboral que todos vivimos sino de situaciones de auténtica vergüenza ajena.

Dicho esto, sólo deseo ánimo y que el proyecto salga adelante, pero deberías cagarte en el que encargó dicho proyecto comercial a esos becarios y no en estos últimos que a fin de cuentas y con lo miserables que se han vuelto algunas becas como ADE que en mi comunidad este año ni las han convocado... es mejor mirar desde el punto de vista de que casi todos fuimos becarios.

PD: Ojo, sería lamentable que el trabajo como programadores no hubieran cumplido las más básicas normas de programación, añadiendo anotaciones y creando un manual, que eso sí es totalmente vergonzoso.

Saludos y suerte con el proyecto.

Joder pues el transporte en mis prácticas me lo tuve que pagar de mi bolsillo, nada me pagaron

Yo creo que ser programador es uno de los trabajos en los que se nota si una persona tiene devoción por lo que hace o sólo está por el "dinero" para poder vivir.

Me ha tocado ver de los dos casos y es una pasada el código final de cada uno.

No creo que sea devoción, es una combinación de formación más interés en hacer las cosas bien.

Yo diría que una mezcla de ambas. No lo llamemos devoción, pero si cuando menos aficción, debe gustarte lo que haces y mostrar interés. Lo bueno de programar es que a diferencia de otras profesiones como poner ladrillos, puedes empezar muy pequeño, lo único que necesitas es un ordenador que ya existe en cualquier hogar medio. Mismamente yo llenaba cintas de 60 minutos con mis programillas de Amstrad CPC cuando no era más que un mocoso, y lo hacía por aficción. Con el paso de los años se ha convertido en mi trabajo.

A veces lo mejor es quedarse con los conceptos y reprogramar todo desde 0, incluso códigos propios hechos en el pasado para adaptarlos a los nuevos paradigmas y técnicas de programación. Si tu problema es que el cliente no va a pagar una refactorización completa siendo esta más sencilla, tienes un problema de codicia, bien tuyo o de tu empresa. SI tanto esta costando modificar el código y ves claro que hacerlo desde 0 te costaría menos estas malgastando horas técnico y dependiendo del tiempo extra que te cueste es tirar dinero.

AxelStone escribió:Yo diría que una mezcla de ambas. No lo llamemos devoción, pero si cuando menos aficción, debe gustarte lo que haces y mostrar interés. Lo bueno de programar es que a diferencia de otras profesiones como poner ladrillos, puedes empezar muy pequeño, lo único que necesitas es un ordenador que ya existe en cualquier hogar medio. Mismamente yo llenaba cintas de 60 minutos con mis programillas de Amstrad CPC cuando no era más que un mocoso, y lo hacía por aficción. Con el paso de los años se ha convertido en mi trabajo.

Joer, me he visto completamente reflejado, a mi me paso con mi Spectrum, del rollo "Esto de los jueguines esta bien pero a ver que dice el libro gordote este que pone BASIC", pasando por un 286 y al segundo dia... ¡¡¡Tapas fuera!!!, a ver que tiene esto por dentro!!!.
Lo que si me ha llamado la atención es que de la peña con la que yo estudié, en la informática como tal, a la larga, solo quedamos los que como tu dices somos aficionados a la vez que profesionales y todos tenemos una evolución parecida desde que cae en nuestras manos el primer cacharro.

En cualquier caso... ¡¡¡Ánimo con esto, que puedes seguro!!! (a pesar de la perdida de cordura que te va a acarrear xD)

P4j4r0 N3gr0 escribió:A veces lo mejor es quedarse con los conceptos y reprogramar todo desde 0, incluso códigos propios hechos en el pasado para adaptarlos a los nuevos paradigmas y técnicas de programación. Si tu problema es que el cliente no va a pagar una refactorización completa siendo esta más sencilla, tienes un problema de codicia, bien tuyo o de tu empresa. SI tanto esta costando modificar el código y ves claro que hacerlo desde 0 te costaría menos estas malgastando horas técnico y dependiendo del tiempo extra que te cueste es tirar dinero.

¿Vas a rescribir 100.000 líneas de código?

¿Vas a rescribir solo un módulo y rezar porque el resto no se te vaya abajo? (cosa normal en un código chapucero).

Ninguna de las dos opciones me gustan

Reescribir todo el código de cero es absurdo en ocasiones, por no decir imposible. Si es un producto propio puede ser factible, pero rehacer una aplicación para un tercero que te puede llevar varios meses sin cobrar puede ser una ruina. No solo no cobras por todo ese trabajo extra, sino que mientras lo haces no puedes dedicarte a otra cosa.

amchacon escribió:¿Vas a rescribir 100.000 líneas de código?

¿Vas a rescribir solo un módulo y rezar porque el resto no se te vaya abajo? (cosa normal en un código chapucero).

Ninguna de las dos opciones me gustan

Sí señor, por ahí van los tiros. El proyecto ha durado más de 1 año de desarrollo y el evolutivo es de un par de meses, evidentemente no puedes condensar en pocos meses nuevas funcionalidades + refactorización completa. Lo que se hace es parchear y punto. Vas haciendo las nuevas funcionalidades y a medida que pasas por encima de un código, lo refactorizas (vamos te lo cepillas y lo haces bien). Y la pesadilla es estimar en 2 semanas una funcionalidad que, para hacerla bien, te obliga a refactorizar varios módulos anteriores

P4j4r0 N3gr0 escribió:Si tu problema es que el cliente no va a pagar una refactorización completa siendo esta más sencilla, tienes un problema de codicia, bien tuyo o de tu empresa.

Joer, me he visto completamente reflejado, a mi me paso con mi Spectrum, del rollo "Esto de los jueguines esta bien pero a ver que dice el libro gordote este que pone BASIC"

Como digo arriba, no es codicia, es imposibilidad material. Ni echando 24 horas al día eres capaz de llevar a cabo semejante refactorización.

Fueron años muy felices, uno con sus libros de Basic

@AxelStone

La verdadera frustracion es seguir mi propio codigo tiempo despues, darme cuenta q no tengo ni puta idea de que quise hacer en su momento, y ensima no escribi ni un jodido comentario

theelf escribió:@AxelStone

La verdadera frustracion es seguir mi propio codigo tiempo despues, darme cuenta q no tengo ni puta idea de que quise hacer en su momento, y ensima no escribi ni un jodido comentario

Mira que no poner comentarios! De todos modos depende del lenguaje ¿no? Me refiero, algo a bajo nivel tipo ensamblador sí es un poco más críptico como no pongas comentarios, pero uno de alto nivel tipo Java es bastante explicativo en sí mismo solo con llamar a las variables y los procedimientos correctamente:

private int numero_usuarios_conectados;
public Date calcularFechaDeInicio() {...}
...

En fin, a nada que le des una vuelta y si es mínimamente estructurado (que justo de eso me quejo con lo que estoy revisando) le coges el pulso en poco tiempo.

El director técnico que tenía hasta hace poco siempre decía que el código debe ser auto explicativo.

Yo la verdad es que no lo veo nada claro..

AxelStone escribió:
Mira que no poner comentarios! De todos modos depende del lenguaje ¿no? Me refiero, algo a bajo nivel tipo ensamblador sí es un poco más críptico como no pongas comentarios, pero uno de alto nivel tipo Java es bastante explicativo en sí mismo solo con llamar a las variables y los procedimientos correctamente:

private int numero_usuarios_conectados;
public Date calcularFechaDeInicio() {...}
...

En fin, a nada que le des una vuelta y si es mínimamente estructurado (que justo de eso me quejo con lo que estoy revisando) le coges el pulso en poco tiempo.

Yo comentarios a nada, es religion

De java ni idea, pero te doy la razon que con lenguajes faciles como C, es sensillo de seguir codigo ajeno o propio antiguo, o al menos, no dan tanto problema


En todo caso, no programes conmigo, jamas sigo una estructura o guion, voy metiendo codigo a medida que se me pasa por la cabeza, y ni un puto comentario

theelf escribió:@AxelStone

La verdadera frustracion es seguir mi propio codigo tiempo despues, darme cuenta q no tengo ni puta idea de que quise hacer en su momento, y ensima no escribi ni un jodido comentario

Los comentarios no convierten un mal código en uno bueno.

No inviertas tiempo en comentar, es mejor volverlo a reescribir de forma que se entienda sin comentarios.

amchacon escribió:

theelf escribió:@AxelStone

La verdadera frustracion es seguir mi propio codigo tiempo despues, darme cuenta q no tengo ni puta idea de que quise hacer en su momento, y ensima no escribi ni un jodido comentario

Los comentarios no convierten un mal código en uno bueno.

No inviertas tiempo en comentar, es mejor volverlo a reescribir de forma que se entienda sin comentarios.

Depende en que programes. En ensamblador que es el lenguaje que uso casi siempre, es al contrario... a mas bueno el codigo, mas criptico se torna

Codigo no muy bueno, es mas facil de seguirle la pista

theelf escribió:

amchacon escribió:

theelf escribió:@AxelStone

La verdadera frustracion es seguir mi propio codigo tiempo despues, darme cuenta q no tengo ni puta idea de que quise hacer en su momento, y ensima no escribi ni un jodido comentario

Los comentarios no convierten un mal código en uno bueno.

No inviertas tiempo en comentar, es mejor volverlo a reescribir de forma que se entienda sin comentarios.

Depende en que programes. En ensamblador que es el lenguaje que uso casi siempre, es al contrario... a mas bueno el codigo, mas criptico se torna

Codigo no muy bueno, es mas facil de seguirle la pista

Bueno, ensamblador es la excepción que confirma la norma

amchacon escribió:¿Vas a rescribir 100.000 líneas de código?

Si es necesario o apropiado, sí.

amchacon escribió:¿Vas a rescribir solo un módulo y rezar porque el resto no se te vaya abajo? (cosa normal en un código chapucero).

No, voy a intentar contar con recursos suficientes y suficientemente capacitados para realizar la tarea que lleva completar el proyecto, ni más ni menos. Si he tirado los precios (por el motivo que sea) o el análisis/auditoría del evolutivo están mal hechos habré de asumir las consecuencias (o quizá no...).

AxelStone escribió:Sí señor, por ahí van los tiros. El proyecto ha durado más de 1 año de desarrollo y el evolutivo es de un par de meses, evidentemente no puedes condensar en pocos meses nuevas funcionalidades + refactorización completa.

Evidentemente puedes si el proyecto esta bien dimensionado. En cualquier caso, si tan spaghetti es el asunto y al cliente le han colado una mierda grandísima, haced vosotros lo mismo, total, que más dará y el que venga detras de vosotros que arrée (¿Ves?, quizá no haya que asumir las consecuencias).

https://www.youtube.com/watch?v=1S1fISh-pag

P4j4r0 N3gr0 escribió:

amchacon escribió:¿Vas a rescribir 100.000 líneas de código?

Si es necesario o apropiado, sí.

Me temo que no se ajusta a la realidad, o al menos no te mueves en el mismo entorno que nos movemos otros. Las cifras: proyecto con 70.000 líneas de código, desarrollado durante 2 años por un equipo de 4 personas. Ojo que NO todo el código está para tirarlo, sino solo la parte por la que pasaron 2 becarios, digamos la mitad del mismo (el resto es bastante decente).

Se plantea un evolutivo de 2 meses de duración (y presupuesto acorde) que afecta casualmente al 50% malo. ¿Me estás diciendo que en 2 meses puedes reescribir 35.000 lineas de código? Imposible, te lo digo ya. Lo más que puedes hacer es refactorizar las partes más críticas, léase establecer prioridades.

El problema no es de los becarios, sino de la persona que los ha supervisado, al poco tiempo tenia que haberles puesto las pilas, o te pones a hacer bien las cosas, o te pones a barrer ...

Lo mejor igual es que empieces de cero, costará ahora, pero a largo plazo saldras ganando.
Por cierto, reescribir 100.000 lineas de becario puede acabar el 10.000 lineas de código:

"Good developers may merge multiple code modules into a single module, improving the system yet appearing to have negative productivity because they remove code."
Fuente: https://en.wikipedia.org/wiki/Source_lines_of_code#Usage_of_SLOC_measures

PD: Yo acabo de tener un becario que ha hecho maravillas

AxelStone escribió:

P4j4r0 N3gr0 escribió:

amchacon escribió:¿Vas a rescribir 100.000 líneas de código?

Si es necesario o apropiado, sí.

Me temo que no se ajusta a la realidad, o al menos no te mueves en el mismo entorno que nos movemos otros. Las cifras: proyecto con 70.000 líneas de código, desarrollado durante 2 años por un equipo de 4 personas. Ojo que NO todo el código está para tirarlo, sino solo la parte por la que pasaron 2 becarios, digamos la mitad del mismo (el resto es bastante decente).

Se plantea un evolutivo de 2 meses de duración (y presupuesto acorde) que afecta casualmente al 50% malo. ¿Me estás diciendo que en 2 meses puedes reescribir 35.000 lineas de código? Imposible, te lo digo ya. Lo más que puedes hacer es refactorizar las partes más críticas, léase establecer prioridades.

Eso es trabajr mal al final, dar un producto malo a precio barato. El problema es de la empresa y quien lo contrata, no del becario ni el trabajador. Alguien con dos dedos de frente lo que haria es cambiar las partes malas, para que eso funcionara sin problemas, no meter parches a algo que no se puede ni coger. No va con mala leche, eh ?

Pues yo he sido becario y reconozco que hasta que empecé a programar lo que es hoy en día, me costó lo suyo...ahora bien, con esos errores tan graves no, desde luego (excepto una vez, que me pidieron adaptar un código ASP, siendo que se usaba ASP .NET y me lo pidieron echando leches, no me iba a complicar la vida y lo que hice fue copiar y pegar, mezclando una solución ASP con ASP .NET. No me sentí orgulloso evidentemente, pero es que si te lo piden de un día para otro, no te complicas la vida). Trataba de hacerlo lo mejor posible y es lo que así hice.

El problema viene que te piden prisas y resulta que te piden premura y "que funcione", no que "sea legible y demás". En casi ningún proyecto he visto eso, sólo que salga bien y ya después, con el mantenimiento "se verá". Entonces, depende la pericia de cada uno. Yo reconozco que cometí errores, como digo, pero vamos, si no hubiera tenido tanta premura, desde luego, habría tratado de hacer las cosas de otra manera. Y si encima nadie te enseña, pues aquí viene un poco los problemas (y menos si no te supervisan). No pueden pretender que si está hecho un producto a bajo precio tenga calidad, porque eso es imposible...y normal que ocurran estas cosas.

Afortunadamente, las cosas han cambiado y ahora programo muchísimo mejor, hago las cosas más legibles, las corrijo y lo que trato es que no den problemas. Lo que sí he hecho siempre ha sido poner comentarios, aunque pudieran parecer "accesorios". Yo pensaba en plan que si un compañero miraba mi código, al menos que se enterara "de qué iba".

Ánimo @Axelstone con la refactorización de código.

Y por hablar de barbaridades, aquí os pongo unas cuantas:

- Dos if iguales que hacían lo mismo.
- Poner String cadena.substring(0,2) en la mayoría de las cosas para hacer comparaciones en lugar de expresiones regulares.
- En lugar de poner en PHP row["nombre_columna"], lo ponía por row[7].
- Restar fechas de manera poco ortodoxa "a lo bruto".
- Este no es proyecto mío, pero en Sharepoint ponían una parte que se llamaba "SUPERPARCHE" y era simplemente un IF.
- Poner un INNER JOIN (esto con Access) en lugar de una consulta SQL normal y corriente (no era necesario, con el where y alias bastaba).
- Métodos que hacen lo mismo con el mismo nombre.
- Excepciones mal controladas que hacían que los procesos fallasen como escopetas de ferias.

Saludos.

Kurace escribió:Lo que sí he hecho siempre ha sido poner comentarios, aunque pudieran parecer "accesorios".

Espero que no sea de este estilo:



No, ¿de verdad?



POR FAVOR, no pongáis comentarios para decir lo mismo que el código

amchacon escribió:

Kurace escribió:Lo que sí he hecho siempre ha sido poner comentarios, aunque pudieran parecer "accesorios".

Espero que no sea de este estilo:

/* Devuelve el día de la semana
*/
public int getDiaDeLaSemana()

No, ¿de verdad?

if (puntos == 0) // Si tienes 0 puntos....
{
    //...
}

POR FAVOR, no pongáis comentarios para decir lo mismo que el código

No hombre . Yo sólo lo pongo en el método que no se entienda muy bien y en alguna parte complicada. Por eso digo lo de "accesorios".

Pero hay gente que no quiere leer código y te lo preguntan directamente .

Saludos.

amchacon escribió:Espero que no sea de este estilo:

/* Devuelve el día de la semana
*/
public int getDiaDeLaSemana()

La verdad manda huevos, porque incluso ese método se presta a detallar más:
/* Devuelve el día de la semana. 0=Lunes..6=Domingo
*/
Al menos que aclare la nomenclatura seguida, ya que por ejemplo en Java es muy habitual partir del 0 (mismamente la clase Calendar cuenta los meses de 0 a 11 si no me equivoco).

AxelStone escribió:

amchacon escribió:Espero que no sea de este estilo:

/* Devuelve el día de la semana
*/
public int getDiaDeLaSemana()

La verdad manda huevos, porque incluso ese método se presta a detallar más:
/* Devuelve el día de la semana. 0=Lunes..6=Domingo
*/
Al menos que aclare la nomenclatura seguida, ya que por ejemplo en Java es muy habitual partir del 0 (mismamente la clase Calendar cuenta los meses de 0 a 11 si no me equivoco).

Quizas lo mejor sería crear un objeto Dia_De_La_Semana y devolverlo.

Creo que a todos nos ha pasado que al ver nuestro propio código con unos meses de antigüedad hemos pensado "¿Qué es lo que pretendía hacer con esto?" o "¿Qué me fumé ese el día?".

Normalmente intento que el código sea simple, esté bien estructurado y sea lo más fácil posible de comprender. De hecho un compañero del trabajo me comentó en una ocasión que mi código no era "limpio" sino "aséptico".

En mi caso, la frustración no es causada por los becarios, ya que he trabajado con alguno que programaba bastante bien, sino mas bien por compañeros "con experiencia", que hacen código espagueti. En algunos casos, creo que hasta un mono puesto de crack hasta las cejas lo haría mejor.

Lo mejor es no quemarse ya que estas situaciones siempre van a ocurrir, con lo que habrá que apretarse los machos y tirar para adelante.

Cuando hay un error en producción:

Programador senior vs programador junior