Second Sprint

mais duas semanas se passaram, e encerramos nosso segundo sprint.

esta segunda iteração tinha como meta realizar avaliações de programadores à distância, e otimizar as funcionalidades de dois sistemas que possuimos. Desta vez não tivemos tantos impedimento quanto da última vez, mas mesmo assim somente conseguimos dar cabo de metade das metas previstas.

Será falta de pessoal ? Será falta de organização ? Será falta de experiencia ? Talvez seja simplesmente um pouco dos três. Por ser recem nosso segundo sprint, falta ainda experiencia para precisar exatamente o que nosso diminuto time será capaz de realizar no periodo de duas semanas disponivel. ‘Incendios’ sempre terão de ser apagados, muitas vezes pelo pessoal com mais capacidade que justamente compunha o time. De qualquer modo, ainda é muito cedo (afinal, foi recem nosso segundo sprint) para esperar que consigamos acertar nossas previsões e metas plenamente.

Para piorar o que já estava ruim, um de nossos colaboradores decidiu começar a trabalhar em casa, o que limita a troca de conhecimento e a agilidade de comunicação. Era um colaborador com quem eu possuia certos desentendimentos ocasionalmente, mas ainda assim um programador competente e capaz. Fará falta.

Iniciamos o terceiro sprint aonde o primeiro terminou, com a refatoração plena do sistema em plugins. Deste modo poderemos trabalhar com cada sub-sistema como uma unidade individual e independente das demais, com um sistema mais simples e melhor organização de controle de versões que o utilizado atualmente.

Desacoplamento dos sub-sistemas e do banco de dados hoje, TDD e Trac amanhã.

First Sprint

Depois de muita conversa e discussão, finalmente conseguimos dar principio às práticas Agile em nossa empresa. Adotamos SCRUM, e iniciamos o primeiro sprint duas semanas atrás, sendo que sua conclusão ocorreu nesta segunda.

A primeira vista, a prática foi um fracasso. Prometiamos mil maravilhas, que os projetos seriam entregues em tempo, que tudo iria funcionar perfeitamente. Porém imprevistos que sequer o Scrum Master conseguiu se livrar acabou por atrasar o projeto completamente. Dos 10 dias que havia reservado para o projeto, somente produzi em metade deles. Prometemos entregar 27 itens, e somente concluimos seis deles.

Fracasso ?! Eu vejo sucesso nisso tudo. Sim, falhamos em atingir nossas metas, mas pela primeira vez mensuramos exatamente o que ocorreu, por que as metas não foram atingidas, e mantivemos a comunicação entre todos os integrantes do time. Os itens entregues, tambem, foram pesquisados, desenvolvidos e avaliados de maneira que há garantia de que não teremos de voltar a eles tão cedo.

Iniciamos o segundo Sprint na segunda a tarde, definindo 21 itens por serem entregues. Vamos ver como nos saimos agora.

programe simples

Durante o 9o. Forum de Software Livre tive a oportunidade de assistir uma palestra do criador do PHP, Rasmus Lerdorf. Entre diversas pérolas de conhecimento que ele distribuiu para os presentes, uma que realmente tenho cultuado desde então é a seguinte:

Passar horas, dias, escrevendo um código altamente complexo para resolver um problema pela primeira vez não é ser esperto, é ser idiota. Se você teve grande dificuldade em escrever o código da primeira vez, multiplique por 1000 e e este será o grau de dificuldade para fazer manutenção neste mesmo código¹

Desde então tenho evitado soluções “mágicas” e ofuscadas para criar soluções inovadoras, sempre buscando na medida do possível simplificar todo e qualquer raciocionio que crio.

____

1 Tradução livre e independente das reais palavras de Rasmus Lerdorf.A palestra foi em abril, e não lembro exatamente quais foram as palavras utilizadas por ele.

onsubmit on form.submit()

Descobri recentemente que os padrões da W3C não permitem que, ao executar a função javascript form.submit(), as funções inseridas no parametro onsubmit de um formulário sejam executadas, somente realizando onsubmit através do input especifico (<input type=submit>). Achei isso muito estranho, e as circunstâncias em que eu trabalhava exigia que eu fosse capaz de criar um botão de submit que pudesse ser utilizado com qualquer formulario, esteja o botão declarado dentro ou fora do formulario, quer existam ou não funções declaradas no campo onsubmit;

Primeira Solução

