Principios SOLID

Estos principios, que supongo ya conoceréis todos, están orientados a los que se inician en la programación orientada a objetos. Después de todo, el sentido común ya nos orienta a este tipo de prácticas, pero es gracias a su recopilación, que los que empiezan pueden aplicarlas.

Ayer un compañero me comentaba: «Oye Roberto, a veces las nuevas incorporaciones las formamos mucho y bien en tecnologías, en frameworks y lenguajes de programación. Pero no les enseñamos realmente a programar». Pensaba en la afirmación, y efectivamente, saber programar es algo mucho más complejo que saber un lenguaje o un framework. Es por eso que me he acordado de este post que llevaba mucho tiempo sin completar.

Por si algún despistado no conoce los principios SOLID, vamos a revisarlos.

Robert C.Martin, introdujo a principios de la década del 2000 este concepto. SOLID corresponde a 5 principios en los que fundamentar la orientación a objetos:

• S: Single responsibility.  Principio de responsabilidad única. Cada objeto, debe dedicarse a una sola cosa. Si os fijáis, es una ampliación del concepto clásico de programación en el que un método o función debe tener un único propósito.
• O: Open-closed. Las clases u objetos han de estar abiertas para su extensión, pero cerradas para su modificación. Este principio está directamente relacionado con la herencia en Orientación a Objetos.
• L: Liskov substitution principle (principio de substitución de Liskov). Este principio promulga que todos los objetos deberían ser sustituibles por instancias de sus subtipos sin afectar al funcionamiento del programa. Es decir, que no debemos reimplementar los métodos en las clases heredadas, sino utilizar los de las clases base.
• I: Interface segregation principle (principio de segregación de la interfaz). Este principio afirma que es mejor muchas interfaces cliente específicas, que tener una sola interfaz de propósito general. Este principio busca el desacoplamiento entre clases.
• D: Dependency inversion principle (principio de inversión de la dependencia), donde Robert C.Martin nos indica que se debe depender de abstracciones, no de implementaciones. Por ejemplo, la técnica o patrón de inyección de dependencias sigue este principio.

¿Y tú, tienes en cuenta los principios SOLID a la hora de programar?

 

Cómo afrontar una entrevista de trabajo (1)

Empiezo poniendo a esta entrada el número 1 porque ya preveo que va a dar para unas cuantas más. Y es que las entrevistas de trabajo son cada vez complejas, y no siempre es dicha complejidad proporcional al puesto de trabajo.

Hoy para empezar, veamos un par de preguntas que así, sin venir a cuento, le hacen a unos amigos en otra empresa, para puesto de programador con experiencia:

Pregunta #1: La cuerda que rodea la tierra

Pregunta: Suponiendo que la tierra fuese una esfera perfecta, si ponemos una cuerda que de la vuelta completa a la tierra por el ecuador y quede perfectamente ajustada a ella…si añadimos un metro a dicha cuerda, ¿cuáles de los siguientes objetos podrían pasar por el hueco que quedaría bajo la cuerda (una moneda, un gato, un vaso de vino)?

Respuesta: Resulta que se trata de un famoso problema matemático, una paradoja matemática que consiste en que el hueco que quedaría entre la tierra y la cuerda es exactamente el mismo, y sólo depende del tamaño de la cuerda añadida (y no del tamaño de la cuerda). Es decir, que si a una pelota de golf (o de tenis, o lo que os de la gana), le añadís un metro de cuerda, la distancia o hueco entre la superficie de la esfera y la cuerda…será exactamente la misma que en el problema inicial de la tierra (aproximadamente, unos 16 cm). Más información y detalle del cálculo del teorema que lo demuestra en: https://en.wikipedia.org/wiki/String_girdling_Earth

Pregunta #2: Una de interruptores

Hay 3 interruptores (de los de encender/apagar luces de toda la vida), en la planta calle de un edificio. Sólo uno de ellos apaga/enciende una bombilla del piso 3. Los otros dos, están conectados a cualquier otra cosa. Si sólo tuvieras una oportunidad de tocar los interruptores y subir al piso 3 (sin volver a bajar ni alterar los interruptores)…¿cómo podrías saber qué interruptor era el correcto?

