Hoje é um dia ensolarado. Você está dirigindo pela estrada para sua vila, onde vivem todos os seus amigos, sua família e seu cão amado. Um dia maravilhoso! De repente, você ouve um terrível pesadelo chorar rasgando o ambiente. A enorme Hydra nojenta está se aproximando da vila para destruí-la! Você pega uma espada (é claro, você tem uma espada!) E tenta proteger todos que ama. Mas há um pequeno problema: o monstro tem muitos objetivos, e quando você corta um deles, um novo cresce rapidamente!

Parece que você não pode vencer esta batalha. Talvez você possa brincar com Hydra por tempo suficiente para que toda a vila tenha tempo de fugir de uma ameaça terrível? Finalmente, você se tornará um verdadeiro herói do mundo inteiro! Quem não quer isso?

O papel da Hydra é a entropia no software: é seu inimigo, ele está exaurindo você, mas você nunca pode se livrar completamente dele. Mas você ainda precisa lutar com ele para que seus aplicativos (e colegas) permaneçam saudáveis ​​e saudáveis.

Vamos descobrir:

1. O que é entropia no software e como notá-lo no seu código.
   
2. Quais são as suas possíveis causas e como manter a entropia baixa.
   

Chega de conversa, direto ao ponto!

Conheça o seu inimigo

O que é entropia e como foi parar no meu aplicativo?

Às vezes, é útil descobrir a etimologia das palavras usadas, especialmente aquelas específicas como entropia. Traduzido do grego, significa "transformação". Mudança. Algo que você deve se acostumar como desenvolvedor de software.

Entropia refere-se à segunda lei da termodinâmica. Diz que em um sistema fechado e isolado, a quantidade de caos não diminui com o tempo. Permanece estável ou em crescimento.
A idéia de entropia em software surgiu através do livro Engenharia de Software Orientada a Objetos . Quanto mais o programa muda, mais caos ele tem, sua entropia aumenta.

A primeira coisa que os desenvolvedores pobres precisam deixar claro para nós é a verdade trágica: podemos combater a quantidade de entropia em nossos programas, mas nunca podemos nos livrar dela.

Crie a melhor equipe (com a sua participação, é claro!), O melhor ambiente, a melhor administração, a melhor cultura da empresa, o melhor projeto. O que acontecerá com o tempo?

1. Você cantarolará todas as manhãs: "Este é o melhor projeto!" Um projeto verde que parece um belo campo, iluminado por um maravilhoso nascer do sol.
   
2. Você e a equipe adicionarão mais e mais recursos. Como você é o melhor dos melhores, por um tempo tudo parece ótimo.
   
3. Meses ou anos se passarão. Ninguém quer mais trabalhar em um projeto. Mesmo que tenha sido bem projetado, a tecnologia está desatualizada, o projeto exige muito esforço e tempo para ser entendido, e é caro escalar. É muito difícil construir seu bom modelo mental.
   

Como você criou essa complexidade? Você só precisa escalar o projeto. Mais elementos geralmente significam mais dependências e maior complexidade. Eu já escrevi um artigo detalhado sobre isso.

Se você explicar isso a Lyokha, seu colega desenvolvedor, ele responderá:

“Nifiga! Você é um tolo Caos e desordem não têm lugar no meu lindo aplicativo! Minha reputação não será manchada por algumas bobagens! Eu sou o mestre do meu destino! Se eu não mudar meu programa, a complexidade não aumentará e, em conexão com essa prova de contradição, declaro que você está enganado e sou o melhor! ”

Você pode explicar calma e convincentemente e decisivamente a Lyokha que, mesmo que você não mude o programa, tudo ao seu redor mudará. Se você tiver bibliotecas de terceiros que não estão sendo atualizadas, haverá problemas de segurança. E se você atualizá-los, abrirá a porta para alterações e entropia.

Além disso, se um dia você precisar alterar algo em seu software após um longo período de tempo, não se lembrará de todos os detalhes. E mesmo a melhor documentação não irá ajudá-lo. O mundo mudou, e o que era verdade ontem pode nunca ser verdade, tanto no nível tecnológico quanto no de negócios.

Tais mudanças ao mesmo tempo trazem uma grande quantidade de entropia.