Após uma simples busca encontrei a seguinte função:

if(form.onsubmit()) {
return form.submit();
}

Excelente e simples solução para o problema. Ele tenta executar as funções descritas no onsubmit, e então executa o submit.

Mas e se o formulário não possuir um onsubmit ? Oops… um erro ocorre…

Solução Final

Para gerar uma função genérica, que pudesse com qualquer formulário, tive de decair ao nivel do gambi-development, os quais quem me conhece sabe que repudio com fervor. A função final ficou parecida com isto:

if(typeof form.onsubmit == "function") {
if(!form.onsubmit()) {
return false;
}
}
return form.submit();

Ele verifica se existe a função onsubmit, executa ela se existente, retorna false se o retorno dela for false, e por fim executa o submit se o resultado do onsubmit for verdadeiro ou a função não existir

Não me orgulho do resultado encontrado, nem um pouco elegante, mas resolve o problema de minha aplicação.

Deixando a Solução mais Elegante

Quando eu idealizei a função acima, em julho de 2008, eu a utilizava em apenas um local que era invocado automaticamente com o template de formulários do gerenciador de nosso sistema. Porém, esta função facilita muito a vida de todos em qualquer outra ocasião onde um formulario deve ser preenchido e tu tem usar a função form.submit() para envia-lo. A solução, portanto, permaneceu não-elegante devido ao fato de não ter ser reutilizada em outro lugar.

Anyway, um jeito bem simples de deixar a solução elegante é criar uma função que a executa passando o formulario por parâmetro.


// form_submit
// submits a form, checking if there is a onsubmit function defined for it
//
// @author hagnat
// @see http://hagnat.wordpress.com/2008/07/22/onsubmit-on-formsubmit
// @param object[form] the form being submitted
function form_submit(form)
{
if(typeof form.onsubmit == "function") {
if(!form.onsubmit()) {
return false;
}
}
return form.submit();
}


Eu podia meter ainda uns testes para prevenir erros usando try-catch, mas dae é complicar desnecessariamente a função. Imagino que quem utilizar esta função saberá colocar os pontos nos i’s e passar os parâmetros corretos para a função

Tadah! Agora basta invocar a função form_submit(form) dentro do onClick de um a ou input. E aquela solução tosca fica um pouco menos tosca

Sem comentários

Se você não comenta seus códigos, é melhor começar: cada função não comentada que você escreve é uma incomodação a mais que você está criando, gratuitamente, na hora de realizar manutenção no sistema que está desenvolvendo.

Comentários possuem diversos beneficios na manutenção de código, como explicar qual a linha de raciocínio que o programador possuia ao desenvolver uma função, quais os parametros de entrada e saída de uma função, alem de descrever em linguagem humana o que determinada função realiza. Basicamente, comentários funcionam como uma documentação rudimentar para sistemas que não possuem uma documentação redigida.

Imaginem um sistema com dezenas de milhares de linhas de código, e você tendo de realizar manutenção neste. Por onde começar ? Você procura a documentação, mas ela não existe; Você segue seus instintos e encontra os arquivos que iniciam o processo do sistema, e consegue encontrar (com dificuldade ou não) os módulos do sistema que precisa realizar manutenção. Analisando o código, você encontra referencias para dezenas de classes e funções que você não tem a menor idéia de onde se localizam, ou o que estas realizam defact.

É importante não apenas comentar, mas faze-lo direito. Um código mal-comentado é quase tão ruim quanto um não-comentado. A ausência de comentários retira a total esperança de uma fácil compreensão do código, enquanto o mal-comentado dá um pouco de esperança apenas para retira-la mais tarde, porém, ainda assim existem comentários com o qual o programador terá com que se basear na manutenção do código.

Programando orientado a objetos, faço questão de que cada função que desenvolvo tenha pelo menos um cabeçalho com o nome da função e uma descrição simples do que esta faz, quando o nome da função não for o suficiente para descrever a função. Cada bloco de código é comentado, determinando o que estou codificando e aonde estas informações serão utilizadas. Existem funções onde comentários são a maior parte referente à estas, de modo que qualquer pessoa que tiver de realizar manutenção em um módulo onde estas funções são invocadas terá pequena dificuldade em compreender o que a função faz.

Escrever comentários pode parecer uma grande perda de tempo no curto prazo, mas no longo prazo acaba se revelando num grande beneficio para os programadores que tiverem de trabalhar neste sistema.

