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.

easing a hurricane called TEAM

Meetup WordPress Porto

Tive o prazer de participar no Meetup mensal da comunidade WordPress do Porto. Um grupo que se reune mensalmente, ininterruptamente há 4 anos. Viajar até à cidade do Porto é sempre um prazer, apesar dos mais de 300km de distância de Lisboa.

easing a hurricane called TEAM

(acalmando um furacão chamado de EQUIPA)

O titulo da apresentação que levei ao Porto. A apresentação começa com uma breve viagem por alguns momentos da minha carreira de programador de software. Com passagem obrigatória por alguns “dramas” mas que, sem esses obstáculos, não seria efetivamente o que sou hoje. Esses momentos também me permitiram conhecer dos melhores profissionais da área. Alguns dos quais tenho o prazer de, ainda hoje, privar com e de poder apelidar de amigos.

Com eles aprendi o que era SCRUM e eXtreme Programming, e qual a importância do papel humano de um CTO.

Anos volvidos, eis que me encontro no papel de coordenar uma equipa numa empresa que promove a implementação de algumas boas práticas do eXtreme Programming.

A segunda parte da apresentação versa sobre como as boas práticas (coding standards, code review, test-driven development, continuous integration, continuous delivery) fazem maravilhas na e para a minha equipa diariamente.

No próximo dia 2 Novembro terei a oportunidade de revisitar esta apresentação mas agora em Lisboa no change.log.

Espero vos encontrar por lá.

 

De volta ao início – Lei de Murphy

Casa de ferreiro, espeto de pau

Por muito que oiça este ditado, nunca o irei interiorizar devidamente.

Nesta área existe somente uma certeza – O que puder correr mal, vai mesmo correr mal.

Qual é o programador que nunca ouviu falar da lei de Murphy? Ou que em determinado momento mais critico, deseja com muita força que o Murphy não o encontre?

Decidi remover, do meu alojamento, as base-dados de projectos antigos. Como mandam as regras, efectuei backups previamente e DROP DATABASE ...

Removi todas as base-dados, excepto duas. De momento só tenho dois blogs no meu alojamento, o meu e o do meu irmão. Qual não é o meu espanto quando tento aceder a ambos os blogs e obtenho um error connecting to database

“Ok, enganei-me nos nomes mas reponho já com os backups”, pensei eu. O malandro do Murphy estava comigo nessa altura e o backup do meu blog não ficou bem realizado.

Aposto que também tu pensas sempre “isso só acontece aos outros”. Pois é, eu também penso assim mas desta vez lixei-me. Vamos lá recomeçar isto.