Palavra do Rei – melhores práticas em desenvolvimento de software (proposta de meme)
Na Myfreecom criamos uma série de regras que são o início do que virá a ser o conjunto de melhores práticas no desenvolvimento de software na empresa. “O Rei” é a inteligência superior resultante da opinião pessoal de cada um em relação a desenvolvimento de software.
Todos nós temos estas “melhores práticas” definidas em nossa mente, mas nem sempre elas são iguais entre a equipe. Esta diferença muitas vezes causa frustação, pois nem sempre as práticas do companheiro de equipe atinge nossas espectativas, ou vice-versa.
O Rei da Myfreecomm diz:
Programação
- Todo o código de programação deve ser escrito em inglês.
- Os nomes de variáveis são em inglês.
- Os parâmetros são em inglês.
- Não devemos usar abreviação em variáveis e parâmetros.
- Nunca uma variável e parâmetro terá apenas uma letra, ela será sempre uma palavra (em inglês) auto-explicativa (com excessão de variáveis locais em iteração, exemplo clássico a variável “i”).
- Nunca suponha em seu código qual será o endereço de uma url ou localização de arquivo. Mantenha suas funções parametrizadas.
- Nunca coloque o nome do produto ou do cliente em variáveis ou nome de projetos.
Deployment
- Nunca duplique um código.
- Quando pensar em duplicar um código, por precisar de uma solução rápida e mais segura, Pare!
- Um código deve sempre estar em um ÚNICO lugar nos ambientes de produção.
- Uma hora ganha por duplicar o código hoje, equivale a uma semana perdida amanhã.
Banco de Dados
- O banco de dados é sagrado, apenas uma programação (a dona do bd) deve ter permissão de acesso.
- Não escreva qualquer programação que acesse direto o bd, além da dona, mesmo que seja apenas para leitura.
- Os nomes de banco de dados, tabelas e campos.. em inglês.
- Nunca teste um código em um banco de dados em produção, pois você destruirá a integridade das informações do banco.
URL
- A definição de uma URL de acesso interno é um recurso caro. O custo de mudança é muito alto.
- Ao definir uma URL de acesso interno, pense bem no escopo em que ela se encontra e abstraia o máximo possível.
- Não use caracter “_” em domínios e sub-domínios, o Internet Explorer vai te dar uma rasteira.
- Prefira “-” para substituir o espaço nos domínios e sub-domínios.
Nós acreditamos que esta lista é dinâmica e nunca se completará. Conforme formos trabalhando, aprendendo novas tecnologias, o Rei vai soltando mais regrinhas e a euipe vai mantendo a equipe com uma idéia única. Sabemos que esta lista mesmo está incompleta ainda…
Acreditamos também que não existe uma única lista “correta” e que cada empresa vai achar o seu conjunto de melhores práticas, de acordo com a sua situação, mercado e visão.
Não tenho dúvidas, que O Rei da Improve-it, por exemplo, vai dizer muita coisa em relação à testes, BDD e afins…
E você, o que acha destas regras, discorda de alguma? Alguma vez já escreveu seu conjunto de melhores práticas? O que o Rei da sua empresa diz?
Convido cada um postar em seu blog a sua lista de melhores práticas e colocar um trackback para cá, que tal?
Seria um MEME interessante, talvez com o apoio de blogs mais fortes, que lêem este, conseguimos começar a trocar uma idéia sobre esse assunto 
Abraços e até a próxima.
Imagino também que seria interessante existir regras em relação a forma que os códigos são digitados, a forma de escrever os comentários. Em fim, como se a página de códigos fosse uma redação, que obedece parágrafos, quebra de linhas e a forma exata de escrever cada rotina. Como por exemplo usar ou não um espaço entre um símbolo de igualdade, usar as chaves (no caso de algumas linguagens) logo após o nome de uma função ou com uma quebra de linha. Parece coisas bobas, mas no final tornam a leitura do código muito melhor e agradável.
Quantos as regras já ditas, achei todas convincentes.
Oi Keyne,
Concordo com você! Não colocamos regras de identação, pois seguimos as convenções da linguagem ou do framework.
De qualquer forma é uma boa incluir estes “coding standards” caso você trabalhe com alguma plataforma específica.
Abraços
“Automatizarás teus testes de aceitação”
(Gostaria de saber em detalhes a sua opção pelo inglês no nome das variáveis)
Os nomes de variáveis devem ser o mais específico poaaível. O que acontece muito é pegarmos códigos que além de não ter comentários, tem variáveis com o nome de “d1″ por exemplo ou “Imp”, abreviações que na realidade só servem mesmo para estragar o código ao invés de torna-lo melhor.
Outra convensão é por exemplo, em variáveis que são arrays, utilize o previxo “arNomeDaVariavel”, variáveis com valores true or false, utilize o prefixo para bolean, ou seja, blNomeDaVariavel, e caso for um objeto, ObjNomeDoObjeto.
É isso aí!
Oi Keyne,
A opção pelo inglês é economia. Você já imaginou ler um livro que as páginas são intercaladas, sendo as pares em inglês e as ímpares, português?! O esforço cognitivo é infinitamente menor quando você pena em um idioma só. Como os códigos da linguagem já são em inglês (if then else when) fica mais fácil escrevermos o resto em inglês. Além disso inglês não tem acentuação e as palavras são menores em geral.
Abraço
É, imaginei por alguns instantes que fosse isso.
Obrigado pelo esclarecimento. Quem sabe não aparece uma instituição não governamental que cuide das recomendações quanto a esses aspectos de organização.
Seria ótimo, poder ter pessoas que entendem, envolvidas em um estudo como esse, afim de otimizar o entendimento e o trabalho em equipe. Uma linguagem, uma cultura em comum. E em constante desenvolvimento.
Realmente é uma boa idéia!
Vamos fazer?
Você já pode dar o primeiro passo, como um blogueiro, blogando estas conclusões a respeito deste assunto, divulgando e atraindo mais comentáristas como eu. Até descobrirmos uma infraestrutura melhor para essas recomendações. O importante é que falemos sobre o assunto.
Bom, você já iniciou o movimento, agora é só continuar hehehehe.
Desculpe Rafael, mas sou totalmente contra sua opção pelo inglês. Até entendo suas razões, mas a pratica tem mostrado que isso não funciona exatamente, criando nomes de funções com interpretações erroneas como Rear-guard que não quer dizer Retaguarda de um negócio. Estive presente em diversos projetos e chegamos a conclusão que as palavras em português bem utilizadas tem melhores efeitos do que o inglês. É clado que isso depende muito de sua equipe, mas se baseando no fato de que o ingês fluênte ainda não é atingido por 100% dos desenvolvedores e analista, exigir esse tipo de coisa se baseando nas próprias qualificações é um tiro no pé. Mesmo eu sendo um nacionalista e brigar pela minha lingua eu usaria esse procedimento sem problemas se realmente fosse eficaz. Neste item o Keyne esta coberto de razão. Os nomes das variáveis e funções devem ser feitas o mais específico possível no bom e velho português
Abraços
Nilton – PMP
Oi Nilton,
Eu entendo que o nome pode ser específico em inglês. Não é pq é inglês que vai deixar de ter significado. Além disso, uma coisa é escrever em inglês e outra é dar nomes errados. A prática depende de quem está no time desenvolvendo.
Abraço