Full-stack Developers, unicornios y otros seres mitológicos

Según la “Developer survey 2016” de StackOverflow, una mayoría de desarrolladores se consideran a sí mismos “full-stack developers”, un perfil intrínsecamente senior, muy exigente en conocimientos y con alta demanda en el sector.

Hablamos de un desarrollador capaz de diseñar e implementar proyectos tanto en el lado servidor como en el lado cliente, lo que implica conocer los puntos fuertes y débiles de cada tecnología y mantenerse actualizado según estas vayan evolucionando y/o aparezcan otras nuevas.

Con la evolución tecnológica del Web stack, mantenerse actualizado y productivo en el front y en el back-end resulta cada vez más complicado, hasta el punto de cuestionarnos si poder cumplir esas expectativas ya es más un mito que una realidad.

Cover-Image

Fuente: www.packtpub.com

 

Orígenes del Full-stack Developer

Cuando se creó este perfil, a principios de los años 2000, las tecnologías Web eran claramente menos complejas y las opciones entre las que escoger, menos numerosas:

  • Existían tres o cuatro servidores de aplicaciones mayoritarios, todos encargados de mantener el estado de la aplicación, aplicar las reglas de negocio y generar el UI de los clientes. Los lenguajes y entornos podían variar, pero el modelo cliente-servidor, los patrones de desarrollo y las técnicas utilizadas eran relativamente similares.
  • Todas las BBDD seguían el modelo relacional, con lenguajes de consulta SQL. Teniendo un dominio del estándar SQL-92, era posible saltar de un SGDB a otro en un tiempo reducido.
  • El front-end utilizaba un Javascript menos potente y un DOM basado en HTML4/CSS2, orientado únicamente a presentar documentos en ordenadores de sobremesa con pantallas de resoluciones y densidades de pixel similares.
  • El ancho de banda de Internet podía ser hasta 100 veces menor que el actual.

En este contexto era perfectamente posible para un mismo desarrollador asumir la responsabilidad de todo el desarrollo.

El perfil full-stack había nacido, haciéndose popular con la expansión de Facebook, la cual, aparentemente sólo contrataba desarrolladores con este perfil.

Evolución Tecnológica

Desde entonces, la evolución de las tecnologías front y back-end ha sido considerable:

  • Se ha dado un cambio fundamental de paradigma sobre dónde reside el estado de una aplicación, que ha migrado claramente desde el back-end hacia el front.
  • Este cambio de paradigma ha modificado también el centro de gravedad de los conocimientos del desarrollador full-stack, que ha pasado de ser, al inicio, un experto en back-end con conocimientos de front, para ser ahora más un experto en front-end con buenos conocimientos de back.
  • Javascript se ha sofisticado (ECMAScript 5, 6 y 7) al punto de poder implementarse soluciones de ingeniería de software a un nivel muy parecido al de C# o Java.

    Los frameworks JS modernos son casi tan complejos como los del back-end, como prueban las curvas de aprendizaje de AngularJS o Ember, empezando desde cero, o la relativa facilidad de adaptación de los developers back-end que se pasan al front.

  • La máquina virtual del navegador ha seguido evolucionando, desde la mera presentación de documentos del comienzo hasta convertirse en una verdadera plataforma de aplicaciones.


    La última característica del paradigma de orientación a objetos que le faltaba, el
    encapsulamiento, ya lleva tiempo resuelta a nivel JS y ahora lo está también a nivel del DOM, con estándares como el Shadow DOM o los Custom Elements.

    Las soluciones que hacen uso de esto nos empiezan a ofrecer la posibilidad de una verdadera “componentización” en las aplicaciones Web:
    AngularJS 2.x, Polymer o React, entre otros, tratan de dar respuesta a esta filosofía (los antiguos expertos en FLEX se van a sentir como en casa ahora).

  • Al inicio de la década actual, al entorno desktop se añadió el entorno móvil con una experiencia de usuario propia.

    Tanto iOS como Android exigen dominar su ecosistema, rico y complejo, si se desean ofrecer soluciones nativas y, sólo en el caso de utilizar tecnologías híbridas basadas en el DOM del navegador (
    Apache Cordova, por ejemplo), es posible ahorrar esfuerzos de desarrollo, si bien con contrapartidas de rendimiento.

    Lo último son tecnologías híbridas donde se administran recursos nativos orquestados mediante Javascript, ofreciendo experiencias de uso indistinguibles de las nativas (NativeScript o React Native).

  • Las posibilidades de layout son ahora mucho más potentes. Los estándares de CSS y el DOM permiten maquetaciones muy sofisticadas, necesarias para adaptarse a los múltiples clientes: mobile/desktop, diferentes tamaños y densidades de pantalla, UIs táctiles, etc. Y son estándares que siguen creciendo (CSS4, FlexBox) no ya solo en 2D, sino también en 3D (WebGL).
  • En el back-end, las BBDD ya no siguen en exclusiva el modelo relacional. Las capas de persistencia “NoSQL” han llegado para quedarse y son varios los actores en esta película.
  • De aplicaciones de arquitectura monolítica se está pasando a arquitecturas más distribuidas, basadas en microservicios, mucho más escalables y a las que se les deriva, no ya aspectos clásicos como el almacenamiento de la información, sino también parte del procesamiento de esa información.

