El blog de ASPgems

Siguiendo el día a día de ASPgems

Qué hace un desarrollador

Qué hace un desarrollador

En ASPgems estamos lanzando un nuevo servicio de formación para programadores. Creemos que los cursos de formación que hay ahí fuera están bien y cumplen su función para enseñar a la gente que quiera empezar en este mundillo a programar. Pero además creemos que son necesarias otras opciones que faciliten, a aquellos que ya saben programar, dar un siguiente salto. Un salto de calidad. Y en nuestro caso optamos por facilitar el salto de programador a desarrollador.

 

Y es por esto que quiero empezar a escribir sobre aquellas cosas que hacen a un buen desarrollador. Porque tengo la sensación de que fuera de nuestro mundo (a veces incluso dentro de él) se desconoce en qué consiste realmente el trabajo de un desarrollador. Parece como si nuestro trabajo fuera exclusivamente escribir líneas de código más o menos complicadas y ya está.

 

Sin embargo los desarrolladores no somos (sólo) programadores. El trabajo de un desarrollador, en realidad, es el de resolver los problemas técnicos de una solución determinada por medio del software.

 

Así que sí, somos programadores, pero también somos algo más.

 

¿Y qué es lo que convierte a un programador en un desarrollador?

 

La visión.

 

Los desarrolladores no sólo nos centramos en el código. Sabemos que el código es la unidad básica de producción, pero que hay mucho más alrededor para que ese código tenga sentido.

 

Todos entendemos que un edificio no es sólo un conjunto de ladrillos puestos unos encima de otros, sino que hay más cosas alrededor: los cimientos, la definición del espacio, la luz, la climatización, la posibilidad (o no) de expansión, la protección contra humedades...

 

Un buen arquitecto se preocupa por todas estas cuestiones (y más) a la hora de construir un edificio.

 

Un buen desarrollador se preocupa por más cuestiones que la del propio código a la hora de construir software.

 

¿Y qué preocupaciones son esas?

 

Aunque puede haber múltiples consideraciones acerca de qué debería preocuparnos a la hora de hacer software de calidad, a mí me gusta agruparlas en estas 3:

 

Fiabilidad, mantenibilidad y escalabilidad.

Fiabilidad: que el software haga lo que se espera que haga

 

Es el “primer nivel de calidad” del desarrollo de software y el objetivo es tener software funcionando como se espera.

 

Para esto un desarrollador diseñará el software buscando las siguientes características:

 

  • El software hace lo que el usuario espera que haga.

  • Permite que el usuario cometa errores, o utilice el software de formas inesperadas (esos mensajes de error, por favor...).

  • El rendimiento es suficientemente bueno en situaciones de carga esperada.

  • El sistema impide acciones y accesos no autorizados.

  • El software tiene cierta tolerancia a los fallos: si un sistema de terceros se cae, mi aplicación debería seguir funcionando, aunque sea parcialmente.

 

En resumen: puedo decir que mi software es fiable cuando funciona y hace lo tiene que hacer.

 

Sí, sé que puede parecer muy obvio, pero si alguna vez has estado en un proyecto de software, seguramente hayas vivido ese proyecto en el que la aplicación siempre se caía, se perdían datos, había fallos de seguridad…

 

A un buen desarrollador no le tienes que decir que tenga backups de la base de datos, o que tenga en cuenta los errores de validación de los formularios.

 

Con esto no quiero decir que haya que perseguir el fallo cero en el software. Al revés, creo que el software está roto por definición y que lo que hay que hacer es minimizar el impacto que estos fallos puedan tener.

 

Los desarrolladores sabemos dónde están los fallos más peligrosos y cuáles no lo son tanto. E igual sabemos esto porque lo hemos aprendido a base de noches enteras sin dormir encontrando y solucionando un bug en producción ;-)

Mantenibilidad: minimizando el coste del software.

 

Es el “segundo nivel” de calidad del desarrollo de software y el objetivo es minimizar el coste que tiene el mantenimiento y la evolución del software.

 

Y es que la mayor parte del coste del software no radica en su desarrollo inicial, sino en su mantenimiento: bugs, investigación de errores, modificación para nuevos casos de uso, pagar la deuda técnica, aplicar parches de seguridad o mantenimiento de versiones...

 

