Autor: Ricardo Boaro

GDK duster

A GDK empresa com sede na Holanda e Inglaterra esta iniciando as suas atividades no Brasil.

A empresa presta serviço de desenvolvimento de software, consultoria, e treinamentos oficiais Delphi. Tambem contamos com desenvolvimento utilizando Mendix.

A partir de 2022 a empresa terá seu escritório na cidade de Rio Claro-SP.

Eu tenho a honra de fazer parte desse time a alguns anos trabalhando para a filial de Londres.

Estou a disposição para maiores informações.

r.boaro@gdksoftware.co.uk

A GDK Software é uma empresa Holandesa com filiais na Inglaterra e em breve no Brasil, entre os serviços e produtos oferecidos pela empresa temos essa ferramenta fantástica chamada de GDK-Duster. Ela foi idealizada e desenvolvida com o objetivo de facilitar o processo de migração de softwares escritos em versões antigas do Delphi para a última versão, no dia em que estou publicando esse post o Delphi esta na versão 11.

Eu a participei de vários projetos de migração de softwares para as novas versões, a grande maioria deles oriundas do Delphi 7. Então eu posso falar com propriedade que não é uma tarefa fácil e muito menos rápida.

Quando eu comecei e trabalhar na GDK, meus colegas contavam histórias de clientes que contrataram a GDK para migrar seus projetos antigos e o quanto o GDK-Duster agilizava o processo. Confesso que não acreditei a ter precisar migrar um projeto de um cliente com um código fonte com mais de 1 milhão de linhas.

Se fizermos essa migração sem a ajuda do Duster, com certeza podemos pensar em algumas semanas de trabalho full-time até concluir a migração. Acreditem ou não com o GDK Duster eu fiz essa migração em menos de uma semana.

Um problema comum para as empresas relacionado a migrar seu código fonte, é que o código antigo não para de ser alterado, você precisa continuar atendendo a demanda dos seus clientes. Mesmo que você tenha mão de obra disponível para ficar dedicada ao projeto de migração o tempo necessário para que a migração seja concluída, e as frequentes manutenções do sistema atual, inviabilizam o processo.

Sendo assim convido a vocês a conhecer o GDK-Duster, o vídeo abaixo foi apresentado recentemente em um Dev Lounge da Embarcadero.

Para mais informações sobre a GDK-Software e como receber um orçamento para migrar o seu software sem compromisso, por favor mandem um e-mail para:

rboaro@rboaro

r.boaro@gdksoftware.co.uk.

Att; Ricardo.

Argumentos das Funções

Seguindo a nossa série de artigos sobre bons códigos, não podemos deixar de falar sobre a quantidade de argumentos das funções. Ou seja os famosos parâmetros.

Não poderia falar desse assunto sem destacar a importância de utilizarmos a palavra Const antes do parâmetro caso o mesmo não seja alterado dentro da função.

Ex: function somar(const aValor1, aValor2: Double): Double;

Declarar parâmetros como const evita que seja feita uma cópia do valor do parâmetro para a memória armazenando apenas a referencia do mesmo. Sendo assim temos um processamento mais rápido e menos consumo de memória.

Quanto a quantidade de parâmetros de uma função, seguem alguns tipos de funções referente aos seus parâmetros, uma função sem nenhum parâmetro é conhecida por niladic. Uma função com um parâmetro é conhecida por monadic, seguida pela dyalic que são as funções com dois parâmetros. Três parâmetros são conhecidos por triadic e devem ser evitadas sempre que possível. Mais do que três parâmetros a polyadic devem existir apenas em situações especiais e devem ter uma justificativa.

Parâmetros são uma das chaves para o bom entendimento de uma função, lembramos que o nome do argumento deve ser claro e ser de fácil entendimento para quem estiver lendo seu código. A quantidade de parâmetros com certeza vai dificultar o entendimento e a execução das funções de teste. Ainda iremos falar sobre TDD, ou testes unitários.

Ainda sobre parâmetros evitem utilizarem parâmetros Output, pois eles normalmente são difíceis de entender, e obrigam ao leitor do código acessar a função e entender o que será feito para que esse parâmetros retorno.

Funções com parâmetros Flag.

Funções com parâmetros flags por exemplo do tipo boolean são feios, não sendo uma prática recomendada pois isso complica a assinatura do método. Sendo assim fiquem atentos a essa pratica.

Conclusão

