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

Retirar um arquivo do publish no visual studio

Hoje aprendi: Como retirar um arquivo do publish no visual studio

O Visual Studio possui um recurso chamado "Publish", que permite configurar o destino de um código compilado para que esse código seja usado em uma publicação.

Uma aplicação, seja ela Asp.Net ou qualquer outra tecnologia, pode utilizar o recurso de publish do Visual Studio. Porém, nem todos os arquivos são arquivos necessários para a execução da aplicação.

Existe uma opção no publish que, se habilitada, gera apenas os arquivos necessários para executar a aplicação. No entanto, existem arquivos que, por motivos particulares, não queremos que sejam enviados para o destino. Um exemplo? Blz, lá vai:

Quero publicar em uma pasta física arquivos que posteriormente serão enviados para outra pasta no servidor de aplicação. Mas eu não quero que meu web.config vá junto pois no servidor de aplicação existe um web.config que é constantemente alterado pelo sysadmin. Então, para evitar que eu acabe por esquecer o web.config e ele seja copiado para o servidor de aplicação, posso configurar para que o web.config não seja copiado no publish.

Alguém: "Ta certo, mas como faço isso ?"

----- OBSERVAÇÃO -----
-- A informação abaixo é muito complexa, tente ler com bastante atenção --
-----

Com o projeto aberto no visual studio, botão direito no arquivo web.config > propriedades > na opção "build action" altere o valor de "content" para "none". PRONTO !!! O arquivo não será mais enviado para a pasta de destino quando utilizarem o publish xD.

Enfim, resolvi postar isso depois de descobrir que um colega passou 2 anos copiando um arquivo manualmente para a pasta de destino, pois em algum momento alguém configurou para "none" esse arquivo. rsrs

É isso :D