Respuesta: La solución, en: http://www.scientificamerican.com/article/answers-to-puzzles-posed-in-let-the-games-continue/

Conclusión.

Por desgracia, estas preguntas tenían poco o nada que ver con la pericia técnica del trabajo para el cual se hacía la entrevista. Sin embargo, son preguntas que se suelen hacer en entrevistas de trabajo, en empresas como Google o Microsoft.

¿Os parecen preguntas adecuadas? ¿Creéis que realmente son objetivas de alguna forma? Ya hay voces de algunos responsables de RRHH que alzan su voz en contra de este tipo de técnicas. Pero eso, lo dejaremos para otro día.

 

 

 

 

 

¿Te conviene trabajar desde casa?

 Los Millenials, esa raza aparte de la que hablaremos otro día, lo valoran. Estamos hablando del trabajar desde casa. Y el trabajar desde casa ha sido objeto de un artículo muy interesante en LinkedIn.

Pero analicemos un poco el artículo, ya que ponen al hecho de trabajar desde casa como un lastre en la carrera profesional. Claro, desde casa es sencillo realizar el 99% de las tareas. Pero por ejemplo, ya no es tan sencillo liderar. Y no hablo de dirigir a un equipo, sino dar ejemplo, y ser el líder que todos desean ver hacer y que guía al equipo.

¿Significa esto que no se puede ser jefe trabajando desde casa? No, pero en el artículo se plantea que a la hora prosperar en la carrera profesional, es más sencillo hacerlo de forma personal en la oficina, o codo a codo con el equipo en el cliente (o donde sea). Es en ese día a día en la oficina, haciéndose ver, donde  se genera la confianza para que los responsables te tengan en cuenta a la hora de promocionarte profesionalmente.

Aquí es donde viene la pregunta: ¿te conviene trabajar desde casa?

Pues tal como lo plantea el artículo, pues no, si lo que quieres es progresar profesionalmente a puestos de dirección.

Por supuesto, si entre tus objetivos están el no progresar rápidamente, sino realizar un trabajo a gusto, y con un adecuado balance entre la vida personal y la profesional, el teletrabajo es un punto a valorar.

El artículo está muy cargado de valores profesionales, y está muy bien dirigido. Sin embargo, no tiene en cuenta que está estableciendo una premisa: si quieres prosperar profesionalmente, debes dejarte ver. Que te vean trabajar, y que te vean haciendo cosas bien.

De nuevo, aquí extraemos algunas tristes conclusiones, dos de las cuales dejo a la reflexión de mis lectores:

• ¿Y si mi visibilidad se reduce no por trabajar desde casa sino porque me mandan a un cliente? En ese caso no es porque queramos, sino que se nos saca fuera «visualmente», impidiendo y coartando nuestra carrera profesional de forma ajena a nuestra voluntad.
• Si se trata de dar visibilidad a nuestro buen hacer, ¿no estaremos fomentando que la gente oculte descaradamente sus errores o su «no tan buen hacer»? O lo que es peor, que se busquen culpables de cualquier situación, en lugar de afrontarlas y solucionarlas (tal y como se esperaría de un líder)

Así que tras darle muchas vueltas…vuelve a mi cabeza la pregunta:

¿Te interesa trabajar desde casa?

 

 

 

La línea de Base y los cambios en producción

Muchos me diréis que a qué viene esto ahora a cuento. Pues me sigo encontrando muchos casos en los que hay programadores que no terminan de entender el concepto de línea base. Además, este concepto es fundamental para entender los cambios en el ciclo de vida del software, desde el entorno de desarrollo, hasta el de producción. Y no, no me refiero a permitir o no hacer cambios directamente en producción. De eso creo que ya hemos hablado. Me refiero a controlar los cambios en cualquier entorno mediante el concepto de línea base.

¿Qué es la línea base?

La línea base es un concepto de la gestión de la configuración (otro día hablaremos de ella). La línea base se define en el IEEE 600.12/1990 como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