Nos últimos artigos falarmos bastante sobre funções, a atenção que devemos ter para nomeá-las, o cuidado com a quantidade de parâmetros e todos os detalhes que destacamos. O importante agora é começarmos a colocar em prática o que aprendemos. De nada adianta aprender algo novo e continuarmos cometendo os mesmos erros. Lembre-se, ser um programador é estar em constante evolução, por mais que você ja tenha mais de 20 anos de experiência, é importante continuar estudando, pois a tecnologia muda rapidamente e estudando é difícil de acompanhar, imagina passar um ano sem ler um livro atualizado sobre tecnologia.

Bons códigos a todos, no próximo artigo começarmos a falar sobre comandos SQL.

Funções

Para que possamos ter um bom código é imprescindível que sigamos algumas regras básicas de códificação. É importante lembrar que toda regra foi criada depois de muitos anos de observação, estudo e por pessoas com muita experiência em programação. Independente de linguagem de programação, IDE e até mesmo tipo de software que você esta escrevendo, essas regras são imutáveis.

Obviamente sabemos que o Delphi é a melhor opção independente de tipo de software ou tamanho de empresa. Simple the best! Não concorda comigo? Sem problemas aceito a sua não concordância, eu falo pelos meus 25 anos de experiência e alegrias com essa IDE, tudo que tenho hoje e todas as vitórias profissionais que conquistei devo ao Delphi. Então me permitam alguns momentos de exaltação a minha IDE.

Voltando ao foco, concordamos que um código limpo é bem escrito do início ao fim, concordamos que precisamos seguir algumas regras e por fim concordamos que para que tudo isso seja possível pesquisa e estudo são necessárias. Então falando sobre funções, vamos a algumas considerações e regras.

A primeira regra para uma função é que ela seja pequena, a segunda regra é que ela deve ser menor do que isso. Eu não posso ser cínico ao ponto de dizer que sempre escrevi funções pequenas, comecei com desastrosas funções de centenas de linhas, outras menos terríveis com dezenas de linhas e algumas louváveis funções com no máximo 30 linhas.

O que aprendi em todos esses anos é que as funções devem ser pequenas. Quando comecei a programar aprendi que uma função, não deveria ser maior do que o tamanho da tela, ou seja não deveria ser necessário rolar a tela para ler uma função inteira. Contudo é importante lembrar que nessa época nos anos 90 trabalhávamos com monitores onde apareciam 30 linhas e 80 colunas. Se seguirmos a regra do tamanho dos monitores, hoje podemos ter centenas de linhas visíveis em uma função.

Funções não deveria exceder 30 linhas, alguns livros falam em no máximo 20 linhas por função, então estou dando um desconto de mais 10 linhas.

Blocos e Identação

Uma dica para refatorar grandes funções, seria criar funções em códigos que estiverem entre o begin end de declarações de if, case etc. Lembrando que o Delphi nos oferece um excelente refactor, e no caso de extrair códigos para criar funções temos o extract method, seu atalho é CTRL + SHIFT + M, selecione o bloco de código que deseja criar uma função, pressione as teclas de atalho ou acesse o menu Refactor | Extract Method e veja a mágica acontecer.

Fazer apenas uma coisa

Literamente e diretamente, uma função deve ser responsável por apenas uma coisa. Aqui podemos fazer uma analogia aos princípios do SOLID, que foi criado para classes. Em português a letra S significa princípio da responsabilidade única. Então lembre – se disso, crie funções com uma única responsabilidade.

Um nível de abstração por função

Para termos certeza que nossa função esta fazendo apenas uma coisa devemos ter certeza que nossa função possua apenas um nível de abstração. Misturar níveis de abstração dentro de uma função a torna sempre mais confusa e difícil de entender.

Para encerrarmos esse artigo sugiro analisarmos nossas funções com um senso crítico suficiente para diminuirmos o tamanho delas. Dividir uma grande função em várias pequenas funções é o primeiro passo para limparmos nosso código.

Bons códigos a todos nos vemos no próximo artigo onde falaremos sobre cases.

Continuando nossa série sobre código limpo, hoje vamos iniciar falando sobre as premissas do código limpo, quais regras devo seguir para que meu código possa ser considerado limpo e um bom código?

Use nomes reveladores da intenção

É fácil de entender que nomes de classes, métodos, variáreis, records, types etc, devem revelar a intensão do mesmo. Lembrem se que tudo que você lê no seu código deve deixar-lo feliz, por passar um entendimento claro do que esta acontecendo.

Eu outras palavras nomes de variáveis e métodos devem responder a seguinte questão. O nome deve revelar por que ele existe, o que ele faz e como ele faz, simples assim, pergunte-se após criar um novo método se isso esta claro. Se o nome requer um comentário então o nome não revela a intensão do método ou variável.

Evite nomes que revelam pistas falsas

