WordCamp Londres 2018

WordCamp é uma conferência que foca em tudo o que seja WordPress. WordCamps são eventos informais, organizados pelas comunidades de utilizadores de WordPress como tu. Qualquer um, desde utilizador casual a developers do core, participam, partilham ideias e conhecem-se uns aos outros.

Como se pode ver pela descrição presente no site da “central” de WordCamps realizados pelo Mundo fora, os WordCamps são momentos de partilha de conhecimentos e experiências, mas também uma oportunidade de expandir redes de contactos e formar parcerias.

log, empresa para a qual trabalho, irá patrocinar o WordCamp Londres e estará presente para apresentar os seus serviços de desenvolvimento em “Nearshore”. É com bastante entusiasmo que farei parte da comitiva. Será um prazer poder passar dois dias a falar com outros programadores de WordPress e, com bastante orgulho, promover a qualidade de código desenvolvido pela minha equipa.

Continuo a acreditar que é possível promover e disseminar a utilização das boas práticas de engenharia que o eXtreme Programming aconselha. Certamente que este será mais uma oportunidade para debater o tema.

Encontramo-nos em Londres?

Programação Pareada

Programação Pareada

O processo de programação pareada (em pares) é uma metodologia de trabalho defendida pelo eXtreme Programming (XP). Como o nome refere, cada unidade de programação é constituída por dois programadores num único computador. Poderemos incorrer no erro de pensar que é um desperdício de capacidade humana, uma vez que estão dois elementos a realizar o trabalho de um. No entanto esse pensamento não poderia estar mais afastado da realidade.

É expectável que uma equipa pareada produza a mesma quantidade de código que seria de esperar de dois programadores individuais, no entanto com a mais valia do código ter maior qualidade. Num artigo anterior escrevi sobre a importância e o papel da revisão de código no desenvolvimento de software. Processo que também consome tempo no presente mas que nos permite ganhar tempo no futuro através da maior maturidade e qualidade do código que seguirá para produção. Se se optar pela metodologia da programação em pares, poder-se-á presumir que a revisão de código já estará presente no código desenvolvido pela dupla de programadores.

Cada um dos programadores terá um papel específico – o “condutor” e o “navegador”.

Isto é, um escreve código enquanto o outro lê e antecipa situações. O melhor entrosamento verifica-se quando o teclado passa de um para o outro, sem que nenhum dos elementos esteja agarrado ao seu papel pre-estabelecido. Como se poder constatar, programação em pares tem tanto de soft-skills como de technical skills. Não é fácil para um programador aceitar a opinião de um par antes de testar a sua opinião. Como todas as demais soft-skills, é possível desenvolvê-la mas que requer tempo e abertura da parte do indivíduo.

“Já que vou ter de colocar dois programadores juntos, o melhor é colocar um sénior junto com um júnior, assim ele vai poder aprender”.

É preciso muito cuidado com este pensamento. A relação de mentoria é diferente da relação entre pares. Se efectivamente se pretende que a produtividade não diminua, a equipa deverá ser constituída por programadores competentes e já numa fase em que são totalmente autónomos.

Existem empresas que optam até por definir os papeis como “programador” e “tester”, ou seja, o “programador” irá escrever código para os testes unitários desenvolvidos pelo “tester”. Estes papéis vão sendo trocados e chegam mesmo a trocar no próprio dia. Como se pode compreender, seria completamente impossível de o fazer se os dois elementos não estivessem no mesmo nível de autonomia e conhecimento.

Outra indicação que o eXtreme Programming nos dá, “mover as pessoas”. É importante que as equipas pareadas sejam trocadas regularmente. Com isso iremos prevenir o aparecimento de “ilhas de conhecimento”, que de futuro nos poderá encaminhar para uma dívida técnica caso os detentores do conhecimento decidam sair da empresa – fenómeno tão temido por qualquer gestor tecnológico.

Assim se percebe que aliando a programação pareada a uma rotação interna de programadores obtemos maior:

  • fluxo contínuo de desenvolvimento e entrega,
  • disseminação de conhecimento da base de código do projecto,
  • qualidade no código produzido,
  • diminuição de possíveis dívidas técnicas.

 

Revisão de Código

Revisão de Código

O processo de revisão de código é há muito defendido pela IBM, de facto desde 1974. Inicialmente designado por “inspecção de código”, um processo formal de análise estática para validar se o software vai ao encontro do requisitos. Este processo era lento mas mesmo assim a IBM conseguiu atingir significativas melhorias na qualidade do código entregue.

A empresa (IBM) quase duplicou o número de linhas de código entregues nos produtos de software do System/370 desde 1976, enquanto o número de defeitos por milhares de linhas de código foi reduzido em dois-terços – Michael Fagan

Graças a ferramentas colaborativas de controlo de versões, conseguiu-se agilizar este procedimento, tornando-o num processo de rotina diária. Na minha equipa, todos os dias, cada engenheiro lê, revê, avalia e comenta o código de algum colega. O objectivo é se aumentar a confiança no código que entrará em produção, reduzindo o número de bugs. O processo de revisão implica que o código poderá ser actualizado e novamente revisto. Esta troca de informação deverá ocorrer o número de vezes necessárias até que a equipa – quem produziu o código e quem reviu – esteja totalmente confiante com o resultado.

Não existem regras rígidas de como deverá funcionar este processo. Com a disseminação do procedimento, o bom senso imperou e começaram a surgir, de diferentes fontes, boas práticas aconselhadas.

