6 consejos a tener en cuanta cuando lideramos equipos que crean software.

A continuación os dejo con un post que escribí en su momento en el blog de Kabel Sistemas de Información compañía en la que trabajo y desempeño mi carrera profesional.

Siguiendo la estela del post 6 consejos a tener en cuenta cuando escribimos software, hoy vamos  a ver algunos aspectos que se dan en los equipos encargados de generar software que tenemos que tratar de evitar.

El código no es ni tuyo ni mío, es nuestro.

Una frase típica en los equipos de software es “mi código funciona”. El código no es tuyo, es del equipo, es nuestro. Siente el código que ha desarrollado otra persona del equipo como tuyo, esto, te va a obligar a involucrarte más en el desarrollo y ser más crítico con nuestro trabajo.

En mi equipo funciona.

El software que desarrollamos no funciona hasta que está desplegado en los entornos de producción y vemos que funciona. Eso de “en mi equipo funciona” es un error. Tenemos que asumir que nuestro código falla, y una vez refactorizado y muy probado, podemos tener la seguridad de que funcionara ok, pero no te lo creas hasta que no lo veas.

Cuantas veces te has encontrado con este caso. Muchas. Aprende de los errores y asume que el entorno de desarrollo no es el mismo que el de producción, que los servidores no van a estar siempre configurados de la misma forma y que aunque no lo queramos, pueden aparecen sorpresas a última hora.

Despliega el software que estas creando de forma asidua en un entorno exactamente igual que el de producción y no te encontraras con estas sorpresas de última hora, que implica cambios a fuego en ficheros de configuración o trabajos a deshoras de la noche.

Los equipos grandes son inversamente proporcionales a la productividad.

Cuanto más grande es un equipo menos productividad tiene el mismo.

Cuanto más grande es un equipo más obligado te vas a ver a realizar tareas de documentación, revisión de código, gestión de tareas, gestión del equipo, etc.

Evítalo.

Si el proyecto es muy grande, crea equipos más pequeños con tareas concretas. Delega funciones. Verás cómo la gente está deseando involucrarse en tareas que de otra forma tendría que realizar el jefe de proyecto / arquitecto y cuanta más gente, más trabajo y sobrecarga para esta persona.

5 equipos de 4 – 5 personas y un jefe de equipo van a ser mucho más productivos y eficientes que 1 equipo de 30 personas.

Interfaces de usuario y perfiles muy “juniors”.

Es un clásico, a menudo se desprecian las interfaces de usuario y se ponen a las personas con menos experiencia a implementarlas.

ERROR GRAVÍSIMO.

La pieza más compleja de toda aplicación, es la que le permite la comunicación hombre-máquina.

Pon ahí a gente con experiencia, profesionales que entiendan que están haciendo, que tengan gusto por el detalle y las cosas bien hechas y sobre todo que le den la importancia que tiene.

La tecnología es un medio no un fin.

La tecnología es el medio que nos va a permitir desarrollar ideas o resolver problemas y tenemos que usarla para eso.

En muchas ocasiones, cuando estas desarrollando software nos olvidamos de esto perdiendo el foco de las tareas que tenemos que realizar, para crear plataformas tecnológicas que se apartan la “idea” inicial que pretenden resolver.

Los mejores han de estar en tu equipo.

Rodéate de los mejores. Busca buenos profesionales. Gente que haya puesto aplicaciones en producción. Es complicado, pero existen muy buenos profesionales con gusto por lo que hacen, búscalos e incorpóralos al equipo de desarrollo.

Anuncios

6 consejos a tener en cuenta cuando escribimos software

A continuación os dejo un post que escribí en su momento en el blog de Kabel Sistemas de Información.

Principio de simplicidad.

El principio de simplicidad ha de prevalecer siempre. Siempre que te encuentres ante una decisión toma la más sencilla. A menudo cuando creamos piezas sumamente complejas sufrimos un impacto la productividad del equipo ya que es mucho más difícil comprender, entender y usar el código.

Esto sumado a las tiempo que hay que emplear en pruebas regresión cada vez que nos vemos en la tesitura de modificarlo hace que estos códigos sean un lastre a la larga.

En aplicaciones en las que hay códigos sumamente complejos, el equipo de desarrollo pasa más tiempo leyendo y depurando el código que escribiendo código y esto hay que evitarlo toda costa.