Recentemente encontrei um nome de variável em um determinado método que recebia o resultado de um cálculo, o interessante é que nome da variável era, valorMenor. Provavelmente em algum momento essa variável foi utilizada para receber o menor valor do cálculo, mas por descuido ou desleixo foi alterado o método e ela passou a receber o resultado que poderia ser maior ou menor;

Outro exemplo que dificulta muito a leitura de um código é utilizar nome de métodos, variáveis, classes etc. preenchendo o mesmo com letras lowercase. Por exemplo, calculamedia, não seria mais fácil de ler se escrevesse-mos CalculaMedia? ou mesmo calculaMedia? Detalhes importantes que fazem toda diferença no momento da leitura do código fonte.

Faça Distinções Significativas

Programadores criam problemas para eles mesmo quando eles escrevem um código unicamente para o compilador interpretar. Se você precisar criar uma classe para receber informações e dados de produtos por exemplo, você deve evitar criar classes assim: TProduto1 = class e TProduto2 = class, ao invés disso crie, TProdutoData e TProdutoInfo. Parece óbvio mas encontro muitas coisas sem sentido por aí.

Use Nomes Pronunciáveis

Se você pode pronunciar o nome de uma variável ou classe então você pode discutir sobre ela sem parecer um idiota tentando pronunciar algo sem fonética.

Use Nomes pesquisáveis

Letras simples, números soltos tem um problema ao serem pesquisados pois não são fáceis de visualizar no código fonte. Eu particularmente prefiro usar nomes curtos para variáveis como letras soltas em variáveis locais onde o escopo de visibilidade seja pequeno. Nomes de Fields de uma classe por exemplo devem ser claros e de fácil localização.

Nome de Classes

Nome de classes e objetos devem ser substantivos, como Customer, Page, Account. Evite usar palavras como Manager, Processor que são verbos. Detalhe importante que facilita a leitura do seu código fonte e o entendimento da funcionalidade do objeto.

Nome de Métodos

Ao contrário das classes métodos devem ser verbos, como postPayment, deletePage, Save, Processar etc. Jamais esqueçam de seguir o nome padrão para métodos que retornam algo, usando Get ou Retorno. e Set ou Setar para os que definem valores.

Ao trabalhar com propriedades considere utilizar uma declaração simples sempre que não for necessário manipular o valor no Get ou no Set. Exemplo:

property Salario: Integer read FSalario write FSalario;

Use Nomes Inteligentes

Lembre que as pessoas que irão ler seu código são programadores portando vá em frente e use termos conhecidos pela computação, nomes de algoritmos, nomes de patterns, termos matemáticos e assim por diante.

O nome AccountVisitor significa que o programador esta familiarizado com o Visitor Pattern e assim por diante, o objetivo é sempre facilitar o entendimento do método. Um grande amigo uma vez me disse que um método bem nomeado é aquele que você sabe o que ele faz somente lendo seu nome.

Considerações Finais

É difícil pensar sobre escolher bons nomes que sejam fáceis de ler e que compartilhe com facilidade o objetivo daquele método, contudo precisamos ficar atentos a nome redundantes, principalmente de variáveis, algo que me deixa frustrado é ler em um com variáveis nomeadas com. Resulta1, Resultado2, Resultado3. Sem chance meus amigos, vamos colocar nossa cérebro para funcionar, tenho certeza que podemos fazer melhor do que isso. A partir do próximo artigo iremos começar a falar sobre métodos iniciando pelas funções e algumas regras de ouro para mantermos um código limpo.

Vejo vocês em breve, bons códigos a todos!

No artigo anterior falamos um pouco sobre analise de requisitos e o que nos leva a escrever um código ruim. Lembrei agora da citação de um amigo de longa data que disse uma vez em uma de suas palestras. “O código de nossa aplicação é como o nosso sangue, se nosso sangue estiver ruim com certeza ficaremos doente”. Eu sempre lembro dessa frase quando estou trabalhando em um código com problemas, ou escrevendo algo novo.

Entendemos até aqui a importância de escrevermos um código limpo. Então chegou o momento de nos perguntarmos, será que nós realmente sabemos o que é um código limpo? Gosto de pensar que um código fonte é como uma pintura, uma obra de arte, cada um de nós pode interpretar de uma maneira, o importante para que tenhamos um julgamento correto é entendermos o código. Reconhecer a arte é um dom e requer tempo de análise. A má noticia que bem ou mau todos nós sabemos pintar.

Escrever um código limpo requer disciplina, começar a aplicar pequenas regras e ser meticuloso linha a linha é um bom começo. Todo programador precisa ter um bom senso de código, pois a maioria consegue identificar um código ruim, mas não sabe como escrever um código bom. Senso de código é uma habilidade que pode ser desenvolvida durante anos de trabalho. A má notícia é que esse profissional precisa ser dedicado aos estudos e procurar melhorar sempre. So assim o senso de código será desenvolvido corretamente.