A empresa SmartBear Software desenvolveu um pequeno white-paper com 11 boas práticas para um eficaz processo de revisão de código:

  1. Rever menos de 200-400 linhas de código (LOC) de cada vez.
    • Mais de 400 linhas de código exigirão maior tempo de atenção, além de ser desmoralizador para o revisor saber de ante-mão que irá passar o dia inteiro a rever “aquele” código.
  2. Apontar para um rate de revisão numa ordem inferior das 300-500 LOC/hora.
    • É preferível que se analisem menos linhas de código mas que se procura situações como bugs, possíveis falhas de segurança, possíveis falhas de optimização e até possíveis falhas no desenho ou arquitectura do código.
  3. Ter tempo suficiente para rever adequadamente, e com calma, mas nunca mais de 60-90 minutos.
    • Por ser uma tarefa que exige atenção ao detalhe, a capacidade de concentração irá decair drasticamente quanto mais tempo levar a tarefa a concluir. Por experiência própria, após 60 minutos de revisão eficaz de código, ou se faz uma pausa (ir beber um café, levantar da cadeira e fazer alguns alongamentos, ler um artigo, etc) ou se começa a ser complacente com algum código e deixa-se de se analisar situações sensíveis como questões de segurança, optimização e escalabilidade.
  4. Autores deverão anotar o código-fonte, antes do processo de revisão começar.
    • É importante que o autor do código encaminhe os seus colegas para quais os ficheiros que devem ser revistos, evitando que código já revisto seja novamente validado.
  5. Estabelecer objectivos quantificáveis para o processo de revisão de código e capturar métricas para se poder melhorar o processo.
    • É importante que a equipa de gestão tenha forma de quantificar se o processo de revisão de código é eficaz, como por exemplo, contabilizar o número de bugs reportados pelo cliente.
  6. Lista de validação melhoram substancialmente os resultados tanto para os autores como para os revisores.
    • O que rever? Sem uma lista, cada engenheiro poderá procurar por algo em particular e deixar ao esquecimento outros pontos importantes.
  7. Validar que os defeitos foram de facto corrigidos!
    • Não basta um revisor indicar onde estão as falhas ou sugerir melhorias. E não se trata de uma questão de confiança nos colegas. É importante verificar que, de facto, as alterações também foram bem implementadas.
  8. Managers deverão cultivar uma boa cultura de revisão de código, em que encontrar defeitos é visto como algo positivo.
    • É necessário evitar a cultura de “porque não escreveste bem à primeira?”. Interessa sim que não se encontrem bugs em produção. No desenvolvimento e no processo de revisão é onde se devem encontrá-los. É importante existir espaço para que um engenheiro possa errar. Só assim poderá aprender algo novo.
  9. Atenção ao efeito “Big Brother”.
    • Similar ao ponto 8, mas na perspectiva do engenheiro. É importante se ter noção de que as sugestões ou bugs reportados nas revisões de código são quantificáveis. Estes dados deverão servir aos managers para analisarem se o processo está a funcionar, se um engenheiro está com alguma dificuldade em particular, mas nunca deverão ser utilizados para avaliações de performance.
  10. O factor Ego: Fazer sempre alguma revisão do próprio código, mesmo que não tenham tempo para fazê-lo até ao final.
    • Saber que o nosso código vai ser revisto por terceiros alerta-nos para sermos mais cautelosos no que produzimos.
  11. As revisões de código feitas de forma “leve” são eficientes, práticas e eficazes em encontrar erros.
    • Não é necessário se entrar no procedimento descrito pela IBM há 30 atrás, onde 5-10 pessoas se fecham em reuniões periódicas com impressões de código e rabiscam a cada linha de código. Utilizando ferramentas como o Git, é possível se participar no processo de revisão de código, escrever comentários associados a linhas específicas, debater soluções através de mensagens assíncronas com o autor, etc.

Aconselho a lerem o documento para terem uma visão mais aprofundada de cada ponto.

Não é possível refutar que a revisão de código irá melhorar a qualidade do código produzido, diminuindo o número de bugs e melhorando o desenho. Existem algumas mais valias adicionais como a partilha de conhecimento entre colegas e a mentoria de elementos mais juniores da equipa.

É um facto que este processo, mesmo que feito de uma forma mais leve, consumirá tempo ao projecto. Ao processo de revisão, temos de adicionar o tempo de resposta do autor e novamente o tempo de nova revisão. Numa tentativa de agilizar este consumo de tempo, aconselho que, após duas tentativas de revisão sem sucesso, o autor e o revisor se sentem lado a lado e debatam o pedaço de código que está a causar o problema.

Mas é importante recordar uma frase que se encontra no site da IBM –  Slow down to go faster (abranda para ires mais rápido).

Gostaria de terminar com uma nota, que tenho como demasiado importante. O processo de revisão de código exige que toda a equipa de desenvolvimento demonstre uma elevada inteligência emocional. Regra geral os programadores têm um ego forte e sentem-se “pais” do código por si escritos. Por vezes não é fácil aceitar comentários menos construtivos. Comentário totalmente destrutivos, provocantes ou jocosos “farão mais mal que bem”, podendo mesmo destruir o espírito de uma equipa. É importante acompanhar esses elementos, tentar que modifiquem as suas atitudes ou, em último recurso, retirá-los da equipa.

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.

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á.