NTC

6 Años

4 Comentarios

Cuando solo tenes un martillo...todos son clavos

Asi como nos quejamos de los que modelan y decimos "los que saben RUP aplican RUP a todo"...y los que desarrollan? No se escucha decir que "los que saben OO aplican OO a todo".

Cito un comentario que me llamo la atencion:

[ "con un diseño orientado a objetos que cumpla..."

Parece que damos por sentado que hay que utilizar un diseño orientado a objetos.

Los "novatos" tenéis que saber que también se puede utilizar una buena programación estructurada y procedural, y no utilizar un diseño orientado a objetos. Incluso aunque utilices un lenguaje orientado a objetos (Java, C++, etc.), no es necesario que utilices un diseño orientado a objetos, puedes utilizar un diseño estructurado y procedural.

"no utilizan herencia ni interfaces"

¿Acaso es obligatorio utilizar interfaces? Esta moda de ahora de utilizar interfaces, por ejemplo "por si cambiamos la base de datos por otra cosa" es típica de alguien que se ha leído muchos documentos "modernos" de los que circulan por Internet pero tiene poca experiencia en una empresa real.

Enterémonos: NADIE cambia la base de datos por otra cosa, y, si se cambia, te aseguro que el menor de los problemas será el haber usado o no interfaces. Es realmente absurda la costumbre de hacer siempre dos fuentes: uno con el interface y otro con la implementación.

Los interfaces están bien cuando necesitas herencia múltiple (que no existe en Java), pero es absurdo usarlos "por si nos cambian la base de datos por otra cosa y tenemos que modificar la implementación". ]

7 Años

0 Comentarios

Tipos de parametros en C#

Ayer hablando con Ricardo me recordo que nunca me quedo clara la diferencia de pasar parametros en C# usando ref y out. Le pregunte al Subcomandante y me aclaro algo pero no de un modo muy academico que digamos, asi que volvi a un libro grandoooote que tengo de C# y esto es lo que encontre...


Parámetros de salida

Un parámetro de salida se diferencia de uno de entrada en que todo cambio que se le realice en el código del método al que pertenece afectará al objeto que se le pase al llamar dicho método tanto si éste es de un tipo por valor como si es de un tipo referencia. Esto se debe a que lo que a estos parámetros se les pasa es siempre una referencia al valor que almacenaría una variable del tipo del objeto que se les pase.

Cualquier parámetro de salida de un método siempre ha de modificarse dentro del cuerpo del método y además dicha modificación ha de hacerse antes que cualquier lectura de su valor. Si esto no se hiciese así el compilador lo detectaría e informaría de ello con un error. Por esta razón es posible pasar parámetros de salida que sean variables no inicializadas, pues se garantiza que en el método se inicializarán antes de leerlas. Además, tras la llamada a un método se considera que las variables que se le pasaron como parámetros de salida ya estarán inicializadas, pues dentro del método seguro que se las inicializa.

Nótese que este tipo de parámetros permiten diseñar métodos que devuelvan múltiples objetos: un objeto se devolvería como valor de retorno y los demás se devolverían escribiéndolos en los parámetros de salida.

Los parámetros de salida se definen de forma parecida a los parámetros de entrada pero se les ha de añadir la palabra reservada out. O sea, se definen así:

out

Al llamar a un método que tome parámetros de este tipo también se ha preceder el valor especificado para estos parámetros del modificador out. Una utilidad de esto es facilitar la legibilidad de las llamadas a métodos. Por ejemplo, dada una llamada de la forma:

a.f(x, out z)

Es fácil determinar que lo que se hace es llamar al método f() del objeto a pasándole x como parámetro de entrada y z como parámetro de salida. Además, también se puede deducir que el valor de z cambiará tras la llamada.

Sin embargo, la verdadera utilidad de forzar a explicitar en las llamadas el tipo de paso de cada parámetro es que permite evitar errores derivados de que un programador pase una variable a un método y no sepa que el método la puede modificar. Teniéndola que explicitar se asegura que el programador sea consciente de lo que hace.

Parámetros por referencia

Un parámetro por referencia es similar a un parámetro de salida sólo que no es obligatorio modificarlo dentro del método al que pertenece, por lo que será obligatorio pasarle una variable inicializada ya que no se garantiza su inicialización en el método.

Los parámetros por referencia se definen igual que los parámetros de salida pero sustituyendo el modificador out por el modificador ref. Del mismo modo, al pasar valores a parámetros por referencia también hay que precederlos del ref.

7 Años

2 Comentarios

Diferencias entre programadores Junior, Semi Senior y Senior

¿Cuáles son las principales diferencias entre un programador junior, un semi senior y un senior?

Me contaron que un ingeniero amigo de un ingeniero amigo consiguio trabajo en una respetable empresa de desarollo de software a nivel internacional como semi senior en Java. Entonces me llamo la atencion como estratifican estas cuestiones de mortal, semi dios y dios, y mas o menos asi:

Experiencia laboral

Cantidad de años de experiencia laboral en informática.
No cuentan los trabajos prácticos realizados durante sus estudios. Tampoco suma si la persona trabajó 2 años atendiendo una agencia de viajes.