Portanto, a questão não é se livrar dele, mas com moderação. Esta é uma verdadeira batalha na qual nós desenvolvedores somos lançados.

Definição de Entropia em Software

Qualidade do software

Como descobrir que seu aplicativo tem um alto nível de entropia? Um bom indicador é a qualidade do código.

O que é e como medi-lo? De acordo com Accelerate: The Science Behind Devops :

• Se a proporção de alterações / falhas aumentar, a qualidade diminuirá. Acompanhe alterações, bugs e falhas, compare-os entre si. Se cada alteração levar a novos erros ou falhas, a entropia no seu programa aumentará.
  
• Um papel importante é desempenhado pela percepção subjetiva do projeto pelos desenvolvedores. Se todos tiverem a sensação de que está se tornando cada vez mais difícil dimensionar o aplicativo sem quebrá-lo, a entropia provavelmente será alta. No entanto, essa sensação deve ser comum.
  
• Se a equipe gasta muito tempo corrigindo bugs ou se recuperando de falhas, a entropia deve ter feito um ninho no seu aplicativo.
  

Se você puder obter informações sobre a proporção de alterações e falhas e gastar tempo corrigindo bugs, poderá criar um bom cronograma para convencer o gerenciamento da necessidade de algum tipo de refatoração.

Demônio da dificuldade

Mesmo se você tiver um código da mais alta qualidade, a complexidade pode aumentar facilmente quando se trata dos próprios recursos do programa. O próprio negócio é uma fonte da complexidade necessária da qual você não pode se livrar.

Com a complexidade excessiva dos negócios, os desenvolvedores terão que gastar muita energia para construir um bom modelo mental dos negócios da empresa. Portanto, eles cometerão erros ao tentar converter os requisitos de negócios em código.

Vamos falar com mais detalhes sobre a complexidade dos negócios: precisamos realmente de todos esses recursos complexos que nos decepcionam?

A razão da entropia e como lidar com ela

Cachoeira da entropia

O problema

Mais ou menos óbvia, a principal causa de entropia no software são os próprios desenvolvedores. Eles são preguiçosos, carecem de qualificações, especialmente da Sanka, com quem você trabalha. Ele faz tantas perguntas!

Discordo totalmente desta opinião. Na minha experiência, o principal motivo da entropia é a liderança, especialmente em empresas com um estilo de gerenciamento em cascata.

Como Gerald Weinberg observou em The Secret of Consulting :

Mesmo que esse seja um problema puramente técnico, sua origem sempre pode ser rastreada até a ação ou inação da gerência.

Eu sei o que você pensou: “Você está errado! A gerência nem sempre é responsável por tudo! É conveniente que os desenvolvedores culpem os chefes por tudo! ”

Não estou dizendo que a liderança seja responsável por tudo, mas ele sempre tem algum grau de responsabilidade . O desenvolvedor fez algo ruim? Você precisa revisar o processo de contratação. As especificações foram mal implementadas? Talvez alguns dos líderes não saibam o que realmente querem e, portanto, as especificações não importam para ele.

Portanto, é tão difícil ser um líder! Quanto mais alto você estiver na hierarquia, mais difícil será.

Como desenvolvedores, quanto você influencia na tomada de decisão? Se 100%, então parabéns, você é o culpado por tudo. Se em 0%, a culpa não é sua. Entre esses pólos, encontra-se todo o espectro de influência. E a cachoeira não implica um grande número dela.

Usando Scrum, Kanban e Poker Planning? Claro que você não usa a cachoeira! Você usa o Agile como uma criança constrói uma casa com uma chave de fenda.

Obviamente, as ferramentas são importantes, mas seu significado é muito menor do que a importância do seu modo de pensar , necessário para o desenvolvimento correto do software. Para citar o manifesto Agile:

Personalidades e interações são mais importantes que processos e ferramentas.

Usar o Scrum não significa que você esteja usando o Agile, especialmente se você não tem o modo de pensar que esta metodologia está tentando ensinar.

Com o gerenciamento em cascata, alguém mais alto que você toma uma decisão, mais alto, outras pessoas tomam novas decisões e assim por diante.

