Sino sabes inglés no eres un programador

Leyendo blogs en el RSS atrasados por culpa de mis vacaciones y otras cuestiones, me encuentro un post de Scott Hanselman, en el que se comenta si hace falta saber inglés para programar.  Esta es una cuestión que siempre está en mi cabeza y creo que en la de muchos. Quizás no te haga falta saber inglés  para programar, aunque siempre se aprende, ya que todo el framerwork de desarrollo está en inglés por ejemplo: using System; Lo usamos como si fuera español estando en ingles, y sabemos su significado.


Pero, ¿hay que ir más allá? Yo creo que sí (incluso por abrirte puertas), creo que los que quieren estar a la ultima y avanzar deben tener mucho más nivel que lo basico del idioma de Shakespeare, para poder leer los comentarios de la MSDN en ingles (lo siento odio el traductor ese que tienen), leer blogs (aunque creo que en este sentido hemos mejorado bastante habiendo cada vez más difusión en español), escuchar conferencia, escribir o simplemente poder comunicarte con alguien fuera de tu país en este mundo cada día más global.


El problema que reside en España, es que llevamos toda la vida estudiando inglés y toda la vida sin tener ni idea de inglés. 


Como resumen, nivel de ingles alto para programar creo que no, cada vez hay más documentación en español, pero nivel alto para estar a la última en programación, indispensable. ¿Lo mejor? creo que nivel medio como minimo para ser un programador


¿Qué opináis?


 

DataSets, DataTables y cambios continuos

Siempre recordaré cuando jugábamos de pequeños, en todos los grupos siempre había un “listillo” o “aventajado” que cuando estábamos en plena partida siempre se inventaba alguna nueva regla o norma para intentar ganar, eso siempre nos obligaba a hacer cambios en nuestras estrategias, para intentar ser el ganador del juego.


Algo parecido me ha pasado desde que trabajo con datos, primero con los recordsets de VB y ahora con los datasets y datatables del Visual Studio .net; es decir, siempre accediendo a los datos de las consultas a través de cadenas de texto, pero claro siempre hay un “listillo”, en estos casos los administradores de bases de datos o los jefes o cualquier persona con poder suficiente para decirte: “bien ahora que tienes el campo Codigo de la tabla clientes que seguro que usas en 3 sitios muy concretos, se va a llamar Id_Cliente, así que en 1 hora estará todo cambiado, así que venga a por ello”. Tu como buen, rápido y eficiente empleado ctrl + h o replace “Codigo” por “Id_cliente”, justo cuando lo vas a hacer cumpliendo plazos (te sientes el rey del mundo), te das cuenta de que “mierda a quien se le ocurriría poner como campo principal de la tabla proveedores Codigo también”, mi gozo en un pozo, ahora toca revisar todos los códigos y ver donde se puede cambiar. Tras las 8 horas de rigor llega el jefe y te pregunta: “Que ya acabaste eso?, si es un cambio sencillo, se hace de 2 patadas”, y tu acordándote de la persona que le cambio los pañales.


Seguro que esta situación la hemos vivido, la vivimos y la viviremos muchos desarrolladores en nuestro dia a día.


Una forma que hace tiempo “descubrí” se trata de un pequeño truquito, que gracias al EDM averiguamos, es, crear un enumerador por cada tabla de la BBDD con todos los campos de la misma, entonces cuando queremos acceder a un campo tenemos que hacer algo como:


String field = dTable.Rows[0][Clientes.Codigo.ToString()].ToString() //Accedemos al valor de la fila 0, de la columna código de un datatable


Si ya tenemos una clase con los datos de las columnas (segun el modelo de aplicacion que usamos en Maldivas) , podemos insertar un enumerador que se llame por ejemplo Fields y que contenga lo de antes. Esto tiene una pega y es que los que useis FxCop os dara un warning en la definición de la clase por tener el enumerador dentro de la clase, entonces nos quedaria así:


String field = dTable.Rows[0][Clientes.Fields.Codigo.ToString()].ToString()


Con esto podemos estar preparados para cuando llegue el malvado administrador de base de datos o tu jefe y diga: “Cambia el campo”, y con un simple refactoring del enumerador, tendríamos en todos los sitios del programa nuestro campo cambiado.


Ahora llega el momento de los “menos trabajadores” que estarán pensando, ya pero claro yo que tengo 1000 tablas de 1000 campos cada una, tengo que mantener eso….¡¡¡INMANTENIBLE!!! Para eso tenemos una herramienta que se llama CodeDom, desde la cual se puede generar código simplemente leyendo información de la base de datos, generando el fichero de código a través de los datos obtenidos de las columnas.


Otra ventaja que tenemos con este metodo es que tenemos un “intellisense” para poder acceder de forma facil a los campos que queremos que contenga la fila.


Otra forma de resolver este metodo es creando constantes de tipo string y con el nombre del campo como valor de la constate. Esto tiene algunos problemas, mucho lio, muchas variables, y que perdemos ese intellisense que con el otro caso tendríamos.


Espero que os sea de utilidad y si conoceis otros metodos que sirvan para resolver este tema, me encantaria comentarlo con vosotros.

Los analistas no son dioses (pero casi)…

Una pregunta que siempre me hago a mi mismo es: ¿Se debe dedicar mucho tiempo a analizar los requerimientos de una aplicación? o ¿es mejor  pasar mas rápido y volver siempre atrás para no perder mucho tiempo en analizar?, con esto me refiero también a los sprint planning meeting de scrum.

Una cosa que no me gustan y que me ponen de mala leche, son los continuos cambios y el “volver” siempre a re-re-re-re-re-hacer lo mismo, porque un analista o analista-programador, por no querer “perder” mucho tiempo dice el primer día: “Hay que hacer las cosas así A-B-C”, (como dijo mi profesor de autoescuela), la primera impresión es la que cuenta. El 2º día cuando lo ve dice: “pero como está hecho esto asiiii no sirve porque es B-A-C”, ya pero me dijiste que lo hiciera así pero bueno a re-hacer toca. 3º Día: “Como esta echo asiiiiiiii si es C-A-B ahora que me acuerdo ” aggggggg otra vez noooooo. No hubiera sido más fácil que el analista tomara aire, pensara 10 min, reflexionara un poco todos los aspectos y dijera: “Después de analizarlo fríamente, despacio tienes que hacerlo así: D-J-K” , hubiera ahorrado mucho tiempo, dinero y quebraderos de cabeza.

 

Sé que los analistas no son dioses, pero deberían serlo?, con esto que ahorraríamos? muchas veces creo que tiempo, esfuerzo y sobre todo alguna reprimenda a muchos desarrolladores por no tener algo tan sencillo y rápido que se hace en 1 día (sabiendo que es lo que hay que hacer y cómo hacerlo claro).