Hola, mi nombre es Pavel y estoy lleno en Mad Devs * aplausos *.En el contexto de una gran cantidad de artículos y materiales sobre el hecho de que
no se necesitan pilas completas, no existen pilas completas ,
las pilas completas son malas , existe una opinión sobre
las ventajas que tiene una pila completa sobre los especialistas especializados , y por qué
se necesitan pilas completas .
Quería dejar una lista de enlaces a otros artículos sobre pilas completas al comienzo del artículo, pero había demasiados, así que lo siento. Solo quiero decir que hay suficiente material sobre por qué una pila completa es buena y por qué una pila completa es mala. Y cada uno de ellos es al menos un 50% cierto.
Probablemente hay emociones y pensamientos personales que no pretenden ser el último recurso.
Como ya dije, mi nombre es Pavel, pronto pasarán 7 años desde que obtenga dinero para la programación. Y durante todo este período me llamé a mí mismo en el currículum, en las entrevistas y en otros lugares:
desarrollador de backend con conocimientos y habilidades en Frontend y DevOps . De una forma u otra, en una carrera profesional, a menudo trabajó como back-end en proyectos, pero nunca tuvo miedo ni del frente ni de las operaciones. Por lo tanto, agregó con orgullo estas dos áreas a su descripción. Es cierto, con la llegada de Mad Devs, y después de haber trabajado en uno de los proyectos con nuestro equipo de MadOps, eliminé DevOps de mi descripción, porque ahora creo que no lo entiendo en absoluto. Todo en comparación es conocido, como sabes. Espero algún día trabajar con los mismos especialistas de front-end que me "persuadirán" para que elimine la posdata de front-end. Lo principal es no encontrarse con un backender, lo que lo obligará a eliminar el backend del currículum, de lo contrario no quedará nada.
Los argumentos más frecuentes de los expertos que escriben y creen que un stack completo es malo suena así:
no hay inmersión en ninguna de las áreas ,
no puedes ser un desarrollador senior de fullstack , los especialistas
estrechos de clase alta ganan más que los stacks completos fuertes , etc. Y sabes, estoy de acuerdo con ellos.
En los últimos meses, he estado trabajando en el proyecto Peklo Tool, que utiliza Ruby en el backend, VueJS en el frente y Go para implementar un generador de texto.
Y siento los problemas:
- Siento que este código en Go se puede escribir mejor, y funcionará más rápido o usará menos recursos del sistema;
- Siento que mi configuración de paquete web se puede configurar mucho mejor, ahora hay mucha basura;
- Siento que este diseño se puede hacer usando CSS moderno, características SCSS, o tomar PostCSS u otras extensiones;
- Creo que el código en los rieles se puede optimizar para que se hagan menos consultas en la base de datos, por ejemplo;
- Siento que los índices deben configurarse humanamente en la base de datos;
- Siento que este Dockerfile necesita ser reescrito para que haya menos (o más) capas;
- y así sucesivamente, así sucesivamente ...
Puedo sentirlo todo. Además, realmente quiero hacerlo todo. Y, cuando aparece un minuto libre, resuelvo parcialmente al menos uno de estos problemas.
Me preguntas:
¿por qué no usas inmediatamente la cosa N en este lugar para que no haya tales problemas?Y responderé:
no sé la cosa N, tan buena que puedo aplicarla rápidamente en un proyecto en un caso determinado. Solo me tomo el tiempo del desarrollo , lea el problema:
no hay inmersión completa .
Y no mentiré, porque el proyecto en el que estoy trabajando necesita características. PekloTool es una herramienta profesional para generar campañas publicitarias contextuales. La herramienta es joven, el desarrollo ha estado en marcha durante poco más de un año, pero entró en producción completa hace solo un par de meses. Como resultado, ahora estamos haciendo todas las funciones útiles para dicho producto.
¿Cómo sé que las características son necesarias y que serán útiles? Muy simple
porque soy full stack . Veo todo el proyecto. Veo los objetivos del proyecto, veo cómo funciona, veo sus jambas, no solo las técnicas sobre las que escribí anteriormente, sino las jambas que los usuarios verán.
Y aquí llegamos al punto principal de este artículo: creo que una pila completa moderna no debería ser solo un codificador que pueda hacer backends, front-end u otra cosa. Fullstack es alguien involucrado en el desarrollo de un proyecto. Además de las competencias de backend, frontend, etc. Full stack debe tener una comprensión del área temática del proyecto, conocimiento de UX / UI e incluso un poco de marketing. Fulstack debe saber cómo el proyecto cumple con su tarea principal: si está haciendo dinero o salvando al mundo. La pila completa debe estar en un pie corto con el "cliente" del proyecto. Cualquier proyecto tiene un "cliente", si es una empresa de outsourcing, es un cliente, en una empresa de productos es un actor o producto. El "cliente" debería ver en la pila completa a ese especialista con el que puede consultar sobre todos los asuntos relacionados con el proyecto.
En el manual de los recién llegados Mad Devs (el mismo documento que se le da a leer el primer día de la empresa) hay un elemento llamado: "Afinidad del cliente" (
Ing. - "Proximidad al cliente"). Describí la esencia del término en el párrafo anterior. Una pila completa siempre debe ponerse el sombrero de un cliente; la opción ideal es cuando el "cliente" realiza tareas de sprint junto con una pila completa. Es decir, una pila completa comprende el historial de la apariencia de cada tarea, y no solo resuelve las tareas que se le asignaron. Creo que si una persona simplemente realiza tareas y su trabajo termina allí, incluso si hace un back-end, una interfaz de usuario, un teléfono móvil, etc., esto no es una pila completa. Esto es solo un back-end que puede hacer front-end, o viceversa.
Entonces escribo todo esto, y el lector puede tener dos pensamientos:
- Qué tontería . Aquí a cada uno lo suyo. Si lo crees, lo más probable es que seas un especialista limitado, entonces tu opinión es clara. Pero, si eres full-stack, te "haré feliz". Pierde una enorme capa de actividades útiles que beneficiarán su proyecto y también pierde la oportunidad de adquirir competencias importantes que pueden determinar el desarrollo futuro de su carrera;
- ¿Es así como debería verse una pila completa en el propietario de un producto? Si tienes razon. Con la excepción de un par de puntos: el producto oouner es a menudo el líder del equipo de todo el proyecto. No atribuiré cualidades de liderazgo a una pila completa. Esto se trata de otra cosa. Bueno, el producto que presenta debe poder considerar el costo de desarrollar un proyecto, no se requiere una pila completa para pensar en las finanzas relacionadas con el desarrollo. Desde su posición, ya hay dinero para el desarrollo. Por supuesto, puede ofrecer opciones para reducir el costo de desarrollo, pero solo en términos porcentuales o cualitativos, no en términos cuantitativos. Tal vez un par de momentos me faltan algunos que el producto debería poder, pero puedo, estoy lleno.
Hay otra cara de la moneda que quiero describir. Esto es
triste El problema con las pilas completas es que están sobrecargadas. Esto es obvio. Como regla general, hacemos tareas muy voluminosas, características complejas. Todavía tenemos comunicación con el cliente para presentar las características y tareas que escribí anteriormente. Además, cuando ve todo el proyecto desde un punto de vista técnico, a menudo trabaja en infraestructura, arquitectura y otras cosas. Cuanta más información, más ideas y más ideas, mayores serán las posibilidades de que se hagan realidad. Como resultado, a menudo piensa: tal vez una base de datos NoSQL, o tal vez GraphQL, o tal vez algo más. Aquí es donde el empleo aparece por sí mismo. No estoy hablando del hecho de que inmediatamente corro para transferir todo a GraphQL condicional, pero a veces aceptas algunas ideas más pequeñas y las implementas. En resumen, muy ocupado.
Quieres que? Me gustaría probar una nueva biblioteca, estudiar más la configuración de Gitlab CI, fumar algo interesante y relativamente nuevo para mí al frente, por ejemplo, Logux. Pero no hay tiempo, usted es responsable del proyecto. No diré que esta
tristeza , solo tristeza triste. En contraste, recibo un gran revuelo: cuando veo comentarios positivos de los usuarios; cuando con alegría escriben sobre una característica por la cual no dormiste durante un par de días; cuando crece el número de usuarios.
En conclusión, expreso la idea de que los especialistas estrechos y amplios tienen sus propias ventajas para el proyecto, su carrera, entorno y desventajas. En mi opinión, describiré las ventajas y desventajas profesionales específicas en uno de los siguientes materiales, a menos que, por supuesto, esto se reciba calurosamente.
Me alegro de que soy full-stack, porque este es el trabajo que me gusta, que no me importa hacer el fin de semana, y que hago con mucho gusto.