Skip to content

Fazer o simples no desenvolvimento de software é um princípio, você sabia?

De tempos em tempos, eu vejo alguém fazendo uma feature mais complexa do que o necessário por causa de várias prerrogativas tecnológicas, mas você sabia que fazer o simples é um principio no desenvolvimento de software? Saiba aqui sobre os princípios KISS e YAGNI.

Quando eu comecei a desenvolver software, eu costumava vê muitas pessoas falando sobre assuntos como Design Pattern, então eu comecei a ler vários livros sobre o assunto por que o pensava que assim eu seria um melhor desenvolvedor. Saber essas coisas não é errado, é uma obrigação, o problema era como eu praticava essas coisas que eram erradas. Abaixo eu explico o por que.

Quando eu iniciei em meu primeiro emprego, tudo que eu costumava fazer era da maneira mais complicada. Uma classe obrigatoriamente tinha um padrão, um projeto tinha que ter uma arquitetura “XPTY” e eu costumava adorar aquilo. Eu ficava feliz quando alguém perguntava para eu explicar por que ele/ela não tinha entendido. Eu era o cara que complicava tudo  com o pretexto de que o “Autor” disse aquilo ou isso.

Então um dia eu conheci alguém como eu. Aquela pessoa amava fazer coisas complicadas, mesmo nosso projeto estando atrasado. Você deve estar se perguntando o quão complicado? Bom, ai vai.

  • Criava-se DTOs na camada de infraestrutura e o mesmo na camada de aplicação, por que? Por que o “Autor” disse que cada camada deve ter o seu próprio DTO (Eu nunca achei isso, mas tudo bem).
  • Todos os Devs sabiam muito bem SQL Server ou Oracle, mais ele queria usar MongoDB, por que? Nenhum motivo, apenas por que estava na moda.
  • Nossa cobertura de teste deveria estar perto dos 100%. Ele testava Filters do ASP.NET (Como se a Microsoft não já tinha testado isso antes) e cada consulta com o banco de dados com os testes de integrações.

Como você pode ver, tudo poderia ser feito quase que na metade do tempo, mas nós sempre fazíamos o que ele queria por que ele era nosso arquiteto de projeto.

Somente para lembrar mais uma vez, nosso projeto estava atrasado. Um dia nosso P.O pediu uma feature onde essa deveria logar todas as ações/eventos dos usuários e o nosso arquiteto pediu um mês para fazer essa feature por causa da “complexidade” que seria para criar os “objetos”, pois iriamos usar o patter “X” e o banco “Y”, então nesse dia eu explodi! Aquele dia eu mandei alguém a merda.

Agora vou contextualizar melhor você, nossa empresa não ganhava muito dinheiro com aquele software por que esse era muito pequeno, basicamente um conjunto de CRUDs. A empresa apenas queria fazer o cliente feliz para ai sim pegar outros “problemas” e com isso realmente ganhar dinheiro.

Você já conheceu alguém assim? Eu vejo e muitas vezes eu e você somos esse cara. Geralmente, quando queremos fazer algo mais complexo do que aquilo realmente é, é por que queremos nos desafiar, provar que também somos capazes de fazer aquilo. Já em outros casos, quando complicamos d+ a coisa, é por que colocamos tantas exceções para a funcionalidade que fica muito mais complexa para desenvolver. Esses são os motivos pelo que fazemos coisas complexas e não simples.

Fazer o simples é difícil, Steve Jobs disse uma vez.

Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.

Por isso existe dois princípios que eu gosto muito, KISS e YAGNI.

A definição de KISS você pode encontrar na wikipedia

KISS, an acronym for “keep it simple, stupid” or “keep it stupid simple”, is a design principle noted by the U.S. Navy in 1960.[1][2] The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.

E a definição para YAGNI você pode ver no deviq

YAGNI, or “You Ain’t Gonna Need It” (or “You Aren’t Gonna Need It”), emerged as one of the key principles of Extreme Programming. Put another way, the principle states:
“Always implement things when you actually need them, never when you just foresee that you may need them.”

Eu gosto muito desses princípios por que eles me ajudam a focar na feature e fazer apenas o que é necessário. Mas como posso pensar de maneira simples?

  • Primeiro erro: quando nos não sabemos sobre o negócio e seu valor. Você deve sempre estar atento ao negócio, o core, como funciona, não somente em como fazer. Que valor essa feature traz para o cliente? Iremos fazer dinheiro (Não tenha vergonha de fazer essa pergunta)?
  • Segundo erro: eu sei que as vezes não sabemos muito sobre a feature por que ela é “um tiro no escuro”, mas mesmo assim você não deve inchar essa feature com coisas que nesse momento não vão dar valor. Esse é o único momento que a criatividade não ajuda.

Martin Fowler em seu artigo fez um grande exemplo onde existia duas features similares, mas não iguais. Uma feature era para fazer agora e a outra apenas nos próximos 6 meses. Porem, o time queria fazer a primeira já pensando em preparar o código para a segunda feature. Quantas vezes você e seu time não fizeram isso? “Bora já implementar para ficar tudo pronto”

Onde está o erro?

Você sabe muito sobre a primeira feature, por isso vai fazer ela agora ou por que a sua prioridade é maior. A segunda feature você não sabe muito até o momento. Você pode imaginar o código que você irá gastar por que você não sabe muito sobre a segunda feature? E se o P.O. passou as informações erradas? E se a segunda feature não for mais necessária (Essa já aconteceu um monte de vezes comigo)? Percebe agora o que o YAGNI quer dizer: Se você não precisa disso agora, não faça.

Alguém pode me falar: “Mas no futuro eu posso ter que alterar todo o código por que eu não preparei meu código”. Sim, você irá alterar o código, mas a diferença é que agora você irá alterar sabendo das regras e o que é necessário para o negócio.

Minha humilde conclusão, se você não precisa disso agora, não faça e se você fizer, faça isso de maneira simples. Mas cuidado, quando falo simples não é de maneira relaxada e porca. Nesses anos todos eu aprendi que os princípios que existem para o desenvolvimento de software é igual ler a Bíblia, muitos tem interpretações totalmente diferentes.

Espero ter ajudado você a abrir a sua cabeça, até a próxima.

Quer fazer um curso de TDD ou DDD a um preço super barato? Acesse um dos meu cursos https://www.udemy.com/user/stephany-henrique-de-almeida-batista/ e começe hoje mesmo!

Published inQualidade de software

Be First to Comment

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *