Padrões de Código

És dos programadores que pensa que ter o código codificado numa espécie de cifra, a qual só tu entendes, para que ninguém te possa roubar o teu código, ou para que mais dificilmente te possam substituir numa equipa?

Espero que leias o artigo até ao fim pois tenho para ti algumas más notícias.

Aos restantes, leiam também que irão encontrar valor certamente.

A comunidade WordPress tem como slogan “code is poetry (código é poesia)“. Eu prefiro idealizar o código como uma boa prosa, escrita com atenção, com boas regras de pontuação e sem segundos sentidos. Basicamente, respeitando as máximas do “clean code (código limpo)“.

Padrão (substantivo masculino), o que serve de modelo ou referência.

Segundo a definição, tudo o que possa servir de modelo ou referência que permita consistência pode ser considerado um padrão. Assim, um padrão de código poderá ser somente um guia de estilo (coding style); como poderão ser fórmulas de resolver determinados problemas, designados por padrões de desenho (design patterns).

A utilização deste tipo de regras permite uma maior legibilidade do código. Ou seja, mais facilmente o código poderá ser lido e entendido por outras pessoas. Ao contrário da premissa do início do artigo, a existência de mais “olhos” sobre o código aumentará substancialmente a detecção de possíveis falhas de performance ou segurança. Com isto também se irá diminuir o sentimento de único proprietário do código, permitindo uma mais fácil partilha de conhecimento entre toda a equipa. Não, não te vão roubar o lugar…na realidade, terás mais oportunidades de evoluir enquanto programador, e isso sim, te fará manter na profissão que escolheste durante mais tempo.

(Fonte: Rose-Hulman – Institute of Technology)

Os padrões de desenho já existem há considerável tempo, existindo uma “bíblia” escrita pelo gangue dos 4 – Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides – “Design Patterns: Elements of Reusable Object-Oriented Software“.

No entanto, com este artigo pretendo me focar mais sobre os guias de estilo.

Diariamente, na log, utilizamos PHP e WordPress, JavaScript, CSS e HTML. Penso que todas as linguagens de programação terão algum tipo de guia de estilo.

Para PHP existe um projecto designado por “PHP Framework Interop Group” onde se debatem e decidem quais os padrões que deverão vigorar. As recomendações para guias de estilo são o PSR-1 (Basic Coding Standard) e o PSR-2 (Coding Style Guide). Existe uma proposta, ainda em estado de rascunho, para um guia de estilo alargado (PSR-12).

O WordPress, apesar do seu código-base ser PHP, sugere um guia de estilo diferente – WordPress Coding Standards – que contradiz alguns pontos do PSR-2. Se pretendes desenvolver plugins, temas ou participar na evolução do core do WordPress, então terás de respeitar o seu guia de estilo.

Na nossa equipa respeitamos o guia de estilo do WordPress, e adicionamos mais algumas regras. Podes ler, usar e contribuir no nosso github.

Muitas vezes, se não a maioria das vezes, este tipo de iniciativas nasce dentro de empresas que não estão directamente associadas à evolução da linguagem ou framework (ou CMS). Um bom exemplo disso é o guia de estilos para JavaScript escrito pela empresa airbnb. Uma das vantagens do código-livre, o projecto poder nascer dentro de uma empresa e passar a ser do Mundo quando existem mais pessoas externas a participar na manutenção e evolução do mesmo.

Para CSS existem várias metodologias como o BEM (Block Element Modifier) que nós utilizamos na log.

No fundo não interessa se vais adoptar o guia de estilo A ou B, mas sim se algum será adoptado dentro da tua equipa. Esse é o desafio maior e onde se sentirão os maiores benefícios. O sentimento de propriedade partilhado por toda a tua equipa fará aumentar a qualidade do código por vocês escrito. Melhor qualidade de código, menor o número de bugs reportados. Melhor código facilitará a sua manutenção. Melhor código permitirá um sistema mais estável e mais maduro. Terás orgulho em ter escrito parte de um bom sistema, assim como o teu empregador.

Como vês, os beneficios serão de toda a equipa, e de ti também.

eXtreme Programming

climbing

eXtreme Programming (XP)

Década de 90

A década de 90 foi palco de uma revolução nos processos e metodologias de desenvolvimento de software. Um grito contra a metodologia Waterfall, os processos de micro-gestão e a extrema burocracia que tornava o desenvolvimento de software lento e altamente contraprodutivo. Poucos anos antes iniciara-se o desenho do SCRUM. O Manifesto para Desenvolvimento Ágil de Software só viria a nascer em 2001, fruto do trabalho de Jeff Sutherland, Ken Schwaber e Alistair Cockburn. Mas esse tema ficará para um possível próximo artigo.

Ano 1996

Kent Beck, um engenheiro de software que viria a assinar o manifesto do Agile, cria a metodologia eXtreme Programming (XP) – designação suportada por ser uma metodologia em que os seus processos são levados ao extremo.

Princípios básicos como o rápido feedback, a presunção da simplicidade, as mudanças incrementais, o abraçar mudanças e o trabalho de alta qualidade são defendidos através das cinco actividades basilares do XP:

  • Planeamento
  • Gestão
  • Desenho
  • Codificação
  • Testes

Considero que os processos inerentes às duas últimas actividades são de extrema valia para a qualidade do código desenvolvido e uma ferramenta importante para a saúde de uma equipa de desenvolvimento de software (nota: a saúde no seio de uma equipa necessita de mais ferramentas que serão abordadas em artigos separados).

Baseei-me nas duas últimas actividades para desenvolver a apresentação – easing a hurricane called TEAM.

Irei publicar um conjunto de artigos sobre as regras que dei maior ênfase nessa apresentação:

  1. Padrões
  2. Desenvolvimento Orientado por Testes
  3. Revisão de Código
  4. Programação Pareada
  5. Integração Contínua

 

Até lá, boa programação.