O que é Código Limpo (Clean Code)

Bjarne Stroustrup inventor do C++; Eu gosto do meu código elegante e eficiente. A lógica deve ser direto para ser difícil de esconder bugs, com o mínimo de dependências para facilitar a manutenção…

Quando Bjarne cita um código elegante ele quer dizer que o código deve ser fácil de ler, você precisa ler o código e entender o que ele faz sem muito esforço. Veremos mais para frente como pequenas alterações em nossas regras de codificação podem ajudar nessa tarefa.

Notem também outra chave para o sucesso em sua definição de um bom código, mínimo de dependência. Para os entusiastas da orientação a objeto essa premissa é básica. Lembram? Alta coesão e baixo acoplamento. Aqui esta a prova de que trabalhar utilizando técnicas de orientação a objeto é um bom começo para um código limpo.

Não posso deixar de chamar a atenção dos leitores da importância de entender e seguir de forma rigorosa as premissas da Orientação a Objeto. Infelizmente me deparo com códigos que são reconhecidos por seus criadores por serem escritos orientado a objeto que pecam em muitas dessas regras básicas. Não seguir as regras básicas de orientação a objeto é escrever um monstro, uma bagunça organizada, que será o pesadelo dos programadores que precisarem fazer manutenção nesse monstrinho.

Um código limpo é focado, cada função, cada classe, cada módulo expõe uma única funcionalidade que permanece nos detalhes.

Grady Booch, autor Object Oriented Analysis and Design with Application disse; Código limpo é simples e direto você lê como uma conversa bem escrita, o código limpo nunca esconde o objetivo, possui uma abstração nítida.

Big Dave Thomas fundador da OTI, pai do Eclipse descreve; Código limpo pode ser lido e melhorado por outros desenvolvedores sem dificuldades. Possui units de teste, e nomes destacando a funcionalidade. O código deve ser literal.

O que nos chama a atenção aqui é observarmos que ele chama a atenção para as units de teste. Preciso abrir um parênteses aqui e chamar a atenção dos leitores para que dediquem tempo a conhecer e estudar o TDD = Test Driven Development, desenvolver orientado a testes por assim dizer, garante uma qualidade no código e segurança na hora do deploy.

Sim você precisa de mais tempo para escrever seu código de forma que as classes de testes possam ser criadas automaticamente, TDD existe para todas as linguagens e IDE’s, no Delphi costumo utilizar o DUnit que é um framework para criar as classes de teste. Recomendo fortemente que tomem nota desse assunto e que se aprofundem nele. Existe muito material legal na Web para que você possam estudar. E obviamente surgindo dúvidas estou a disposição.

Michael Feathers, autor de Working Effectively with Legacy Code, nos diz; Eu poderia listar as qualidades que percebo em um código limpo mas existe uma que é mais abrangente. Um código limpo sempre foi escrito por alguém que se importa com a qualidade.

Penso que se importar com a qualidade requer um trabalho minucioso. Eu particularmente gosto de escrever uma função, testar, e olhar para ela alguns instantes, então me pergunto. O que pode ser melhor? Como poderia ser mais eficaz? Os nomes de variáveis e parâmetros dizem a quem ler essa função o que ela faz? São pequenos detalhes que muitas vezes apontam para falhas óbvias que não enxergamos pois estamos com todo contexto do projeto em mente.

Ron Jeffries, autor de Extreme Progaming Installed e Extreme Programming Adventure in C#; Recentemente eu criei algumas regras para um código limpo, são elas.

• Rodar todos os testes
• Não conter partes duplicadas
• Expressar todos os desejos e o objetivo da função
• Minimizar o número de entidades tal como classes, métodos etc.

Vamos fazer um breve resumo para encerrar a parte II dessa série. Código limpo é aquele que temos prazer em ler, ao analisarmos uma função sabemos exatamente que parâmetro precisamos passar para ela e o que ela irá retornar. Cada classe criada é especialista em uma única funcionalidade, e não depende de outras classes para funcionar. Dependência mútua entre classes, expressamente proibido.

Declaro aqui a minha segunda regra inalterável. Não pode haver dependência mútua entre classes!!!!!!

Ficamos por aqui, em breve teremos outro artigo da séria Código Limpo.

Obrigado pela atenção dos amigos leitores e Bons Códigos!

