• Organizacionais ou processuais

Englobam o tipo de gestão de projecto, metodologia de desenvolvimento da equipa, qualidade e processo de recolha de requisitos.

• Técnicos

Os artefactos de código e semelhantes produzidos pelos developers e os processos levados a cabo por testers.

Este post foca-se primordialmente nos factores técnicos, que passo a enumerar.

Correcção do código produzido

É importantíssima a exigência que cada programador coloca em si próprio para escrever código de qualidade: primeiramente, código o mais correcto possível.
No entanto, não basta tentar escrever código correcto, é também necessário pensar nas implicações de performance do que se escreve (por exemplo, fazer um select completo a uma tabela grande sem necessidade), de thread safety, de segurança (caso mais comum, SQL injection para o qual PreparedStatements são uma grande ajuda), de documentação (comentários relevantes) e de estética do próprio código (definir e seguir convenções).

Este ponto depende também da própria qualidade das pessoas na equipa e a diferença além de se pagar nota-se!

Testes Unitários

Escrever testes unitários é a forma mais directa que a equipa tem de garantir correcção do código.
Em TDD (Test Driven Development) o teste unitário é a unidade básica e o código é desenvolvido para satisfazer cada teste. Esta aproximação é altamente eficaz mas exige disciplina e considero que é difícil de ser usada pela maioria das equipas, especialmente portuguesas.
No entanto, mesmo em ambientes não TDD este tipo de testes são essenciais, não só para garantir que o código está correcto, como para verificar que não se quebra código anterior cada vez que se alteram ou adicionam funcionalidades.
Quanto maior for a percentagem de caminhos possíveis de código coberta por testes unitários – o chamado code coverage – maior é a indicação de garantia de qualidade do código como um todo.

Ferramentas:
JUnit, TestNG, DbUnit, Cactus, Atlassian Clover (code coverage)

Code Reviews

Ainda dentro dos mecanismos de controle que a própria equipa pode usar durante o desenvolvimente encontram-se os code reviews.
Devíamos existir sempre code reviews, embora seja aceitável que não tenhamos 100% do código revisto, apenas uma boa percentagem. E esta boa percentagem é um equilíbrio entre o esforço que a equipa tem a rever e a melhoria de qualidade percebida.
Ter este tipo de controle cria um tipo de peer pressure na equipa. Ninguém é dono do seu pedaço de código, todos sabem que os outros colegas vão validar o que escrevem por isso vão ter um cuidado extra no que produzem.
Desta forma más práticas e erros são detectados cedo no processo e toda a equipa ganha pois todos os membros da equipa aprendem com as correcções que lhes são feitas, especialmente os membros menos experientes que têm neste processo um mentoring por parte de toda a equipa.

Ferramentas:
Atlassian Crucible

Análise Estática

Ferramentas de análise estática permitem detectar no erros e standards no código de forma simples. Alguns erros detectados por estas ferramentas poucos ou nenhums programadores conseguem detectar e não são apanhados na grande maioria dos outros testes por isso são uma grande adição.

Ferramentas:
FindBugs (obrigatório!), Checkstyle

Sistema de builds / integração contínua

Builds automatizados é obrigatório! Muitos são os projectos hoje em dia em que cada developer tem o seu próprio processo de build separado no seu IDE.
Seguindo a regra de ouro de que quanto mais cedo se detecta um erro melhor, o processo de builds pode e deve ser escalonado num motor de integração contínua que permite rapidamente detectar quando um membro da equipa quebra o build.
Igualmente importante é adicionar ao processo de build meios adicionais de controlo de qualidade na forma de plugins ou tasks extra – correr testes unitários, gerar relatórios de code coverage, correr ferramentas de análise estática de código, etc.

Ferramentas:
Ant, Maven, Ivy, Cuise Control, Hudson, TeamCity, Atlassian Bamboo

Equipa de testes / QA