Nos níveis mais baixos da hierarquia, há funcionários cuja maldição é seguir todas as decisões tomadas. Qual é a tarefa deles? Para fazer, como se trabalhadores na linha de montagem de uma fábrica de automóveis. Eles não precisam pensar, precisam fazer carros .

Más notícias: como desenvolvedor, você estará no final da hierarquia.

Se alguém no topo tomar decisões sobre as funções do aplicativo e você praticamente não tiver oportunidade de influenciar o processo de tomada de decisão, seja bem-vindo à cachoeira! Infelizmente, na maioria das vezes, a gerência sênior não vê que no mundo do desenvolvimento de software não haja fase de produção . Os desenvolvedores estão envolvidos no design do sistema , e essa tarefa está longe da montagem do transportador da cabine.

Porque Porque, diferentemente de um carro, os aplicativos estão mudando constantemente! Você precisa projetá- los corretamente para que funcionem, atendam às necessidades dos usuários, que os aplicativos tenham desempenho aceitável, que sejam escaláveis ​​e resistentes a mudanças, mantendo a entropia em um nível baixo. Para fazer isso, você precisa tomar muitas decisões sobre como refletir o conhecimento comercial em seu código.

Se você não afeta a complexidade que a liderança desce para você, terá que gastar muito esforço gerenciando-a no código. Isso será considerado uma complexidade "necessária": uma que não pode ser evitada.

Resultado possível? Os níveis de entropia podem crescer muito, muito rapidamente.

Possível solução

A empresa precisa praticar a tomada de decisão e a responsabilidade conjuntas o mais ativamente possível.

Se você reconhecer sua empresa no modelo em cascata que descrevi, precisará conversar com aqueles que tomam as decisões:

• Forneça dados e argumentos sólidos sobre por que e como simplificar o recurso X ou Y. Explique o preço possível do desenvolvimento de um recurso complexo agora e no futuro .
  
• Explique por que o desenvolvimento ágil de software significa que as pessoas precisam trabalhar juntas. Gerentes, designers, desenvolvedores e todos os demais devem fazer parte do processo de tomada de decisão, dependendo dos requisitos de negócios.
  
• Se sua liderança rejeitar automaticamente a oferta, você precisará entender por que ela fez isso. Faça perguntas.
  
• Fale sobre o que os tomadores de decisão consideram o mais importante: dinheiro e tempo. Mostre a eles que o pensamento no estilo ágil (e não apenas ferramentas) pode salvar os dois.
  

No entanto, é difícil tentar resolver o problema se você não tiver sido questionado sobre isso. Muitos gerentes estão muito satisfeitos com o modelo em cascata e muitas vezes nem sabem que o estão seguindo. Você precisará de muita diplomacia e tato.

Diante de tudo isso, se você acha que as soluções de negócios adicionam muita complexidade ao seu aplicativo e que não pode fazer nada, mesmo se tentar, aconselho você a encontrar outro emprego. É exaustivo - trabalhar com alta entropia todos os dias e criar um produto inchado de prazer não é suficiente ... ou usá-lo. Isso pode lhe dar uma dica sobre o sucesso que seu produto espera.

E a última: o que pode parecer complicado no nível de negócios pode ser simplificado se você conhecer bem os processos de negócios. Isto é extremamente importante. Portanto, saiba mais sobre as atividades da sua empresa, o que elas estão fazendo e o que não estão fazendo, isso ajudará a simplificar os recursos e a base de códigos.

À medida que expressamos nossa arquitetura, explicamos algo ao computador. E para isso, precisamos entender bem o que explicamos.

Donald chicote

Qualidade do código e dever técnico

O problema

Além da complexidade "necessária" introduzida pelos negócios, a entropia no software está intimamente relacionada à qualidade do código e à dívida técnica.

O que é dívida técnica? Simplificando, essas são as simplificações (hacks) usadas para economizar tempo, sabendo que mais tarde isso poderá voltar para você. Especialmente nos casos em que outros recursos dependem desses hacks: você terá que corrigi-lo com juros, como uma dívida real, na forma de dificuldades e dor de cabeça.

Dependendo da tarefa do seu aplicativo, a dívida técnica pode ser mais ou menos aceitável. Se o programa durar alguns meses, não será possível pensar em dívida técnica, entropia ou qualidade. Basta juntar as partes do código e pronto!