A partir desse pequeno artigo, pretendo abordar um assunto de suma importância para nós programadores. Como podemos identificar bons códigos? O que podemos considerar um bom código? Quais critérios precisamos utilizar para podemos dizer que o código esta limpo e pode ser considerado um bom código?

Sejam bem vindos a essa série de artigos, o objetivo de todo trabalho é estarmos habilitados a escrever bons códigos e aos poucos podermos nos considerar bons programadores.

Não irei atentar a frases bonitas bem elaboradas, utilizando a concordância verbal perfeita e a maneira mais polida de falar sobre os temas que irei abortar. Então me perdoem se não estiver a contento, conto com a compreensão de todos.

Vamos ao que nos interessa, irei separar em tópicos tudo que considerar importante para termos ao final do trabalho um bom código. Contudo, quero chamar a atenção dos amigos que escrever um bom código não se trata apenas de seguir as boas práticas de programação, aplicar corretamente os conceitos de programação orientada a objeto, ter uma identação perfeita etc.

Um bom código precisa ser eficiente, e atender ao requisito apresentado, precisa ser de fácil leitura, precisa estar organizado, precisa ser em outras palavras coerente. Então vamos falar do primeiro critério de avaliação para um bom código.

Análise de Requisitos

Sim, item fundamental para que não percamos tempo desenvolvendo algo errado por não entender qual resultado final nosso código deve gerar. Analisar os requisitos para determinada funcionalidade, vai além de dedicar alguns minutos pensando e partir para o código feito louco. Jamais façam isso, por mais que a ansiedade de começar a produzir código seja grande, lembrem-se que ao analisarmos os requisitos com calma, criarmos diagramas de sequência, listarmos as partes que serão afetadas, etc. Tudo isso já é estar produzindo. Então você jamais deve se considerar improdutivo se passar um ou dois dias fazendo a análise minuciosa do requisito, levantando dúvidas e entendendo a funcionalidade para então podermos escrever um código eficaz e legível.

Adicionar Funcionalidades ao Código

Não é raro estarmos trabalhando em determinado projeto com meia dúvida de requisitos listados, analisados, estudados, discutidos, e então começado a ser transcrito para o código da máquina, e um novo requisito aparece!

A capacidade de abstrair e entender o que o cliente precisa para dentro de um código é algo de suma importância, mas infelizmente não podemos prever novas ideias que o cliente apresenta no decorrer do projeto e que chegam a nós como um novo requisito a ser incorporado ao sistema.

Com certeza essa situação pouco a pouco se torna um grande pesadelo, pois teremos no mínimo dois impactos catastróficos por assim dizer. Primeiro, o prazo definido para a entrega do sistema dificilmente irá mudar, e voce estar atrasado. Segundo tentar adaptar a nova funcionalidade, por mais simples que pareça pode destruir nosso código. Nesse momento o bom código desaparece e a pressa para entregar no prazo aliada a necessidade de não falhar e fazer com que o requisito funcione com o menor esforço, obrigado os programadores a cometer um erro inadmissível. Criar uma pequena Gambiarra tenho certeza que os amigos ja conhecem essa palavra, e mais certeza de que um dia, vocês fizeram uma. Para atender um prazo, para facilitar sua vida naquele momento, etc. Motivos para uma que uma gambiarra seja feita normalmente não faltam.

Infelizmente uma leva a outra que leva a outra que caracteriza nosso código como um lixo. Sim estou sendo severo utilizando esse termo, mas se faz necessário para chamar a atenção do amigo(a) leitor(a) como é importante evitar essa abordagem. Afinal, quem irá fazer a manutenção no código? Provavelmente vocês, então quem irá se arrepender desse atalho? Com certeza vocês.

Então declaro aqui a minha primeira regra inalterável. Gambiarra Jamais!!!!!!

Eu entendo que muitas vezes estamos pressionados pelo chefe para terminar o projeto. Muitas vezes estamos pensando no backlog e em todas as outras coisas que voce prometeu fazer, afinal você quer ser um bom funcionário, talvez até receber um premio, bônus ou algo assim. Então você é aquele funcionário que diz “Sim Senhor” para tudo. Cuidado meu amigo isso pode lhe colocar em uma armadilha e obrigá-lo a escrever um código ruim para atender toda demanda.

Infelizmente o dia que esse código passar por uma análise e você for julgado como um mau programador por ter escrito um código ruim ou feito uma gambiarra, ninguém vai lembrar da quantidade de trabalho que você tinha e quanto estava produzindo deixando assim os chefes felizes. Lembre, em nossa profissão, tempo é dinheiro.

Finalizamos por aqui, em breve estarei publicando a parte II, meu objetivo é manter a sequência de um pequeno artigo por dia.

Até Breve e Bons Códigos a todos!