Junior: Menos de 2 años de experiencia.
Semi Senior: De 2 a 6 años de experiencia.
Senior: Más de 6 años de experiencia.

Conocimientos técnicos

Principalmente referido a las herramientas, tecnologías, lenguajes de programación, paradigmas de programación, base de datos, arquitecturas, etc. que deba utilizar para cumplir sus labores.

Junior: Para desempeñarse suele requerir acompañamiento. El código que genera puede presentar mayor cantidad de bugs de lo esperado. Probablemente no maneja todas las herramientas que se necesitan para la tarea.
Semi Senior: Técnicamente autosuficiente. Puede desarrollar funcionalidades más complejas y ejecutar proyectos de mayor envergadura. Pero no es un crack y todavía comete errores “evitables”.
Senior: Es referente técnico dentro del equipo. Su conocimiento le permite colaborar en definiciones arquitectónicas y desarrollar los proyectos más desafiantes. Su código funciona, es bueno y fácil de mantener.

Conocimientos funcionales

Relacionado a los procesos, metodologías, estándares, circuitos requeridos para cumplir sus labores.

Junior: Para desempeñarse suele requerir cierto nivel de acompañamiento. No conoce todos los procesos, ni los estándares. No es experto en los temas propios del negocio.
Semi Senior: Maneja los circuitos lo suficiente como para desempeñarse. Respeta los estándares y metodologías. Conoce buena parte de los procesos del negocio.
Senior: Ayuda a definir procesos, metodologías, estándares y circuitos. Por supuesto cumple los existentes.

Proactividad

Indicando si la persona espera a que le asignen sus tarea o si por el contrario toma una actitud de mayor iniciativa.

Junior: Necesita que frecuentemente le definan su trabajo. Está a la espera del siguiente pedido. Cuando tiene tiempo libre no sabe con qué seguir. Depende de otros para avanzar con sus tareas.
Semi Senior: Se preocupa por aprovechar mejor su tiempo. Pide nuevas asignaciones cuando tiene tiempo disponible y es autosuficiente para llevar adelante una gran parte de sus tareas.
Senior: No solamente recibe requerimientos, sino que los busca y genera. En muchas oportunidades es él quien le genera asignaciones nuevas a su superior.

Seguimiento requerido

Atención que requiere de su superior inmediato.

Junior: Requiere seguimiento diario a nivel detallado.
Semi Senior: Requiere seguimiento semanal y a nivel general.
Senior: Proactivamente reporta el estado y avance de sus tareas.

Indicadores de productividad

Indicadores varios relacionados con el trabajo que realiza

Junior: Calidad: Baja/Media  -  Productividad: Baja/Media  -  Innovación: Poca o Nula
Semi Senior: Calidad: Media  -  Productividad: Media  -  Innovación: Poca
Senior: Calidad: Alta  -  Productividad: Alta  -  Innovación: Alta

Cumplimiento de fechas

Cumplimiento de las fechas de entrega pautadas. Se aplica a las tareas de análisis, desarrollos, documentación, reporting, etc.

Junior: La mayoría de las veces no cumple con sus estimaciones.
Semi Senior: A veces cumple, a veces no.
Senior: Siempre cumple. Cuando surge un desvío (inevitablemente) lo informa adecuadamente y con anticipación.

Respuesta bajo presión

Referido a situaciones extremas… no a la corrida semanal para cumplir con la fecha de entrega del siguiente release en producción.

Junior: Le pueden pasar alguna de las siguientes cosas:
- Se bloquea
- Se angustia
- Se confunde
- Se estresa
El resultado de su trabajo en una situación de presión no es bueno.

Semi Senior: Le pueden pasar alguna de las siguientes cosas:
- Se enoja
- Se defiende
- Se distancia (se borra)
- Se resigna
El resultado de su trabajo en una situación de presión a pesar de todo, es bueno.

Senior: Le pueden pasar alguna de las siguientes cosas:
- Se entusiasma
- Se compromete
- Se hace cargo
- Se inspira
El resultado de su trabajo en una situación de presión puede llegar a ser asombroso.

Relación interpersonal

(Gracias a Javier Scavino por mencionar este aspecto).

Más allá de los conocimientos y capacidades de una persona, la habilidad de comunicarse con su entorno es fundamental para su desarrollo profesional.

Junior: Puede tener dificultades para transmitir sus ideas con claridad. No logra arribar a conclusiones concretables. No siempre sabe interactuar con otras personas de forma colaborativa y profesional.
Semi Senior: Se hace entender pero no logra ganarse la simpatía ni despierta la vocación de sus colaboradores para acompañarlo en sus sugerencias. Se permite escuchar otros puntos de vista pero sigue intentando que sean sus ideas (buenas y malas) las que prevalecen.
Senior: Es bueno comunicando, pero principalmente escuchando. Puede participar en desiciones de alto nivel y colaborar si es necesario en actividades más operativas privilegiando el resultado y la calidad de las relaciones por sobre su autoría en las ideas.


Dicho todo esto, les presento a un flamante desarrollador SEMI SENIOR: