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.
10 Responsesso far
He podido constatar en los últimos años, que muchos desarrolladores de Visual Basic no se han atrevido
Justo has citado mi caso, pq yo sé programar en visual basic 6, pero aun no me atrevo a programar en .net. Y la verdad es q no se a ciencia cierta por q aun no lo he hecho, algunas veces por temor a la complejidad, o tal vez a como me dijo alguna vez un profesor, si lo que quiers q haga lo hae visual 6, por q te vas a cambiar a .net – Una respuesta no tan profesional q digamos, pero algunas veces pienso q eso tal vez me detiene.
Por otro lado estaré a la expectativa de tu próxima entrega referente al tema.
Gracias
Muchas Gracias,
Espero con ansias la 3ª parte.
Me gustaría saber qué porcentaje de programadores de VB nos hemos quedado en la versión 6, o hemos cambiado a otro lenguaje distinto de .NET antes de aprender VB .NET
Yo me atrevería a decir que sólo un 20% ha cambiado a VB.NET
¿Qué opináis?
AMEN!!!….
triste pero cierto… muchas veces el lio de que vean mal a VB son los mismos que programan en VB :(…
VB RULEZ
Salu2
Ddaz
Fuí programador en VB6, Cuando empecé con .Net me costó enormemente (entendí la POO sobre la marcha). Y yo era de los que pensaba «¿Si con esto me sirve para que voy a aprender algo mejor?». Conocer las ventajas de VB.Net me hizo darme cuenta de lo equivocado que estaba. Es verdad que con VB6 se podía hacer. Pero mucho más lento y peor.
Llevo dándole desde hace un mes al C# y aún no entendí del todo porque se supone que es mejor que VB.Net. Llego a dos conclusiones.
a) todos esos gurús de la POO que Microsoft contrató para que les hiciese la plataforma .Net, no querían saber nada que sonase a VB (su «enemigo» por excelencia. Por eso el framework está echo en C#. Es decir por mera política.
b) No se porque es más potente si se compilan ambos en el mismo LI y utilizan el mismo framework.
c) Que queréis que os diga: VB.Net me parece más intuitivo.
d) El hacer buen o mal código depende más del método de hacerlo que del entorno que utilices. Puedes hacer mal código con C# (por muy bueno que sea el entorno.)
Es cierto, pero todo depende del programador, yo programo en VB 6 desde hace años y aun no me paso a los que es .NET
pero como reza el texto:
>> DIME COMO PROGRAMAS Y TE DIRE QUIEN ERES<< Saludos.
Visual Basic .Net no tiene nada que envidiarle a C#, se puede hacer lo mismo en ambos lenguajes, los que dicen que C# es mejor son ignorantes o no se que, pues no conocen bien el VB .Net.
¿Qué dice Microsoft?
Solo basta con echar un vistazo al White Paper «Differences Between Microsoft Visual Basic .NET and Microsoft Visual C# .NET» para darnos cuenta de que ambos lenguajes son considerados igualmente poderosos y que realmente no existen argumentos para suponer que alguno de ellos es superior. El siguiente párrafo ha sido extraído precisamente de la introducción de ese documento.
«Debido a las diferencias del pasado entre Microsoft Visual Basic, Microsoft Visual C, y Microsoft Visual C++, muchos desarrolladores tienen la impresión de que Microsoft Visual C# .NET es un lenguaje mucho más poderoso que Microsoft Visual Basic .NET. Algunos desarrolladores asumen que muchas cosas que son posibles en Visual C# .NET son imposibles en Visual Basic .NET; de igual forma en que muchas cosas que son posibles en Microsoft Visual C 6.0 ó Microsoft Visual C++ 6.0 son imposibles en Microsoft Visual Basic 6.0. Asumir esto es incorrecto. Si bien existen diferencias entre Visual Basic .NET y Visual C# .NET, ambos son lenguajes de programación de primera clase basados en el Microsoft .NET Framework, y ambos son igual de poderosos.
QUEDA CLARO NO?.
Saludos.
coincido 100% a la menos 1..o sea no estoy de acuerdo con tu opinion en ninguna de tus lineas….estoy cansado de que califiquen al programador por la facilidad o dificultad al programador…no te olvides que la programacion es un «negocio»…en todo negocio debe satisfacerse el «cliente»…y que los mas importante es cuanto capaz sos de hacer feliz a tu «cliente». Al cliente le importa si cuando te pide las cosas cumplis en tiempo y forma, le importa que seas capaz de comprender su «empresa», que tengas habilidad para no cometer «errores» sonsos. Lo de case sesitive es un dolor de cabeza para la programacion, no soluciona nada. Cualquier libro te recomienda no repetir nombres de variables para diferentes funciones. Seria loco declarar la variable «Tiempo» y otra que se llame «tiempo» jajaja…es comico y de muy mal programador. Por favor, basta de preocuparse por pavadas y mejor precoupense por lo que mencione antes «hacer feliz a su cliente». Para hacerlo feliz lo mejor es usar una herramienta sencilla, rapida, eficaz, de resultados rapidos. EL cliente no entiende nada, un carajo de programacion, ni de ordenadores, ni nada…lo unico que entiende que su produccion va a aumentar si la interfaz que desarrollo el programador es entendible y agil. Si a la mitad del uso no nace un problema como un cartel que diga «error nºA34B349832», o que se cargue basura en su base de datos. No olviden que el desarrollo tiene muchas etapas (proyecto, analisis, diseño, desarollo, depuracion y manteminiento. Tambien mas importante que el lenguaje es la atencion al cliente. POR FAVOR, BASTA DE TECNISISMO SIN SENTIDO, sean expertos en ESCUCHAR A SUS CLIENTES,y no en llenarse la boca de saliva hablando de programacion orientada a objetos, bajo nivel de programacion, funciones o metodos, si van a cerrar con un corchete o si es posible usar el mismo nombre de la variable gracias al «idolo» que se le ocurrio el famoso «case sensitive», que al final recomiendan no utilizarlo jamas.
Consejo: Sean excelentes analistas, arquitectos y programadores de software. Cuando su cliente hable escuchenlo que ahi esta la calidad de su producto. No piensen el sistema operativo si va a ser linux o «windows», el cliente va a usar el que sea con tal de sacarle provecho a la «compra». Busquen la herramienta que les traiga menos «dolores de cabeza» al momento de programar. Amplien la vision de un software y mirenlo como un producto que entra en un mercado de usuarios finales que poco entienden y menos les importa el proceso de fabricacion. Con VB o C# podes ser exitoso o fracasar. Y no olviden esto que es lo MAS IMPORTANTE. El mejor recurso son las personas, ni vb, ni C, ni POO, ni case sensitive, ni metodos, ni funciones. Su creatividad, originalidad, rapidez, inteligencia los va a destacar y los va a ser mas ricos o mas pobres. En el mundo hay demasiado contexto para estar enfocados en «tonterias».
Hola,
NO entiendo nada de esto. Es por ello que busco un programador de visual basic ,para aplicación industrial.
Favor de contactar vía mail, para poder ampliar información.
saludos.
domingo.mrn@gmail.com