El invitado del nuevo número del podcast Dry Oars es el arquitecto de software Yegor Taflanidi. Estamos discutiendo qué tipo de papel metafísico es este, qué dificultades hay en el trabajo y qué tiene que ver la fuerza oscura con él.
Artyom Kulakov y Roma Choryev son los desarrolladores de Redmadrobot.
Graban podcasts de tubo donde, junto con los invitados, discuten diferentes aspectos de la creación de productos de TI. A continuación hay un enlace al nuevo problema y respuestas a varias preguntas urgentes.
Tiempo01:40 Egor cuenta cómo se convirtió en arquitecto
12:40 Mitos populares: un arquitecto es la etapa más alta de desarrollo de un desarrollador; el arquitecto sabe todo lo mejor y más; el arquitecto no escribe el código (porque olvidó cómo hacerlo); un arquitecto se sienta y dibuja algunos esquemas
31:20 Discusiones sobre lenguajes de programación modernos
39:10 Sistema / Solución / etc. Arquitecto. ¿Qué significa todo esto?
47:50 Discusión de la misma "maldición"
50:24 Cómo convertirse en arquitecto (advertencia: algunos chistes)
55:16 Gestión del tiempo: un día hábil de un arquitecto, ¿qué hace?
01:03:39 ¿Cuáles son las dificultades en el trabajo y cómo superarlas?
01:13:49 Y lo que sigue: ¿cuáles son los vectores de desarrollo?
01:26:59 La respuesta a la pregunta: ¿cuál es el verdadero camino para el arquitecto?
¿Quién es un arquitecto de software?
Un arquitecto es un especialista que construye sistemas de TI para resolver problemas comerciales. Está bien versado en todos los matices del diseño del sistema.
Si necesita desarrollar, por ejemplo, una aplicación, el arquitecto le dirá cómo hacerlo sin pisar un rastrillo. Explicará qué tecnologías utilizar, qué problemas se pueden encontrar, y sentará las bases para el desarrollo del proyecto. El diseñador de la aeronave decide desde qué construir el avión, y el arquitecto decide con qué tecnologías desarrollar un sistema de TI que resuelva el problema.
¿Debería un arquitecto entender todo?
En la conversación resultó que esto sale por sí solo. El arquitecto está involucrado en diferentes situaciones: se comunica con el cliente, resuelve problemas de ingeniería e incluso participa en la planificación del proyecto. Si quieres o no, profundizas en el negocio y descargas la habilidad de gestión. Egor explica:
- Toda la esencia se reduce a dos cosas: el arquitecto debe resolver los problemas de los negocios y debe alejar el sistema de las restricciones. Si sabe que el sistema no tiene la capacidad física para realizar estas u otras cosas, pero existe una necesidad comercial, entonces su tarea es descubrir cómo y armar todo. Podemos decir: asegúrese de que las ovejas estén enteras y los lobos estén llenos.Durante el día, un arquitecto pasa una gran cantidad de información de gerentes, desarrolladores, clientes. Por lo tanto, al final del día resulta que él está familiarizado con la situación desde diferentes ángulos. Artyom resumió:
- Un arquitecto tiene más que ver con el ancho que con la profundidad. Por ejemplo, no tiene que poder trabajar con la reflexión y algunas cosas de bajo nivel en Android, pero es importante comprender cómo funciona todo en general.¿El arquitecto escribe el código?
En resumen, algunos arquitectos codifican. Más sobre esto en un discurso de cinco minutos en el podcast, que comienza a las 10:25 p.m. Spoiler: se trata de código perfecto, problemas perfeccionistas y requisitos comerciales.
¿Cómo convertirse en arquitecto?
Según su experiencia, los muchachos dijeron que es imposible simplemente cambiar de desarrolladores a arquitectos. La necesidad de esta posición debe aparecer primero. Solo entonces se selecciona a una persona del equipo o se llama a un especialista externo.
- Lo teníamos de esta manera: la compañía se estaba desarrollando, la cantidad de personas y proyectos estaba creciendo. Había que mantener la calidad, por lo que llegó el momento en que apareció un "nicho de responsabilidad" gratuito.¿Es el arquitecto el más alto nivel de desarrollo?
El estudio acordó que este es definitivamente un hito en el desarrollo del desarrollador. Pero no tome al arquitecto como una versión mejorada del "senior". Egor explicó que el arquitecto no es el final ni el techo. Tal especialista tiene una gran habilidad para resolver problemas de ingeniería, por lo que hay muchas opciones para el desarrollo. Por ejemplo, puede ir a IoT, diseñar lenguajes de programación o ir a un área adyacente.
¿Y qué tipo de "maldición"?
Entonces Yegor explica este fenómeno:
- "La maldición" es que cuando hay necesidad de un arquitecto, y una persona ocupa este puesto, nadie más en esta empresa puede convertirse en arquitecto.Dijo que es poco probable que el especialista que asumió el cargo pueda hacer algo más en el futuro (dentro de la empresa). Esto se debe al hecho de que es difícil "educar" al adjunto. Esto sucede por varias razones: las tareas de un arquitecto son difíciles de delegar, no siempre hay una persona que quiera tomar el lugar de reemplazo y simplemente no hay suficiente tiempo para la capacitación.
Escuche el podcast en una plataforma conveniente:
SoundCloud ,
Apple ,
Google Podcasts .
Enlaces utiles
Artículos importantes, videos y libros para aquellos que quieran transformarse en arquitectos:
Muchos artículos y videos útiles que son útiles para pasar de desarrolladores a arquitectos.Arquitectura de software en la práctica, L. Bass: los fundamentos de ser arquitecto.Arquitectura de sistemas de software: trabajar con partes interesadas utilizando puntos de vista y perspectivas es uno de los principales libros que describe más completamente los principios del arquitecto.¡Suéltelo!: Diseñe e implemente software listo para producción: historias sobre cómo diseñar software y lo que sucede cuando está diseñado de forma torcida.Patrones de arquitectura de aplicaciones empresariales: memorias del viejo Martin Fowler sobre cómo diseñar software.Diseño basado en el dominio: abordar la complejidad en el corazón del software E. Evans: sobre el modelado correcto.
Aplicación de UML y patrones: una introducción al análisis y diseño orientados a objetos y al desarrollo iterativo C. Larman - proyecto @ documento,% username%.
Requisitos de desarrollo para software, K. Wigers: Microsoft escribe sobre requisitos de desarrollo.Descripción general de los patrones de diseño.Ven a discutir el tema
en el chat de Telegram.