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?

 

Anuncios

Cómo afrontar una entrevista de trabajo (1)

dilbert-entrevista-trabajoEmpiezo 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?

Dilbert-Teletrabajo 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

branch-per-taskMuchos 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

dogfoodingHoy 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)

ñapa-as-a-serviceHoy 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”. Hay 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

6758_Prog_WinStor_Apps_HTMLOtro 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.