Por exemplo, isso pode ser uma solução temporária antes de criar um aplicativo mais complexo do zero. Ou então, você pode escrever rapidamente um protótipo para ilustrar a ideia e reescrever tudo ou abandonar o conceito.

Por outro lado, as empresas geralmente desejam desenvolver aplicativos de vida mais longa. Isso é razoável: reescrever um aplicativo pode ser muito caro (especialmente se for grande) e ninguém pode garantir que seu nível de entropia seja mais baixo. Copiar é um negócio muito arriscado.

Nesses casos, você precisa ter muito cuidado com o dever técnico e a qualidade do código. Esta é uma parte importante do seu trabalho como desenvolvedor.

No famoso livro The Pragmatic Programmer (no qual, entre outras coisas, o princípio DRY é introduzido), é apresentada uma analogia interessante da dívida técnica. Um estudo é descrito aqui que compara a destruição de prédios urbanos com ... janelas batidas neles. A janela quebrada dá a impressão de abandono, inspirando todos os agressores da região. Como resultado, edifícios com janelas quebradas são vandalizados mais rapidamente do que edifícios com janelas inteiras.

Dívida técnica é uma simplificação ou invasão do seu código, uma janela quebrada. Quando outro desenvolvedor, ou você mesmo no futuro, perceber isso, haverá uma tentação de adicionar ainda mais dívida técnica, porque "ainda há um código ruim aqui, então por que tomar um banho de vapor?"

Exemplo: você escreveu uma solução alternativa para um bug complexo, porque não havia tempo para procurá-lo. Outro desenvolvedor (ou você mesmo mais tarde) na parte superior desta solução alternativa pode escrever código diferente, resolvendo outro problema. Camadas de soluções alternativas que ninguém jamais descobrirá muito rapidamente crescerão.

Solução

Primeiro, como você sabe se um código tem dívida técnica?

Pergunte a si mesmo:

• Posso explicar de forma simples e lógica o que o código faz?
  
• Os nomes corretos são usados ​​aqui? Eles ajudam a explicar o que o código faz?
  
• Os nomes longos com "e" se aplicam, como "deleteUserAndShutDown"? Este é um bom sinal de que você precisa separar uma função, método ou alguma outra construção.
  
• Parece que algum código foi adicionado por causa da preguiça? Isso viola a lógica e prejudica a compreensão?
  

Quanto mais seu conhecimento e experiência aumentam, mais curioso você é e, com mais frequência, mantém discussões saudáveis ​​com outros desenvolvedores, mais frequentemente você notará padrões de dívida técnica. Este é o código com um estrangulamento

Ao encontrar esses padrões, não os considere permissão para adicionar ainda mais dívidas técnicas:

1. Um aumento no tempo técnico levará a novos problemas. Eles retornarão e perseguirão você (e sua equipe) ainda mais.
   
2. Tendo cumprido uma dívida técnica, refatore-a. Esta é a melhor opção. Se você não tiver tempo ou energia, basta adicionar um comentário // TODO: refatorar por esse e por esse motivo. Relate um problema, não o deixe escondido na base de código.
   

Não esqueça que você precisa refatorar em paralelo com o desenvolvimento de outros recursos para que eles correspondam à arquitetura atual. Simplificando, reparar a dívida técnica não deve ser uma tarefa independente, mas um processo contínuo que pode não estar relacionado à tarefa atual. Ao desenvolver um recurso, dê a si mesmo o direito de corrigir a dívida técnica encontrada.

Refatore pequenos pedaços de código de cada vez e execute testes para garantir que o sistema esteja funcionando conforme o esperado.

Por fim, durante a refatoração, você pode precisar de alguns bons argumentos:

1. Primeiro para você. É fácil pensar que seu colega não é capaz de programar e que você conhece melhor que os outros. Mas se você não vê os benefícios específicos da refatoração, não o vê. Talvez a coisa toda esteja apenas no seu ego, e você possa arruinar alguma coisa.
   