La línea base es un contrato. Un contrato igual que lo es una API, o el WSDL de un servicio web. La línea base establece en qué puedo confiar, porque es algo acordado (ni siquiera tiene porqué ser bueno, probado, excelente o definitivo). Hablamos de una versión de cada uno de los componentes software, que en conjunto, se ha acordado que es correcta en su conjunto. Pero sin suponer esto que cumpla los requisitos, ni las pruebas…simplemente es un hito.

Cuando trabajas con Subversión, TFS o Github, tenemos los conjuntos de cambios, tags o Changesets. Esas etiquetas o paquetes de cambios identifican el software en su conjunto, y son como una foto. Sí, como una foto del software en un momento y situación determinados del tiempo.

Aquí la idea no es versionar. No es un control de cambios. Es tener la posibilidad de devolver todo el código a un momento del tiempo en el que sabíamos que algo funcionaba (o no), pero al menos conocíamos su estado en conjunto. Esto es muy importante para controlar el estado de los entornos, para poder devolver un entorno (pruebas, desarrollo, calidad, preproducción, formación, producción), a un estado conocido.

Si la línea base es una foto, instalar una línea base es devolver a un entorno a un estado conocido, es un viaje al pasado.

Por ese motivo, jamás deberemos tocar el código en producción, ni en pre-producción, ni en otro entorno que no tengamos debidamente controlado con el correspondiente gestor (SVN, Github, TFS…). Porque si tocamos el código, hemos perdido la partida. Ya no podremos tener control de hacer una nueva «foto», y empezaremos a perder el control de los cambios, de los entornos, del desarrollo.

Y claro que podemos coger ese código, hacer un checkout en desarrollo y poner ese código después para recuperar el estado del entorno de desarrollo. Y claro, también existe Santa Claus, y Blancanieves, y los siete enanitos. Si no lo hicimos en un principio, si nos hemos dejado seducir para tocar el código en producción y «jugárnosla», hemos perdido el control y ha dejado de jugar a nuestro favor todos los beneficios de la integración continua, testing automático, etc, etc.

Alguna vez he oído decir que tocar el código en producción es como dejarse seducir por el lado oscuro de la fuerza. Tentador…pero no sólo es algo que esté mal…es algo cuyo precio vas a pagar tarde o temprano.

Eat your own dog food

Hoy vamos a hablar de un término (dos en realidad), que están relacionados con prácticas de testing interno.

No te despistes al escuchar la frase ‘eat your own dog food’. En el mundo del desarrollo del software, nos referimos a una empresa que usa sus propios productos en el día a día, de forma interna, incluso mucho antes de salir al mercado. ¿Qué mejor demostración de confianza en tus productos y mejor forma de entregar un producto software pulido y plenamente operativo que usarlo tú mismo, de forma interna?.

Esta práctica, que también podremos oir como «dogfooding» (este es el segundo término), puede tener varios orígenes:

• Queremos dar una imagen de confianza en nuestros productos. Es una manera de decir al público: «eh, fijaos si nos fiamos de nuestro software, que lo usamos día a día internamente».
• Qué mejor beta-testing que precisamente usar el producto de forma interna. Tendremos la garantía de que todos los defectos encontrados van a ser reportados, y resueltos de forma inmediata.

Hay muchas compañías que aplican este concepto. Apple usa internamente sus productos, Microsoft es otro habitual en el uso de esta práctica: usa sus lenguajes y entornos de desarrollo para crear sus…lenguajes y entornos de desarrollo, sistemas y aplicaciones. Incluso Microsoft usó Windows Server 2012 todavía sin terminar como plataforma para dar servicio a Bing a nivel mundial.  De hecho, Microsoft lleva toda su historia ligada al concepto de dogfooding con sus productos.

Pero son muchos los desarrolladores que lo hacen. Esto era muy típico por ejemplo hace algunos años con las típicas soluciones sectoriales de pequeñas compañías que desarrollaban software interno para su gestión (facturación, contabilidad, nóminas y gestión de…presupuestos, clientes, proveedores, etc.) y con el tiempo acababan vendiendo el software a empresas de su sector, o incluso a otros sectores.

¿Y tú? ¿Te atreverías a usar internamente en tu empresa el propio software que produces y confiar en él hasta el punto de dejar tus procesos de negocio críticos en sus manos?