Imaginava que isto já fazia parte do bom-senso da sub-cultura dos programadores, mas alguns códigos que vi recentemente me provaram o contrario. A seguir: sobre a importância de boa nomenclatura de funções.

Sincero Pedido de Desculpas

Lembro quando eu estava apenas engatinhando em programação, quando eu trabalhava no laboratório de pesquisas, a famosa Sala 1734. Lá eu dedicava parte da minha vida acadêmica aos estudos de algoritmos genéticos, vida artificial, resolução de problemas de quimiometria, além das normais atividades ligadas à jogatina, bebida e festas. Somente depois de três anos estudando computação foi que finalmente pude dedicar de corpo e alma à esta profissão.

Apesar da minha inexperiência, produzi excelente resultados, otimizando algoritmos já existentes para que aproveitassem melhor os recursos disponíveis, alem de ajudar no desenvolvimento de versões mais rápidas destes (o processo de otimização de um algoritmo genético levava horas, e tão cedo terminava a máquina ficava osciosa. Eu ajudei a reduzir o tempo consumido e a criar filas de testes de modo a permitir melhor aproveitamento das máquinas). Dediquei-me de corpo e alma, e por vezes fazia da minha univesidade minha segunda casa defacto.

Foi então que entrei em discussão com um de meus professores, na cadeira de Engenharia de Software. Me fervia a mente ter de me sujeitar a preencher os sem números de diagramas e organizar as dezenas de tabelas de documentação que meu professor ensinava como ferramentas básicas de um bom e estruturado projeto. Lembrava dos meus códigos, bem estruturados em arquivos ordenados, encapsulados de modo a permitir que um pudesse ser substituido por outro conforme a necessidade, e como para nenhum deles havia um diagrama sequer, uma tabela de documentação (apesar de que eles possuiam alguma documentação… eu SEMPRE documentei meus codigos), uma página de referencia citando o que já havia sido feito e o que poderia ser feito. Meu raciocinio era de que “O trabalho de pesquisa as vezes é algo momentaneo. Eu tenho uma idéia e preciso verificar se ela está correta ou não, e não posso perder tempo documentando isso quando poderia estar programando defacto”.

Alguns semestres mais tarde me vi frente a um problema onde eu sabia a resposta, porem não possuia as habilidades de programação necessárias para realizá-lo. Um de meus colegas possuia as habilidades para realizá-lo, mas não sabia como responder. Juntou-se a fome com a vontade de comer. Tentei explicar para ele como fazer, mas somente depois que rabisquei em uma folha de papel um diagrama com todos os passos que o sistema deveria realizar que este foi programado corretamente. Um excelente sucesso. Mais tarde, com o papel ainda em mãos, percebi o quão errado eu estivera na discussão com meu professor.

Alguns anos mais tarde, quando iniciei minha recente carreira como programador web, me vi novamente frente a diversos problemas onde a falta de documentação dificultava a capacidade de dar manutenção à códigos antigos. E me vi eu sendo o defensor de padronização, reutilização e documentação de código, enfrentando resistência daqueles que acreditam que “perder tempo documentando” iria somente atrasar suas já atrasadas tarefas de programação.

O mundo dá voltas. Nunca substime qualquer ensinamento que lhe for dado.

Estágios de Programação

Programando profissionalmente para uma pequena empresa web me perimtiu visualizar os mais adversos estágios de programação que um poderia imaginar. Os estágios iniciais foram-me apenas relatados, como se fossem estórias de terror de tempos imemorávis.

Inicialmente cada programador era responsável por um projeto. Ele recebia o layout do design, cortava-o do jeito que o convinha programar, organizava a base de dados de acordo com sua lógica, sempre sem utilizar chaves estrangeiras uma vez que estas não existiam nas rudimentares versões de mysql utilizadas outr’ora. As ferramentas de gerência da página de internet eram geradas com um script, que era basicamente um copy-pasta de outros projetos. Bugs eram resolvidos com dificuldade, e toda melhoria no sistema gerava uma quantidade enorme de re-trabalhos e bugs causados porque algo foi mudado que não deveria. Este é o estágio “Cada um por si, e o manual nos acuda!“

