O que significa uma posição de arquiteto de controle de qualidade? E o que significa a posição completamente incompreensível do wrangler de memes? Desde quando os testadores devem ser conectados ao trabalhar na arquitetura? Como mudar processos na organização para que as pessoas em uma reunião com a primeira complexidade não voltem à antiga?
Neil Ford apresenta três opções em seu site: ThoughtWorker (um funcionário da ThoughtWorks, que muitas pessoas conhecem por causa de Martin Fowler), arquiteto de software e Meme Wrangler. Em breve, em nossa conferência Heisenbug, ele falará sobre a criação de “arquiteturas evolucionárias”, que podem ser alteradas com a mudança de circunstâncias externas. Enquanto isso,
Mikhail xomyakus Druzhinin (membro do comitê do programa Heisenbug) perguntou a Neal: como seu discurso se cruza com os testes e muito mais.
- Você pode começar falando sobre você e sua carreira?Claro. Estou na ThoughtWorks há quase 14 anos. Antes disso, ele era CTO em uma pequena empresa de consultoria e treinamento de cerca de 25 pessoas e lá começou a tentar a mão em tecnologias como Java. Os três primeiros livros que escrevi antes de ingressar na ThoughtWorks. O primeiro foi sobre Delphi, na época bastante popular na Rússia e na Europa.
Quando eu era CTO, me cansei de ser um nerd alfa. Quando você sabe mais do que as pessoas ao seu redor, realmente não se desenvolve. Comecei a falar em uma variedade de conferências e realmente gostei de estar entre os outros oradores porque eram pessoas muito inteligentes e interessadas. E comecei a procurar inconscientemente uma empresa na qual pessoas realmente inteligentes e interessadas trabalhassem principalmente. E literalmente tropeçou no ThoughtWorks, como muitos, no site de Martin Fowler. Em coisas como CruiseControl e a biblioteca de testes do NUnit, notei que elas dão uma enorme contribuição ao código aberto e fazem muitas coisas muito interessantes. Por isso, inadvertidamente, iniciei o processo de entrevista com a ThoughtWorks, ao final do qual recebi uma oferta de emprego. Este foi um bom passo para mim, porque eles são desenvolvedores muito inteligentes e muito entusiasmados.
Eu poderia ser um consultor independente, mas nesta função não gosto de duas coisas. Primeiro, você deve fazer todos os negócios: faturar, perseguir as pessoas por dinheiro, regular os fluxos de caixa e tudo mais. Eu sou capaz de fazer isso, mas isso não me interessa. Minha paixão é software e desenvolvimento.
E a segunda: se você é um consultor independente, raramente consegue trabalhar em colaboração com alguém, como uma equipe. Você está quase sempre sozinho, e eu realmente gosto do desenvolvimento de equipes. Até escrevi vários livros em conjunto com outros autores, incluindo meu último livro, Evolutionary Architecture. Parece-me que, ao trabalharem juntos, o resultado é maior que a soma dos componentes individuais. Quando você colabora no trabalho criativo, seja um projeto de redação ou um programa, pode obter mais pontos de vista e uma idéia mais geral, portanto o resultado será melhor.
Assim, em abril já faz 14 anos que estive na ThoughtWorks. Sei muito bem disso, porque uma das vantagens interessantes de trabalhar na ThoughtWorks é que, se você trabalha na empresa há 10 anos, recebe 12 semanas de férias pagas, quando pode fazer o que quiser. E depois disso, a cada 5 anos você recebe uma licença criativa paga de 6 semanas, então eu tenho um ano restante até as primeiras 6 semanas. Gostei muito da de 12 semanas e estou ansiosa pela próxima. Você sempre se lembra da década em que esteve aqui: eles são medidos com férias tão agradáveis.
- Esta é uma duração muito tangível de férias, legal."Fui contratado pela ThoughtWorks como arquiteto e desempenhei esse papel por um tempo até chegar ao nível de diretor." Atualmente, a maior parte do meu trabalho está relacionada ao campo da arquitetura de software. Passei muito tempo na interseção de práticas de arquitetura e engenharia (por exemplo, entrega contínua) - suspeito que aqui meus interesses se cruzam com os da audiência da Heisenbug.
Em particular, o que eu falei muito ultimamente é o tópico do meu último livro, a construção da arquitetura evolucionária. Se você pode evitar bugs, as pessoas que estão testando o aplicativo serão mais fáceis. A arquitetura evolutiva inclui técnicas de segurança para recursos arquiteturais críticos - como capacidade de implantação, testabilidade, escalabilidade, desempenho e assim por diante.
"O que significa Meme Wrangler?"- De acordo com as regras do ThoughtWorks, você pode escolher qualquer cargo, exceto alguns reservados, como "CEO". Se você tiver uma posição interessante para si mesmo, por favor. E quando o conjunto de cartões de visita terminar, você poderá criar um novo.
Meu primeiro trabalho foi arquiteto de aplicativos. Essa posição refletia a essência do trabalho, mas muitas vezes em grandes empresas implica que você não trará mais muitos benefícios, que gaste mais tempo desenhando do que criando qualquer coisa.
E uma das vantagens do desenvolvimento personalizado é que você pode se familiarizar com um grande número de projetos diferentes. Penso que os arquitetos de software são "correspondentes de padrões" por natureza: tentamos aplicar padrões a tudo o que vemos, mesmo a coisas do mundo real. Portanto, se você é um arquiteto em desenvolvimento personalizado, precisa ver muitos projetos diferentes, ver padrões repetidos neles, ver quais deles funcionam. E percebi que, de fato, meu trabalho é um pouco de coletar idéias interessantes do ecossistema de software. A partir daqui veio o Meme Wrangler.
Meme é um termo cunhado pelo escritor Richard Dawkins; é uma unidade difundida para designar idéias. Todo mundo conhece memes da Internet - isso é algo espirituoso que pega e se espalha como um vírus. E a palavra "disputa" tem dois significados úteis, o primeiro é agir como juiz em uma disputa e o segundo é dirigir para um rebanho. E escolhi a posição de Meme Wrangler, porque ela reflete com mais precisão o que estou fazendo agora. Além disso, agora que estou lançando outro livro, estou escrevendo no Twitter que "laço outro meme" e o coloco neste livro.
- Você pode explicar o que um arquiteto de software deve fazer, o que você faz como arquiteto de software?"É claro que posso tentar, mas ninguém realmente consegue definir isso". Martin Fowler - um homem que é muito legal em dar definições a tudo no campo da programação - se recusou publicamente a definir o termo "arquiteto de software" em seu texto
"Quem precisa de um arquiteto?" .
Mas se você observar o papel de um arquiteto de software, uma das coisas é que eles são responsáveis por tudo o que é difícil de mudar. Tudo isso está relacionado à estrutura do seu sistema de software: quais padrões fundamentais você usará, qual idioma ou quais estruturas. Porque todas essas decisões têm consequências de longo alcance.
Uma das coisas com as quais os arquitetos realmente se importam é o que chamamos de "parâmetros arquiteturais", que também são chamados de "requisitos não funcionais", mas não gostamos desse nome. São coisas como desempenho, escalabilidade, elasticidade, capacidade de implantação - tudo isso é de responsabilidade do arquiteto. Um arquiteto pode criar uma estrutura que levará em consideração os requisitos do próprio programa e todos esses parâmetros arquiteturais que devem ser fornecidos nele.
Suponha que você seja um arquiteto e precise criar uma estrutura de sistema de software para registrar alunos em uma universidade. Suponha que tenhamos mil estudantes e 10 cursos nos quais eles devem se matricular. E agora, com base no nosso conhecimento de como as universidades são organizadas, o que você acha que acontecerá: os alunos serão distribuídos uniformemente ao longo do semestre, para obtermos o mesmo número de alunos em cada curso ou durarão até a última hora, e então corre para gravar tudo de uma vez?
E isso é elasticidade, é um parâmetro arquitetural que você deve garantir ao criar esse sistema. Provavelmente, isso não é indicado em nenhum lugar, mas você sabe disso, simplesmente com base na área de assunto. É isso que torna a arquitetura dos sistemas de software tão complexa: você precisa entender a área de assunto, bem como os recursos e limitações técnicas da sua empresa. Você pode ser limitado, por exemplo, pelo fato de esse banco de dados relacional já estar selecionado para o padrão de nossa empresa, e precisamos aumentar a produtividade. Como podemos alcançar esses resultados?
Esse é o trabalho do arquiteto de software - lidar com todas essas decisões importantes relacionadas ao fato de ter consequências em longo prazo e é muito difícil alterá-las posteriormente. Muitos elementos da estrutura, como a interface do usuário, são muito fáceis de desenvolver, porque você apenas altera uma camada do aplicativo. E a arquitetura é mais sobre como todas essas camadas são justapostas, e geralmente é muito mais difícil mudar.
Eles dizem que os microsserviços agora são bastante populares e essa arquitetura foi criada especificamente com a expectativa de mudanças constantes. Portanto, é muito mais fácil fazer grandes alterações na estrutura do microsserviço, mas elas foram criadas desde o início. E esse é um tópico muito interessante para a pesquisa - como projetar uma arquitetura fácil de mudar, porque para a indústria é exatamente isso que tem sido o mais difícil há muito tempo.
- Sobre a questão da arquitetura e das postagens: vejo cada vez mais o “arquiteto de controle de qualidade” nos cartões de visita e no LinkedIn.- Esse é um dos problemas do termo "arquiteto": cada empresa deve inventar seus próprios nomes para isso. Eu conheci os “arquitetos de controle de qualidade” e “arquitetos de dados”, “arquitetos de sistemas”, “arquitetos de soluções”, “arquitetos técnicos” - conheci arquitetos de todas as faixas possíveis. E isso é um problema, porque ninguém pode dar uma definição clara e dar o que você deseja.
O que "controle de qualidade do arquiteto" pode significar para uma empresa em particular, nem sei ao certo. Essa pessoa desenvolve uma estrutura de controle de qualidade? Quanto a mim, isso está mais próximo da função de um arquiteto como especialista técnico, porque muitas vezes um arquiteto também é gerente de projetos técnicos. Mas o arquiteto também lida com apresentação e documentação. Então, se eu sou arquiteto e tive uma ideia brilhante para uma nova arquitetura, mas não posso fazer uma apresentação e convencer as pessoas com dinheiro de que devemos fazer isso, não teremos a chance de realizar minha ideia legal. Isso significa habilidades de comunicação.
Essas habilidades se aplicam ao controle de qualidade e quem faz isso também pode ser chamado de "arquiteto". Você vê, este é um post tão vago. Muitas organizações simplesmente chegam ao ponto de chamar o engenheiro sênior de arquiteto, porque parece legal e elas não conseguem descobrir como chamar isso. Você sabe, desenvolvedor sênior-sênior-sênior - tudo bem, arquiteto. E conheci empresas onde existe um tipo de arquiteto, e conheci empresas onde existem dezenas de variedades de arquitetos. De fato, esses são postos fictícios. Meu “meme wrangler” é melhor nesse sentido, porque é obviamente inventado.
- Vamos conversar na direção do seu discurso na Heisenbug. Você falará em uma conferência de testes - e a qualidade do software para você?Pessoalmente, considero a qualidade dos componentes arquiteturais do sistema. Sei que o mundo do controle de qualidade vê o software mais como uma caixa preta, ou seja, olha da perspectiva do usuário se há erros e falhas, se funciona corretamente. Claro, também estou interessado nisso, mas estou mais preocupado com as causas principais dos erros: por que o aplicativo não é confiável, por que ele falha periodicamente? Aqui eu tenho que ser a última linha de defesa, descobrindo por que isso está acontecendo. E há coisas como desempenho e capacidade de resposta. Há muita conversa sobre eles no mundo da interface do usuário agora, eles têm indicadores claros: se o site para celular carregar conteúdo visível por mais de 3 segundos, os usuários sairão e irão para outro lugar.
É dada muita atenção ao desempenho da web: qual é o tempo antes de carregar o primeiro conteúdo visível, qual é o tempo total de carregamento da página. E todos esses são parâmetros de qualidade, certamente visíveis do ponto de vista de um observador externo, e sou eu quem deve descobrir como construiremos um sistema no qual esses indicadores sejam alcançados. E isso pode levar a alterações no front-end em relação a quais tecnologias da Web serão usadas, mas também pode levar a alterações no back-end. Talvez transmitir informações não em tempo real, mas em um pacote e no meio criar um mecanismo de cache? Para mim, a qualidade é assim: determine quais são os requisitos e, em seguida, crie uma implementação técnica que os incorporará.
- Você pode dar o estudo de caso mais interessante da prática relacionada à qualidade?- É difícil dizer, todos os projetos são diferentes, então o melhor é sempre o último em que trabalhei!
Bem, de alguma forma, trabalhei em um sistema em que os requisitos se pareciam parcialmente com o Lotus Notes. Lembra de um programa tão antigo? Ela era um programa terrível, mas fez uma coisa muito, muito boa. Este programa sincronizou muito bem: você pode baixar seus e-mails e notas, pegar um táxi, ir a algum lugar, responder a todas as cartas naquele momento e, na próxima vez em que você se conectar à rede, tudo será automaticamente descarregado, sincronizado e funcionará magicamente caminho.
E tínhamos um cliente com um sistema de vendas que desejava o mesmo princípio de funcionamento. Como os vendedores estão sempre em movimento, e era necessário que eles fizessem pedidos sem uma conexão à Internet, e então tudo sincronizaria e se tornaria como deveria.
E percebemos o quão difícil isso é, devido a vários casos e cenários limítrofes que precisam ser fornecidos. Primeiro, desenvolvemos um sistema que funcionava sem nenhuma conexão com a Internet e, então, iniciamos a sincronização. E houve muitas dores de cabeça - por exemplo, o desempenho de um aplicativo online comparado ao offline, um atraso notável apareceu ao conectar, porque a sincronização estava ocorrendo naquele momento. Portanto, nesse caso, o controle de qualidade foi uma grande lasca para nós, porque encontraram casos limítrofes que destruíram todo o sistema.
E do lado de fora, isso parece uma tarefa simples. Aplicativos como o Dropbox e o Google Drive resolveram esse problema, tornando-o invisível. E parece fácil. Mas quando tentamos resolvê-lo, houve um milhão de casos limítrofes. Portanto, sem um controle de qualidade confiável, é difícil encontrar todos eles, cada um dos quais deve ser retornado para se alinhar à estrutura do aplicativo, a fim de garantir que a estrutura geral ainda funcione.
Na verdade, enquanto desenvolvíamos esse sistema, fazendo mudanças fundamentais na estrutura, percebemos que casos limítrofes seriam frequentes e inaceitáveis. E esta é uma excelente ilustração de como é importante ter um ciclo de feedback muito bem estabelecido entre o design da arquitetura e partes como o controle de qualidade. Muitas empresas adiam isso no último momento, mas se você fizer isso, no final, muitas coisas serão feitas de forma errada, e você terá que voltar e gastar muito tempo para refazê-lo. Se você estabelecer um contato próximo entre o desenvolvimento da arquitetura e os testes, poderá encontrar esses casos limítrofes e alterar a estrutura muito mais rapidamente. Felizmente, éramos extremamente flexíveis nesse projeto - já que era um projeto da ThoughtWorks, tivemos um ciclo muito rápido. E tivemos uma equipe muito forte de testadores.
- Muitas pessoas nos testes perguntam como elas podem afetar a arquitetura. Para eles, a arquitetura é algo em uma torre de marfim. O que pode ser feito com isso?- Parece-me que seria útil para os testadores procurar os arquitetos e explicar-lhes que eles estão fazendo seu trabalho mal, e é melhor para os testadores saber como realizá-lo. As pessoas adoram quando lhes dizem isso! Na verdade, não, eles não gostam, nada de bom resultará disso.
Eu tenho um mantra favorito para esses casos: "é melhor mostrar do que discutir". Você precisa mostrar o quão diferente é o seu mundo do mundo deles. Se você é um engenheiro de testes, precisa trazer um caso de usuário que demonstre claramente a falha do projeto. Se você mostrar esse cenário a um arquiteto, isso não é apenas uma reclamação sobre algo, mas uma demonstração concreta: "Agora, seu projeto não funcionará nesse cenário, portanto, ele precisa ser alterado." Se eles não concordam com isso, significa que simplesmente perderam o contato com a realidade. E os arquitetos devem ser sensíveis às coisas que acontecem no mundo real.
Há muito pouco, como eu chamo,
poesia do ex-secretário de Defesa Donald Rumsfeld, que fala do "famoso famoso" e do "desconhecido desconhecido". Portanto, em todo projeto de software existem "incógnitas desconhecidas", portanto o desenvolvimento de qualquer arquitetura deve ser iterativo. Como não importa o quanto você pensa, coisas que você não poderia prever de alguma forma aparecerão de repente enquanto você estiver tentando construir essa estrutura.
, , 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», . , , ?Claro. , , meme wrangler.
, DevOps-. , , . DevOps , , — , , .
, — , « » . . , . , : , , . , , ?
— .— , , ! , , . — , , , , , . , , , , : Docker -, - . , , .
, , — , , .
— . !Heisenbug , 17-18 , «Building evolutionary architectures: Fitness functions». , : , — .