ÑaaS (Ñapa as a Service)

Hoy os traigo una delicatesen que un buen amigo me ha proporcionado. Como ilustra la figura adjunta, la ñapa es una de las lacras de esta profesión del desarrollo de software, y por desgracia, hay quien la ofrecen como servicio de forma habitual.

Quiero pensar que el autor de la imagen, al escribir «Programming the spanish way», no hablaba en serio. Me niego a pensar que la forma habitual de programar en España sea la Ñapa.

Para los lectores de otros países, o que me lean mediante el traductor automático, vamos a ofrecer una traducción del término «Ñapa». No os molestéis en buscar en la RAE (Real Academia Española de la lengua). El término Ñapa no aparece allí. Sin embargo, es harto conocido al menos en España

ÑAPA: chapuza, mierda, parche, remiendo. En informática, dícese del trabajo mal remunerado y peor ejecutado, que consiste en construir un simulacro de aquello que espera ver el cliente, con el mínimo esfuerzo, y totalmente alejado de lo que una mente sana entendería como adecuado.

Eso es una ñapa. Este término está muy relacionado con otros que ya he blogueado (y algunos que aún no he terminado de escribir) como: cantamañanas, o vendemotos, o vendedor de humos (smokeseller para los amigos). Es gracias a esta fauna de la selva informática, a quienes debemos agradecer la existencia de las ñapas.

También hay que agradecerlos a los clientes, que también los hay, que son capaces de cambiar de opinión cada poco tiempo para disfrute de los programadores. Esos programadores que se encuentran que después de docenas o cientos de horas construyendo aplicaciones, éstas dejan de tener sentido debido a «un pequeño cambio».

Y me rio, me parto de la risa ácida que me entra de forma visceral e insostenible, cuando me salta el iluso de turno con su «esto se arregla siendo ágil». Amigo, esto no lo arregla SCRUM, ni CMMI ni nadie. Cuando el cliente decide que lo más importante no es identificar el impacto de un cambio, ni priorizarlo. Solamente llevarlo a cabo. Aunque haya que tirar a la basura semanas y semanas de duro trabajo para rehacer desde cero miles de líneas de código.

La ñapa o chapuza, es una enfermedad del software (podéis leer más enfermedades del software que he ido recopilando en esta categoría, como la comentitis, singletonitis, excusitis, cacheitis, patronitis… ). Y esta enfermedad es difícil de erradicar. Desde mi experiencia, lo más importante no es la metodología, no es ser más o menos ágil. Sino ser consecuentes y tener la mente fría. Identificar el impacto de las cosas, y asumir que los cambios existen, y que la forma más rápida de llevarlos a cabo es precisamente…no ponerse a ellos de forma inmediata. Sino ponerlos en cartera y ver cómo se relaciona con otros cambios solicitados, los desarrollos en curso, etc, etc.

Gracias José Antonio Herrero por la imagen.

Libros gratis y de calidad para este verano