O segundo estágio envolve os primeiros passos de centralização do processo de trabalho. Todos os projetos são reunidos e os banco de dados centralizados em um um único servidor. Ferramentas “padronizadas” e testadas são reutilizadas em novos projetos. A programação, porem, continua caótica. Uma vez que os arquivos são abertos diretos do servidor, se duas pessoas tiverem de trabalhar em um mesmo projeto e tiverem de editar um arquivo centralizado, como o arquivo de CSS do site, haverá conflitos por perca do trabalho do primeiro tão cedo o segundo sobre-escrever o arquivo salvo deste. A aparente organização do servidor defato torna dificil trabalhar em time, fazendo os programadores a se forçarem a trabalhar sozinhos para evitarem as dores de cabeça de ter de compartilhar os recursos do servidor. Este é o estágio “Um servidor para todos governar e na desorganização aprisioná-los“

Até o momento não falei em programação orientada a objetos. Esta incrivel opção, introduzida no PHP 3, melhorada no PHP4, divinizada no PHP5, e em processo de trancedencia no PHP6, permite que dados e funções sejam encapsulados de acordo com o contexto destes. $contato_sexo não mais irá receber qualquer valor, mas $contato->setSexo($value) irá tratar o valor de acordo que somente valores válidos sejam retornados com um $contato->getSexo(). Uma vez que as funções do objeto ficam centralizadas num arquivo apenas, é possível organizar o código de modo a re-aproveitar o código em diversos outras funções do site. O programador fica todo bobo com as possibilidades da progarmação orientada à objetos que começa a fazer tudo, por mais ridiculo que seja, utilizando objetos. Este é o estágio “$this->programacao->incrementarEstagio()“

Outro estágio é o de separar o código em camadas. Temos uma camada que conecta com o banco de dados, outra camada que trata de processar as requisições do usuário e organizar os dados vindos do servidor, e uma terceira camada que exibe estas informações seguindo um código simples e fácil de compreender em HTML com pouca inclusão de código PHP (pois a camada de processamento dos dados já deixou tudo arrumadinho para esta). Aqui somos defato programadores profissionais, com códigos limpos e de fácil leitura. Separando as camads, é possivel substituir os códigos de uma de modo a atender as necessidades e limitaçõs do servidor. Programamos o site com mysql, mas o servidor utiliza Oracle ? Sem problemas, basta trocar a camada de banco de dados para Oracle. Esta é a fase “Quer programar como?“

O próximo passo consiste na sequencia do segundo. A estruturação da base de dados agora deixa de ser função do programador, e passa para as competentes mãos de um analista. Chaves estrangeiras são respeitadas, nomes de variáveis padronizadas, alem de todo um trabalho de indexar as tabelas de modo a agilizar sua consulta. O servidor centralizado deixa de simplsmente armazenar os arquivos, mas passa a controlar estes com ferramentas de controle de versão, como o CVS e o SVN. Vemos a divisão da equipe de desenvolvimento em progamadores de módulos e macacos de programação, onde os primeiros desenvolvem as ferramentas que serão utilizadas em todos os projetos que os segundos irão processar. Este é o estágio “Dividir para programar“.

Antes de dar seqüência, quero deixar claro que não há nenhum preconceito para com os macacos de programação. Estes são parte vital da companhia, uma vez que sem eles para finalizarem projetos baseado nos frutos do trabalho dos programadores de módulos não haveria dinheiro algum entrando na empresa. Um necessita do outro para realizar suas funções.

Muito bem, muito bem. Temos agora um ambiente bem organizado de trabalho. Porém ainda não tratamos do árduo processo de personalizar a dar manutenção ao site do cliente. A vantagem de ter o código quebrado em dezenas de arquivos diferentes é que se for necessário corrigir um, basta substituí-lo sem grandes danos aos demais. Porém, o que ocorre quando uma melhoria num módulo tem de ser aplicada em dezenas, centenas!, de clientes diferentes, cada um com uma personalização diferente para o módulo ? E se o site tiver de ser traduzido para um novo idioma, o que fazer ? Para resolver este dilema passamos a nos utilizar de Markup Languages, como XML e YAML. Organizando o código de modo a buscar nestes arquivos os dados personalizados do cliente, podemos muito bem alterar nossa programação sem temer que pornografia apareça em meio ao site daquele cliente filiado à igreja. Este é o estágio “Admirável Configuração Nova“.

Estes são os estágios perceptiveis da organização do processo de trabalho desta empresa. A cada passo que damos é mais um passo para a maturidade desta. Nossos futuros passos, porém, ainda são muitos, e não temos uma noção concreta de para qual direção eles nos levam.