Executando verificação de segurança...
6

Vou começar falando sobre os termos "complexo" e "complicado".

Embora não haja uma distinção geral de significado entre os dois, eu gosto de usar na área de engenharia um significado diferente para cada. Pra mim, complexo é algo inerente ao problema, é a dificuldade fazer porque o que tem em mãos envolve muitos elementos e suas relações são entremeadas. Já complicado é algo evitável e geralmente feito assim só por desconhecimento de forma melhor ou relaxo.

Portanto, dentro dessa definição, o programador não consegue evitar código complexo mas consegue evitar código complicado.

O problema é que a decisão do que é complicado pode ser subjetivo. O que é complicado para um pode não ser para outro. Frequentemente eu acho complicado códigos que a maioria das pessoas fazem o tempo todo. Ou seja, cheia de elementos que não precisariam estar ali, e violam o YAGNI e o KISS. Ao mesmo tempo eu faço código simples que algumas pessoas podem achar complicadas porque elas desconhecem a forma de programar assim. Vou dar um exemplo:

if (ativo == true)

   
é complicado para mim

if (ativo)

   
é complicado para outras pessoas.

Então algumas pessoas entendem que complicado é ser tão explícito que se torna redundante, e para outras é tudo o que é desnecessário.

Todo mundo concorda que deve fazer código simples. "Ninguém" concorda sobre o que é um código simples. Boa parte do que os autores citados pregam são complexidades muitas vezes desnecessárias em um código, mas que muita gente adota porque está em um livro. Se o que eles pregam é realmente necessário para o código ser sustentável então é uma complexidade aceitável. Caso contrário é só complicação que a pessoa adotou por falta de entendimento completo sobre o processo de desenvolvimento de software, o que eu acho frequentemente de "seguir receita de bolo".

Código sustentável é aquele que observa um contexto. E não coloca penduricalhos desnecessários. Porque cada token de código que coloca e não serve para nada, é um código a mais para dar manutenção. Se o código tem aquela necessidade, então está tudo bem.

Em geral, um código ruim acontece por falta de domínio da computação e engenharia de software e/ou do domínio específico que está trabalhando. O exemplo que eu dei acima é falta do primeiro. Frequentemente o segundo acontece porque o programador não tem todas informações necessárias, e isso é relativamente normal. É muito difícil obter todas as informações necessárias, então ele vai deixar de colocar algo importante e colocará algo no código que não faz o menor sentido, só porque ele acha que será um dia, de acordo com a informação atual que obteve.

Minha observação pessoal é que acontece mais os extremos. Ou a pessoa faz sem qualquer planejamento ou ela faz um monte de coisa porque ela acredita que terá necessidade, paga o preço por isso e nunca compensa o esforço. Achar o equilíbrio é difícil até para os experientes, a não ser em um problema idêntico que a pessoa já tenha trabalhado e já cometeu todos os erros e já os corrigiu antes. O que é muito raro acontecer.

Uma das justificativas que as pessoas dão para tornar a solução mais complexa é a redução da complexidade, o que torna complicado. Para isso é comum usar soluções em camadas, como o anti pattern chamado "código lasanha", em geral mal pensado e sem vazamento de abstração se torna muito difícil usá-lo em uma situação diferente do que ele foi pensado. A pessoa faz o código como se estivesse produzindo um carro, só que carros são difíceis de dar manutenção já que eles têm regras próprias que você tem que se conformar, você não pode usar do jeito que bem entende.

Repito, é muito difícil prever o futuro, e o software sempre tem um futuro incerto. Se preparar demais para o futuro será tudo complexo demais, complicado de fazer e até mesmo, de certa forma, de dar manutenção. Se fizer simples demais terá que refazer tudo depois. E isso pode ser melhor em alguns casos, ao contrário da crença popular. O problema é saber quando usar um ou outro.

De forma geral concordo com o texto e ele é valioso para ajudar as pessoas entenderem o problema, só achei que precisava complementar com isso.

Faz sentido para você?

Espero ter ajudado.


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Carregando publicação patrocinada...
1

Mestre maniero, como sempre com reflexões importantes que enriquecem o conteúdo.

Sobre o código simples, penso eu, que é aquele que você consegue bater o olho no algoritmo e ler como se fosse uma história. Tu entende o inicio o meio e o fim da instrução de código.

Nomes de métodos e variáveis bem descritivas e por ai vai.

Concordo 100% sobre o fazer código sem planejamento, na maioria das vezes é colocando um Over Engineering absurdo em cima de coisas que deveriam ser simples.

1

Importantíssimo a parte explicando sobre complexidade. Realmente, alguns domínios do conhecimento são complexos, não há oque fazer, é uma característica inerente a eles.

Consequentemente, a implementação desses domínios em um software irá requerer uma estruturação relativamente complexa para criar uma abstração à altura da complexidade inerente. Um framework MVC de alto nível, por exemplo, possui diversos módulos necessários para caracterizar essa ferramenta como eficiente.

Uma implementação de leitura de request, de um esquema de rotas, de uma camada de acesso a um banco de dados são implementações relativamente complexas, que muitas das vezes são abstraídas o máximo possível para que o usuário da ferramenta não enfrente dificuldades. Porém, com uma rápida olhada no código pode debaixo dos panos, percebe-se que o que está em alto nível é apenas a casca de um todo, de complexidade muito maior.

Achei interessante também a explanação sobre o fato do conceito de 'complicado' ser relativo. A implementação e a leitura de um código com design patterns pode ser complicada para um iniciante, porém, é sabido que esses patterns tornam o projeto mais saudável e manutenível, e na maioria das vezes diminuem a curva cognitiva para entendimento do código.