2. Se a refatoração estiver relacionada ao estilo do código, significa que sua equipe não a definiu claramente . Faça uma reunião e decida em conjunto que estilo de código você deseja adotar. Isso precisará ser anotado em algum lugar, para que todos possam lidar com a necessidade. Edite o contrato de acordo com as necessidades da equipe. Caso contrário, seu código será preenchido com comentários como “usamos guias !!! NÃO ESPAÇOS !!!!! 11! 1 !!! ”. Este é um barulho inútil.
   
3. Finalmente, se alguém lhe perguntar por que você mudou o belo código dele, você terá argumentos reais para explicar sua decisão.
   

Bons argumentos sempre desempenham um papel positivo no futuro. Por exemplo, agrupando uma biblioteca de terceiros para que não cause vazamento na sua base de código. Se você não entende por que estou falando de um vazamento, leia o que escrevi sobre abstrações .

É difícil para nós, humanos, fazer previsões a médio e longo prazo. Portanto, nem sempre é fácil refatorar ou "vender" algo de olho em um futuro desconhecido.

O dever técnico reflete o dualismo entre o caminho simples e o caminho certo . O primeiro é rápido e atraente, o segundo tornará seu projeto escalável e fácil de manter. Você precisará de autodisciplina para escolher o segundo caminho o mais rápido possível. Caso contrário, o futuro será preenchido com sofrimento.

Se você está cansado demais, irritado ou cheio de outros pensamentos ou emoções que reduzem sua motivação para seguir o caminho certo, e não o simples, é melhor não programar ainda. Dê um passeio, converse com colegas, faça uma pausa. Retorne ao código com novos cérebros.

Na maioria das vezes, a dívida técnica é adicionada durante a depuração. Se você corrigir um erro adicionando uma solução alternativa, não corrigiu nada. O bug permanece, é apenas mais difícil de executar e encontra-o acidentalmente. Você precisa corrigir os erros usando refatoração , alteração ou exclusão completa do código. Em seguida, teste o código para garantir que o erro não ocorra novamente.

Por último: culpar os colegas por erros é improdutivo. Se você falar mal ou sarcasticamente sobre sua base de código, isso também não resolverá os problemas, apenas piorará a situação. Não destrua o espírito de equipe. Você precisa reduzir a entropia no projeto e não destruí-la verbalmente.

Testes automatizados

O problema

Há algo de fascinante para mim no mundo mágico do desenvolvimento de software, especialmente nas startups: muitos programadores ainda não querem escrever testes automatizados.

Por que isso me fascina? Em todas as outras áreas da engenharia, eles testam o que fazem seguindo um processo rigoroso. Quando você constrói um foguete, você precisa testar muitos sistemas, ou o foguete cairá. O mesmo vale para carros, pontes, aviões - qualquer coisa.

Economizando dinheiro .

Um exemplo simples: a NASA está testando completamente seu código (consulte a regra 5) .

, , , . , , .

. .

, , — , . ? , . , , ( ), , - .

, : , . , .

, .

Solução

, , , .

. - 1,3 . , . «» .

:

• « ».
  
• « , ».
  
• « . , , ».
  

, , - ( ), :

• . , , .
  
• . , , - .
  
• . — , .
  
• , - . , - . !
  
• , . !
  

, .
, . , . , .

, , . .

, , . , , - .

, , . , , :

• , , .
  
• - , .
  

, . , . . , , , - , .

— , .

, .

,

:

• .
  
• , .
  
• , - .
  

. , , .

?

— . - , . , .

Isso é tudo! , .

, , .

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

: , . , . , .

, , , . , , . !

. :

• .
  
• , .
  
• .
  

, . , . , , .

, , . ?

, . , , .

:

• , . «, ?» — , « ! ! !».
  
• , . , , , , . «, , ?» « , 289 ».
  

, . , !

( !) .

. , , .

, — , , . !

!

, , , , . ? ? - ? ?

. , . -, . , , , .

, , . . — .

Então ?

• — . . , .
  
• — .
  
• . / .
  
• , , .
  
• , . , .
  
• , , (, ).
  

. . , . , — !

:

• The Pragmatic Programmer
  
• Software Entropy Explained: Causes, Effects, and Remedies
  
• Entropy in software
  
• Software Rot, Entropy and the Broken Window Theory