9 cosas que todo desarrollador debe saber

El libro 97 things every programmer should know contiene 97 pequeños consejos y prácticas que como desarrolladores deberíamos aplicar a diario en el desarrollo de software. En su blog, Brian Du Preez destaca 9 consejos en particular que le resultaron de interés. Veamos cuáles son...

1. La regla del Boy Scout (por Robert C. Martin, Uncle Bob)

"No es necesario hacer que cada módulo sea perfecto antes de subirlo al repositorio de código. Simplemente basta con hacer que sea un poquito mejor que cuando lo bajamos".

Nos resulta fácil decirnos cosas como "Ya estaba así", o "ese código horrible está así desde hace años, no voy a tocarlo", o "nunca tuvo pruebas". Si parte de nuestro proceso fuera hacer las cosas un poquito mejor (como borrar código que no se usa, o escribir una prueba unitaria), año tras año... lograríamos ahorrar mucho tiempo y dinero a muchas personas.

2. La belleza está en la simplicidad (por Jørn Ølmheim)

"Al final, el código hermoso es el código simple"

Con los años esto me resultó muy importante. Cuando empecé esta carrera, y especialmente cuando tenía que comenzar algo nuevo, me embarcaba en crear los mega-diseños. Era algo como "Bienvenido a la escuela de la sobre-ingeniería", todo sería una abstracción al décimo nivel, y habría patrones de patrones, interfaces para las abstracciones y enormes cantidades de código y componentes que se encargaban de cualquier "qué pasaría si" que podría existir, y que sólo yo comprendía. Todo esto llevaba a código muy "atractivo", y aumentaba mi ego, ¿pero a qué costo?

Sólo había un pequeño detalle: mantenerlo era una pesadilla. Desde entonces prefiero la implementación más simple para casi cualquier solución, incluso aunque no parezca la mejor implementación técnica. En el mundo del software, la mantenibilidad siempre debería pesar más que otros temas.

3. Detenete y automatizá, automatizá, automatizá (por Cay Hosrtmann)

Debemos automatizar todo lo posible: construcciones, despliegues, análisis de código, pruebas unitarias, pruebas funcionales, pruebas de integración. Nadie quiere mirar estas cosas todos los días y la automatización es la única forma de alejarnos de esto. No podemos automatizar demasiado. Automatizá, automatizá, automatizá.

4. Aprendizaje continua (por Clink Shank)

Este es un tema muy importante, estamos en una industria de constante crecimiento y cambio, y como programadores necesitamos estar aprendiendo y mejorando siempre que podamos. Es fácil caer en la zona de confort y descansar sobre los laureles. Algunas cosas que recomiendo:

1. Lean libros.
2. Usen Google Reader y agreguen blogs populares y feeds RSS de sitios web para temas específicos de su interés, además de agregar algunos otros temas que no sean de su interés particular.
3. Creen un blog, y traten de publicar algo 1 -2 veces por semana, asegurándose que sea cosas nuevas que aprendieron.
4. Únanse a alguna comunidad de software libre, en general no tenemos suficiente desarrollo "técnico" en los ambientes corporativos.

5. Antes de culpar a otros verificá tu código (por Allan Kelly)

Como dice el título, tendemos a buscar la culpa en cualquier cosa excepto nuestro código "perfecto". Desde el sistema operativo hasta la red, desde la base de datos hasta la JVM, desde librerías hasta las interfaces de otros equipos. Esto nos lleva a horas y horas de esfuerzo desperdiciado, o ignorar por completo el problema real que eventualmente volverá a molestarnos. La mayoría de nosotros puede recordar momentos en los que hicimos esto... y es tan frecuente que asusta.

6. El trabajo duro no vale la pena (por Olve Maudal)

"La verdad es que trabajando menos podemos lograr más"

"Si tratás de estar enfocado y "productivo" por más de 30 horas a la semana, seguramente estás trabajando demasiado"

Una gran frase de Olve Maudal. Muchos de nosotros ya pasamos por esto, gastamos días, semanas meses de trabajo, pero no solemos ver los efectos negativos que ocurren después de trabajar 50-70 horas por semana. Desde la lógica común hasta la motivación y la dinámica del equipo, todo esto sale por la ventana. Incluso aunque se logren los objetivos a corto plazo, a menudo las repercusiones a largo plazo son mucho peores. Nadie revisa porqué hay que re-escribir después de 4 años debido a que la arquitectura o el código nos sirven. Me encantaría saber cuántas de estas situaciones son por trabajar una cantidad ridícula de horas con tiempos imposibles. Puede haber alguna ocasión donde sea necesario un par de horas extras, pero debemos mantener esto al mínimo.

