Abner Ballardo

¡La programación es una parte vital de todo proyecto de desarrollo de software! Lamentablemente hay personas que creen que no es así y solo piensan en contratar mano de obra barata, dando como resultado proyectos con mas problemas de lo normales. En fin, ese es otro tema y lo trataré en otro artículo.

Hay diferentes formas de ver la programación:

  • Como algo que no te gusta pero tienes que hacerlo porque esta en tu curricula.
  • Como algo que no te gusta pero tienes que hacerlo para luego poder comenzar como programador pero dejarlo lo mas pronto posible para poder luego postular por un puesto de analista programador, analista, jefe de proyecto, etc.
  • Como algo que no te apasiona pero que tampoco te parece terrible hacerlo.
  • Como algo que te apasiona y te interesa aprender más y más.
  • Como un arte.

Este artículo va orientado para todos los apasionados por la programación y mas aun para los que ven la programación como un arte.

Las buenas practicas en programación han ido cambiando o adecuándose a través de los años con el nacimiento de nuevas tecnologías, nuevas técnicas y las nuevas necesidades. Lamentablemente muchos de los malos hábitos perduran y complican innecesariamente el desarrollo de software en la actualidad. En este artículo enumerare solo algunos de ellos y propondré que buenas practicas o técnicas se deberían seguir.

Nunca borres código! Solo tienes que comentarlo porque no sabes cuando lo necesitaras.

En este caso el programador cree ser clarividente, pitoniso, chaman o brujo. Luego de una serie de visiones tiene claro que va a necesitar mantener algún rastro del estado actual del código y no ha encontrado mejor solución que comentar el código que modificara (ya se de el o de otro). Continuará lineas mas abajo su trabajo, contento y feliz que su futuro sera mas tranquilo.

El programador tiene temor de modificar el código ya sea por que es novato o por malas experiencias anteriores. Por ello, trata de dejar un rastro del código anterior sin saber que este mal hábito iniciará o continuará el desorden y hará el código más y más difícil de entender.

Para dejar este mal hábito es necesario mejorar el autoestima del programador, tienen que confiar en si mismos!. Como apoyo, el histórico de los cambios al código debe ser gestionado por un controlador de versiones y se puede complementar con el uso de test cases para probar automáticamente el código y estar seguro de que los cambios que se hagan no afecten al sistema.

Dejar este mal hábito es difícil.

Imprime logs, más logs, más logs hasta que encuentres el problema.

En este caso el programador esta tan paranoico (debido al stress, sobre tiempo, etc, etc) que comienza a dudar de todo cuando no funciona algo en lo que esta trabajando. A veces dudan del IDE o del compilador o creen que por alguna razón mágica el string que contiene el password del usuario cambia y no por eso lo imprimen a cada rato. También hay casos donde los programadores liberan sus tensiones, frustraciones, odios a la empresa donde trabaja a través de mensajes sórdidos o sarcásticos en los logs. En casos muy extremos se encuentran tantas lineas de código de negocio que lineas de código para imprimir logs.

El programador esta utilizando una de las técnicas más antiguas de debugging: imprimir mensajes a stdout, stderr o a un archivo. El problema radica en que no eliminan esos logs luego de usarlos ya sea por flojera o porque creen necesitarlo en el futuro. Este mal hábito puede afectar la performance de la aplicación, complicar la administración y detención de problemas en producción, sin mencionar que se ve poco serio un sistema que tenga logs con bromas, insultos, etc.

Para dejar este mal hábito es necesario forzar al programador que borre sus comentarios luego de usarlos. Usar un framework para el manejo de logs es una muy buena opción pero también se debe explicar claramente su uso (por ejemplo: que son los niveles de log, etc.) La raíz de este problema es la necesidad de realizar debug, para ello recomendaría aplicar la técnica “make a test case instead of debugging”.

Dejar este mal hábito es difícil.

Funciones, procedimientos ¿para qué?. Todo en un sola función!

En este caso el programador puede tener una afición desmesurada por lo gigantesco, grande o tal vez tiene temor a crear nuevos métodos, clases o peor aún le da flojera crearlos. Muchas veces detrás de este mal hábito esta el deseo del programador de ser el único que sepa como modificar el código o quiere que sufra el siguiente programador que verá su código.

El programador al no aplicar la recomendación de divide y vencerás tendrá que convivir con la complejidad de su código. En el caso de lenguajes orientados a objetos perderá la potencia que le brinda la herencia, polimorfismo, etc. Este mal habito disminuye la calidad del código, dificulta el cambio o mejora del código y hace que el traspaso del conocimiento (de un programador a otro) sea una tarea imposible de realizar de manera satisfactoria.

Para dejar este mal hábito se debe iniciar al programador en Refactoring, Pre-factoring y de ser necesario por intravenosa! Al aprender sobre Refactoring es imposible no aprender también de patrones, asi que es necesario también conocer de patrones, refactorings to patterns, etc. Como técnica avanzadas en este campo tenemos aspect oriented refactorings, database refactorings, html refactorings, etc.

Dejar este mal hábito es difícil.

Copy & Paste es tu mejor aliado, úsalo siempre!

En este caso el programador cree que la mejor técnica de re-utilización de código es el famoso “copy & paste” (algunos lo pronuncian como “copy & page”). Esta es la manera mas fácil de complicar el desarrollo no solo para el que lo implementa sino también para los que verán el código fuente durante toda su vida útil. Ya que al copiar código ademas de tener más lugares donde dar mantenimiento también corren el peligro de copiar bugs. Un síntoma común es que si modifican alguna parte del código otro componente se cae!

El programador debe evitar usar “copy & paste” en la mayoría de casos! La re-utilización de código implica también tener un solo lugar donde realizar mejoras y cambios de tal manera que múltiples partes del sistema se puedan beneficiar de dichos cambios. Este mal hábito genera código inmanejable y facilita que surjan bugs, bugs y más bugs!.

Para dejar este mal hábito es necesario que el programador tenga una dieta de “copy & paste” y que aprenda sobre Refactoring y Pre-factoring.

Dejar este mal hábito es muy muy difícil.