Tradicionalmente, o processo de desenvolvimento de software é comparado à construção. O termo "arquiteto" apenas fortalece a conexão associativa entre esses processos. Mas as realidades modernas tornaram esse modelo irrelevante, porque existem mecanismos que ele não pode explicar:
- Se criamos algum tipo de objeto ou produto físico, por que o software nunca é considerado completo?
- Se estamos falando de soluções de engenharia, por que nunca podemos planejar com confiança com antecedência?
- Se somos arquitetos ou construtores, por que tantos projetos terminam em fracasso?
- E, finalmente, com tantas dicas, práticas recomendadas, princípios, livros e relatórios de desenvolvimento de software, por que tantos projetos se tornam um lugar insuportável para se trabalhar?
Proponho uma tradução do brilhante relatório de Sarah May, “Código habitável”, próximo ao texto, onde ela considera todas essas questões.
Por que é importante ter um modelo?
O modelo nos permite traçar uma analogia entre um processo desconhecido ou difícil de entender e algo familiar, compreensível para nós. Além disso, não deve ser adequado apenas para descrever uma situação em que tudo esteja bem, mas, como qualquer boa analogia, o modelo deve nos guiar em situações limítrofes.
O processo de desenvolvimento de software é uma combinação de duas entidades relacionadas, interagindo, mas ainda assim separadas: código e equipe.
A confirmação disso é a lei de Conway. O relacionamento dessas entidades nos diz que os problemas no código estão relacionados aos problemas da equipe e vice-versa. Portanto, temos duas opções para resolvê-los: no lado do código e no lado da equipe.
Alguns problemas parecem ser apenas problemas com o código, outros apenas com a equipe. De fato, todos eles são problemas com os dois componentes. Portanto, o novo modelo deve ser adequado às realidades modernas e refletir a relação entre os dois componentes do processo de desenvolvimento.
Descrição do novo modelo
O espaço em que o aplicativo reside
A construção do edifício possui três etapas distintas: projeto, construção e manutenção. Anteriormente, o desenvolvimento de software era semelhante: o resultado do desenvolvimento era um produto acabado. Foi instalado pelo usuário e transferido para dar suporte a um grupo separado, e os desenvolvedores começaram a fazer outra coisa.
Mas no mundo dos aplicativos da web, implantações e lançamentos várias vezes ao dia, na verdade, nada está completo. Uma situação semelhante é observada em aplicativos e jogos para dispositivos móveis, quando eles são atualizados automaticamente no console via Steam (geralmente no momento mais inoportuno). Além disso, em um ambiente de negócios em mudança, os aplicativos devem ser flexíveis e capazes de mudar. O esforço de desenvolvimento deve ser enorme para garantir essa flexibilidade. O mesmo não pode ser esperado dos edifícios.
A infraestrutura que usamos no desenvolvimento de aplicativos é mais como um edifício. O que criamos não são os próprios edifícios, porque a maioria dos aplicativos ocupa espaço em estruturas pré-montadas. Parece um passo de arquitetos a designers de interiores, mas há muito poder nesse modelo. Os prédios nele são a base de nossas aplicações: a base é o sistema operacional, o nível de estacionamento é a linguagem de programação, o próprio prédio é a estrutura usada e estamos desenvolvendo aplicativos que já estão dentro deles.
O espaço interno (estrutura) fornecido pelos prédios é mutável, porém é mais difícil alterá-lo do que seu próprio código. Por mais que a demolição do muro seja mais difícil do que mover os móveis. Assim, o próprio edifício (estrutura) impõe certas restrições sobre as capacidades e a aparência do seu interior (aplicação).
Cada edifício é otimizado para seus próprios propósitos. Um aplicativo pode ser colocado em qualquer um deles, mas alguns espaços serão mais adequados para ele e outros serão piores. Portanto, o código que você colocará em um espaço pré-formado será gerado de uma certa maneira por esse espaço.
Ainda há uma quantidade enorme de trabalhos de construção em nossa indústria, mas a maioria de nós ainda trabalha em interiores (aplicações).
Novo objetivo no desenvolvimento
Se você acrescenta a tudo isso que os projetos nunca são considerados concluídos, você conclui que o código não é o que estamos construindo, mas sim onde vivemos . Isso faz você olhar para o próprio objetivo do desenvolvimento de um ângulo diferente. O local em que vivemos precisa ser habitável : adequado, confortável e confortável para a vida. E não apenas para nós mesmos, mas também para aqueles que vivem conosco. No caso do código, não basta apenas finalizar o produto e seguir em frente. Também precisa ser tornado habitável : compreensível, suportado, extensível - para a equipe que "vive" nele.
O que é código habitável?
Habitável em relação à casa significa que você mora em um espaço onde pode realizar as atividades diárias com conforto e facilidade. Há uma lâmpada de leitura no quarto, guardanapos estão sobre a mesa de café, há uma caixa de joysticks na sala de estar e um suporte de bicicleta no corredor.
Mas o que significa viver para um grupo de pessoas depende de si. Uma casa confortável para pais jovens com um filho não é como uma casa para estudantes ou idosos, ou para uma mãe solteira com um adolescente.
O código habitável significa a mesma coisa: você pode alterar ou adicionar o que deseja, mas sem complexidade e aborrecimento excessivos. Você entende o que é o local, pule com facilidade para o lugar certo no código e trabalhe com ele. Aqui o princípio é o mesmo: o fato de que habitável para uma equipe não é adequado para outra. O que é habitável para um idoso e quatro juniores difere do habitável para cinco idosos e é muito diferente do habitável para uma equipe terceirizada.
As pessoas vêm e vão, portanto, a criação e manutenção de código em um estado habitável é um processo contínuo. A aparência de um novo membro da equipe é semelhante a um novo vizinho de apartamento: ele tem um sofá estranho, que por algum motivo ele realmente ama, então você relutantemente concorda em colocá-lo na sala de estar. E depois de alguns dias, um vizinho sugere a substituição de cortinas e persianas, porque existem outras mais ergonômicas. E o pior é que ele lava a louça com abas em vez de espaços! 
Mas agora vocês moram juntos, então precisam negociar.
Acontece que seu humor e condição dependem mais daqueles com quem você mora do que de coisas específicas no apartamento e menos ainda do layout. Também com o código: seu bem-estar depende principalmente daqueles com quem você trabalha e muito menos do código em si ou da estrutura.
Como um projeto se torna confuso
Mas e se o seu código se parecer com esta sala? Como torná-lo adequado para a equipe? Por onde começar?
Concordo, é difícil se deslocar por aqui, sem mencionar a compreensão de como colocar as coisas em ordem. Por que os lares atingem esse estado? Costuma-se dizer que isso é preguiça. Os psicólogos pensam de maneira diferente: a casa entra em tal estado devido a uma série de decisões erradas aparentemente insignificantes.
Imagine como tudo poderia começar. Há uma pequena sala em que você tentou otimizar o espaço: adicionou várias prateleiras e gavetas, usou um peitoril da janela. Por um tempo, tudo correu bem: você manteve a ordem diariamente. Mas a noite chegou depois de um dia difícil em que você não saiu. De manhã, você dormiu demais e, quando voltou para casa, jantou na sua mesa e esqueceu de remover o prato. Os pais trouxeram suas coisas antigas no fim de semana. Não houve tempo para desmontá-los e você colocou as caixas como estão. E você sente que a sala não está mais em ordem, mas sua condição é tão deprimente que você não consegue entender por onde começar a corrigir a situação e ela logo se transforma em TI. Uma série de pequenas decisões erradas: a sala já está uma bagunça terrível, por que não jogar livros no chão?
O mesmo acontece com o código. Você abre um arquivo que já é ruim, meia dúzia de padrões que não funcionam mais. E o gerente está parado atrás de você, esperando a correção do bug. A primeira coisa que vem à mente é consertar o bug com fita o máximo possível e sair daqui o mais rápido possível.
Essas soluções locais aparentemente pequenas são exatamente o que torna o código impossível . No entanto, existem maneiras de sair desse buraco, que cavamos por nós mesmos.
Salvação através da mudança de hábitos
Você já reparou que na maioria das casas desorganizadas e arrumadas, muitas vezes existem muitas revistas, recortes de jornais com interiores bonitos e aconchegantes? Há também fotos, projetos, dicas para arranjo competente de espaço vital.
As pessoas que vivem em casas desordenadas querem viver de maneira diferente, olham para todas essas revistas e fodidamente querem o mesmo interior, mas não sabem como alcançá-lo. E eles acham que apenas uma decisão importante, um evento permitirá que eles façam da casa o mesmo que na foto.
Há um programa Hoarders na TV americana. As pessoas que vivem em uma eterna bagunça concordam em participar, para que uma equipe de profissionais faça a limpeza e faça um interior de designer em sua casa. Bem, e como sempre, no final do programa, lindas fotos antes e depois. Curiosamente, a maioria dos participantes admite que, no final, sua casa retornou ao seu estado original. É simples: a mesma sequência de pequenas decisões incorretas os levou ao resultado anterior.
Acontece que uma maneira mais eficaz é trabalhar gradualmente mais, não com o conteúdo da casa, mas com as próprias pessoas. O objetivo é mudar seus hábitos para que eles façam da manutenção da ordem parte de suas vidas diárias. Infelizmente, os produtores acham essa opção muito chata para um reality show.
O código desordenado se comporta da mesma maneira: combatemos todos os dias, apenas para resolver o problema atual e sonhamos em reescrever tudo. Agora, se pudéssemos refazer tudo, definitivamente não cometeríamos os mesmos erros! Temos que reescrever o jQuery no Ember! Temos que cortar o monólito em microsserviços!
Às vezes funciona, pelo menos o tempo suficiente para escrever uma postagem de blog triunfante. Mas então a luz se apaga, as câmeras param de funcionar, a equipe de filmagem sai do local e, se você não mudou seus hábitos, está uma bagunça novamente e ainda mais rápido do que pensa.
As pessoas pensam que grandes erros estão nos matando: a casa é pequena demais, o layout é malsucedido, a estrutura errada, o monólito, os recursos insuficientes. Isto não é verdade. Somos mortos por decisões muito pequenas que são causadas por hábitos e maneira de pensar.
Você pode reescrever o que quiser. Porém, se sua equipe não mudar seus hábitos, você se encontrará em uma intrincada rede de microsserviços, assim como uma intrincada rede de classes e módulos em um monólito.
Hábitos da equipe
Note-se que não estamos falando de indivíduos, mas de hábitos e normas de equipe. Isso explica por que a imagem do desenvolvedor como profissional individual, artesão, não reflete a realidade. Este não é um desenvolvedor separado, preguiçoso e não profissional. Esta é uma equipe com uma cultura de trabalho em equipe manca.
Assim como com os colegas de quarto: todos devem realizar a limpeza diária, lavar a louça depois de si mesmos, limpar periodicamente o banheiro e o banheiro, limpar a sala de estar comum. Mas existem atividades mais complexas para aumentar a habitabilidade , que podem ser deixadas "apenas para os interessados". Por exemplo, superam os armários de cozinha ou escolha uma mesa adequada na sala de estar, em vez de ser muito volumosa.
Mas o trabalho diário é o que todos devem fazer. Ou seja, você pode ter pessoas na equipe interessadas em refatoração arquitetônica global, dividindo módulos muito grandes, otimizando as interações entre eles e aqueles que não desejam fazer isso. Nem todo mundo é obrigado a participar do rearranjo dos móveis, mas todos devem lavar a louça.
Dois extremos são inabitáveis ou por que os livros não funcionam
Interior maravilhoso, não é? Tudo está perfeitamente combinado e pensado, nada mais. Em uma palavra - um sonho. Assim como uma descrição de padrões mostrando uma bela versão de um código perfeitamente consistente e perfeitamente abstrato. Tão bonito que o olho se alegra.
Sim, o apartamento da foto é lindo, mas você não pode morar nele. Os apartamentos das páginas das revistas são intencionalmente privados de lixo, porque o lixo é algo individual.
O que essa bagunça consiste é de coisas diferentes para todos. Se você gosta de ler, esses são livros; se você gosta de jogos de computador, esse é um console e joysticks; se você gosta de atividades ao ar livre, é uma bicicleta ou um caiaque. As coisas que você usa devem estar à mão, para que você tenha que lidar com uma certa bagunça. O principal é que não deve haver muito disso.
Revistas sobre belos interiores no mundo do desenvolvimento de software mostram códigos irrealisticamente limpos e, portanto, definem as diretrizes erradas. São livros sobre desenvolvimento de software, padrões de design, dicas de blogs e artigos. Código que satisfaça todos os seus requisitos, perfeitamente consistente e abstrato - não é viável no mundo real. Mesmo se você conseguir isso, não poderá viver nela.
Precisamos de uma pequena bagunça para nos sentirmos confortáveis. Isso é verdade para o apartamento e o código.
Ambos os extremos são inabitáveis . Se você tem um código que não entende e não sabe como trabalhar com ele, é um desses extremos. Ou está muito cheio que é impossível distinguir idéias adequadas de idéias inadequadas, ou é tão puro que as idéias adequadas são simplesmente impossíveis de encontrar.
Além disso, esses dois extremos podem existir simultaneamente no mesmo projeto. Às vezes até nas vizinhanças. O código habitável está em algum lugar no meio. Além de um espaço confortável para morar, fica entre fotos das capas de revistas e apartamentos desordenados.
Portanto, você precisa ter uma pequena quantidade de lixo, pois torna o espaço habitável .
Manifesto
Você pode dizer: “Isso é tudo, é claro, muito interessante, mas e se meu código já estiver completamente desarrumado? Ou se o projeto não for tão ruim, mas quero ter certeza de que ele não está indo na direção errada? ”
Digamos que seu código se pareça com uma sala de estar herdada e desarrumada, com caminhos estreitos de entendimento que passam por ele. Não se preocupe, você não é uma pessoa má - isso pode acontecer com todos.
Se você observar o problema do ponto de vista da engenharia, ele simplesmente grita: “Reescreva! Como é possível organizar algo em um local sem espaço livre? Apenas tire tudo daqui e comece de novo! ”Esse planejamento de cima para baixo é adequado para determinadas tarefas de engenharia, mas não para a maioria dos softwares. Isso não ocorre porque somos maus engenheiros ou tentamos mal, mas porque em nossa área a abordagem de engenharia não funciona. E o código funciona como um espaço no qual as pessoas vivem. Você precisa entender que as pessoas são exatamente no que você precisa trabalhar.
Aqui está como fazê-lo. Existem quatro regras que se aplicam a qualquer idioma e estrutura.
Não faça mal
Quase como na medicina. Ao abrir um arquivo já desordenado, prometa que não o tornará pior. Mesmo se você não tiver tempo para consertar as coisas que já são terríveis. Se, ao realizar uma revisão de código, você perceber como uma pessoa viola essa regra, lembre-a apenas do que você concordou.
Acredite em melhorias consistentes
Uma pilha de cinco livros no chão e uma arrumada em uma estante de livros é melhor do que uma pilha de seis livros. Talvez quem toque esse código da próxima vez mude outro livro da pilha para a prateleira. Se você esperar o tempo para colocá-los todos de uma vez, isso nunca acontecerá.
Usar essa abordagem pode ser um problema. Os aprimoramentos sucessivos são difíceis para muitos; portanto, eles continuam vivendo com um desejo ardente de reescrever completamente um módulo, subsistema ou aplicativo. Como resultado, a pilha de livros não diminui e permanece no chão de iteração para iteração.
Tornar a limpeza parte do fluxo de trabalho
Não inicie histórias de usuário para refatoração. Não espere duas semanas para corrigir um arquivo. Aprenda a incorporar regras simples ao seu trabalho diário. A regra dos batedores diz: deixe o acampamento mais limpo do que era antes de você chegar. Se você segui-lo constantemente, gradualmente se livre de "maus hábitos".
Mantenha contato
Esteja preparado para sempre se comunicar com cada membro da equipe sobre o que você está fazendo. O parágrafo anterior não significa que você precisa ocultar o que está fazendo. Você só precisa refatorar e colocar as coisas em ordem como parte de tudo o que faz.
Quando você refatorar:
- Não peça permissão. Isso faz parte do seu trabalho. Mas esteja aberto a discutir suas decisões.
- Não se esquive da responsabilidade por seus erros e aprenda com cada um deles. Erros também fazem parte do trabalho. É através deles que chegamos a entender no que estamos trabalhando. Você os fará, humilhe-se. Às vezes você não pode terminar a refatoração, às vezes, pelo contrário, pode se deixar levar demais, mas o principal é aprender com seus erros repetidamente.
- Peça dicas, mas nem sempre as siga. Sua tarefa como desenvolvedor é determinar o que você precisa refatorar e o que não. Você deve ter a liberdade de tomar essas decisões e cometer erros.
- Faça tudo junto porque você mora aqui. Isso é muito importante. , , , .
Conclusão
— . — . , , , , .
. — . , , , , .
Referências
- , ,
- Princípios relacionados de Bob Martin