7. Comentar sólo lo que el código no dice (por Kevin Henney)

Lo que dice. No le contemos a otro programador lo que puede saber leyendo el código. Los comentarios tienen que explicar el motivo de negocio detrás de un algoritmo en particular, lo cual es mucho más útil que un //sumar 1

8. Conocer al IDE (por Heinz Kabutz)

Pasamos varias horas con nuestro IDE. Aprender los atajos, las características que tiene... usar el IDE con todo su potencial nos puede ahorrar incontables horas.

9. Aprender a estimar (por Giaovanni Asproni)

Si bien esto es algo que viene con la experiencia, podemos hacer cosas para mejorar esta habilidad. Algunos puntos para mejorar nuestras estimaciones:

1. Sean honestos con ustedes mismos, digan lo que saben y admitan abiertamente lo que no.
2. Tengan presente lo que hacen y cuánto les lleva, no necesariamente para el líder del proyecto sino para ustedes mismos. Sean honestos con ustedes mismos.
3. No cuenten las estimaciones ni habilidades percibidas de otras personas. Sean honestos con ustedes mismos.

Fuente

TDD y Unit Tests

Benefícios de Test-Driven Development

• El conjunto de test unitarios proporciona contante retroalimentación de que cada uno de los componentes sigue funcionando.
• Los test unitarios actuan como documentación que no se queda obsolet, al contrarío que otros tipos de documentación.
• Cuando el test pasa y el código de producción es refactorizado para eliminar duplicidades, es claro que el código está terminado, y el desarrollador se puede mover a la siguiente tarea.
• TDD fuerza un análisis y diseño crito porque el desarrollador no puede crear código de producción sin entender realmente cuales deberían ser los resultado deseados y como probarlos.
• El software tiende a estar mejor diseñado, esto es, menos acoplado y más facilmente mantenible, porque el desarrollador es libre de hacer decisiones de diseño y refactorizar en cualquier momento con la confianza de que el software todavia funciona.
• El conjunto de tests actua como una red de seguridad contra regresiones en los bugs: Si se encuentra un bug, el desarrollador debe crear un test que ponga de manifiesto el bug y despues modificar el código de producción para eliminar el bug. En sucesivas ejecuciones de los test, todas las correcciones de bugs son verificadas.
• El tiempo de depuración se reduce.

Características de un buen unit test

• Se ejecuta rápido, se ejecuta rápido, se ejecuta rápido. Si los test son lentos, no se ejecutaran a menudo.
• Separa o simula dependencias ambientales como bases de datos, sistemas de archivos, redes, colas y demás. Los test que ejercitan estos no serán rápidos y los fallos no dan información significativa sobre cual es el problema realmente.
• Es muy limitado en su alcance. Si el test falla, es obvio donde bucar el problema. Realiza pocas llamadas a la clase Assert de manera que el código que falla sea obvio. Es importante probar una única cosa en cada test.
• Se ejecuta y pasa de manera independiente. Si los tests requieren establecer entorno especial o fallan inexperadamente, no son buenos tests unitarios. Cambialos por simplicidad y fiabilidad. Los teste deben ejecutarse y pasarse en cualquier máquina. La excusa "funciona en mi máquina" no sirve.
• Usa a menudo stubs y mock objects. Si el código que está siendo probado llama a un base de datos o al sistema de archivos, estas dependencias deben ser simuladas. Esta dependencias habitualmente serán abstraidas usando interfaces.
• Revela claramente su intención. Otro desarrollador puede ver el test y comprender que se espera que haga el código de producción.

Arquitectura SOA: Los Servicios. Introducción

Definición

En una arquitectura SOA la funcionalidad de la aplicación está expuesta a través de una colección de servicios. Estos servicios son independientes y encapsulan tanto la lógica de negocio como los datos asociados.

Desde una perspectiva empresarial, los servicios son activos independientes que se corresponden con actividades comerciales reconocibles o funciones comerciales del mundo real y que son accesibles de acuerdo con las políticas que se hayan establecido para los mismo.

Desde un punto de vista técnico podemos decir que se trata de componentes autónomos de grano grueso, con interfaces bien definidas (contratos de servicio) y con una clara separación entre su interface pública y su implementación privada interna.

