Ambiente irrepreensível: ninguém deve escrever um código de qualidade

No RIT ++, Nikita Sobolevn ( sobolevn ) fez, como ele mesmo chamou, um sermão sobre a qualidade do código e processos na empresa. Particularmente sensível, sirva-se de chá de camomila, mas não oferecemos afastamento das telas. Você pode discordar de qualquer uma dessas teses, insistir em que falar sobre programas de TV é a chave para um ambiente saudável na equipe e afirmar que não é necessário um quadro estrito de linter e CI para escrever um bom código. Mas se você já culpou os outros por falhas no trabalho, leia ou assista à história de Nikita.

Você já trabalhou em um emprego ruim?

Eu trabalhei por um longo tempo. Minha companhia era terrível. Tudo estava muito ruim, por nada, tudo está fora do comum. Tivemos processos repugnantes, odiamos clientes e desenvolvedores ineptos. Nada poderia ser feito sobre isso. Quando tudo está tão ruim, você simplesmente não sabe o que levar, por onde começar. Você se sente como uma roda dentada miserável que não pode influenciar nada.



Quando digo que tudo está ruim, quero dizer que tivemos:

• código incorreto - ninguém pensou na qualidade do código, ninguém conseguiu formular qual é a qualidade do código.
• maus processos.
• não conseguimos nos comunicar normalmente,
• nós não fizemos o que o cliente queria.

Sim, era desenvolvimento terceirizado, mas isso não tornava as coisas ruins. As pessoas a fizeram assim.

“As pessoas estão fazendo um trabalho ruim, são as pessoas responsáveis ​​pelo fato de que os processos são ruins, o código é ruim e os clientes são ruins” - esse pensamento me atormentou por muitos anos. As pessoas são culpadas pelo fato de eu não gostar do meu trabalho.



Atribuí todos os pecados possíveis às pessoas e pensei que elas eram a principal fonte de problemas. Eu esperava que um dia eles mudassem, ou outros aparecessem, e tudo ficaria bem.

Com toda a seriedade, pensei no fato de que outras empresas empregam pessoas fundamentalmente diferentes, que diferem em suas qualidades internas e profissionalismo, e que essas outras pessoas são de um teste diferente.

Mas, em algum momento, comecei a adivinhar que talvez as pessoas não sejam culpadas - talvez um erro em um nível diferente, em algum lugar em que algo deu errado muito antes. E então o caminho para a correção aparece. Somente então você poderá se salvar como desenvolvedor.

Percebi que precisamos de uma revolução, que tudo precisa mudar: a maneira como trabalho, como me sinto, que ir trabalhar não se torna um teste para mim. Eu queria trabalhar em um bom lugar.

Havia apenas um problema - era a minha empresa .



Eu sou a pessoa que iniciou esta revolução.

Percebi que você precisa mudar tudo para aproveitar seu negócio favorito novamente. Adoro programar, estou pronto para fazê-lo 12 horas por dia e chamo de descanso e trabalho.

Portanto, eu percebi todas as falhas muito dolorosamente. Eles não apenas estavam ligados ao meu negócio favorito, mas também às minhas finanças, ao meu senso de si e às relações com outras pessoas, e foram fortemente refletidos em toda a minha vida. Quando algo não funcionou para mim, eu não conseguia descansar, não conseguia pensar em mais nada.

Decidi que a coisa mais importante que posso fazer agora para melhorar minha vida é fazer bem meu trabalho. Para isso, eu precisava repensar todo o caos que tínhamos e trazer ordem a ele.



Mas quando você olha para o caos, não vê padrões - nada que indique como deveria ser.

Criar ordem a partir do caos é um ato de criação difícil.

Você precisa começar desde o início para entender quando tudo entrou em caos. Você precisa determinar um novo pedido e explicar a si mesmo o que fazer. Estas são palavras bonitas: "Vamos fazer tudo bem!". Mas você vem para o trabalho e não entende o que fazer para mudar tudo, não há idéias.

A educação que você recebeu e os livros que lê não ajudam, porque tudo o que você fez antes aprendeu com esses livros e com essa educação.

Declaração do problema

Então eu pensei - qual é o maior problema? Onde está o ponto mais doloroso que não permite viver e trabalhar? Percebi que esta é uma declaração do problema . Para mim, definir uma tarefa sempre foi bastante opcional.

Eu acho que muitos de vocês viram a tarefa em um cabeçalho "Corrija o bug no prod". Nós tínhamos muitas delas, eu as escrevi em uma linha, e então as pessoas fizeram algo errado e tentaram consertar isso errado. Eu pensei: “Por que eles não pensam com suas próprias cabeças? O que você está fazendo? Você precisa corrigir um bug simples e não fazer todo esse absurdo. "

