No utilices el martillo de oro

Hoy me apetece relatar las consideraciones que hay que tener en cuenta a la hora de escribir código.

Todos los que programamos tenemos ciertos vicios creados y es dificil prescindir de ellos, puesto que según el antipatrón de diseño del martillo de oro cuando un martillo funciona todo te parece un clavo :) y es prácticamente imposible eludir esa norma, así que desde mi humilde opinión voy a mencionar algunas ideas que a mi me han valido.

* Piensate bien las cosas antes de actuar, pero no dejes que eso te paralice, una aplicación sana comienza en la base de datos y termina en la interface de usuario sin descuidar ninguno de sus puntos intermedios, un error de diseño en cualquier paso será como una pequeña piedrecita, pero se convertirá en una enorme losa de granito al final del desarrollo, como nadie es perfecto, refactoriza frecuentemente, no dejes que la losa te aplaste.

* Utilizar un lenguaje de marcas al generar la interface siempre es una buena idea, aunque si el tamaño de la aplicación lo merece, es mucho más recomendable utilizar un motor de plantillas, esto facilitará mucho la comunicación entre el equipo de programación y de diseño.

* Tampoco estaría mal tener un método rápido y sencillo para generar todo el código que vaya al servidor, de la misma forma que se genera el x?html si va al servidor no es más que mera presentación, por qué no darle el mismo trato al html?

* $Deity nos coja bien follados confesados en las depuraciones bajo internet exploiter, como su propio nombre indica es una bestia indomable e impredecible, en este caso conviene atarla bien atada con una dtd, para que el quirks mode no haga de las suyas, o pasar de dtd, ponerte el gorro mejicano y que comience el rodeo.

* Estudia tus necesidades e intenta casarte lo mínimo posible con cualquier tecnología, a no ser que necesites rendimiento, entonces cásate con cuantas quieras, siempre que las hagas modulares, si formas amalgamas es probable que cuando haya que cambiar por una chinita en el camino, la losa te aplaste.

* En realidad cuando uno es buen programador encuentra caminos fáciles y concretos y camínos difíciles y genéricos, siempre hay que buscar al fantasma de la sobreingeniería y resolver el problema con el grado de complejidad correcto, un exceso costará más, pero lo más probable es que cuando se implemente la parte que sobró haya que adaptar la interface o que esa parte nunca se use, un defecto llevará a una refactorización, ya sea para adaptar interface o ampliarla, en cualquier caso la parte a + b parece mejor opción, sobre todo si la parte b no se conoce en el momento de la generación del código, por qué implementarlo si no se sabe ni como ni cuando se va a usar?

Me dejo todo un libro en el tintero, pero, cuando uno tiene estudios aprovechados, dos dedos de frente o un buen proyecto, aprende todas estas cosas enseguida, para el resto de los mortales son los misterios del exito del código de otros y no son más que cuatro recomendaciones básicas, así que recuerda, no utilices el martillo de oro