Este ponto não é técnico mas considero-o importante. Em todos os projectos que trabalhei em Portugal apenas uma vez trabalhei uma equipa de QA (Quality Assurance) organizada. Na maioria dos projectos os testes de “qualidade” resumiam-se a fazer deploy da aplicação para outro ambiente e ter alguém – muitas vezes da parte do cliente – testar ad-hoc a aplicação. E quem fazia estes testes era muitas vezes o interessado em passar a aplicação a produção – muitas vezes o próprio project manager da equipa.
É muito importante ter uma equipa, ou mesmo apenas uma pessoa, de QA que tem responsabilidades de testes em determinadas fazes. É ainda mais importante que esses membros não façam parte da equipa de desenvolvimento, pois estariam com “maus hábitos”, nem da gestão de projectos, pois vai querer é satisfazer o cliente, nem do cliente, que simplesmente não vai testar devidamente e depois a culpa é da equipa. Grande parte dos projectos têm baixa qualidade porque o desenvolvimento para clientes envolve os tais “compromissos” entre qualidade e tempo/dinheiro que os PMs tanto falam.

Testes funcionais

Quer se tenha um processo de desenvolvimento em cascata ou iterativo, depois de cada release deve-se passar à fase de QA em que os testes funcionais são executados.
Estes testes devem ser feitos com base num plano de testes já elaborado ou nos próprios requisitos do projecto – sejam eles use cases, user stories ou outra coisa qualquer.
Nestes testes o carácter específico de um membro QA entram em cena: o espírito inquisitivo e a capacidade de interpretarem os requisitos do ponto de vista do utilizador.

Testes de carga

Num modelo de desenvolvimento iterativo os testes de carga não precisam de ser feitos no fim de cada iteração mas apenas em releases major.
Duas perspectivas devem ser testadas: performance e escalabilidade.
Algumas ferramentas podem ser usadas para testas as duas perspectivas – por exemplo, a aplicação que testa o tempo de invocação de algo pode lançar x threads para testar como escala.
Para testar devidamente escalabilidade, devem ser tida em conta a infraestrutura do projecto. Não é necessário replicar um ambiente de produção, é aliás impossível a maioria das vezes devido aos custos, mas se em produção temos uma base de dados numa máquina e um aplication server noutra, vamos deixá-los separados também para testes para ter em conta todas as variáveis.

Ferramentas:
WebLoad, JMeter, Grinder

Testes de segurança

Uma das áreas menos testadas no desenvolvimento de aplicações web é a segurança, normalmente até acontecer algo de mau. Mesmo a maioria dos testers não sabem fazer testes de segurança nem o que é uma ataque de Cross-Site Scripting (XSS). E mesmo a maioria dos developers não têm grandes cuidados com segurança além dos típicos ataques de SQL Injection.
A falta de ferramentas é um dos grandes problemas nesta área.

Ferramentas:
WebScarab

Testes de UI

O teste mais básico de UI é ver se as coisas fazer rendering correcto nos diferentes browsers. Validar automaticamente o código gerado de acordo com standards é também importante.
Para facilitar o trabalho, existem diversos projectos de automatização de testes de UI.

Ferramentas:
Selenium, Watir, Windmill

Outros testes importantes são os de integração e de regressão mas não são áreas em que tenha muita experiência ou opinião formada por isso abstenho-me.

Todos estes pontos são bastante lógicos, penso eu. Tudo o que se possa fazer para aumentar a qualidade final do que se desenvolve é positivo e a qualidade deve estar na mente de todos e não ser uma moeda de troca, razão da mediocridade de grande parte das aplicações feitas para clientes que vi na minha vida profissional.
Qualidade custa também dinheiro, sim, mas o retorno é grande, tenho a certeza.

Update:
A proposito de um comentário do Diego Carrion, fica uma referência para o JBehaviour2, para testes funcionais numa aproximação BDD (Behaviour-Driven Development)

No entanto, para o código javascript que nós próprios desenvolvemos ou que as frameworks que usamos usam ou geram raramente minimizamos os ficheiros javascript. Isto apenas seria feito para cenários de produção, mas rapidamente se tornaria demasiado trabalhoso.
Se queremos minimizar apenas para determinados cenários e de forma totalmente automática, tem lógica incluir este processo nos nossos processos de build.

E é aqui que entra o plugin do YUICompressor para o Maven.
Este plugin permite processar os ficheiros javascript, minimizando-os. Também corre o JSLint, para verificar a correcção do código. Este último é uma forma de análise estática de código que ajudo muito a reduzir a probabilidade de erros não detectados.