Então eu não percebi que realmente defini mal as tarefas. Mas, em algum momento, ainda percebi que precisava fazer isso de uma maneira completamente diferente e desenvolvi vários princípios.



As tarefas devem ser curtas . Não em termos de descrição de como "corrigir um bug no prod", mas de natureza curta. Tarefas curtas e pequenas são práticas. Eles são compreensíveis para qualquer pessoa: um iniciante, um desenvolvedor médio e experiente. Todos podem entender essa tarefa e executá-la, por exemplo, em meio dia útil. Você pode começar com isso.

As tarefas devem ser ordenadas . Quando eles definem tarefas, geralmente não pensam em que ordem devem ser feitas. Mas as tarefas podem bloquear-se, paralelizar ou adicionar complexidade adicional a outras tarefas, se concluídas com antecedência, etc.

Muito pouco é dito sobre a ordem das tarefas: elas são trazidas para Jira ou Trello e depois são retiradas de lá. Mas poucos pensam, e em que ordem, por que e por que a ordem é exatamente isso.

Todas as tarefas devem ser individuais . O que isso significa? Tarefas são entidades que existem em um projeto e sempre pertencem a alguém. Às vezes, na descrição do problema, você pode encontrar: “Sergey, Masha, corrija isso. Você sabe como fazer isso. Você não pode fazer isso, é necessário fornecer todo o contexto para que essa tarefa se torne individual em si mesma, para que qualquer pessoa que a leia possa cumpri-la. Portanto, não há conhecimento disperso sobre o projeto e não há significados ocultos na estrutura desta tarefa.

Quando as tarefas se tornaram individuais, curtas e ordenadas, as pessoas começaram a executá-las da maneira que eu quero.

Apenas mudando o modo de comunicação, eu tive certeza de que as pessoas que haviam feito esse absurdo começaram a fazer o que eu queria - não é mágico? Isso não prova que muito é fácil mudar? E comecei a aprofundar-me nessa questão.

Muitas vezes falhamos com o cliente, não fizemos o que o beneficiaria. Eu pensei que, se os desenvolvedores começassem a entender nossas tarefas e executá-las como deveriam, elas poderão entender o que o cliente realmente quer e fazer como ele deseja?

Tentei combinar isso em uma espécie de figura de duas caras, que por um lado pensa como um desenvolvedor, por outro lado - como um cliente.



Esta não é uma tarefa nova. Em geral, essa abordagem é chamada de Design Orientado a Domínio e foi aplicada com sucesso por muitos anos. Decidi aproveitar o melhor - um meio de comunicação, ferramentas, tecnologias e tentar fazer os desenvolvedores entenderem o que precisa ser feito para satisfazer os desejos do cliente.

A tarefa foi muito difícil e ainda estou trabalhando na solução. Mas eu desenvolvi uma fórmula simples para mim.

Requisitos . Tudo começa com eles, o cliente expressa sua vontade para nós, os desenvolvedores, na forma de requisitos. O cliente diz condicionalmente: "Exijo que a página de login funcione". Sua consciência começa, rabiscando na forma de tabelas, listas, gráficos, etc. Os requisitos permanecem com você como a parte mais importante do seu projeto. É isso que você faz no nível mais alto.

Mas esses requisitos não são operáveis ​​para o desenvolvedor, eles são de alto nível e brutos. Para começar, o programador precisa de documentação.

Documentação e requisitos são irmãos gêmeos, isso é dupla unidade. Requisitos - é isso que você precisa fazer e a documentação - como fazê-lo.

Quando percebi que, em princípio, a documentação pode ser gerada a partir de requisitos, isso se tornou uma parte importante do nosso processo de negócios. Aprendemos como registrar requisitos em um formato especial e gerar documentação.

Testes . O próximo passo lógico é verificar se funciona. Começamos a testar nossos requisitos para garantir que estamos realmente fazendo o que é necessário.

O mais interessante é que não inventei nada - não escrevi uma única linha de código para que isso funcionasse. Eu apenas peguei as tecnologias existentes e recebi: requisitos, são documentação, são testes.

O próximo passo lógico foi extrair o código da coisa toda, porque é nele que estamos diretamente envolvidos.

Código - pelo qual tudo é realmente iniciado. Para que o cliente e o desenvolvedor se conectem, ao que parece, é necessário entrar na cabeça de um deles e garantir que eles se entendam. Mas, para entrar na cabeça, você pode pegar as mesmas ferramentas e conectá-las para que o desenvolvedor comece a entender o que está acontecendo. Aqui você pode ler como eu faço isso na prática.

