Cuando los programadores ven el concepto de “full stack”, probablemente tengan dos reacciones

1. ¡Joder, esto es genial, alucinante!

2. ¿Qué sabrás tú? Full stack es ser mediocre en todo

Las dos reacciones anteriores son en realidad injustas. Porque, aunque solo se aprenda una tecnología, hay mucha gente que es muy mala en ella; y entre los ingenieros full stack también hay muchos que hacen de todo y lo hacen bastante bien. Ni hablar de que en este mundo existe otro tipo de programadores “explosive stack”, que hacen cualquier cosa y en todo son excelentes.

Desde mi práctica personal,Aprendiz de full stackAl menos debes dominar las siguientes habilidades:

• Desarrollo front-end web; dominar al menos un framework de front-end;
• Desarrollo back-end de servidor; dominar al menos un framework de back-end;
• Operaciones de servidor; dominar la construcción y el mantenimiento de Linux Server;
• Desarrollo de cliente; dominar al menos uno entre iOS y Android;
• Bases de datos; dominar bases de datos SQL y noSQL.

Y obtener“full stack”como título debería implicar, al menos, que una persona pueda completar por sí sola la construcción de un producto, y que realmente haya pasado por la operación comercial, y que haya sido, por la propiaestupidez,perjudicado innumerables veces.

De esto se deduce que el umbral del full stack es bastante alto. No es que dominar las cinco habilidades anteriores te permita llamarte full stack; al menos hay que añadir “aprendiz” como matiz. Y es precisamente porque demasiados aprendices se autodenominan full stack que los demás piensan que “full stack” es sinónimo de “mediocre en todo”.

Sin embargo, el título de este artículo es: por qué deberíasprobarel full stack. Así que lo que quiero discutir no es si hacerte full stack, sino el probarlo.

El lego y el experto

En los últimos años, hablé con no pocos equipos y descubrí que la gran mayoría de los conflictos de equipo se deben a:

• El lado del servidor no entiende al cliente; después de diseñar una API, dice tonterías;
• El diseñador no entiende al cliente; al diseñar una interacción, dice tonterías;
• El cliente no entiende al servidor; dice tonterías sobre la API;
• El cliente no entiende el producto; dice tonterías sobre los requisitos;
• El product manager no entiende los requisitos; le dice tonterías al Team.

Excepto el último, el product manager, que debería ser quemado, los primeros cuatro conflictos todavía tienen solución.

El programador es una profesión en “modo Dios”; su trabajo diario es crear, por lo que parece una profesión muy genial. Sin embargo, precisamente por eso, los programadores tienen algo de arrogancia.El resultado de la arrogancia es usar el limitado conocimiento propio para especular sobre cómo debería hacerse el trabajo de los demás.。

Si el lado del servidor no entiende al cliente, es muy fácil diseñar APIs que no se ajustan a los mecanismos del cliente. En ese momento, si el programador del lado del cliente explica con paciencia, cada API puede tomarse uno o dos días de ajuste; si no, se llega a pelear.

Pero los programadores del servidor no siempre se equivocan. El cliente espera que todos los datos, una vez entregados, no necesiten procesamiento adicional; pero si se entregan según la estructura que el cliente necesita, algunas consultas pueden tardar uno o dos segundos. Si el cliente no entiende los mecanismos del servidor y se limita a exigir con la idea de que “el servidor está para servir al cliente”, las discusiones serán difíciles de evitar.

Si las discusiones entre técnicos son una guerra de armas blancas, entonces, si te encuentras con un product manager o un jefe todavía más lego, estalla una guerra nuclear.

Solo tienes que modificar una página web. ¿Puedes resolverlo en diez minutos?

¿Cómo va a ser tan difícil de hacer el efecto? ¡Te lo hago yo!

¡Que salga en línea mañana, apúrate!

No me importan las dificultades técnicas. ¡De todos modos, tienes que implementármelo!

Y este tipo de escenas se repiten constantemente en casi cualquier empresa.

Trata de entender la tecnología del otro

Hablemos primero de mi trayectoria de crecimiento técnico.

Empecé a usar Linux desde la secundaria; mi sistema principal era Ubuntu, luego cambié a ArchLinux y después volví a Ubuntu, y lo usé hasta el primer año de universidad. Estos años de experiencia con Linux sentaron las bases de la arquitectura de servidores. En el primer año de universidad empecé a intentar crear un producto propio.

En ese momento pensé que debía escribir primero una versión web y luego un cliente.

Así que empecé por el backend. Usé Django como punto de partida, pero pronto me pasé al bando de Rails. El desarrollo ágil de Rails redujo enormemente los costos de desarrollo, y sus convenciones permiten que los novatos crucen volando con seguridad muchas zonas peligrosas.