Falo do YUICompressor como podia falar de outras ferramentas de compressão e obfuscação de javascript, como seja o JSMin, ShrinkSafe, Packer ou outro. Não sei é sobre a existência de plugins para todos, embora não deve ser muito complexo de os desenvolver.

Desta forma conseguimos comprimir o nosso código para melhorar a performance e verificar estaticamente por erros no javascript (um erro javascript pode quebrar o build: bom!). Podemos ainda usar o plugin para gerar documentação javascript (JsTools) ou mesmo para efectuar testes unitários em javascript (JsUnit).

Poderíamos ainda melhor mais a performance, gzipando os nossos ficheiros a nível do servidor. Para esta e outras optimizações, é muito útil o YSlow, também da Yahoo que é um plugin para o Firebug que verifica determinados parâmetros de performance na página.

Esta conversa já me surgiu em diversas ocasiões e voltou a despontar numa thread na mailing list do PTJUG, e confesso que tenho alguma dificuldade em compreender a enorme resistência que imensos programadores apresentam em aprender e utilizar javascript. Isto é, baterem código mesmo em javascript sem usar frameworks que gerem o código todo – e.g. GWT, ou helpers de php, ruby, etc. -, mas usando obviamente bibliotecas como o prototype, jquery, etc.

Javascript é uma linguagem dinâmica, weakly typed e prototipada. Logo aqui, há diferenças para as linguagens que a maioria usa: C#, Java (statically e strongly typed) e python (dynamically mas strongly typed). O modelo de prototipagem é um pouco diferente do modelo de classes para definição de objectos, por isso percebo que possa introduzir confusão ou pelo menos dar origem a um novo processo de aprendizagem.

Mas não é assim tão complicado como isso…

Razões para usar javascript directamente, não ter medo e assumi-lo com orgulho

1. Desenvolvimento web = (X)HTML + CSS + Javascript + linguagem_server_side

Quer sejamos programadores java ou de uma outra tecnologia web, a probabilidade de termos de usar ou gerar html, css e javascript é muito elevada. Podemos inclusivamente usar geradores mas como facilitadores e não por sermos incapazes de produzir código de qualidade numa linguagem dinâmica ou, pelo menos, compreender o código que estamos a gerar. Devemos poder mudar de linguagem e continuar a dominar a parte de interface web, apenas tendo de aprender conceitos da outra linguagem/plataforma.

2. jsFUD

Durante muito tempo, javascript foi muito pouco estudado e visto como uma linguagem de scripting básica que permitia escrever umas linhas de código. Não havia propriamente estruturação de código e muita gente entende que programar javascript é isso. É um pouco como aquelas aplicações java de alunos de primeiro ano que metem 2000 linhas de código num só ficheiro ao monte.
Hoje em dia javascript não é isso, é uma linguagem madura, os problemas de interoperabilidade entre browsers são mitigados com as novas bibliotecas, estão a ser preparadas virtual machines (compilação JIT incluída) que melhorarão imenso a performance de código no browser, há uma proposta de uma nova versão da linguagem (resumo da nova especificação) com possibilidades de verificação de tipos estática e outras features que fazem dela uma linguagem muito mais parecida com algo tipo java (ActionScript é a coisa mais parecida actualmente).

3. Javascript não é só web

Nos últimos meses tenho desenvolvido aplicações com a suite de BPM Teamworks da Lombardi que utiliza javascript como linguagem de programação para as actividades dos BPMs. A utilização de javascript nestes moldes ou, melhor ainda, como linguagem para desenvolver plugins ou algo semelhante para aplicações, tirando partido das suas propriedades dinâmicas é altamente refrescante. Basta usar os jars que a Mozilla fornece com a implementação do projecto Rhino.

4. JSON

Poder estar a programar e definir as minhas estruturas de dados em formato JSON é magnífico. É menos verboso, simples e escrevo muito menos new’s.

5. Abrir horizontes