Assim que combinamos (o Código é um!) Desenvolvedores e o cliente com a ajuda de uma engenhosa mistura de entidades diferentes, alcançamos uma importância muito grande: nossos desenvolvedores finalmente começaram a fazer o que a empresa precisava . Eles pararam de apresentar algo assim, porque viram os requisitos e os entenderam, entenderam o que precisava ser feito.

Para garantir a execução, temos testes escritos na forma de requisitos, e esses requisitos são claros o suficiente para serem implementados em uma linguagem compreensível no código e escrevemos um bom código de acordo com esses requisitos.

Comunicação

Eu já mencionei "comunicação" muitas vezes. Adoro conversar com meus amigos e familiares, mas não no trabalho. No trabalho, tenho que me comunicar com as pessoas - não as escolhi com base nisso. Muitas vezes, a comunicação no trabalho não ajuda .

Todos nos comunicamos com colegas sobre tópicos que não são do trabalho (discutindo programas de TV etc.), porque somos pessoas. Felizmente, essa falha é corrigível. Para entender como a comunicação é realmente desastrosa para nós, você pode ver vários exemplos.

Antes de tudo, as pessoas se distraem e partem de um estado de fluxo. O homem apareceu e disse algo - o que devo fazer com isso agora? Por que ele me disse que queria transmitir isso?

Ou comícios. Eu os odeio, sempre me sinto um idiota quando sento nas reuniões. Todo mundo parece entender alguma coisa, eles têm rostos inteligentes, e eu sinto falta de uma e penso quando isso vai acabar. Eu quero sair porque tudo o que discutimos pode ser discutido muito mais rapidamente.

Comícios roubam uma quantidade enorme de tempo e não adiantam.

Existem várias outras questões importantes, por exemplo, as pessoas começam a jurar nesses comícios. Imagine que você foi colocado em uma pequena sala cheia de pessoas que você realmente não quer ver. Você quer sair e essas pessoas fazem você tomar algumas decisões sérias. Naturalmente, o abuso começa - primeiro agressão passiva, depois insultos óbvios. Infelizmente, nada pode ser feito com isso, porque as pessoas são seres conflitantes. Não importa como você tente moderar a situação, não importa como você encontre pessoas boas que não juram - as pessoas juram, e isso é normal .

Há outro problema em nossos negócios - as pessoas desaparecem . Seu front-end ou devops podem facilmente parar de responder um dia. Especialmente as pessoas que trabalham remotamente podem simplesmente desligar o telefone e encerrar a conversa unilateralmente.

Estes e alguns outros problemas parecem insolúveis. Você não pode ensinar todas as pessoas a serem boas, sem conflitos, responsáveis ​​- é simplesmente impossível.

Mas você pode viver com isso. Sendo realista, você pode entender que a vida é assim: as pessoas desaparecem, xingam, não querem se comunicar com você - isso é normal. Resolvi esse problema da seguinte maneira - comunicação estruturada.



Para estruturar a comunicação, basta dar dois passos:

• Vá para o Telegram agora e exclua-o. Depois de excluir todas as suas páginas nas redes sociais, as pessoas não poderão escrever para você.
• Depois disso, inicie um canal e diga que você pode se comunicar apenas dessa maneira.

Quando você está em uma posição em que pode ditar sua vontade a outras pessoas, ensina-as a se comunicar. Você mostra que a comunicação deve ser estruturada e útil para todos os participantes .

Escolhemos a comunicação através do GitLab. Se você tiver uma pergunta, faça-a no GitLab. Se você quiser fazer uma pergunta estranha, faça-a lá. Se você entende que não há um lugar onde possa fazer essa pergunta, talvez ela não precise ser feita.

Só nos comunicamos sobre tópicos de trabalho . Se alguém quiser discutir o Game of Thrones - desculpe, estamos trabalhando e discuta o Game of Thrones com seus amigos. Se você quiser discutir uma nova tecnologia, criar um ticket, vamos discutir: talvez isso beneficie o projeto. Mas "Game of Thrones" certamente não trará benefícios para o projeto.

A comunicação estruturada torna pessoas diferentes iguais. O GitLab ainda tem avatares iguais - um tem a letra K, o outro C, e eu não sei quem são essas pessoas. Não ligo para o que são, o principal é que eles se comuniquem dentro da estrutura.

Depois de estruturarmos a comunicação, estabelecermos um trabalho com o cliente, aprendermos a escrever tickets compreensíveis, é hora de seguir o código.

Código

