quarta-feira, 30 de setembro de 2015

Seis características presentes em todo bom software

Há muitas e muitas linhas de código sustentando sistemas ao redor do mundo. Para se ter uma ideia, apenas o Google soma mais de dois bilhões de linhas em sua estrutura. Mas nem todas fontes são criadas de maneira semelhante. 
Para descobrir o que faz de alguns códigos melhores que outros, buscamos a opinião de diversos desenvolvedores. Além disso, indagamos outros programadores para ver quais características esperam ou querem de um sistema no qual trabalharão. Com base nisso, listamos seis pontos que softwares “bem escritos” têm em comum.
É facilmente legível?
Os desenvolvedores parecem concordar que uma das qualidades mais importantes de um código é a sua legibilidade. Sistemas escritos de uma forma que podem ser lidos rapidamente por outros programadores são considerados um trabalho de alto nível.

“Sinto que se eu não consigo entender a intenção do autor do sistema em cinco minutos ou menos, o programador fez um trabalho ruim”, dispara Luke Burnham, engenheiro de software da Lionbridge. “Um código é escrito uma vez e lido muitas outras ao longo de sua vida útil”, adiciona, citando a necessidade de usar recursos que facilitem esse processo de leitura e entendimento.
Para um desenvolvedor de aplicativos web que pediu para não ser identificado, um bom código é aquele que “segue um estilo de codificação consistente (o espaçamento adequado, o recuo, o fluxo geral)”, disse. Ele também enfatizou a importância de escolher “nomes de variáveis” que fazem sentido de uma maneira geral.
Em resumo: mais legível significa mais compreensível e facilita a vida de todos. Assim, quanto mais rápido alguém poder compreender a estrutura, melhor.
Tem comentários úteis?
Além de boa formatação e “nomeação”, os comentários podem também tornar o código, em última análise, mais facilmente compreendido. Mas não apenas quaisquer comentários, como Burnham salienta. “Eu não preciso comentários para me dizer o que um loop faz. Preciso de comentários para me dizer por que o código está fazendo o que está fazendo”, afirma. “Para mim, um bom código tem comentários que explicam o que passou na cabeça do autor durante a construção”.

É simples?
O melhor código – e isso parece consenso – muitas vezes é algo simples. Bons programadores sabem como fazer o trabalho sem excesso, que compliquem demais as coisas. “... há uma correlação estatística comprovada entre a complexidade de código e bugs ...”, escreveu Neville Kuyt.

É flexível?
A funcionalidade de uma parte do código existente, muitas vezes, necessita ser alterada, expandida, ou reutilizada em outros lugares no futuro. É por isso que Burnham aconselha: “Bons softwares são escritos com as exigências tanto de hoje quanto com as perspectivas para futuro”.

Obviamente, prever o que está porvir é impossível. “Mas praticamente todo bom programador é capaz de criar um sistema flexível o suficiente que exija mudanças mínimas para acomodar novos requerimentos”, adiciona o engenheiro.
Código é bom se os desenvolvedores são capazes de "adicionar ou alterar certas partes do código sem ter que quebrar outras partes do código", comentou um desenvolvedor, que pediu para não ser identificado. “Você realmente saberá quando um código de alguém é bom mesmo terá que mexer nele”.
É sustentável?
Não importa quão bem um pedaço de código é escrito, inevitavelmente, ele terá bugs. "Obviamente alguém pode ter que corrigi-lo", disse Kevin Moylan, engenheiro de software na Genuine Interactive. "E a pessoa que fará isso pode ser você”.

Manutenção, então, é um atributo-chave de um bom código. Todo o código tem de ser mantido: não há necessidade de tornar essa tarefa ainda mais difícil do que o necessário. Portanto, evite fazer coisas como "valores que podem mudar (urls, teclas de acesso, senhas de banco de dados, etc)", escreveu o desenvolvedor anônimo.
Funciona?
Finalmente, há uma característica aparentemente óbvia de bom código de software que provavelmente deve ainda ser reforçada antes do final desse texto: ele precisa, efetivamente, funcionar. Em resumo, o sistema tem que fazer o trabalho para o qual foi projetado. “Não importa o quão grande ele se parece, se ele não fazer o trabalho, não é bom”, sintetizou Burnham.


Fonte: CIO

Nenhum comentário:

Postar um comentário