Last but not least, não devemos ter receio de linguagens dinâmicas. Um programador java tem um trabalho confortável e laborioso: estamos protegidos com verificações estáticas em tempo de compilação, checked exceptions e outras demais coisas o que nos dá segurança e permite apanhar erros cedo; por outro lado, tudo isto nos dá mais trabalho sem muitas vezes nos garantir qualidade do software (para isso preferiria ter contratos estritos definidos entre os componentes com verificações em tempo de compilação e runtime, o que seria demais para a maioria nos sistemas).
Trata-se pois, de uma questão de encontrar a chave de fendas que funcione melhor com o parafuso. Sejam linguagens dinâmicas ou não, o que interessa é a que produza melhor resultado final e isso pode nem sequer depender da linguagem mas de outros factores externos como a equipa, o tipo de requisitos, etc.

Em termos de resumo, coisas como o GWT são excelentes paradigmas mas não se deve perder de vista o que se passa debaixo do capô. Experimentem desenvolver uma aplicação em javascript para testar o poder da linguagem. Repito, uma aplicação, não um bloco de script.

• seguimos o link permanente para a entrada (caixa ‘Posts Recentes’) e depois fazemos ‘back’ no browser;
• damos ao dedo a fazer scroll na página até que a entrada fique visível.

Uma forma interessante de resolver este problema seria ter uma opção de toggle do texto das entradas, ou seja, ter uma opção para mostrar ou esconder o texto dos posts por escolha do utilizador.

Estava a matutar sobre isto enquanto admirava os tons campestres desta página e pensei que não era má ideia pôr a solução em prática.

Um requisito importante é que o teria de fazer sem alterar efectivamente a página (só para não estar a chatear o Administrador do blog durante o fim-de-semana ).

Outro é que o código teria de ser suficiente pequeno para poder ser postado aqui.

Era definitivamente um bom desafio para por à prova o jQuery.

Precisava de quatro operações para concretizar as alterações:

1. esconder inicialmente o texto das entradas e os links para tags e comentários mas não o titulo ou a informação dos autores;
2. acrescentar à frente do nome do autor um link para permitir mostrar ou esconder o texto;
3. associar ao evento click do link uma função para concretizar a opção do utilizador;
4. desenvolver a função;

Usei o Firebug para analisar a estrutura do DOM da página.
Cada entrada tem uma estrutura fixa:

1. um <h2> com o link para o titulo;
2. um <h4> com a data do post e a identificação do autor;
3. um <div> com a class ‘entry’ com o texto;
4. um <p> com a class ‘tagged’ com links para as tags e comentários

Portanto, para concretizar a primeira operação só precisava de esconder os elementos com as classes ‘entry’ e ‘tagged’ que em jQuery se traduz como:
$('.entry, .tagged').hide();

Para a concretizar segunda operação acrescentei um link à frente do nome do autor, ou seja, de todos os <h4>s precedidos por <h2>s, ou em jQuery:
$('h2 ~ h4').append('<a href="javascript:void(0)" class="entryToggler">(Mostrar)</a>');

Para a terceira opção e visto que associei os links criados à class entryTogger, basta associar uma função ao evento onclick de todos os elementos com esta classe ou em jQuery:
$('.entryToggler').click(toggleEntry);

Falta só desenvolver a função toggleEntry.

Uma vez que esta função tem acesso ao elemento anchor seleccionado pelo utilizador (this), podia usá-lo como referência para:

1. verificar o estado da entrada a partir do texto:
   var isHidden = $(this).text().search('Mostrar')!=-1;
2. seleccionar os elementos correspondentes ao texto e aos links para as tags e comentários:
   var x=$(this).parent().next(); x = x.add(x.next());
3. mostrar ou esconder os elementos seleccionados:
   isHidden ? x.slideDown('slow') : x.slideUp('slow');
4. alterar o texto do link para ficar de acordo com a operação:
   isHidden ? $(this).text('(Esconder)') : $(this).text('(Mostrar)');

e estava feito!

Como podem testar o código? É fácil:
abram a página principal do blog. (pessoal do rss, tem mesmo que ser na página principal)

Se estiverem a usar o Firebug podem copiar o código completo para a consola e executarem-no:

