SNIPPET: Afinal, o que é um código incrível?!
Olá pessoal. Tudo certo?!
Recentemente, há muita discussão sobre se devemos, ou não, escrever código incríveis. Mas, afinal, quais são as características de tais códigos?!
Para mim, códigos incríveis são (em ordem de importância):
- Fáceis de entender, mesmo para um programador júnior;
- Fáceis de alterar (por isso, acho que devem ser fáceis de testar);
- Atendem ao seu propósito;
- Enxutos (tanto em linhas de código quanto em padrões);
- Equilibrados em performance e legibilidade.
Códigos incríveis, para mim, são simples e fáceis. Quanto mais fácil, mais simples, mais incrível!
O que não são, necessariamente, códigos incríveis?!
- Códigos fiéis a paradigmas;
- Códigos com mais de X% de cobertura por testes;
- Códigos com deploy contínuo;
- Códigos com “algorítmos inteligentes”;
- Códigos com containers de injeção de dependência;
- Códigos que adotam tecnologia X, Y ou Z.
E para você?!
Estou seguindo este snippet criando uma classe/lib que conversa com o protocolo HTTP via socket. Pensei que não iria dar tanto trabalho, mas desmistificar os headers HTTP, Proxy, Encoding ta sendo foda!!
Código incrível pra mim é aquele que, seguindo os recursos e paradigmas da linguagem, consegue ser auto-explicativo a ponto de precisar de comentários somente para as partes que envolvem conhecimento da solução como um todo
Boa !!!
Para min um código Incrível seria algo semelhante a sua:
* Fácil compreensão .
* Fácil alteração inclusive para programadores Júnior
* Código bem separado em métodos e classes ( me falaram uma vez o nome de um método tem que ter apenas 1 verbo sendo assim ele vai fazer apenas uma unica coisa e vai delegar para outros métodos demais afazeres )
* Fácil de testar
Em alguns momentos / aplicações precisamos aplicar maior complexidade de código, mas escrever constantemente códigos de alta complexidade não considero uma boa prática até porque vai dificultar a manutenção do mesmo por demais membros ou futuros membros da equipe / produto.
Engraçado o item “Atender seu propósito” estar na terceira ordem de importância, este item não deveria ser pré-requisito de qualquer código? Se não o fosse, não deveria ser o primeiro na ordem de importância?Já que se um código não atende ao seu propósito, não tem o porquê da existência do mesmo.
Grande Francisco!
Bateu em um ponto que eu considero fundamental. Perceba:
* Se eu tenho um grande código que ainda não atende seu propósito, deverá ser fácil “arrumar”
* Se eu tenho um código ruim que atende o propósito, pode não ser possível fazer o sistema continuar evoluindo.
Por isso, embora controverso, prefiro um código bem arrumado que está perto de funcionar do que um código “terrível” que funciona “por enquanto”.
Eu acho que são duas coisas diferentes, por exemplo “Por isso, embora controverso, prefiro um código bem arrumado que está perto de funcionar do que um código”, até esse ponto um código bonito que “ainda” não atende o propósito não tem valor, ou melhor mais valor que um código ruim que atende.
Digo isso justamente porque o ruim pronto possívelmente já está entregando valor para a empresa $$$, claro que entra o resto da conversa, manutenção, etc…
Resumindo:
Ta bonito mas incompleto = ferrou
Ta feio mas funciona = toma cuidado, vai ter problema ai
Ta bonito, funciona e entrega o que precisa = perfeito
Ainda pensamos diferente. Mas, entendo seu argumento.
Acho que a questão está em definir melhor “funciona”
hehe sim claro que tem que definir o funciona
, eu só acho que as vezes o foco do problema a ser resolvido é deixado de lado pela “beleza” do código, e isso não da para tolerar.
Não suporto código feio também, mas entre o feio que resolveu o problema para o bonito que não resolveu, ai acho que não tem muito que escolher
, e novamente, não estou adicionando nesse cenário custos de manutenção, etc…
Cara, concordo integralmente com você.
Tanto que acho que um dos conceitos mais negligenciados por nós é, exatamente, o conceito de dívida técnica.
Para mim, ter uma dívida técnica = reconhecer que precisei abrir mão de algum aspecto de qualidade interna para atender um aspecto de qualidade externa.
Isso é bom, natural e … desejável.
Ninguém consegue escrever “o fino” todo o tempo. Aliás, quando falei em “Work in progress”, reconheci isso.
Lembra do meu conceito de eficácia?! Entrega para o cliente/Custo total de propriedade? Então, se aplica integralmente aqui.
Exato, chegamos em um acordo
Não tão rápido!
Ainda acho mais importante, para chamar um código de incrível, que ele seja fácil de entender e alterar do que estar pronto!
Deixar pronto, é questão de trabalho. Deixar fácil de entender ou manter, as vezes, implica em começar do zero.
Gostei da sua definição, só faria a alteração que o Francisco sugeriu…primeiro de tudo tem que atender o propósito, tem que funcionar, senao de nada adianta ser simples e compreensível!
Considere meu argumento para o Francisco
Sim, entendi o seu argumento.
Mas, para mim, faz mais sentido a ordem do TDD, primeiro o teste deve passar para depois refatorar. Ou seja, primeiro atende o propósito depois limpa a sujeira
Tem um ditado que diz que a ordem das batatas não altera a maionese, talvez estejamos discutindo algo semelhante.
Entendi o seu argumento. Concordo desde que exista o desejo e a iniciativa de “pagar a dívida” assim que possível.
Cara o que o Elemar quis dizer é que com um código bonito e incompleto pode-se está a apenas 20% da solução definitiva e com o código feio pode-se está a 80% da solução definiva. Aquilo terá terá que ser praticamente reescrito só atende no momento mas pode não atender nos próximos 20 minutos após se descobrir que terá que incluir uma nova funcionalidade ou que existe um bug difícil de resolver porque não houve reuso e o problema está disseminado por várias partes do código. Se tá mal escrito não tá pronto não é expansível, não evolui, já tá morto.
Acredito que um código incrível é um pequeno código simplesmente complexo, aquelas pequenas linhas que dariam um livro, devido aos conceitos e principalmente as possibilidades.
A questão pode ser mais filosófica a partir dos pontos de: o que é um código bom/ruim partindo do ponto que ambos resolvem o problema? O que determina são os critérios.
Já pensei dessa forma. Aliás, continuo pensando. Entretanto, considero os pontos que destaquei como sendo os “critérios”.
Primeiramente, venho te acompanhando um bom tempo e acho estranho você submeter este tema. Seus posts são interessantes, mas sempre muito complexos e distante da realidade.
É algo parecido aquilo que passamos quando estamos em uma disciplina que um aluno olha para o outro e diz: Tá, e onde uso isso?!?!
Já, os itens que você elencou eu concordo, mudando o item 3 para a primeira posição, claro!!
Pois, do que me adianta um desenvolvedor que faz código facílimo de entender, ótimo de dar manutenção, mas não entende os anseios do cliente, o “proposito” da solução completa???
Agora outro ponto: cobertura de testes!! no meu dia-a-dia não uso TDD, mas sinceramente: me sinto humanamente vulnerável quando mexo em uma rotina e não estou confiante que testei de todas as maneiras possíveis. Por isso acho muito importante cobertura de testes!!
Era isso!!
Ouch Nane! Interessante, mas, distante da realidade?! Quase “Bonitinho mas ordinário”.
Curioso: Se entende que há importância na cobertura por testes, por que não implementa?
Desafio aceito! Estabelecer melhor o link entre o que mostro aqui e o dia-a-dia.
Fazendo uma analogia de software com literatura.
Nós temos livros que tem páginas e mais páginas sobre determinado assunto, a maioria maçante e ao chegar no final não agregou nada. Assim como temos textos que dizem tudo em pouquíssimas palavras.
Se repararmos, os bons escritores usam da técnica de escrever pouco, de forma sucinta e simples; Já escritores que querem ser importantes e reconhecidos acabam dando com o rabo entre as pernas.
Clean Code! O “Uncle” Bob tem exatamente essa perspectiva.
Assunto polêmico… mas não menos importante, nos faz para para pensar nos códigos que escrevemos todos os dias e o que estamos fazendo, certo? errado? Tudo depende!
Quanto a atender um propósito, se escrevemos código sem propósito, é melhor não fazê-lo, afinal, não faz sentido…
E a ordem? Se temos em mente que um código deve ser fácil de entender e de alterar, estaremos mais perto do propósito. Por exemplo, um prédio terá vários andares, mas o mais importante é a fundação, senão o resto do projeto será comprometido.
Sempre penso que não é simples escrever código, ainda mais, fáceis de entender e alterar, mas que isto são os pontos importante, assim como ser enxuto, pois sempre teremos alterações futuras, nenhum código é escrito e nunca mais modificado.
Ao colocarmos o propósito em primeiro lugar, acabamos escrevendo códigos de difícil compreensão e alteração, pois teremos o foco no propósito e não do futuro que teremos que alterar e entender tudo que foi escrito.
Se pararmos para pensar, normalmente é o que acontece, “qual é o propósito? Ah blz, vamos fazer”, depois disto, mãos na massa e nem se pensa no que está sendo feito, tendo como o principal fator para desculpas: o tempo; “Ah não tivemos tempo para fazer”, “Muita pressão cara!”, etc.
Sinceramente, a ordem que traçou é ótima, mas precisamos nos aperfeiçoar para conseguirmos chegar até ela. Não é apenas sentar e escrever código, mas pensar em como escrevê-lo melhor e para isto é necessário conhecimento, lembrar que está escrevendo código não apenas para você, que ele irá crescer e que se não fizer direito uma hora não será mais possível continuar.
Acredito que o código incrível esteja muito relacionado ao seu humor, inspiração, satisfação, amor pelo que está fazendo.
Deixo uma frase do livro Code Clean:
”Um código limpo sempre parece que foi escrito por alguém que importava. Não há nada de óbvio no que se pode fazer para torná-lo melhor. Tudo foi pensado pelo autor do código, e se tentar pensar em algumas melhorias, você voltará ao início, ou seja, apreciando o código deixando para você por alguém que se importa bastante com essa tarefa.”
Para mim, perfeito!
Lindo!
A questão do código que funciona tem haver com tentar tirar o cliente falando (“gritando”, às vezes) no seu ouvido, e do código bom tem haver com garantir que ele não voltará para gritar no seu ouvido amanhã. – O primeiro e custo de manutenção o segundo é investimento.
A questão na minha opinião é mais simples, ao tentar sempre atender o proposito do cliente ao criar um código muitas vezes esquecemos de atender necessidades técnicas para a boa fluidez do projeto. Um código limpo, bem escrito e simples deve vir antes do proposito do código por que os propósitos podem ser modificados se o cliente alterar as regras de negocio por qualquer motivo e ai teremos um problema por que se precisar alterar o proposito de um código devido a uma alteração, será mais rapido e facil se você tiver um código simples, claro e preciso. Tente alterar regras de negocio em um código onde você simplesmente nem sabe o que faz o que, é complicado e as vezes impossivel, forçando a recriar muita coisa. O ideal no meu ver é sempre, antes de tudo, planejar a maneira de como codificar e depois codificar.
Se pensarmos em proposito existe propositos técnicos propositos de negocio. Os propositos técnicos , que incluem a legibilidade, fluidez, simpliidade do código vem antes do proposito de negocio na minha opiniao, por que se estrutar bem o código a atender a parte técnica, naturalmente o negocio será bem atendido.
“Antes de construir a cobertura de um prédio, cria-se primeiro os alicerces e é melhor que esses alicerces estejam bem construidos” .
Considerando os comentários já colocados aqui, eu colocaria no item 1 o código que atende ao seu proposito, mas no item 2 colocaria o código fácil de alterar, porque acredito que isso é (um pouco) mas importante que o código ser fácil de entender. As experiências que tive até hoje me levaram a crer que mexer na estrutura é quase inevitável para evoluir, e quem faz isso nunca é um desenvolvedor junior.
Pra mim um código incrível é o código que resolve um problema incrível com performance e legibilidade. Com a performance como objetivo principal. (O código funcionar e resolver o problema não entra na lista por serem óbvios)