Para evitar esto hay tres principios de diseño que conviene conocer: operabilidad, simplicidad y plasticidad

Operabilidad

 

Los desarrolladores deberíamos conocer todo el proceso que envuelve a la construcción y entrega de software y, además, reconocer su importancia. Un buen sistema de operaciones puede solventar un software malo o incompleto, pero un buen software no compensa un proceso de operaciones mal diseñado.

 

Por esto, los desarrolladores tenemos que preocuparnos por cosas como::

 

  • La monitorización del sistema.

  • La implantación de mecanismos para restaurar servicios de forma rápida.

  • Actualizaciones de software.

  • Documentación.


Todas estas cosas persiguen que el proceso de construcción sea fluido, que sea tolerante a fallos y que no dependa de personas concretas.

Simplicidad

 

Asumamos de una vez que los sistemas de software son sistemas complejos. Los sistemas de software son sistemas deterministas, si y sólo si, conocemos de antemano las entradas del sistema. Sin embargo, esto deja de ser así en el momento en el que soltamos nuestro software al mundo real.

 

Un desarrollador debería preocuparse de generar el código lo más simple posible. Debería huir de la “sobrearquitectura” y de la optimización prematura. En cambio, perseguirá un código simple que facilite la comprensión de este sistema complejo.

 

Para conseguir esto, es fundamental una buena capacidad de abstracción. Sin embargo, la capacidad de abstracción es una habilidad muy complicada de adquirir, y es más un arte que una ciencia.

 

A lo largo de mi vida profesional me he cruzado con un par de programadores que hacían su código lo más intrincado posible para que nadie salvo ellos lo entendieran. Decían que así se aseguraban su futuro en la empresa. Me pregunto dónde estarán ahora mismo… Y, sobre todo, espero que no llegue a mis manos código suyo jamás.

Plasticidad: facilitando el cambio
 

El mundo en el que vivimos es de todo menos estático. Tus prioridades de negocio cambian a medida que aprendes, tus usuarios te piden nuevas funcionalidades que no tenías contempladas, aparecen y desaparecen plataformas tecnológicas…

 

Los desarrolladores nos preocupamos por crear un software que permita cambios de una forma razonable. Los cambios no serán gratis, y no todos los cambios son igual de fáciles o difíciles de acometer, pero tenemos esto en la cabeza. Constantemente.

 

Un buen desarrollador sabe que el código que hace hoy, es código legacy mañana.

Escalabilidad: que mi software siga siendo fiable en el futuro

 

Es el “tercer nivel de calidad” del desarrollo de software y el objetivo es el de que el software siga funcionando cuando algún parámetro concreto se incrementa de forma sustancial (base de datos, usuarios concurrentes, peticiones / segundo…).

 

Un software que no se haya desarrollado pensando en la fiabilidad y la mantenibilidad, difícilmente tendrá problemas de escalabilidad.

 

En sucesivos posts iré adentrándome en cada uno de estos principios de fiabilidad, mantenibilidad y escalabilidad para explicar qué problemas deberíamos preocuparnos de resolver en cada uno de estos “niveles”.

 

Si mientras tanto quieres saber más, aquí tienes algunos enlaces que me han parecido relevantes.

 

http://bryanpendleton.blogspot.com.es/2012/03/internet-scale-administrations-and.html

http://blog.empathybox.com/post/19574936361/getting-real-about-distributed-system-reliability

https://www.safaribooksonline.com/library/view/designing-data-intensive-applications/9781491903063/ch01.html

http://www.learningthegoodstuff.com/2015/11/overarchitecture-in-software-is-desire.html?view=sidebar

http://highscalability.com/stack-overflow-architecture

 

Añadir nuevo comentario

Desarrollo con Drupal

Desarrollo con Drupal
Equipo de desarrollo de drupal 7 y drupal 8.

Desarrollo en Ruby on Rails

Desarrollo en Ruby on Rails
Más de 8 años de experiencia en Rails.

Rails development

Rails development
Using RoR since 2006, more than 150 projects

Desarrollo Web

Desarrollo Web
Co-creamos con nuestros clientes las mejores soluciones ágiles.

Web development

Web development
We co-create the best agile solutions with our customers.

Etiquetas

Artículos relacionados

Nuestra revista

View my Flipboard Magazine