var toggleEntry = function(){
	var isHidden = $(this).text().search('Mostrar')!=-1;
	var x=$(this).parent().next();
	x = x.add(x.next());
	isHidden ? x.slideDown('slow') : x.slideUp('slow');
	isHidden ? $(this).text('(Esconder)') : $(this).text('(Mostrar)');
};
$('.entry, .tagged').hide();
$('h2 ~ h4').append('<a href="javascript:void(0)" class="entryToggler">(Mostrar)</a>');
$('.entryToggler').click(toggleEntry);

Para os outros casos, escrevi o código todo numa só linha que podem copiar para a caixa de endereço do browser (substituindo o http://www.zonaj.org):

javascript:var toggleEntry = function(){var isHidden = $(this).text().search('Mostrar')!=-1;var x=$(this).parent().next();x = x.add(x.next());isHidden ? x.slideDown('slow') : x.slideUp('slow');isHidden ? $(this).text('(Esconder)') : $(this).text('(Mostrar)');};$('.entry, .tagged').hide();$('h2 ~ h4').append('<a href="javascript:void(0)" class="entryToggler">(Mostrar)</a>');$('.entryToggler').click(toggleEntry);void(0);

Testado com FF2, IE7 e Opera9.

É claro que tive a vantagem de não me ter de preocupar em importar o script de jQuery porque a própria página já o faz.
Caso estivesse a alterar o DOM de uma página que não use jQuery, podia fazer o mesmo tipo de alterações usando o jQuerify.

Nota 1:
Para deixar a primeira entrada sem alterações basta alterar a linha
$('.entry, .tagged').hide();
para
$('.entry, .tagged').not(':first').hide();
e a linha
$('h2 ~ h4').append('<a href="javascript:void(0)" class="entryToggler">(Mostrar)</a>');
para
$('h2 ~ h4').not(':first').append('<a href="javascript:void(0)" class="entryToggler">(Mostrar)</a>');

Nota 2:
Para remover a irritante ‘caixa picotada’ à volta do link quando este fica activo, acrescentar como ultima linha da função:
$(this).blur();

Nota 3:
O código final tem cerca de 10 (!) linhas e repeti-o 3 vezes neste post.

Nota 4:
Para ter de volta a página original basta fazer reload no browser (mesmo tendo alterado a linha de endereço).

Isto é o contrário de: se um campo de texto estiver seleccionado o formulário é submetido se carregarmos a tecla enter.
Isto acontece para campos com a tag input; não acontece por exemplo para a textarea.

Um requisito óbvio (usabilidade) é que o site continue a ser navegável com teclas. Logo, inputs do tipo submit e button, bem como todas as outras tags, deveriam continuar a processar o enter.

Eis a solução final, testada em FF2 e IE6:

<html>
  <head>
    <title>This form doesn't submit with Enter key</title>
  </head>
  <body>
    <form id="formID" .../>
       ...
    </form>

    <script type="text/javascript"><!--

/* Checks if enter key was pressed and this is allowed.
 * This functions tries to solve issue : "If a text field has focus, the
 * form will submit upon hitting the enter (or return) key."
 * @param e the event
 * @return true if enter key is pressed for input fields (input tags not of
 * type 'button' or 'submit') ; false otrhewise
 */
function disableEnterKeyForInputs(e){

  // next lines suport multibrowser
  var key = (window.event) ? event.keyCode : e.which;
  var srcElement = (window.event) ? event.srcElement : e.target;

  if (key == 13) {
    var tagName = srcElement.tagName.toUpperCase();
    if ( tagName == 'INPUT' ) {
       // only inputTags have enter issue
       // and buttons and submit should respond to enter
       switch ( srcElement.type.toUpperCase() ){
         case 'BUTTON' :
         case 'SUBMIT' :
            return true;
          break;
         default :
            return false;
       }
    }
  }
  return true;
}

if ( (theForm = document.getElementById("formID") ) != null)
  theForm.onkeypress=disableEnterKeyForInputs;

// -->
    </script>
  </body>
</html>

tanx to Ricardo Antunes, Lurdes Spínola

Leituras

• [1] Nabble Forums : Form Submit On Enter (http://www.nabble.com/Form-Submit-On-Enter-t1320364.html)
• [2] http://www.jsftutorials.net/defaultActionTag.html (http://www.jsftutorials.net/defaultActionTag.html)