Otro año más, Eric Ligman ha publicado en su blog una entrada con más de 150 libros para que podamos ponernos al día en las últimas tecnologías (Windows 10, Azure, SharePoint, HTML, CSS, JavaScript, CRM, Office 2013, Lync, Windows Server….

No solo son totalmente gratis (sin pedir el email, ni ningún tipo de información, sólo descarga desde la propia página), sino que además, se encuentran en los principales formatos de ebook: pdf, mobi, epub, etc.

¿Quién dijo que formarse es caro?

Buena lectura, y feliz verano.

El fin de los mensajes de error

Leía en linkedin un artículo de opinión (Error Messages are Evil), y mi sorpresa ha sido mayúscula al encontrar que se había formado todo un terremoto de respuestas, una pequeña polémica. Y mi sorpresa ha sido aún mayor al encontrar a gente joven entre los que responden en contra de la opinión del autor. En el artículo, el autor (Don Norman), defendía que los mensajes de error son el mal, y mostraba como ejemplo un mensaje de error ofrecido por una aplicación.

Yo esperaba que los usuarios más jóvenes apoyaran por fin estos conceptos de usabilidad, pero parece que al menos entre los lectores del artículo, no era así.

Y sí, estoy de acuerdo, los mensajes de error son malignos. Realmente, hay que erradicarlos. Ya lo comentaba hace tiempo Alan Cooper, uno de los maestros del UX en «The inmates are running the asylum». Los mensajes de error tradicionales violan las reglas de la usabilidad:

• Hacen sentir estúpido al usuario, al culparle por no saber usar el software.
• Distraen del objetivo del usuario, que no es usar el software, sino obtener resultados.

¿Por qué decimos al usuario lo que hay que hacer DESPUÉS de que lo haga? ¿Porqué asumimos que es un error algo como un texto mal introducido? ¿Porqué no nos centramos en guiar al usuario a cumplir sus tareas en lugar de obsesionarnos en que use «correctamente» nuestro software?

Pues porque al desarrollar software, caemos en la trampa del egoísmo. Sólo pensamos en nosotros mismos, de forma que cuando el usuario no hace lo que nosotros queremos/esperamos…es SU culpa! Malditos usuarios…

Bueno, no puedo irme sin recomendaros no sólo el artículo de opinión en sí, sino esa gran obra  pionera en el mundo del UX (User Experience) que es «The inmates are running the asylum».

Metodología XP – Introducción

Hoy me apetece hablar de la metodología XP (eXtreme Programming). Personalmente, me gusta porque es de las primeras metodologías ágiles con la que tuve contacto, allá por el año 1999. Al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas. XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software. El autor o precursor de esta metodología fue Kent Beck, y está basada en 5 valores fundamentales:

• Respeto: todos los miembros del equipo muestran respeto por el trabajo de cada uno de los demás.
• Simplicidad: la he puesto en segundo lugar, porque aunque en teoría leeréis que lo simple y la búsqueda de lo simple es la base de XP, me niego a verlo por detrás del respeto.
• Comunicación: cada una de las tareas del equipo se consideran una forma de comunicación, desde el código, pruebas unitarias, etc.
• Feedback: XP fue una de las primeras metodologías en incorporar el feedback del cliente. De hecho, el cliente se considera parte del equipo de trabajo.
• Valor: se refiere principalmente al valor o valentía necesarios para realizar algunas de las prácticas ágiles que XP incorpora. Como el comenzar a programar lo antes posible, o valentía para que el código sea refactorizado y no haya deuda técnica desde el principio, etc.

Como metodología, XP es muy ligera, o más bien podríamos decir, poco estructurada («ligera» podría considerarse como un término despectivo en el mundo del desarrollo del software). Lo que sí hace XP es incorporar una serie de técnicas o buenas prácticas. Algunas prácticas fundamentales de XP:

• Programación por parejas: es el punto más controvertido, ya que propone que sean dos personas las que se dediquen a programar. Una persona escribiendo y otra revisando (se pueden alternar). De todas formas, el código se discute antes y durante la escritura. Aquí se practica el famoso «cuatro ojos ven mejor que dos».
• Desarrollo por iteraciones: el código se construye mediante iteraciones que van sumando valor o funcionalidad al resultado final.
• Simplicidad: el axioma «KISS» (Keep It Simple, Stupid), se aplica con regularidad.
• Refactorización: el código se refactoriza regularmente para que la calidad de código sea notoria, y se evite la deuda técnica. Recordemos que refactorizar, tal y como hemos indicado ya en este blog, nos puede llevar a la refactoritis, una enfermedad de la que ya hemos hablado anteriormente en este mismo blog.

¿Debe saber programar un jefe de proyecto?

La eterna disputa. ¿Debe un jefe de proyecto ser sólo un gestor…o debe también saber programar? ¿O debe haber sido programador? ¿O no hace falta? Bueno, hoy creo que me voy a ganar enemistades por razonar en contra de la moda. Vayamos a ello.

Algunos puntos a favor:

• Sí, debe saber programar para saber dirigir mejor a sus equipos.
• Sí, porque así tiene empatía con su equipo.
• Sí, porque así sabe de qué hablar al negociar un cambio.
• Sí, porque así sabe llevar un lenguaje técnico durante las ventas.

Algunos puntos en contra:

• No, porque la dirección de proyectos en realidad tiene que ver muy poco con la programación. Dirigir a los equipos no es enseñarles cómo hacer su trabajo. Eso se llama formación. Dirección consiste en dar directrices, pautas y restricciones (limitaciones, restricciones, requisitos variados, etc.). Dirigir consiste en facilitar el enfocarse en una dirección, no llevar físicamente el peso del equipo. También en entender e identificar las dificultades que van surgiendo, anticiparse (riesgos), resolverlas cuando se producen (problemas), etc.
• No, porque aunque la empatía es útil para conectar con la gente, la empatía no se consigue programando. Puedes ser un buen programador y sin embargo (y de estos me he encontrado unos cuantos), ser incapaz de conectar con clientes, compañeros, etc.
• No, porque al negociar un cambio, ser programador no es la clave. La clave es conocer el impacto en el código, documentación, y otros proyectos o trabajos en curso. Es una temeridad creer que aunque seamos técnicos, vamos a poder identificar, en medio de una negociación, si el cambio se acepta o no, y mucho menos llevarlo a cabo. Para identificar el impacto de un cambio son necesarios: una mente analítica, tener identificada la estructura del proyecto (aquí ayuda la documentación, algún modelo o arquitectura bien estructurada, etc.). Y por supuesto, ayuda la experiencia. Pero no experiencia en programar, sino experiencia en la dirección de proyectos y cómo sus cambios cuesta llevarlos a cabo.
• Es un error pensar que las ventas han de hacerse en un lenguaje técnico. Las ventas han de hacerse pensando en el lenguaje de la persona que tenemos delante, que no tiene porqué ser técnica. Pensar sólo en lenguaje técnico, es como mínimo, una falta de respeto a quien tenemos delante. Somos nosotros quienes tenemos que escuchar al cliente, lo más importante, y no al revés.

La realidad nos dice, y de esto encontraréis múltiples artículos en la web hablando de ello (incluido nuestro querido Dilbert), que los buenos programadores, cuando son promovidos a categorías superiores de dirección de proyectos, se encuentran con que no están preparados para dirigir equipos y proyectos. Es duro encontrarse con que se deja de tocar código, y se enfrentan decisiones organizativas, operativas, planificaciones, estimaciones, etc. Cuántos jefes de proyecto recién promocionados se sienten perdidos y decepcionados, y por supuesto poco preparados.

Tampoco estoy de acuerdo con que un jefe de proyecto deba ignorar la tecnología. Más bien al revés. Sin embargo, el mero conocimiento técnico, no nos convierte en buenos gestores. Cuantas veces oigo eso de «yo dirijo equipos», de personas que se limitan a decir a sus programadores lo que tienen que hacer, a «pasarles las tareas». Eso no es ser un jefe de proyecto, ni dirigir un proyecto. Hay un salto cualitativo (por la complejidad) y cuantitativo (por el número de tareas) que debe realizar un buen jefe de proyecto. Por desgracia, hay tantos malos jefes de proyecto, que es habitual oír quejas de sus programadores en los términos que comento más arriba en el apartado «Algunos puntos a favor».

Para ser buenos los programadores, hemos de conocer los estándares de programación. Lenguajes, buenas prácticas, arquitecturas, frameworks, patrones…

Igualmente, para ser buenos gestores, hemos de conocer los estándares de gestión (PMBOK, PRINCE, ITIL,…), cómo adaptarlos a distintos proyectos, entender los riesgos que se corren con los cambios, establecer planificaciones (bien con un Gantt de los requisitos, una secuencia de sprints o iteraciones de historias de usuario, etc).

Mi conclusión, por tanto, es que sí y no. Un buen jefe de proyecto puede beneficiarse mucho de venir del área de desarrollo, y haber sido programador, analista, etc. Pero aún con toda esa experiencia, sólo con empatía, y saber hablar con los programadores, no se enfrentan y solucionan los problemas organizativos de un proyecto. Un marinero experto no es suficiente para ser un gran capitán. Aunque todo buen capitán, es fácil que haya sido antes marinero experto.