Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
Para a obtenção dessas características, é necessário um esforço e que exista um relacionamento entre elas, uma influencia na outra. Por exemplo: as otimizações de desempenho frequentemente reduzem a legibilidade e a mantenabilidade.
Na fase de implementação, a preocupação é com a correção, a eficiência, a fle- xibilidade dos aspectos executáveis para o modelo que está sendo desenvolvido. Podemos utilizar algumas ferramentas nesta fase, por exemplo: compiladores, interpretadores, editores, depuradores, geradores de código, geradores de tes- tes, formuladores de código, analisadores etc.
ESTILO DE PROGRAMAÇÃO E CODIFICAÇÃO
Um fator que é essencial para a obtenção de um código claro e que ofereça facili- dade de manutenção é a boa utilização dos mecanismos presentes na linguagem adotada que são os estilos de programação e codificação.
É importante para a empresa adotar estilos ou padrões de codificação. Estes estilos fornecem e especificam algumas regras de: atribuição de nomes de variá- veis, endentações e estilos de comentários entre outros. Isto é importante quando se trabalha em equipe e quando outros programadores estiverem realizando a depuração ou a manutenção de seu código posteriormente.
Muitos programadores, geralmente, trabalham em equipe, necessitando se integrar, testar e muitas vezes alterar os códigos que são produzidos por outros programadores. Por isso, é importante que haja padrões de codificação para a fase de implementação. Tais padrões devem ser seguidos por todos os progra- madores, de modo que o código e a documentação sejam claros para quaisquer membros da equipe.
A seguir vamos ver algumas questões importantes que devem ser utilizadas e que podem afetar o estilo das codificações, conforme Tsui e Karam (2013, p. 136):
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
Atribuição de nomes: essa questão refere-se à escolha de nomes que serão usados em variáveis, classes, métodos e outros elementos de programação. Outro ponto importante é a consistência, assim, procure utilizar sempre nomes com a mesma palavra ou abreviação para um dado conceito e evite usar o mesmo nome ou abreviação para conceitos diferentes.
Separação de palavras e utilização de maiúsculas/minúsculas: em muitos casos, um nome poderá ser composto por mais de uma palavra e em algumas linguagens de programação possuem diferentes convenções para combinar as palavras para um identificador. Assim, seria recomendado que se utilizasse as convenções-padrões para a sua linguagem.
Endentação e espaçamento: se refere ao acréscimo de espaços horizontais antes de algumas linhas para melhorar a estrutura do código. Para muitos, é um erro do programador iniciante não endentar o código de forma apropriada. A endentação afeta a legibilidade e a mantenabilidade do código.
Tamanho da função/método: códigos com grandes funções ou métodos são mais propensos a erros do que os menores até certo ponto, pois, às vezes, méto- dos muitos pequenos podem gerar muitos erros também.
Questões de atribuição de nomes de arquivo: uma das grandes vantagens quando se adota um padrão é especificar como devem ser atribuídos os nomes de arquivos, assim a localização de todos os elementos é facilitada.
Elementos particulares de programação: temos várias linguagens de pro- gramação diferentes e que suportam recursos diferentes e muitos destes recursos são considerados perigosos.
“Um abordagem de bom senso para a implementação: mantenha simples, ajuste para satisfazer as necessidades locais, e certifique-se de que tudo agregue valor.”
©shutterstock Comentários Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
COMENTÁRIOS
Conforme Tsui e Karam (2013, p. 136), “os comentários são muito importantes e podem ajudar ou prejudicar significativamente a legi- bilidade e a mantenabilidade”. Neste caso, quando usamos os comentá- rios durante o desenvolvimento, podem surgir alguns problemas, por exemplo:
■ Eles podem desviar a atenção
do código e tornar o código mais difícil de ler.
■ Eles podem estar errados, aumentando a incidência de erros.
Outro caso que pode ocorrer, os comentários podem ficar desatualizados con- forme os códigos vão mudando e com isso, criando novos erros. Isso porque, eles podem estar errados desde a primeira vez e como não são testados e atua- lizados, a funcionalidade pode ter mudado.
Os textos das mensagens são mais voláteis que o código da aplicação. Du- rante o período de implantação, as mensagens tendem a ser alteradas para serem mais bem compreendidas pelo usuário. Uma boa prática é armaze- nar estas mensagens fora do código fonte da aplicação. Isto permite que os textos sejam alterados sem que a aplicação seja compilada novamente. Além disso, os erros de negócio mostrados para o usuário devem estar na linguagem utilizada pelo usuário. Isto implica que o mecanismo de mensa- gem precisa armazenar os textos das mensagens em diversas linguagens, o que contribui para a utilização de um repositório que armazena essas men- sagens.
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
Apesar de alguns problemas, os comentários podem ajudar a esclarecer o código, assim como outras fontes relacionadas a ele. Entretanto, é preciso des- tacar que eles representarem algum nível de duplicação do código, em certos momentos. Um comentário que não possui relação ao código o qual ele foi inse- rido pode causar muitos erros que se tornam difíceis de encontrar e corrigir.
Para Tsui e Karam (2013, p. 136), os comentários podem ser definidos nos seguintes tipos:
Repetição do código: comentários que normalmente são feitos por pro- gramadores novatos. Para não gerar confusão, devem ser evitados, pois são um desperdício de esforço e irão distrair os leitores.
Explicação do código: alguns programadores costumam explicar na lin- guagem o que o código faz, em casos de códigos complexos. Mas em quase toda situação, se o código é muito complexo que exija uma explicação, ele deve ser revisado.
Marcador no código: muitos programadores utilizam marcadores para indicar que está com itens incompletos, para indicar mudanças ou quem fez as alterações. Neste caso, é recomendado que seja usado um gerenciador de ver- são para controle.
Resumo de código: são muito úteis para que os programadores enten- derem o código, desde que estejam sempre atualizados. Esse resumo, sempre atualizado, eliminará a necessidade de comentários ao longo do código, o que dificulta a manutenção.
Descrição do objetivo do código: são os comentários mais úteis, pois ele descreve o que o código deve fazer e não o que ele faz. Neste caso, se o código não fizer o que foi descrito, ele estará errado.
Referências externas: usados para vincular comentários a entidades exter- nas, como por exemplo, livro, outros programas ou a existência de dados de inicialização nas tabelas do banco de dados.
Comentários Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
Os comentários podem mostrar outro problema sério, podem ser utiliza- dos para justificar as práticas de codificação inadequada. Muitos programadores podem produzir códigos excessivamente complexos e difíceis de dar manuten- ção, com isso vão acrescentando comentários em vez de revisá-lo e reescreve-lo usando um bom padrão.
Conforme Tsui e Karam (2013, p. 136), muitos especialistas recomendam que se evitem os comentários em excesso e que os programadores devem buscar incluir os comentários em seu lugar e, especialmente, na forma da descrição da intenção do programador. Para isso, encoraje os programadores a utilizar bons nomes e boas práticas de programação, reservem os comentários para referên- cias externas e declarações de intenções e no caso de códigos mais complexos, que não podem ser revisados, recomendar a utilização de comentários de resu- mos, que são mais fáceis de fazer a manutenção.
Durante a execução de uma atividade, alguns erros podem ocorrer. O usu- ário que iniciou a atividade precisa ser informado sobre o que deu errado. O recurso de tratamento de exceções das linguagens é um avançado meca- nismo que auxilia neste controle de erros e de mensagens. É necessário es- tendê-lo para criar um mecanismo capaz de controlar exceções de negócio. Erros de variáveis não inicializadas, de tipos incompatíveis de dados, de índi- ce inválido de vetor, entre outros, são erros da linguagem que devem ser se- parados dos erros de negócio, que seriam: erro ao iniciar um processo; erro ao executar um serviço; erro ao registrar a movimentação na conta; erro de saldo insuficiente para a operação. Geralmente, erros de linguagem revelam bugs da aplicação, enquanto que erros de negócio revelam inconsistência nos dados da aplicação ou dos parâmetros fornecidos para algum processo.
©shutterstock Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
DEPURAÇÃO
Conforme Tsui e Karam (2013, p. 139), “depuração é o ato de localizar e corri- gir erros no código. Os erros geralmente são descobertos através de testes, mas podem ser encontrados por outros meios, incluindo as inspeções de códigos e por meio do uso normal do programa”.
Depurar é considerado um processo usado para reduzir ou encontrar bugs no seu sistema. De uma forma geral, depurar o código não é uma tarefa fácil de ser execu- tada. Um dos motivos, é que podem ocorrer muitas variações que podem vir a atrapalhar esse processo, um exemplo é a linguagem que está sendo utiliza e ferramentas disponíveis para fazermos a depuração de um código.
Mas devemos tomar cuidado, pois depu- rar é um processo iterativo. Você estará criando possíveis hipóteses em cima do erro, criando possíveis testes para pro- var estas hipóteses, podendo alterar o código para corrigir os erros encontrados. Mas caso essas hipóteses sejam falsas pode ser necessário voltar atrás e iniciar o processo com novas hipóteses.
Tsui e Karam (2013, p. 139) identificam quatro fases no processo de depu- ração e elas podem ser resumidos da seguinte maneira:
Estabilização (reprodução): nessa fase reproduzimos o erro em uma confi- guração particular, no caso, a máquina do programador e assim verificar os erros que estão ocorrendo. O mais importante desta fase é a identificação do erro e das condições em que ele ocorre. Os resultados dessa fase são um conjunto de testes que reproduzem o erro várias vezes, desde situações mais simples. A fase de estabilização pode ser considerada muito difícil às vezes, pois podem ocorrer erros aleatórios, que ao serem testados mais de uma vez, produzem resultados diferentes.
Depuração Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
Localização: nessa fase ocorrem as descobertas de seções do código que podem levar aos erros. Esta fase é a que envolve a parte mais difícil de ser veri- ficada. Mas se a fase de estabilização encontrar situações de testes, a fase de localização se torna mais fácil e mais óbvia.
Correção: nessa fase o processo de correção envolve possíveis alterações do código para a correção dos erros, desde que tenha ocorrido antes a estabiliza- ção e a localização do que causou os erros, melhorando as chances de corrigi-lo. Caso tente corrigir os erros de forma aleatória pode ser que sejam introduzi- dos novos erros.
Verificação: nessa fase é feita as verificações e certificações de que o erro realmente foi corrigido. Também é verificado que não há outros erros que pos- sam ter sido introduzidos no código durante a alteração. Pois, uma alteração no código não corrigirá o erro e ainda poderá introduzir novos erros.
Segundo Tsui e Karam (2013, p. 139) “erros em um programa podem ser categorizados em erros de sintaxe e erros lógicos”. Em linguagens compiladas os erros de sintaxe tendem a ser fáceis de encontrar, pois o compilador irá detectar e ele irá fornecer informações sobre a sua localização, apesar de os compilado- res não possuírem uma linguagem clara.
Mas para facilitar a depuração, já que ela possa ser considerada uma tarefa muito complicada, existem algumas ferramentas que podem te ajudar no pro- cesso de depuração. Conforme Tsui e Karam (2013, p. 139) são elas:
■ Comparadores de código-fonte: ajudam a encontrar as alterações no código.
■ Verificadores Ampliados: usados para encontrar problemas com sin- taxe, lógica e estilo.
■ Depuradores Interativos: permite que sejam verificadas as variáveis, esta- beleça pontos de interrupção, saltar em pontos de seu código.
■ Bibliotecas especiais: construídas para reimplementar as bibliotecas padrão, possuem segurança extra, para detectar e evitar erros.
■ Traçadores de perfil: ferramentas que descrevem as pré e as pós-condi- ções, ferramentas de cobertura que ajudam nos testes.
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
A depuração é uma tarefa importante a fim de evitar erros e, consequentemente evitar uma necessidade de transformação total do código depois de pronto. O programador ao utilizar uma ferramenta de depuração possui uma ajuda extra, pois uma ferramenta que só precisa configurar um breakpoint corretamente e seguir os passos para a depuração faz com que não ocorra perda de tempo. Ou seja, a depuração é algo rotineiro na vida dos programadores e algo importante, pois ajuda sempre a descobrir os erros.
Por que a depuração é tão difícil? Com toda certeza, a psicologia humana tem muito mais a ver com a resposta do que a tecnologia de software. No entanto, algumas características dos erros fornecem alguns indícios: 1. O sintoma e a causa podem ser geograficamente remotos. Isto é, o sinto- ma pode aparecer em uma parte de um programa, enquanto a causa pode realmente estar localizada em um ponto muito afastado.
2. O sintoma pode desaparecer (temporariamente) quando outro erro for corrigido.
3. O sintoma pode ser causado por erro humano que não é facilmente ras- treável.
4. O sintoma pode ser um resultado de problemas de temporização, e não de problemas de processamento. Pode ser difícil reproduzir com precisão as condições de entrada.
[...]
7. O sintoma pode ser intermitente. Isso é particularmente comum em siste- mas embutidos que acoplam hardware e software inextricavelmente. 8. O sintoma pode ocorrer devido a causas distribuídas por várias tarefas, executando em diferentes processadores.
©shutterstock
Asserções e Programação Defensiva
Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.