Además gran parte de los proyectos de software son después mantenidos por equipos que no han desarrollado las aplicaciones, por lo tanto, la persona que ha creado un código sumamente complejo desaparece y esto suele derivar en códigos que nadie quiere tocar por miedo al impacto que pueda tener.

Nada es reutilizable hasta que se reutiliza.

A menudo, cuando diseñamos los diferentes componentes de la aplicación, pensamos en el futuro de la misma e intentamos crear códigos reutilizables “por si acaso”.

Error.

Nada es reutilizable hasta que se reutiliza. Esta es una gran verdad que tenemos que tener clara en todo momento. Crear un código para posteriormente reutilizarlo (por que sí) implica complicar ese código, cayendo en el punto anteriormente enumerado.

No a soluciones genéricas que se adaptan a todos los casos.

Cuidado con los casos “voy a diseñar un control que valide lo que introduce un usuario, ya sea un mail, un código postal o un DNI”.

Este tipo de acciones, deriva en códigos complejos y a los problemas anteriormente vistos. A menudo, estas piezas de software mágicas resuelven solo lo que contemplan y conforme tienes que ir añadiendo funcionalidad vas complicándolo más y más.

Soluciones concretas a problemas concretos.

Construir de menos a más. Haz refactoring.

Siempre que creemos piezas de software, tenemos que partir de código sencillo y conforme vayamos teniendo necesidades, crecer sobre lo creado anteriormente.

