En estos tiempos en los que es tan difícil encontrar un buen trabajo, una vez que se consigue hay que hacer todo lo posible por mantenerlo. Pero no es nada fácil: un buen programador debe mantenerse siempre actualizado, conocer todas las nuevas tecnologías que vayan saliendo, ser eficiente en sus desarrollos, generar un código limpio y fácil de mantener, etc.
O también puedes seguir el consejo del canadiense Roedy Green y volverte imprescindible a base de crear un código tan enrevesado que ningún otro programador sea capaz de mantenerlo y siempre tengan que acabar recurriendo a ti. Pero ojo, hay que ser lo suficientemente sutil para que el siguiente programador no piense que es mejor idea reescribir tu código que modificarlo.
Por eso Green nos ofrece su guía sobre «Cómo escribir código inmantenible». Una extensa pero imprescindible lectura en la que nos da multitud de consejos acerca de diversos aspectos de la generación de código:
- Nombrado. Usa variables con nombres parecidos y sin significado, como
asdf,asfd,xy_zoxy_Z. También da buen resultado utilizar nombres que por su significado nos distraigan del verdadero uso de las variables, y así obtener sentencias tan obtusas comoparentesis = ( igual + mas ) / por;
- Camuflaje. Aprovéchate de que el ojo humano no ve el código igual que el compilador, e intenta engañarlo escondiendo información importante, como colocar entre una inmensidad de comentarios una macro extraña como
#define a=b a=0-b - Documentación. Si mientes en tu documentación, mantienes versiones antiguas de la misma que ya no se ciñan al código, o te dedicas a documentar sólo las instrucciones más obvias, conseguirás que el encargado de mantener tu código pueda estar entretenido intentando adivinar si es tu código o tu documentación el que está equivocado.
- Diseño del programa. No valides nunca los datos de entrada, usa innecesariamente clases amigas o atributos estáticos, crea dummies que no valgan para nada, haz que todos tus atributos sean públicos y todas tus clases finales… ¡La diversión está asegurada!
- Ofuscación de código. Incluir 3 ó 4 sentencias en una misma línea no sólo la hace ilegible, sino que además te hace parecer un gurú. Combinado con un exceso de puntos y comas, llaves y paréntesis, puede convertir tu código en toda una experiencia visual para otros programadores.
- Ambigüedad. Usa nombres de métodos como
manejaroprocesarDatos, que ofrecen una información casi nula acerca de su comportamiento. - Otras técnicas. Da rienda suelta a tu imaginación, todo vale. Por ejemplo, define las constantes
TRUE = 0yFALSE = 1y haz que todos tus condicionales las usen para alterar el significado de la sentencia.
No olvidéis que la guía está escrita de modo sarcástico, y si por algún motivo queréis llevar sus consejos a cabo, guardaos al menos una versión “no inmantenible”, por si vosotros mismos sois los pringaos a los que les toca modificar ese código.
Vía | fht233
Más información | How to write unmaintainable code
En GenbetaDev | Ofuscación de código, el antipatrón por excelencia
Comentarios
interesante
Efectivamente, así lo mejor que puedes conseguir es código que ni tu mismo puedas mantener!
la mejor manera de mantener tu puesto de trabajo es hacerlo bien, todo lo que escribiste más allá del primer párrafo te lo podrías haber ahorrado
interesante
Por si no quedaba suficientemente claro, en el último párrafo he dicho explícitamente que el contenido de la guía es sarcástico. Pero eso no quiere decir que sea inútil, al contrario, conviene conocer todos esos antipatrones para no repetirlos nunca.
eh... me parece a mi que estás un poco equivocado. Puede que lo hagas muy bien, pero si son 20 programadores no se pondrán a ver el código que hace uno a uno, despiden a 10 por obligación y listo, y ahí no vale llorar "pero si yo lo hago bien" ... Con esto no quiero decir que sea ético o moral lo que se comenta, pero tampoco es buscar el "lado bonito" que planteas, porque en los tiempos actuales tampoco es algo seguro lo que tu comentas.
Saludos
Eso no es escusa para hacerlo mal adrede. Yo prefiero ser valorado por lo bien que lo hago y lo que aporto que porque soy "imprescindible" y yasta porque sólo yo soy capaz de hacer mi trabajo.
-- editado por última vez a las 21:03
Si una persona lo hace igual mejor que vos y más barato ya me decís donde queda el imprescindible. Que no digo que esté bien, ni lo defiendo, ni mucho menos, a lo que voy es que no se valora lo que se tiene (el empresario) pero bueno... :)
Me mantengo en lo que he dicho: "Yo prefiero ser valorado por lo bien que lo hago". Y eso, creeme, es MUY difícil de sustituir y muchas veces imposible. Si aun así la empresa te tira entonces es la empresa quien tiene un problema, no tú.
Un saludo.
-- editado por última vez a las 00:06
Espero de veras que mis compañeros de trabajo no lean nunca este artículo. De momento van por la fase de plagar el código de GoTo y de meter más de 2000 líneas de código en el manejador de evento del botón que se llame Aceptar (sí, yo soy el pringao que mantiene el código).
Muy bueno lo de encadenar sentencias en una sola línea de código. Eso lo he visto muchas veces en internet: Un tío escribe 5 ó 6 sentencias en la guarda de un bucle for, con la intención de quedar como un Master Ninja de la programación, y sólo consiguiendo quedar como un auténtico GILIPOLLAS.
Jaaaaaaaaaaaaaaajajajaajaj
No se puede considerar programador a una persona que NUNCA se haya tenido que enfrentar a un código inmantenible, y que además, tenga un jefe que te diga "aprovecha el código y en media horita lo tienes". :-)
Yo, para que nadie se confunda de que hago en la empresa, todas mi ropa tiene el mismo color: el marrón, jeje!!
interesante
Yo no necesito aplicar éstas técnicas... ya programo así naturalmente. jajaja.
Yo siempre escribo código que solo puedo modificar yo, así me aseguro trabajo y si hay algún problema no me roban código.
interesante
Eso es un poco rastrero, más que nada porque no da buena imagen de ti. ¿Te has parado a pensar que pasaría si cambias de empresa? El que venga detrás tuyo, comentará la situación y se creará una mala imagen que puede perseguirte. El mundo es un pañuelo lleno de mocos , me dijo alguien algún día. Y no sabes lo que puede pasar al día siguiente.
Mi consejo es que hagas software de calidad, bien comentado, etc. Aunque prescindan de ti, los que vengan verán un buen trabajo y aunque creas que no, ese buen trabajo será transmitido hacia arriba.
No todo el mundo es capaz de diseñar buenos sistema, por mucho que hayan heredado código y este sea excelente.
Una palabra lo resume todo: KISS.
Sin llegar a estos niveles, si no me lo pidieran todo para ayer, y no me estuvieran cambiando las especificaciones y las fuentes de los datos cada 48h, seguro que la calidad de mi código sería infinitamente mayor.
No es necesario complicarte la vida ofuscando código para que nadie lo entienda, solo tienes que ponerte a programar un día que no estés muy concentrado y volverlo a mirar al día siguiente. Ahora en serio, se podrían escribir varios libros con las burradas que nos podemos encontrar en las lineas de código, y los comentarios que ponen los que lo han programado.
Creo que en mi empresa siguen este manual al pie de la letra. Todos los punto que comenta la entrada es el patrón 100% de mis compañeros. Cosa que evito y se ve claramente código de calidad cuando me toca hacerlo a mi. Así se con seguridad que desarrollo y que no. Además de que soy bastante pijo con el código.
Jajaja, me interesa ese concepto. ¿Qué es ser pijo con el código? Porque imagino que no será llamar a las variables _gucci, _tommyHilfiger y cosas así, ¿no? =P
jejejeje no, me refiero a que me gusta que esté ordenado, autodocumentado y lo más limpio posible. Algunos lo ven como "ser pijo" picando código.
Yo en mi actual empresa, he visto cosas así y la persona que lo hizo ahora mismo esta en la calle, osea que no funciona os lo advierto jaja.
Hey, gracias por el credito! aunque sea para mi usario anonimo de usar y tirar.
Un buen sistema para no tener que recordar todo eso es programar en PERL. El unico lenguaje en el que el codigo tiene el mismo aspecto despues de encriptarlo.
Escribir un comentario
Para hacer un comentario es necesario que te identifiques: ENTRA o conéctate con FacebookConnect