¿Qué significa una posición de arquitecto de control de calidad? ¿Y qué significa la posición completamente incomprensible de meme wrangler? ¿Desde cuándo se deben conectar los probadores cuando se trabaja en arquitectura? ¿Cómo cambiar los procesos en la organización para que las personas en una reunión con la primera complejidad no regresen a la anterior?
Neil Ford presenta tres opciones en su sitio web: "ThoughtWorker" (un empleado de ThoughtWorks, que muchas personas conocen por Martin Fowler), "Arquitecto de software" y "Meme Wrangler". Pronto, en nuestra conferencia de Heisenbug, hablará sobre la creación de "arquitecturas evolutivas", que se pueden cambiar con las circunstancias externas cambiantes. Mientras tanto,
Mikhail xomyakus Druzhinin (miembro del comité del programa Heisenbug) le preguntó a Neal: cómo se cruza su discurso con las pruebas, y mucho más.
- ¿Puedes comenzar contando sobre ti y tu carrera?- por supuesto. He estado en ThoughtWorks por casi 14 años. Antes de eso, era CTO en una pequeña empresa de consultoría y capacitación de unas 25 personas, y allí comenzó a probar suerte en tecnologías como Java. Los primeros tres libros que escribí antes de unirme a ThoughtWorks. El primero fue sobre Delphi, en ese momento bastante popular en Rusia y en Europa.
Cuando era CTO, me cansé de ser un geek alfa. Cuando sabes más que las personas que te rodean, realmente no se desarrollan. Comencé a hablar en una variedad de conferencias, y realmente disfruté estar entre los otros oradores porque eran personas muy inteligentes e interesadas. Y comencé a buscar inconscientemente una compañía en la que las personas realmente inteligentes e interesadas trabajarían principalmente. Y literalmente tropecé con ThoughtWorks, como muchos, en el sitio web de Martin Fowler. En cosas como CruiseControl y la biblioteca de pruebas de NUnit, noté que hacen una gran contribución al código abierto y hacen muchas cosas muy interesantes. Y así, sin querer, comencé el proceso de entrevista con ThoughtWorks, al final del cual recibí una oferta de trabajo. Este fue un buen paso para mí, porque son desarrolladores muy inteligentes y muy entusiastas.
Podría ser un consultor independiente, pero en este rol no me gustan dos cosas. Primero, debe hacer todo el negocio usted mismo: facturar, perseguir a las personas por dinero, regular los flujos de efectivo y todo eso. Soy capaz de hacer esto, pero no me interesa. Mi pasión es el software y el desarrollo.
Y el segundo: si eres un consultor independiente, rara vez logras trabajar en colaboración con alguien, como equipo. Casi siempre estás solo y realmente me gusta el desarrollo del equipo. Incluso escribí varios libros junto con otros autores, incluido mi último libro, Arquitectura evolutiva. Me parece que cuando trabajamos juntos, el resultado es mayor que la suma de los componentes individuales. Cuando colaboras en un trabajo creativo, ya sea un proyecto de escritura o un programa, puedes obtener más puntos de vista y una idea más general, por lo tanto, el resultado será mejor.
En abril ya habrán pasado 14 años desde que estuve en ThoughtWorks. Lo sé muy bien, porque una de las ventajas interesantes de trabajar en ThoughtWorks es que si has estado en la compañía durante 10 años, obtienes un tiempo de vacaciones pagado de 12 semanas cuando puedes hacer lo que quieras. Y después de eso, cada 5 años obtienes un permiso creativo pagado de 6 semanas, por lo que me queda un año hasta las primeras 6 semanas. Realmente me gustó el de 12 semanas y estoy deseando que llegue el próximo. Así que siempre recuerdas la década que llevas aquí: se miden con unas vacaciones tan agradables.
- Esta es una duración de vacaciones muy tangible, genial."Fui contratado por ThoughtWorks como arquitecto y jugué ese papel por un tiempo hasta que llegué al nivel de director". La mayor parte de mi trabajo ahora se relaciona con el campo de la arquitectura de software, pasé mucho tiempo en la intersección de la arquitectura y las prácticas de ingeniería (por ejemplo, entrega continua). Sospecho que aquí mis intereses se cruzan con los de la audiencia de Heisenbug.
En particular, de lo que hablé mucho últimamente es el tema de mi último libro, la construcción de la arquitectura evolutiva. Si puede evitar errores, las personas que están probando la aplicación serán más fáciles. La arquitectura evolutiva incluye técnicas de seguridad para características arquitectónicas críticas, como capacidad de implementación, capacidad de prueba, escalabilidad, rendimiento, etc.
"¿Qué significa Meme Wrangler?"- De acuerdo con las reglas de ThoughtWorks, puede elegir cualquier título de trabajo, excepto algunos reservados como "CEO". Si se te ocurre una posición interesante, entonces, por favor. Y cuando finaliza el conjunto de tarjetas de presentación, puede crear una nueva.
Mi primer trabajo fue un arquitecto de aplicaciones. Esta posición reflejaba la esencia del trabajo, pero muy a menudo en grandes empresas implica que ya no aportas muchos beneficios, que pasas más tiempo dibujando que creando algo.
Y una de las ventajas del desarrollo personalizado es que puede familiarizarse con una gran cantidad de proyectos diferentes. Los arquitectos de software, creo, son "emparejadores de patrones" por naturaleza: tratamos de aplicar patrones a todo lo que vemos, incluso a cosas del mundo real. Entonces, si eres un arquitecto en desarrollo personalizado, tienes que ver muchos proyectos diferentes, ves patrones repetitivos en ellos, ves cuál de ellos funciona. Y me di cuenta de que, de hecho, mi trabajo consiste en recopilar ideas interesantes del ecosistema de software. De aquí vino el Meme Wrangler.
Meme es un término acuñado por el escritor Richard Dawkins; es una unidad generalizada para designar ideas. Todo el mundo conoce los memes de Internet; esto es algo ingenioso que se captura y se propaga como un virus. Y la palabra "disputa" tiene dos significados útiles, el primero es actuar como juez en una disputa y el segundo es conducir a un rebaño. Y elegí la posición de Meme Wrangler, porque refleja con mayor precisión lo que estoy haciendo ahora. Además, ahora que estoy lanzando otro libro, estoy escribiendo en Twitter que "enlazo otro meme" y lo puse en este libro.
- ¿Puedes explicar qué debe hacer un arquitecto de software, qué haces como arquitecto de software?"Por supuesto que puedo intentarlo, pero nadie realmente logra darle una definición a esto". Martin Fowler, un hombre que es muy bueno para dar definiciones a todo en el campo de la programación, se ha negado públicamente a definir el término "arquitecto de software" en su texto
"¿Quién necesita un arquitecto?" .
Pero si nos fijamos en el papel de un arquitecto de software, una de las cosas es que son responsables de todo lo que es difícil de cambiar. Todo esto está relacionado con la estructura de su sistema de software: qué patrones fundamentales utilizará, qué idioma o qué marcos. Porque todas estas decisiones tienen consecuencias de largo alcance.
Una de las cosas que realmente preocupan a los arquitectos es lo que llamamos "parámetros arquitectónicos", que también se llaman "requisitos no funcionales", pero no nos gusta este nombre. Estas son cosas como el rendimiento, la escalabilidad, la elasticidad, la capacidad de implementación: todo esto es responsabilidad del arquitecto. Un arquitecto puede crear una estructura que tenga en cuenta los requisitos del programa en sí y todos estos parámetros arquitectónicos que se deben proporcionar en él.
Suponga que es arquitecto y necesita crear una estructura de sistema de software para registrar estudiantes en una universidad. Supongamos que tenemos mil estudiantes y 10 cursos para los que deben inscribirse. Y ahora, según nuestro conocimiento de cómo están organizadas las universidades, qué cree que sucederá: los estudiantes se distribuirán de manera uniforme durante el semestre para que obtengamos la misma cantidad de estudiantes en cada curso, o todos durarán hasta la última hora, y entonces se apresura a grabar todo a la vez?
Y esto es elasticidad, este es un parámetro arquitectónico que debe asegurarse cuando crea un sistema de este tipo. Lo más probable es que esto no se indique en ninguna parte, pero lo sabe, simplemente en función del área temática. Esto es lo que hace que la arquitectura de los sistemas de software sea tan compleja: debe comprender el área temática, así como las capacidades técnicas y las limitaciones de su empresa. Puede estar limitado, por ejemplo, por el hecho de que esta base de datos relacional ya está seleccionada para el estándar de nuestra empresa, y necesitamos aumentar la productividad. ¿Cómo podemos lograr estos resultados?
Este es el trabajo del arquitecto de software: hacer frente a todas estas decisiones importantes relacionadas con el hecho de que tiene consecuencias a muy largo plazo y es muy difícil cambiarlo más adelante. Muchos elementos de la estructura, como la interfaz de usuario, son bastante fáciles de desarrollar, ya que solo cambia una capa de la aplicación. Y la arquitectura se trata más de cómo se yuxtaponen todas estas capas, y generalmente es mucho más difícil de cambiar.
Dicen que los microservicios ahora son bastante populares, y dicha arquitectura se creó específicamente con la expectativa de cambios constantes. Por lo tanto, realizar cambios importantes en la estructura del microservicio es mucho más fácil, pero se crearon desde el principio. Y este es un tema muy interesante para la investigación: cómo diseñar una arquitectura que sea fácil de cambiar, porque para la industria esto es exactamente lo que ha sido lo más difícil durante mucho tiempo.
- Sobre el tema de la arquitectura y las publicaciones: veo "QA Architect" en tarjetas de presentación y LinkedIn cada vez más.- Este es uno de los problemas del término "arquitecto": cada empresa tiene que inventar sus propios nombres para esto. Conocí tanto a "arquitectos de control de calidad" como a "arquitectos de datos", "arquitectos de sistemas", "arquitectos de soluciones", "arquitectos técnicos". Conocí a arquitectos de todas las franjas posibles. Y esto es un problema, porque nadie puede dar una definición clara y dar lo que quiere.
Lo que "arquitecto QA" puede significar para una empresa en particular, ni siquiera lo sé con certeza. ¿Esa persona desarrolla una estructura de control de calidad? En cuanto a mí, esto está más cerca de la función de un arquitecto como experto técnico, porque a menudo un arquitecto también es un gerente de proyecto técnico. Pero el arquitecto también se ocupa de la presentación y la documentación. Entonces, si soy arquitecto y tuve una idea brillante para una nueva arquitectura, pero no puedo hacer una presentación y convencer a la gente con dinero de que deberíamos hacerlo, entonces no tendremos la oportunidad de hacer realidad mi genial idea. Esto significa habilidades de comunicación.
Estas habilidades se aplican al control de calidad, y quien lo haga también puede llamarse "arquitecto". Verás, esta es una publicación tan vaga. Muchas organizaciones simplemente llegan al punto de llamar arquitecto al ingeniero principal, porque suena genial y no pueden imaginar cómo llamarlo. Como, ya sabes, desarrollador senior-senior-senior ... está bien, arquitecto. Y conocí compañías donde hay un tipo de arquitectos, y conocí compañías donde hay docenas de variedades de arquitectos. De hecho, estos son mensajes ficticios. Mi "meme wrangler" es mejor en este sentido porque obviamente está inventado.
- Hablemos en la dirección de tu discurso en Heisenbug. Hablarás en una conferencia de prueba: ¿qué pasa con la calidad del software para ti?- Personalmente considero la calidad de los componentes arquitectónicos del sistema. Sé que el mundo del control de calidad ve el software más como una caja negra, es decir, desde la perspectiva del usuario se ve si hay errores y fallas, si funciona correctamente. Por supuesto, también estoy interesado en esto, pero estoy más preocupado por las causas raíz de los errores: ¿por qué la aplicación no es confiable? ¿Por qué se bloquea periódicamente? Aquí tengo que ser la última línea de defensa, averiguar por qué sucede esto. Y hay cosas como el rendimiento y la capacidad de respuesta. Se habla mucho de ellos en el mundo de la interfaz de usuario ahora, tienen indicadores claros: si su sitio móvil carga contenido visible durante más de 3 segundos, los usuarios se irán y se irán a otro lugar.
Se presta gran atención al rendimiento web: cuál es el tiempo antes de cargar el primer contenido visible, cuál es el tiempo total de carga de la página. Y todos estos son parámetros de calidad, que desde luego son visibles desde el punto de vista de un observador externo, y yo soy quien debería descubrir cómo construiremos un sistema en el que se logren dichos indicadores. Y esto puede conducir a cambios en la interfaz con respecto a qué tecnologías web se utilizarán, pero también puede conducir a cambios en el back-end. ¿Quizás, para transmitir información no en tiempo real, sino en un paquete y en el medio hacer un mecanismo de almacenamiento en caché? Para mí, la calidad se ve así: determine cuáles son los requisitos y luego presente una implementación técnica que los incorpore.
- ¿Puede dar el estudio de caso más interesante de la práctica relacionada con la calidad?- Es difícil decir que todos los proyectos son diferentes, ¡así que lo mejor es siempre el último en el que trabajé!
Bueno, de alguna manera trabajé en un sistema donde los requisitos se parecían parcialmente a Lotus Notes. ¿Recuerdas un programa tan antiguo? Era un programa terrible, pero hizo una cosa muy, muy buena. Este programa se sincronizó muy bien: puede descargar su correo y notas, luego tomar un taxi, ir a algún lugar, responder todas las cartas en ese momento, y la próxima vez que se conecte a la red, todo se descargará, sincronizará y funcionará mágicamente automáticamente camino.
Y teníamos un cliente con un sistema de ventas que quería el mismo principio de funcionamiento. Debido a que los vendedores siempre están en movimiento, y era necesario que pudieran hacer pedidos sin una conexión a Internet, y luego todo se sincronizaría y se convertiría en lo que debería.
Y nos dimos cuenta de lo difícil que es esto, debido a un montón de casos límite y escenarios que deben proporcionarse. Primero, desarrollamos un sistema que funcionaba sin ninguna conexión a Internet, luego comenzamos la sincronización. Y hubo un montón de dolores de cabeza: por ejemplo, el rendimiento de una aplicación en línea en comparación con fuera de línea, apareció un retraso notable al conectarse, porque la sincronización se estaba llevando a cabo en ese momento. Entonces, en este caso, el control de calidad fue una gran astilla para nosotros, porque encontraron casos límite que destruyeron todo el sistema.
Y desde el exterior, esto parece una tarea simple. Aplicaciones como Dropbox y Google Drive resolvieron este problema para que se volviera invisible. Y parece fácil. Pero cuando intentamos resolverlo, resultó que había un millón de casos límite. Por lo tanto, sin un control de calidad confiable, es difícil encontrarlos todos, cada uno de los cuales debe volver a alinearse con la estructura de la aplicación para garantizar que la estructura general aún funcione.
En realidad, mientras estábamos desarrollando este sistema, realizando cambios fundamentales en la estructura, nos dimos cuenta de que los casos límite serían frecuentes e inaceptables. Y esta es una gran ilustración de lo importante que es tener un circuito de retroalimentación muy bien establecido entre el diseño de la arquitectura y partes como QA. Demasiadas compañías posponen esto en el último momento, pero si lo hace, al final muchas cosas se harán mal, y tendrá que regresar y pasar mucho tiempo para rehacerlo. Si establece un contacto cercano entre el desarrollo de la arquitectura y las pruebas, puede encontrar estos casos límite y cambiar la estructura mucho más rápido. Afortunadamente, fuimos extremadamente flexibles en este proyecto, ya que era un proyecto de ThoughtWorks, tuvimos un ciclo muy rápido. Y teníamos un equipo muy fuerte de evaluadores.
- Muchas personas en las pruebas preguntan cómo pueden afectar la arquitectura. Para ellos, la arquitectura es algo en una torre de marfil. ¿Qué se puede hacer con esto?- Me parece que sería útil que los evaluadores acudan a los arquitectos y les expliquen que están haciendo mal su trabajo, y que es mejor que los evaluadores sepan cómo realizarlo. ¡A la gente le encanta cuando les dicen esto! En realidad, no, no les gusta, nada bueno saldrá de eso.
Tengo un mantra favorito para tales casos: "es mejor mostrar que discutir". Necesitas mostrar cuán diferente es tu mundo de su mundo. Si usted es un ingeniero de pruebas, debe presentar un caso de usuario que demuestre claramente la falla del diseño. Si le muestra este escenario a un arquitecto, entonces esto no es solo una queja sobre algo, sino una demostración concreta: "Ahora, su proyecto no funcionará en tal escenario, por lo que debe ser cambiado". Si no están de acuerdo con esto, significa que simplemente perdieron el contacto con la realidad. Y los arquitectos deben ser sensibles a las cosas que suceden en el mundo real.
Hay una gran
poesía , como la llamo,
poesía del ex Secretario de Defensa Donald Rumsfeld, que habla de los "famosos famosos" y "desconocidos desconocidos". Por lo tanto, en cada proyecto de software hay "incógnitas desconocidas", por lo que el desarrollo de cualquier arquitectura debe ser iterativo. Debido a que no importa cuánto lo pienses, las cosas que no podrías prever de ninguna manera simplemente aparecerán repentinamente mientras intentas construir esta estructura.
, , Docker. , , . , , .
. , , , — , .
, , ?
— .— ! ! , , , . (QA). , , , .
, , QA , . , , , . -, . -, .
, — . , QA , . , . , .
— , ?— . , , , - QA-, -, , data science, . , .
, . , , . - : « ». - : «, , , , , ». , , , . .
, ThoughtWorks, « » . , , deployment pipeline. , , , , , . , QA, , , , , , , . , -.
— . , «-», «QA» - ?— . ThoughtWorks , , , . , , . , , -, . , . , .
— QA ?— , , . — . , .
- , . , , , . - , . , , . , , , . , .
, . , — , 1975 , .
— 1975-?— « -» , . , . ( ), « ». , . , , - , . , . , .
, , , — , QA . , . , , . , , .
— .— , , Apple , . Wi-Fi , , . . UI, . QA, .
— , . , ThoughtWorks — ?— , , « , ». , , , .
, . ? UI, , , — , . , , , : «! !» , , 50 Jira, .
. , : , , , : , , , . , .
. , . , , , .
, — « , ». , . , , . , , . , , — , . , .
. HR, . . — , , . , - ? , , -, , , ? , - :
— ! , - ? ?
— .
— .
15- Jira, , , . , , , , . , , - Slack, , , , Slack.
, , . , 30 . ? , . , , , . -. , . , .
: , , , , . - QA: , , email Slack, , . , , , .
— . . , -, , . .— , . , , . , , : , .
Slack! Slack — , . , , . « » , Slack. , « ». , , , , . - Slack, , , - .
, , .
-. , . — , , , . , . , - ?
— .— ! , . , . Slack, , . , Slack, , , , , , , .
— -. - , , .
. , IT-, , , , . . , , - - ?— . . - , , , -, . - , .
: - , . «, ». . , .
, . , , . ThoughtWorks, , , , . . , ThoughtWorks , .
, , , , , . « , ». , , - , — , . , - , . «»: , , , . . , , , .
, . -, . : «, , agile-, 1,3 , «», 30% ». , . : « , , , , ».
— , ?— : ? ? , . , - — . ? - — , , .
, , . , , , . , -, QA , , , , . , . , , , — , , , .
— , , , - ?— . , : , , -, , , , .
— , , , . , : « », , , .
— «architecture is abstract until operationalized», . , , ?- por supuesto. , , meme wrangler.
, DevOps-. , , . DevOps , , — , , .
, — , « » . . , . , : , , . , , ?
— .— , , ! , , . — , , , , , . , , , , : Docker -, - . , , .
, , — , , .
— . !Heisenbug , 17-18 , «Building evolutionary architectures: Fitness functions». , : , — .