En el interés de crear oportunidades de trabajo en el campo de la programación en Java, describo algunos consejos de como escribir código tan difícil de mantener, que las personas que vengan después de ti tardarán años en hacer los cambios más simples. Además, si sigues estás reglas religiosamente, te aseguraras tu empleo de por vida, ya que no habrá persona viva salvo tú que pueda mantenerlo. De nuevo, si sigues estás reglas demasiado religiosamente, ni tu serás capaz de mantenerlo.
|
etiquetas: codigo fuente , algoritmos , codigo mantenible , mantenimiento software 
qué sería de los curriculums inventados en este pais si no existiera github para hacer copia-pega y llamarte a ti mismo "programador"!!
www.meneame.net/story/opera-50-introduce-proteccion-antiminera-criptom
Choose variable names with irrelevant emotional connotation. e.g.:
marypoppins = (superman + starship) / god;
This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about.
También puede servir ser gallego del Barbanza y comentar cosas como: "instrución para aquelar o aquel de xeito que quede aqueladiño e evitar que estea aquelado"
Aunque si lo que quieres es que sea incomprensible, hay que hacer antes un curso de murciano.
Mejor pon if(false) y te ahorras un comparador
bofhers.net/blog/marrón-oscuro-el-idiotizador-cuarta-parte
Gran invento, el idiotizador...
TE TENGO EN MIS RECUERDOS **
borras .git
git init
git add .
git comit -m 'rama personalizada para xxxxx, primera version: hola mundo!'
La programación es un campo curioso porque a veces se da una especie de selección natural inversa. Por ejemplo, ¿por qué sigue habiendo tanto código en COBOL en la banca? ¿Porque COBOL era muy bueno? No, porque era un truño inmantenible y lleno de pequeñas rarezas y caprichos, y como resultado hay muchos programas en COBOL que nadie se atreve a migrar. Si el lenguaje hubiese sido más modular, legible y mantenible, seguramente ya no quedaría casi nada porque esas mismas virtudes harían mucho más fácil migrar el código a otra cosa.
En cualquier caso, algunas cosas que comenta suelen darse habitualmente. P. e., a veces para que algo funcione con un nuevo elemento, necesita que se toque código, configuración y base de datos. Si eres tú quien lo hizo, vas derecho, pero si ponen a otro, da palos de ciego.
Muchas veces los comentarios en el código son contraproducentes, porque explican qué hacía el código en su primera versión, pero se ha tocado luego tantas veces, que ese código hace otra cosa distinta a la que se comenta.
Lie in the comments
Huele a estafa a kilómetros.
Recuerdo algunos jefes de proyecto de mi etapa en Madrid, que veian las pull request / pair reviews como una perdida de tiempo y no nos permitian literalmente mantener la calidad, metiendo y sacando developers todas las semanas.
Luego claro, el fracaso es monumental, y la culpa, del equipo TECNICO.
Pero bueno de eso hace unos años, y de hecho en mi ultimo trabajo las pull requests eran revisadas de forma extrema, fue un shock al principio tanta paranoia sobre el source formatting. Espero que ahora la industria haya madurado bastante.
Leyendo por internet asi parece, pero me da la sensacion que las empresas que lo hacen bien hacen muchisimo ruido, como si sus buenas practicas fuesen lo habitual. Pasa lo mismo leyendo discusiones en s. overflow, parece que todos los programadores controlan y luego en la vida real, ya tal...
En la empresa donde trabajo había uno que se encargaba de desarrollar y mantener una herramienta que usábamos todos los días. Todos los cambios tardaban mil en implementarse, incluidas las soluciones a los fallos que cometían. Aún recuerdo una en la que hicieron imposible borrar cosas agrupándolas (y que antes funcionaba perfectamente), pues al día siguiente se reportó el tema y aún (2 años después) no lo han arreglado.
Primero porque el cabr** era más perro que Rintintín y segundo porque un año después de tan majestuosa obra, durante las revisiones salariales no le subieron el sueldo. Momento en que aprovechó para dárselas de imprescindible y su jefe acabó por cabrearse y ponerle de patitas en la calle. Pues ahora tienen a 4 programadores trabajando en mantener el programa y por lo visto tenía todo tan enrevesado y hecho para solo poder mantenerlo él que ahora los cambios van a dos por hora y tienen a cuatro personas en el puesto de una solo para entender que ha hecho.
....
If(variable == False)
Telacuelo() ;
Y donde estoy ahora les da igual de donde salga el código mientras funcione, si algún día hay problemas de licencia ya verán como solucionarlo.
Y aún así a veces te vienen a preguntar subnormalidades porque al que sea no le da por leerse el código de un programa de 200 líneas...
yondu = (marypopping + starship) / celestial
Vale que si son simples no pase nada, pero si tienes una compleja cadena de IFs, no es mala idea separarlo en líneas (alt+enter) y indentarlo con espacios.
Porque tenía un sueldazo que por indemnizaciones era almohadilla despedirlo, supo a lo largo de la historia de la empresa hacerse importante y pedir aumentos en el punto justo para ir haciéndose intocable.
El chico de oro, llevaba un proyecto para servers en Perl (1° ofuscación) y después era muy celoso de que tocaramos el código (pese a tener svn al principio y git después), tenía tabulaciones mezcladas en todo el código (2° ofuscación) y después el lío de código y que sólo el sabía de esa parte del proyecto ya era el remate.
Era tan celoso que a mí a base de reprimendas (porque no eran broncas) me fue apartando de mi idea de por lo menos que estuviera bien formateado el código, recuerdo que al principio en plan infantil le metía mano a "su código" cuando estaba de vacaciones, pero se enteraba cuando conocía y hacia un svn update (en aquellos tiempos).
Recuerdo cuando el jefe le enviaba novatos a intentar meter alguno más en el esa parte proyecto, y como los echaba con delicadeza y mareandolos.
Pero sabéis lo mejor, que el tío era buena gente, creo de los mejores compañeros de esa empresa, pese a que desapruebo esa forma de empoderarse, a costa de poner en una situación difícil a los compañeros.
Era buena gente, porque en otra que estuve, además de ser varios intocables en varias proyectos de la empresa, eran unos bordes y cabrones.
Claro, en cuanto termine el contrato voy fuera, porque no seré imprescindible.
Si a algún director técnico incompetente le cuelan así proyecto tos realizados por otros... Pues bueno.
El marzo nos vamos todos a la calle: www.meneame.net/story/eu-denuncia-euipo-contrata-servicios-informatico
La verdad, si hubieramos conocido la decisión de antemano no sé si nos hubieramos esforzado tanto en hacer el codigo tan mantenible. Normalmente haces codigo para que tu empresa y tu equipo lo disfrute. No para que otro país se lleve el beneficio y aprendan nuevas tecnicas gracias a nuestro código.
#46 Esa es la actitud. Mis dieses: 'Si me voy de esta empresa ya encontrare sitio en otra pq HAGO BUENOS PRODUCTOS.' Que te valoren por lo que eres, no por lo que escondes.
#68 Ni de palo tio; tu has aprendido y eso que te llevas. Ya saldran mas cosas y tu sabes mas cosas para ellas.
Esto de la programacion es aprender siempre, no poner tornillos.