Hacer uso de refactoring (http://en.wikipedia.org/wiki/Code_refactoring) es una buena práctica, dado que, conforme vamos revisando nuestro software, podemos detectar carencias y subsanarlas, además de ir añadiendo funcionalidades necesarias. Por otro lado, el refactoring te va a dar una visión clara de las funciones de que cada una de las partes de la aplicación a lo largo de todo el proyecto.

No a tu framework, usa frameworks ya desarrollados.

Evita en todo momento crearte tu propio framework. Hay gente, equipos enteros que se están encargando de esto. Usa estos frameworks. Ten en cuenta que seguramente, están desarrollados por buenos profesionales, que están perfectamente testeados y que prácticamente en el 100% de los casos, estos frameworks, van a ser bastante mejores que el tuyo.

Usa JQuery, Modernizr, usa el .NET Framework, usa el framework que quieras, pero no te crees el tuyo.

Por ejemplo, no puedes estar desarrollando un framework de acceso a datos cada vez que desarrollas una aplicación. Esto tiene un gran impacto en la productividad del equipo y seguramente no te van a pagar por desarrollar esa pieza, sino por resolver una problemática concreta. Céntrate en tu negocio.

Haz Pruebas unitarias.

El trabajar con pruebas unitarias, puede parecer que tiene un impacto en los tiempos del proyecto, y bien es verdad que dado que tenemos que escribir más código inicialmente vamos a tardar algo más, pero a la larga, nos va a permitir reducir los tiempos.

Si un código no funciona, vamos a detectarlo en el momento en que ejecutamos la batería de pruebas y esto nos permite ser más eficaces dado que sabemos en qué punto concreto falla nuestro software.

Trabajar bajo el paradigma del TDD, nos va a obligar a diseñar el código de una forma concreta (desacoplado) para poder probarlo, obteniendo así un software diseñado de manera “uniforme” a lo largo de todo el desarrollo, lo cual hace más sencillo su posterior uso, reutilización y refactoring por todo el equipo.

 

Francisco de Goya, en el año 1799, publico una serie de grabados realizados por medio de aguafuerte, aguatinta y retoques de punta seca que llamo Los Caprichos. Mediante estos grabados busco satirizar y retratar la sociedad española de finales del XVIII.

El sueño de la razón produce monstruos, es el grabado 43 de los 80 que componían la serie. Y este, además de posiblemente ser el más famoso de todos, cuenta con un título totalmente inspirador con el que no años después, si no siglos después, nos encontramos que su mensaje sigue siendo totalmente vigente.

En nuestro sector seguro que todos hemos visto casos en los cuales podemos decir que la fantasía ha sido abandonada por la razón y esto se ha traducido en aplicaciones de software monstruosas.

TDD, Unit Testing y Code Coverage

Todo desarrollo de software que se precie debería realizarse según las directrices del TDD (Test Driven Development) o Desarrollo Orientado a Pruebas, ya que nos va a permitir crear un código más mantenible y escalable.

Esto no es algo nuevo, al contrario, y la verdad es que está bastante trillado, pero siempre es bueno recordarlo ya que lo considero una de las mejores prácticas para el desarrollo de software.

Las pruebas unitarias son, más que útiles, fundamentales ya que nos permiten trabajar de una forma desacoplada y nos ayudan a estructurar y encapsular nuestro código. Pero una vez que las tenemos en verde, ¿Cómo podemos saber qué es lo que se está probando y si están bien hechas?

Aquí es donde entra el Code Coverage.

El code coverage como medida de calidad de nuestras pruebas unitarias, por lo tanto de nuestro software.

El Code Coverage, es una medida que nos va a permitir conocer el porcentaje de ejecución de nuestro código, tras haber ejecutado una batería de pruebas.

De esta medida, podemos sacar varias conclusiones:

  1. Podemos necesitar más pruebas unitarias.
  2. Hay código que hemos creado, que nunca se va a ejecutar, por lo tanto no es necesario y sobra.

El Code Coverage, no es necesario que este al 100%, ya que para conseguir esto, quizás tengamos que realizar pruebas unitarias que realmente no sean tales o no sean muy útiles (por ejemplo que estemos probando el Framework en lugar nuestro código), pero sí que es verdad que cuanto más cercano sea al 100% mejor.

La buena práctica, es trabajar con pruebas unitarias, y usar el code coverage como métrica de la calidad de nuestro software y eficacia de nuestro equipo, ya que lo interesante es ver como el code coverage va creciendo (o por lo menos va manteniéndose) iteración tras iteración en el ciclo de vida del desarrollo el software.

Y para finalizar, deciros, que hay varias herramientas por ahí, aunque yo la verdad, solo he usado la que viene con Visual Studio 2008.

Para activar el Code Coverage, únicamente tenéis que ir a:

Test -> Edit Test Run Configuration -> Local Test Run

Y en el dialogo que aparece, vamos a la pestaña de Code Coverage y elegimos los proyectos a los que se lo queremos aplicar.

Aqui teneis una captura del Code Coverage de uno de los proyectos que hemos acabado recientemente, aunque no se vea el porcentaje total (por no desvelar el proyecto que es), ha sido un 91%.

Code Coverage en el ultimo proyecto en el que he estado

Code Coverage en el ultimo proyecto en el que he estado

Nada más por hoy mis druguitos. Os dejo que tengo que estudiar, pero no os quedais solos, aqui teneis a The Pains of Being Pure At Heart que son geniales y me ponen mogollon.

Yahoo Design Patterns: Navegaciones en búsquedas de datos

Yahoo, en su developer network, tiene una sección llamada Yahoo Design Patterns, donde muestran los patrones de diseño orientados a interfaz de usuario, que han aplicado en el famosísimo buscador.

Por la falta de información de este tipo en el mundo del diseño de iteración y la usabilidad, esto es un recurso muy valioso, y hoy vamos a hablar de un gran desconocido (en homenaje al Sr. Carlos Herrera), los controles de paginación en las páginas de resultados de búsquedas.

Recordar antes de nada que un patrón es una buena solución dentro de un contexto, pero si el contexto no es el adecuado, este patrón puede convertirse en un anti patrón. Sigue leyendo

Breadcrumb Navigation, una forma sencilla de incrementar y mejorar la navegación por nuestro sitio web

El Breadcrumb Navigation es un sistema de navegación que permite indicarle al usuario el lugar donde se encuentra además de la jerarquía del sitio así como el camino que hay que seguir para llegar al documento actual.

El nombre viene del libro Hansel y Gretel de los hermanos Grimm. En él, Hansel iba dejando migas de pan por el bosque parar marcar el camino de vuelta a casa.

Cuando tenemos que usar el Breadcrumb Navigation

El Breadcrumb Navigation lo tendremos que usar cuando sea necesario es decir, cuando la posible navegación del sitio web, sea lo suficiente compleja como para tener varios sistemas de navegación.

No obstante vamos a ver la principales razones para usarlo: Sigue leyendo