E aqui um novo problema está à espera - as pessoas não sabem escrever código, e isso é normal . Eu costumava pensar que outras pessoas escreviam códigos ruins e eu sou bom. Mas então percebi que eu mesmo estava escrevendo um código incorreto. E depois de um tempo, percebi que todas as pessoas escreviam códigos ruins , e tudo bem.

As pessoas não são feitas para escrever código. A programação é um ambiente agressivo ao qual uma pessoa não está predisposta. O código tem muitas complexidades: arquitetura e uma enorme quantidade de informações. Em sistemas distribuídos, é terrível em geral. É difícil para uma pessoa lidar com o fluxo de informações. E isso é normal.

Mas, nesse caso, você pode fazer algo com isso e aprender a trabalhar nessas condições.



Para trabalhar com isso, você precisa de rigor - IC e testes que sejam tão rigorosos quanto possível sobre o que você faz. Deve ser o Último Julgamento - uma ferramenta que responde à pergunta, código bom ou ruim. Somente olhando para ele, o olho que tudo vê da CI dirá se seu trabalho vai dominar ou permanecerá em algum lugar no palco.

Esse IC, é claro, deve ser inevitável. Assim que alguém obtém o direito exclusivo de se comprometer com o domínio, todas as tentativas de criar processos desmoronam, porque esse alguém começa a fazer todo tipo de besteira.

O IC inevitável e rigoroso fornece alguns recursos mais interessantes. Esta é uma oportunidade de desenvolvimento, porque agora existe uma barra base na qual você pode criar: cada pedaço de código subsequente é melhor que o anterior. Cada trecho de código subsequente agrega valor ao projeto e melhora o IC. Cada parte subsequente do código é um passo em direção ao desenvolvimento.

Quando a fundação estiver pronta, você poderá seguir em frente.

Mas as pessoas ainda cometem erros, porque nenhum IC, mesmo configurado da maneira mais rigorosa, pode pegar todos os erros . E eles aparecerão em lugares sobre os quais ninguém mais vai pensar.

O que pode ser feito sobre isso? Você pode voltar às táticas habituais e dizer: “Você cometeu um erro, corrija-o. Você escreveu um código incorreto - aprenda a escrever código ". Este é um caminho ruim que não leva ao desenvolvimento.

Para realmente escrever corretamente e desenvolver seu produto, você precisa de uma nova abordagem e uma nova mentalidade.

Ambiente irrepreensível

Chamei essa abordagem de ambiente sem culpa - isso significa que nunca culpo as pessoas por nada . Se um bug entrar no seu projeto, isso é um problema do projeto. Este bug deve ser corrigido para que nunca mais aconteça. Se este for um erro no código, você precisará escrever um teste de regressão. Se esse é um erro na infraestrutura do projeto, você precisa escrever uma ferramenta que evite esse erro.



Quando você começa não apenas corrigindo bugs e esperando que tudo não desmorone na produção, mas corrigindo-os no nível do sistema, você começa a criar e criar - criando novas ferramentas, desenvolvendo novas abordagens e padrões de arquitetura. Você começa a pensar com a cabeça e garante que os erros não se repitam.

O trabalho constante sobre erros leva o desenvolvedor a um nível fundamentalmente diferente. Você começa a inventar ferramentas para desenvolvedores, implementá-las, promover etc.

A criação da qual estou falando agora é enorme. Ao tentar usar essa abordagem, você encontrará o fato de que tudo o que existe agora, especialmente para algumas linguagens de programação, não é estrito o suficiente.

Uma vez me perguntei se poderia escrever um linter que faria todos escreverem o mesmo código. Eu era muito rigoroso e incluía todas as regras possíveis que eu poderia criar. Mas as pessoas ainda escrevem códigos diferentes . É muito parecido, mas sempre consigo entender que esse código foi escrito por pessoas diferentes. Portanto, meu linter ainda não é rigoroso o suficiente - aguarde novos lançamentos.

A abordagem permanece: estamos aguardando a resposta da máquina, o programa está bem feito ou não. , .

, — . , , , , CI.

, . , , . - . -, , , .

, .

, , , - CI . , , . - — .



— .

— . . : « , ?!» , , .

: , . , , , — : . , .

- — . , , , : « ? . , - ». — , - , - . .

— , — .

— , . , .

, , . . . , .

, , , , . , , , .

, , , , , , , .

— . , — , , , .

, . , , . open source , .

. , , , — .

. , , , , . , — , — . , .

. , . : — , — . .

. , , — ? , , , . .

. , , — , . - , , . , . open source.

. , , , , , . , , , .. !

. : . - , . , , . . , , . .

. , , - , . -, .

. , . - — , . , .

, . , . , .

Agile , . QualityConf , ++, — . , , .