Muito bem, a esta altura todos já concordaram que Rails representa um passo importante para desenvolvimento ágil, código de qualidade, bons princípios, custos justos. Porém, desenvolvimento de software é muito mais do que sentar à frente de seu micro, abrir seu editor de textos favorito e digitar algumas linhas de código.
Em um projeto, simplesmente codificar é apenas uma pequena parte do processo. Necessariamente precisamos ter Controle sobre o que estamos produzindo. Mesmo quando falamos em processos Ágeis, o fim da linha é que precisamos de mecanismos que nos garantam algum nível de controle.
Muitos programadores confundem processos Ágeis com anarquia no desenvolvimento, ou seja, nenhum controle. Isso não existe. Processos ágeis significam, literalmente, processos enxutos, com consciência explícita de mudanças constantes. Ou seja, significa menos burocracia, mas não nenhuma burocracia. Metodologias que implementam o conceito Ágil continuam tendo procedimentos e, principalmente, disciplina. E mais importante de tudo: a única coisa que realmente importa são o Conhecimento e a Experiência, nenhuma marca ou moda pode substituir isso. Desconfie de pessoas que defendem cegamente esta ou aquela metodologia. Não é o nome que importa, mas os resultados palpáveis que você consegue tirar deles.
Rails, por si só, já reforça alguns aspectos do processo. Por exemplo, ele disciplina que todo projeto deve ter uma separação física e obrigatória entre bancos de dados/ambientes de desenvolvimento, testes e produção. Isso não é opcional: NUNCA devemos realizar testes em produção.
Além disso ele traz embutido muito do ferramental necessário para testes. Desenvolvimento Orientado a Testes é um assunto extenso por si só. Fazer testes apenas usando manualmente o aplicativo NUNCA é suficiente. Testes unitários, testes funcionais e testes integrados automatizados são obrigatórios. Tentar pular essa etapa é justificável apenas por uma única razão: preguiça. Se não for preguiça é pior ainda: ignorância. E perceba o que eu disse: testes automatizados, repetíveis. Testar navegando manualmente na aplicação é inaceitável e com grandes chances de esconder erros graves. Notem que eu não disse que Rails tem Todo o ferramental para testes. Ainda existem níveis de controle extra onde precisamos da ajuda de outros softwares, como o Selenium, que está em desenvolvimento pela consultoria ThoughtWorks e nos dá uma interface gráfica para automatizar e acompanhar a evolução dos testes.
http://dev.rubyonrails.org/svn/rails
Para quem não conhece esse conceito, um programador jamais deve ter seu código concentrado apenas em sua máquina. Mesmo um programador solo, que não trabalha em equipe. Todo o código deve ser versionado em um repositório. Isso nos garante poder voltar atrás, mudar de idéia, além de garantir que seu código não desaparecerá por pane na sua máquina. Acredite, Murphy existe. E isso não é apenas um assunto de backup. Versionar, simplificadamente, significa que podemos carimbar um certo momento no tempo e chamá-lo de ” 1.0”, ou “1.1” e assim por diante. Um repositório é apenas uma pequena parte de áreas como Gestão de Mudança e Gestão de Configuração. Recomendação: estudem o máximo possível sobre esse assunto, existe uma ampla literatura sobre isso.
Quando gerenciamos projetos precisamos saber exatamente em que pé estamos, quem está fazendo o que, se o planejado está de acordo com o realizado. Quando temos equipes pequenas, algumas planilhas são suficientes para manter o projeto na linha. Mas quando estamos falando de equipes médias, projetos com dezenas de módulos, meses planejados para desenvolvimento, fatalmente precisaremos de sistemas que automatizem a burocracia e ajude o gerente de projetos a manter tudo sob controle.
Infelizmente não existe uma ferramenta absoluta. Existem dezenas no mercado que podem nos ajudar, mas tudo depende de quem você é, quais são suas técnicas, como você trabalha, ou seja, das circunstâncias particulares de cada um. Esta tabela compara alguns dos muitos sistemas do mercado. Novamente, não importa qual você use, contanto que use algum. Manter o projeto na linha é imperativo. Um produto que ainda é novo mas parece promissor é o Collaboa. Uma de suas principais características é que ele se integra ao Subversion. Ele é mais voltado uma área paralela ao gerenciamento de atividades: a de bug e issue tracking. Um Issue Tracking nos ajuda a controlar a manutenção dos sistemas, é uma área pós-projeto, ou seja, de operação.
Veja o exemplo do site que organiza o projeto de desenvolvimento do Rails. A plataforma escolhida foi o Trac que está muito em voga ultimamente. Ela é feita em Python e conta com seções que mostram os tickets de bugs, sua evolução e discussão.
E falando em operação, não podemos nos esquecer do controle sobre o que está em cada um de nossos servidores. Rails escala muito bem, principalmente quando distribuímos a carga entre vários servidores. O Capistrano serve exatamente para isso, controlar o Deployment das aplicações em produção, em uso pelos usuários. Com ele podemos nos integrar ao nosso repositório Subversion e garantir que a versão correta esteja instalada em cada uma de nossas máquinas. Um bom administrador de sistemas poderia substituir isso, mas humanos erram. Tarefas burocráticas deveriam, por definição, ser automatizadas. Precisamos colocar humanos onde precisamos de cérebro e máquinas para fazer o trabalho repetitivo.
Um projeto é uma empreitada temporária, com começo e fim definidos, para desenvolvimento de um produto ou serviço específicos. Por definição, projetos têm recursos escassos que, portanto, precisam ser gerenciados. Tempo, Custo e Escopo formam o trinômio que representa os limites de um projeto. Se os recursos são limitados, precisamos ter Controle sobre seu consumo. Somente com essa consciência poderemos ter desenvolvmento sustentável de projetos, tanto de Rails quanto de qualquer outra plataforma.
Todos os diretos reservados a RubyOnBr. Copyright RubyOnBr .
This site is powered by Radiant CMS.