FullStack-Image

Fuente: www.carlosja.com

Conclusiones

Aún con este panorama tecnológico tan amplio, el desarrollador con vocación full-stack aún tiene alguna posibilidad. Un ejemplo de ello es que, escogiendo bien el stack de tecnologías, ahora se puede utilizar el mismo lenguaje en todos los contextos del desarrollo: Javascript en el cliente desktop (DOM), en el cliente móvil (Cordova, React Native), en el servidor (Node.js) o en la BBDD (MongoDB).

Y sin embargo, esperar que una misma persona pueda escoger las tecnologías óptimas en toda circunstancia, realizar los desarrollos front y back con alta productividad y todo en un plazo de tiempo razonable, parece algo cada vez menos realista.

Sin negar que siga habiendo casos en los que esté justificado un perfil full-stack clásico, como en start-ups creadas en torno a un stack concreto o en proyectos más pequeños, ¿no deberíamos jubilar definitivamente este perfil tal y como lo conocemos?

¿O quizás solo es cuestión de buscar una nueva etiqueta para alguien que, teniendo que conocer hasta cierto nivel todas las capas, su responsabilidad principal sea sólo integrarlas?

Con 14 años descubrí que, tecleando ciertas cosas, podías hacer aparecer en la pantalla lo que quisieras y desde entonces no he parado. Tras estudiar informática en la Universidad Pontificia de Salamanca me especialicé en el diseño y desarrollo de sistemas multimedia, tanto dentro como fuera de la pantalla, siempre interesado en la experiencia de usuario final. Soy miembro del departamento UX de Paradigma Digital, con el rol de front-end developer.

Ver toda la actividad de Arturo Batanero

Recibe más artículos como este

Recibirás un email por cada nuevo artículo.. Acepto los términos legales

7 comentarios

  1. Luis Calvo dice:

    Muy buen post Arturo, coincido contigo en gran parte del enfoque que muestras del full stack. Lo único en lo que creo que discrepo contigo es en lo que yo considero que es un front-end developer full stack. Opino que un front full stack no debería conocer tecnologías servidor (java, php, phyton, etc) sino que es una persona que controla de desarrollo front (html.css, javascript) y que utilizando node es capaz de realizar desarrollos en back (hasta cierto punto)

  2. David Montalvo dice:

    Habría que encontrar primero una definición formal de que es un “full stack” pero mientras tanto la cuestión es, Luis, si la industria y ese gran porcentaje de developers que se considera “full-stack” lo entiende como tu dices. Yo creo que no, yo creo que se consideran a sí mismos algo parecido a lo que describe Arturo.

    Lo que StackOverflow dice tras lanzar el dato es: “More respondents consider themselves Full-stack Developers than any other role. On average, Full-stack developers are comfortable coding with 5 to 6 major languages or frameworks (vs. 4 for everyone else). Esto tampoco nos aclara si un “full stack” es A o B.

    Buen post!

    • Luis Calvo dice:

      Es que el término se ha desvirtuado. Un full stack era un front que con Javascript tocaba cosas de back (en Node) y ahora, con gente de back (javeros por ejemplo) que aprenden a usar Angular y ya se denominan full stack. Lo que comenta Arturo es más parecido al antiguo Webmaster (un hombre-orquesta que hace front, back, seo, reparte octavillas en el metro y reparte los pedidos)

  3. David Montalvo dice:

    Bueno, un webmaster era ese “ser” que manejaba aquello tan novedoso de “Interné”, eso incluía sistemas, diseñar la interfaz, diseñar un logo y hacer la colada del jefe. Si el término se ha desvirtuado -coincido- entonces es que la gente se ve como dice el artículo y lo que es más importante los recruiters también lo ven como el artículo, un tipo que sabe *bien* de front y back.

    • Arturo Batanero dice:

      El conjunto de responsabilidades a las que nos referimos -ser capaz de resolver en front y en back- están claras.

      Por supuesto los términos van evolucionando y con el artículo lo que digo es que, precisamente, eso es lo que hace falta: un nuevo término.

      A mi, el que más me gusta de los que he oído es “Full-stack Integrator”.

  4. Juan del Río dice:

    Coincido con Luis en que ahora el término full stack es igual al antiguo web master.

    Ojo al dato:
    https://www.google.es/trends/explore#cmpt=q&q=%22full+stack+developer%22

    Cuando empezó a ponerse de moda el término tenía todo su sentido, ya que estaba acotado a las tareas que podía abordar un perfil front en la parte back con node.

    Los primero artículos que yo recuerdo sobre esto:
    https://www.smashingmagazine.com/2013/11/introduction-to-full-stack-javascript/
    https://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

  5. […] una toma de contacto con las tecnologías front-end y viceversa fomentando también la creación de ingenieros full-stack. Además en el caso de los ingenieros back-end esto nos permite incluir fácilmente un front para […]

Escribe un comentario