quarta-feira, 13 de dezembro de 2017

Convenções e padrões no desenvolvimento de software

Porque é importante respeitar as convenções e padrões no desenvolvimento de software ?

Tenho certeza que a grande maioria de nós, principalmente a galera de .Net (explicarei) já presenciou nomes de classe em lowercase, propriedades em uppercase, variáveis que iniciam com "o" (exemplo: var oPessoa = new Pessoa();) e outras coisas que até causam arrepios. Ocorre que grande parte dessas nomenclaturas foram herdadas de linguagens interpretadas como php ou asp, e infelizmente, pessoas que vieram dessas tecnologias, trouxeram esse costume e acabaram por cometer esses erros (muita gente não vai gostar de ler isso, mas tentarei ser o mais claro possível).

- Primeiro vou explicar o porque eu disse "principalmente a galera de .Net":

Java, diferente de .Net, não teve uma linguagem "antecessora". Ou seja, não existiu uma linguagem anterior (um ASPZÃO) para criar vícios nos desenvolvedores.
Por muito tempo, a comunidade Java se preocupou em estabelecer um padrão, definir uma convenção - https://www.devmedia.com.br/convencoes-de-codigo-java/23871 - para possíbilitar que outras pessoas possam colaborar com a grande quantidade de bibliotecas que eram criadas e distribuidas na internet.

Observando o mundo microsoft, sejá usando VB ou C#, é possível lembrar quando surgiu o .Net Framework. Muitas pessoas buscando treinamentos, lendo sites para conhecer esse tal de .Net Framework que prometia acabar de vez com o bom e velho ASP. Então, essa galera do ASP, entrou de cabeça no .Net - seja com VB ou C# -, e trouxeram com eles as "PROPRIEDADES", "nomes_de_classes", ou "oVariaveis" e tudo mais que eles estavam acostumados a ver e colocar em pratica naquele mundo muito louco. Naquela época, não existia preocupação com convenções. As linguagens eram interpretadas. Eu não disponibilizada minhas bibliotecas para a comunidade. Eu não "versionava" meu código (meu git ou tfs era a pasta de produção onde o IIS fazia a leitura dos arquivos rsrs). Então, por esses motivos e também por motivos particulares ou misticos, é comum encontrar softwares dentro do mundo Microsoft com nomenclaturas totalmente fora da convenção.

Alguém diz: "Blz, falou falou falou e não falou nada... Quem disse que essa tal de convenção ai é a correta ?"

Bom, obviamente eu não fui. Mas essa convenção, padrão ou seja lá como quiser chamar, foi extrair do .Net Framework. Ou seja, a Microsoft já possui um padrão, tudo que a comunidade de desenvolvedores fez, foi extrair, documentar e difundir esse conhecimento com o objetivo de fazer o que a galera de Java já faz por anos: Padronizar a forma como um código é escrito.

Lembro da frase de um antigo colega/líder/coordenador/gerente: "Eu quero olhar para esse código e não saber quem foi que escreveu!" (by F.M.).

Bom, antes que eu clique no publicar e não coloque aqui a convenção que tanto falei, segue o link: http://www.dofactory.com/reference/csharp-coding-standards.

Vale ressaltar que nem eu, nem esse site ai são os donos da verdade. Basta observar atentamente a nomenclatura dos métodos, propriedades, variáveis, constantes, variáveis de contexto, etc... que existem no Framework .Net ou na própria documentação da Microsoft. Fazendo isso, garantimos que o próximo que pegar nosso código, terá condições de entender e seguir o mesmo padrão.

Alguns benefícios de criar e mantar convenções:

  • A palavra padrão começa a fazer sentido.
  • O código pode facilmente ser mantido por qualquer um e não apenas pelo criador.
  • Fica simples saber quando estou olhando para uma propriedade, um método, ou uma variável.
  • Aumento de produtividade, pois não é necessário perder tempo tentando entender o que aquele código significa.
  • Minimiza o custo com suporte em uma transferência de propriedade.
  • Demonstra respeito para com o próximo.


Bom, acho que consegui explicar a importância de utilizar convenções e padrões no desenvolvimento de software. Se você não faz isso hoje, não tenha vergonha. Começe agora mesmo. :D

Ah, só pra não esquecer: http://www.dofactory.com/reference/csharp-coding-standards

Nenhum comentário:

Postar um comentário