La anarquía de los programadores de Visual Basic (II)
[Ref.: La anarquía de los programadores de Visual Basic (I)]
En todas las oportunidades en las que tuve la posibilidad de hablar de .NET cuando éste apareció por primera vez, comenté que era importantísimo para el desarrollador tener muy claro los conceptos base de la programación orientada a objetos. Daba igual que hubiera decidido dar el salto a .NET en ese instante o más adelante, independientemente de esto, era muy valorable que comprendiera los conceptos de la orientación a objetos.
Un desarrollador de Visual Basic puede entrar en el mundo de .NET sin tener ni idea de programación orientada a objetos, pero le costará mucho más esfuerzo comprender algunos de los mecanismos fundamentales del desarrollo de aplicaciones en .NET que un programador que tiene esos conocimientos ya asentados. Además, mantener y entender el código le resultará una odisea en un primer momento.
Sin embargo, hay algo intrínseco a los desarrolladores de Visual Basic en general, y es esa anarquía que siempre hemos tenido a la hora de desarrollar aplicaciones en .NET. Gracias a esa anarquía, hemos logrado construirnos una gran fama según la cual, un desarrollo de Visual Basic no puede poseer una calidad adecuada por estar escrito en eso, en Visual Basic. La frase de que en Visual Basic puede desarrollar cualquiera denota bajo mi punto de vista, cierta ignorancia o desconocimiento respecto al propio desarrollo del Software con Visual Basic. El auténtico mérito de Visual Basic ha sido hacer fácil lo que para muchos era difícil, el desarrollo rápido de aplicaciones Windows. De hecho, gracias a Visual Basic, tenemos hoy una gran cantidad de lenguajes de desarrollo visuales.
La anarquía que aquí comento no obstante, tiene o puede tener su origen en diferentes fuentes, y una de esas fuentes es el hecho de que Visual Basic no es case sensitive, es decir, podemos declarar una variable como variableDeclarada y otra variable como variabledeclarada, y el entorno nos dará un error indicándonos que no se puede declarar la misma variable dos veces.
Otra característica que voy a comentar ahora es algo que no le gusta escuchar a mucha gente, sobre todo a los desarrolladores de C#, pero que es así como lo voy a contar, y es lo que en Visual Basic se denominan métodos y funciones. Para un desarrollador de C#, todo son métodos. Para un desarrollador de Visual Basic, los métodos no son funciones, y las funciones no son métodos. Es decir, un método no devuelve nada, y una función por su propia naturaleza, devuelve algo. Esto que parece muy poco importante, genera a veces discusiones interminables, y en otros casos, impiden que un desarrollador de Visual Basic entienda perfectamente lo que se indica en un libro o el comentario del código de una aplicación. En mi modesta opinión, me gusta más como se plantea esto en Visual Basic que en otros lenguajes de programación como C#, pero sé que no todo el mundo estará de acuerdo conmigo con esta afirmación.
Además de todo esto, en otros lenguajes de programación como C# hay algunas cosas que el propio compilador no deja hacer. Con Visual Basic, esas mismas cosas que no se pueden hacer con C#, sí se pueden llevar a cabo con Visual Basic, en buena parte para ayudar a los desarrolladores que vienen de Visual Basic 6.0 o anteriores.
Algunas de esas libertades que se pueden hacer en Visual Basic para .NET y que se permiten hacer por compatibilidad, no hacen nada más que alargar y ser más permisivos con esa anarquía de la que hablo. De todos los modos, aconsejo a quien lea esto, que abandone el uso de instrucciones mantenidas en Visual Basic para .NET por compatibilidad. Así por ejemplo, si utilizamos MsgBox() en lugar de MessageBox.Show() tendremos el mismo efecto, y el compilador se encargará de cambiar MsgBox() por MessageBox.Show() en la compilación, pero la lógica nos invita a sustituir MsgBox() por MessageBox.Show() en nuestro código aunque sea un poco más largo de escribir. Sin embargo, veo en muchos ejemplos de código para .NET en Internet, incluso en ejemplos mostrados por responsables del lenguaje Visual Basic, el uso de MsgBox(), algo que personalmente me irrita.
Pero con todo y con esto, es importante que el desarrollador de Visual Basic trate de minimizar al máximo la anarquía que tiene a la hora de escribir código sacando provecho eso sí, de las bondades de Visual Basic como lenguaje. Es en sí, responsabilidad del desarrollador. Pero no sólo se le puede achacar la responsabilidad de esta decisión al desarrollador, sino también a todo el equipo de desarrollo, desde su Jefe de Proyecto hasta el programador. A veces las decisiones vienen impuestas, y no sería la primera vez que se obliga a trabajar de una forma caótica porque así se lleva haciendo desde hace muchos años y no se va a cambiar ahora que todo el mundo está acostumbrado a trabajar así (esta frase la he oído tantas veces…).
De esa manera, podríamos dar una serie de consejos y pistas iniciales para tratar de evitar en lo posible esa anarquía. Los siguientes consejos, los considero básicos para hacer frente a un desarrollo con Visual Basic en .NET.
Además de comprender y conocer la base de la orientación a objetos, es bueno que escribamos el código de nuestras aplicaciones basándonos en primer lugar en una adecuada nomenclatura de código. El uso de una adecuada nomenclatura de código ayuda a que todo el mundo escriba aplicaciones .NET de una forma homogénea, o al menos lo más homogénea posible, de modo que el mantenimiento de las aplicaciones sea lo más efectivo y práctico posible. La reutilización de código aquí no tendría ningún riesgo, y sería trasparente al propio desarrollo del Software.
La gestión de errores debe realizarse siempre que se pueda de la misma forma, de manera que siempre que desarrollemos una nueva aplicación sepamos tener unas directrices generales sobre la gestión de errores que aplicaremos en todos nuestros desarrollos.
Con posterioridad tendremos que aplicar un conjunto de acciones como por ejemplo las pruebas unitarias. Las pruebas unitarias son o deben ser tan importantes como el propio desarrollo. Aún mucha gente no entiende esto, pero es esta una fase más del desarrollo del Software que es obviada en muchos proyectos, y su importancia es vital.
A veces, podemos utilizar herramientas externas para analizar el código tratando de que este tenga una calidad aceptable, no sólo en cuanto a su nomenclatura, sino en cuanto a líneas de código escritas por método o profundidad del código, etc. Recuerden todos esto… ¡Refactoring existe!.
En resumidas cuentas, no es que estos pequeños consejos nos ayuden a eliminar o erradicar la anarquía que los desarrolladores de Visual Basic tenemos a la hora de desarrollar nuestras aplicaciones, de hecho podríamos seguir enumerando más consejos muy importantes todos ellos, pero sí es cierto que estas pequeñas ayudas nos permitirán asentar las bases de cualquier desarrollo. La práctica y la prueba/error harán el resto… nadie hemos nacido enseñados.
Entonces, ¿cuál es la frontera entre anárquico y estricto a la hora de escribir el código para nuestras aplicaciones Software en Visual Basic para .NET?. En mi opinión, cuando un desarrollador de Visual Basic para .NET escribe una aplicación, debería pensar en que esa aplicación es para .NET, por lo que cualquier desarrollador de la plataforma .NET podría mantenerlo, y ese desarrollador no necesariamente debería venir del mundo Visual Basic, incluso podría venir del mundo C# por poner un ejemplo. El programador de Visual Basic para .NET debería evitar por lo tanto el uso de librerías de compatibilidad incluidas en .NET para facilitar a los desarrolladores el paso de Visual Basic 6.0 a .NET. El motivo principal es el mantenimiento de las aplicaciones y en otros casos incluso, el rendimiento de las mismas.
Muchas de las criticas que recibimos los desarrolladores de Visual Basic es que debido a esa fama anárquica que nos hemos ganado a veces escribiendo el código de nuestras aplicaciones en ese lenguaje, muchos piensan erróneamente que las aplicaciones escritas en Visual Basic no se merecen ese respeto que sí tienen otros lenguajes, que las aplicaciones escritas en Visual Basic no poseen una calidad respetable, que los desarrolladores de Visual Basic no sabemos realmente programar, que las aplicaciones de Visual Basic no son tan potentes como una misma aplicación escrita en C# por ejemplo, o que con C# por ejemplo, se pueden hacer más y mejores cosas que con Visual Basic. Siento mucho citar en varias ocasiones C#, pero quiero que se entienda que todas esas afirmaciones, por mucho que se repitan, son mentiras. Lo que sí es cierto es que muchos programadores de Visual Basic, han o hemos sido tan anárquicos al escribir nuestras aplicaciones Software, que nos hemos ganado con pulso algunas injustas dudas depositadas en Visual Basic como lenguaje de programación, pero solo eso.
Como dice un dicho, créate fama y échate a dormir.
En otras futuras entradas, tengo previsto hablar de algunos aspectos relacionados con el camino hacia .NET que deben, en mi opinión, emprender los desarrolladores de Visual Basic 6.0 hacia .NET, así como temas o aspectos relacionados con la migración de aplicaciones de Visual Basic 6.0 hacia .NET.