Los servicios interactúan entre sí a través de mensajes, con un esquema que define su formato, un contrato para definir sus intercambios y la definición de una política de cómo deben ser intercambiados.

Aplicaciones como conjunto de Servicios.

El primer paso en cualquier proyecto de SOA es identificar claramente los problemas críticos para el negocio o desafíos.

Los servicios incluirán los procesos de negocio y serán publicados para su consumo por parte de usuarios, sistemas u otros servicios.

Los servicios pueden utilizar otros servicios para cumplir sus funciones, serán en este caso servicios compuestos de otros servicios.

La creación de grandes aplicaciones será un proceso iterativo de incluir nuevos servicios y publicarlos.

En la terminología SOA componer nuevos servicios basándonos en los ya existente se llama Orquestación (Orchestration) al igual que en una orquesta iremos combinando instrumentos para realizar tareas más complejas.

La importancia del contrato

Las aplicaciones SOA publican sus servicios y no saben quien los va a usar ni donde, estando

fuera del control de la aplicación. Publican un contrato (interface) que se mantendrá constante a lo largo del ciclo de vida del servicio. El ciclo de vida de un servicio diferencia entre los servicios en producción y en desarrollo, para los servicios en producción nunca se modificará su interface sino que en su lugar el servicio se marcará como en desuso y se notificará a sus consumidores que hay una nueva versión del servicio disponible que deberán usar.

Es fundamental la separación entre la interface y la implementación. El usuario de un servicio sólo necesita (y debe) conocer la interface. La implementación puede cambiar a lo largo del tiempo sin que para ello deba afectar a sus consumidores .

Servicios Web

Como comentamos antes, un error muy común es confundir servicios, componentes que forman una arquitectura SOA, con servicios web. Los servicios web son una forma de implementar estos servicios, pero no es obligatorio que los servicios estén implementados como servicios web aunque sí es lo más común.

En nuestro próximo artículo vamos a profundizar en los servicios web como forma más habitual de implementar los servicios de una arquitectura SOA, haciendo referencia a las dos formas más habituales de servicios web (SOAP y RESTFUL) y las principales diferencias entre ellas.

Breve Introducción a SOA

Si tu conocimiento sobre SOA se limita a la realización de algunos Web Services, pero te apetece conocer un poco más en profundidad la Arquitectura Orientada a Servicios.

En éste primero voy a enumerar 5 ideas fundamentales que debes conocer sobre SOA.

1. SOA no son webservices. Los servicios web son una forma de implementar los servicios de SOA, la más conocida e implantada, pero incluso sin webservices podríamos tener SOA siempre que tengamos una forma estándar de comunicar los servicios entre sí. Digamos que los servicios web son los árboles y SOA va sobre el bosque entero.
2. Los servicios en SOA representan procesos de negocio. Hay una relación directa entre los procesos de negocio de una empresa y los servicios que se van a implementar en SOA, de tal manera que un proceso de negocio estará formado por la llamada a varios servicios.
3. SOA no tiene porque ser válido para todas las organizaciones, donde realmente tiene sentido es en grandes sistemas distribuidos y heterogéneos donde el bajo acoplamiento entre los distintos componentes es el factor más importante. Si nuestra empresa no tiene componentes distribuidos y además todo está bajo la misma plataforma probablemente SOA no nos aporte nada.
4. Implantar SOA no significa cambiar todos nuestros sistemas por un nuevo (y carísimo) software basado en SOA, uno de los principios de SOA es aprovechar los sistemas heredados, realizando servicios que se encargarán de actuar como fachada entre estos sistemas y el resto de servicios.
5. El Gobierno SOA es un factor fundamental en una arquitectura SOA y es el encargado de velar porque se cumplan los principios de la arquitectura.

Por último algunas siglas que deberías conocer:

• ESB: Enterprise Service Bus o bus de servicio empresarial, es el encargado de facilitar la comunicación entre los servicios y puede ofrecer muchas funcionalidades de valor añadido como alta disponibilidad, enrutamiento inteligente, orquestación de procesos, monitorización, etc.
• BPM: Business Process Management o gestión de procesos de negocio, es complementario a SOA, como los servicios representan procesos de negocio es factible que se puedan crear nuevos procesos de negocio en base a la combinación de los servicios ya existentes, con lo que dando de alta nuestros servicios en una herramienta BPM los podemos combinar incluyendo condiciones y utilizando para ello un lenguaje específico como BPEL (Business Process Execution Language)

Fuente