Cuando empecé a escribir el front-end web, no sabía que existía algo llamado framework front-end. No fue hasta terminar de escribir con Rails que descubrí que existía una cosa llamada Ember.js, así que empecé a reescribirlo con Ember.js. Al principio todavía pensaba en cómo usar Rails para renderizar el front-end; luego descubrí que, en realidad, después de introducir un framework front-end, el papel de Rails ya se había convertido en un API Server.

A partir de ahí, empecé a considerar desde una nueva perspectiva cómo diseñar las APIs de Rails. Leí muchísimos materiales sobre diseño de APIs: cómo diseñar el front-end para que sea fácil de usar, cómo reducir el tiempo de consulta, caché del servidor, Redis, seguridad, etc.

La automatización de Rails ayudó bastante: muchos lugares que yo no conocía ya estaban hechos por él. Y cuando quieres entenderlos, descubres que su implementación es sumamente ingeniosa. Ni hablar de la receptividad de Rails hacia nuevas tecnologías, que hace que siempre tengas cosas nuevas con las que jugar. CoffeeScript y Sass fueron absorbidos por Rails desde el principio como las tecnologías front-end predeterminadas de su framework.

Luego pasé de Ember.js a Angular.js y reescribí todo con Angular. Durante ese tiempo también conocí la herramienta front-end Grunt (el front-end cambia a pasos agigantados; lo que se usa ahora ya no es esto).

Finalmente empecé a desarrollar el cliente iOS. En ese momento, la implementación de la interfaz de iOS era muy diferente del HTML y CSS de la web, así que dediqué bastante tiempo a comprender los conceptos de UI de iOS y a transformar mi forma de pensar, de la web a la filosofía de desarrollo de interfaces de iOS.

La base de datos también cambió en ese período de MySQL a MongoDB, porque la moda de aquellos años era justamente esa transición.

En este proceso de práctica técnica, afortunadamente estaba solo, así que no había nadie con quien pelear. De lo contrario, creo que en cada etapa habría habido muchos motivos de discusión.

Después de que el proyecto que desarrollé saliera en línea, a medida que aumentaba la complejidad de las operaciones, entré en contacto con métodos de operación automatizada como Chef y Ansible. Más adelante también monté servicios de monitoreo como NewRelic. Y para tener un entorno de desarrollo estable, usé Vagrant.

Todo esto ocurrió en solo un año.

Curiosamente, muchas veces, mientras escribía el cliente iOS, de repente comprendía los principios de implementación de HTML y CSS; mientras trabajaba con Rails, de repente se me ocurría una mejor forma de arquitectura para iOS. La sensación de comprender distintas tecnologías por analogía ocurría todos los días.

En el tiempo posterior, esta experiencia hizo que me fuera muy fácil comunicarme con diferentes técnicos, porque el año pasadoMiaoShi,para hacer filtros, empecé a investigar OpenGL; al retomarBlenderesto, muchos lugares que antes entendía a medias, de repente su implementación se volvió tan simple como Hello World. Así que también me puse a jugar con Unity; con toda esta acumulación, aprender Unity se volvió muy fácil y se convirtió en mi proyecto de ocio nocturno. Quizás pronto verás un juego hecho por mí (podría ser un RPG).

No creo que el full stack te haga mediocre en todo. Cada tecnología, mientras la practicas, puede aportar ideas a las demás. Y si conoces varias tecnologías, profundizar en una de ellas a menudo retroalimenta a las otras. Al contrario, si las tecnologías que conoces son muy limitadas, probablemente eso sea lo que restrinja tu propio potencial.

Respeto y paz

En la comunicación del equipo, comprender la tecnología del otro puede reducir muchísimo los costos de comunicación y aportar respeto y paz.

Es raro ver a grandes maestros discutiendo sobre quién debe ceder; al contrario, suelen ser los que apenas han vislumbrado el camino los que discuten sin parar todo el día y explotan ante la menor provocación.

Aunque es difícil decir que el nivel de toda la industria pueda cambiar cualitativamente pronto, creo que si los requisitos del producto pueden describirse con detalle y claridad, explicando las razones; si los técnicos pueden aprender unos de otros y debatir con paciencia; si los diseñadores pueden respetar las cuestiones de la dimensión técnica y diseñar prototipos más acordes con el presente; entonces todo se desarrollará en una buena dirección. Todo esto comienza por comprender el trabajo del otro.

Autor:Zhou Kaiwen

Dirección original: http://www.ifanr.com/551905