Keep Learning Conhecimento nunca é o bastante

Desenvolvedor, arquiteto, programador, engenheiro…

É realmente necessário ter equipes de arquitetura separadas de equipes de desenvolvimento? Essa pergunta é muito antiga e cada um tem uma resposta. Pra mim, não. Mas vamos pensar mais sobre isso.

Em primeiro lugar, o que é um arquiteto de software? É um desenvolvedor com muito conhecimento e experiência (minha resposta)? É um profissional diferente, especificamente treinado para a arquitetura de sistemas? É alguém que possui algum “dom” especial?

O cargo de “Arquiteto de Software” como empregado hoje na indústria do software é mais uma herança ruim da comparação entre desenvolvimento de software e construção civil. Nesta última, o arquiteto faz o projeto mas, em geral, não suja as mãos no cimento. O ponto é: arquitetar um sistema de software é ou não é fundamentalmente diferente de construir software, isto é, programá-lo, testá-lo e mantê-lo? Não. Existem algumas diferenças e algumas preocupações diferentes mas é impossível dissociar as atividades no nível em que é feito em outras áreas.

Um fato interessante é que apenas empresas grandes, com orçamentos folgados (que, em geral, desperdiçam tempo e dinheiro com futilidades e becos sem saída) costumam oferecer o cargo de arquiteto de software. Eles geralmente ficam em equipes de arquitetura, longe das equipes que “sujam” as mãos no código no dia-a-dia. Ora, isso, por si só, cria as Torres de Marfim e uma certa animosidade latente entre as diferentes equipes – que deveriam trabalhar em conjunto todos os dias.

Não faz sentido (e não é eficiente) ter equipes de arquitetura separadas, sem contato direto e constante com as equipes de desenvolvimento. Também não faz sentido empregar arquitetos de software que só planejam e não participam da execução diariamente.

Usando a já batida metáfora do desenvolvimento de software como jardinagem é fácil perceber que estamos longe do processo utilizado, por exemplo, na construção civil ou na indústria automobilística. Não é possível projetar todo o software com antecedência, como um prédio ou um carro, comprar a matéria-prima, contratar os operários e implementá-lo praticamente sem desvios. O projeto é o software e o software é o projeto.

Podemos, sim, ter um plano geral, um conjunto de guias e processos a serem seguidos, interfaces definidas, padrões e tudo mais, mas é preciso adaptação rápida à mudança. Na criação (e não construção, isso é importante) de um jardim, uma planta pode não se desenvolver por um entre vários fatores. Na criação de software, uma especificação da equipe de arquitetura pode não se encaixar nas necessidades do projeto.

Se houver uma “equipe de arquitetura” como uma entidade especial, separada, perde-se muito tempo para reagir às mudanças. Se os arquitetos são do tipo que se acha bom demais pra se sujar na programação as conseqüências são ainda piores – em primeiro lugar porque eles não tem noção da realidade do projeto enquanto fazem os planos e, em segundo, porque tendem a resistir à mudanças no que consideram um plano perfeito.

Se insistíssemos em utilizar a metáfora da construção civil, podemos comparar todo o ciclo de desenvolvimento de software com o ciclo de arquitetura e projeto de um edifício, excluindo sua construção. O desenvolvimento de software é uma atividade criativa, não “mecânica”.

Um desenvolvedor de software que não se atenta à arquitetura, que não tenta melhorar nos fundamentos básicos necessários ao entendimento do software como um todo, não passa de um programador – um mero codificador, facilmente substituível.

Um arquiteto de software que não programa, não se envolve com o dia-a-dia da produção de software e não se interessa pelos outros aspectos da disciplina, não passa de um “masturbador mental de software“. Daí para o que os americanos chamam de “Death by PowerPoint” leva um piscar de olhos.

Sim, é necessário que tenhamos a figura do “líder técnico”, aquele desenvolvedor com bastante experiência e jogo de cintura, que já viu e já fez de tudo na área. Ele, inclusive, pode ter o cargo formal de arquiteto de software. O que não pode acontecer é que ele seja um profissional isolado em uma esfera de cristal, um “deus” criando o que ele pensa ser adequado, dando ordens e ignorando eventuais questionamentos de sua intocável arquitetura. Isso é tudo o que um time de verdade não precisa.

Em resumo, um bom desenvolvedor é também um bom arquiteto. E um bom programador. E um bom qualquer coisa que seja necessária para criar software consistentemente.

O ActiveSupport mexeu no seu logger? Recupere a formatação original!

Recentemente estava escrevendo um script de manutenção utilizando o logger padrão do Ruby e tudo estava indo muito bem. A formatação padrão do logger oferece uma boa quantidade de informação, com timestamp, id do processo, nível da mensagem (erro, informação etc), como na imagem abaixo:

Formatação padrão do logger

Pouco depois, resolvi utilizar o ActiveRecord (que carrega junto o ActiveSupport) no script. Feito isso, o output do logger mudou para:

Formatação com ActiveSupport

Isso não é bom. Pesquisei um pouco e descobri que o ActiveSupport modifica a formatação padrão utilizando uma classe chamada SimpleFormatter ao invés da classe Formatter padrão do logger.

Desta forma, recuperar a formatação original é simples, basta modificar o formater utilizado pela sua instância do logger:

log = Logger.new(STDOUT)
log.datetime_format = "%d-%m-%Y %H:%M:%S"
 
# Recuperando a formatação original
log.formatter = Logger::Formatter.new

Também é possível alterar o formatter padrão na classe Logger. Dessa forma todas as instâncias utilizarão o formato padrão:

# Fazer isso após carregar o ActiveSupport para reverter a alteração do formatter
class Logger
  def formatter
    @formatter = Formatter.new
  end
end

Utilizando rack-debug para debugging com Passenger

Desenvolver aplicações Rails utilizando o Phusion Passenger (principalmente no Mac OS X com o Passenger preference pane) é muito prático. Porém, uma coisa que logo senti falta foi a possibilidade de utilizar a gem ruby-debug quando precisava de breakpoints para debuggar o código.

Uma maneira de conseguir isso é através da gem/plugin rack-debug. Para utilizá-la, segui os passos abaixo.

1. Instalação

 $ script/plugin install git://github.com/ddollar/rack-debug.git
 
 # config/environments/development.rb
 config.middleware.use "Rack::Debug"

2. Chamar o debugger onde necessário:

  def create
    @status = current_user.statuses.create(params[:status])
    debugger
    if @status.valid?
...

3. Conectar-se ao debugger

 # No diretório da aplicação, chamar a task rake
 $ rake debug
 Connected.

4. Ao executar a linha onde o debugger foi chamado, a aplicação para e você tem acesso ao console do debugger

 (rdb:1) p @status
 #<status id: 231, text: "Testing rack-debug", user_id: 4, ...>

Pronto. Happy debugging!

Update: ao chamar a task rake, pode ocorrer um erro com a mensagem “Server is not running or Passenger has spooled down”. Neste caso, reinicie o Apache e tudo deve funcionar normalmente.

Seu chefe é incompetente? A ciência explica!

Pesquisas feitas na Universidade de Catania, na Itália, mostram que, quanto mais promoções, mais incompetente é o profissional. A pesquisa foi feita a partir do chamado Princípio de Peter, formulado pelo psicólogo canadense Laurence J. Peter, com a seguinte frase (original, em inglês): “Every new member in a hierarchical organization climbs the hierarchy until he/she reaches his/her level of maximum incompetence”.

A explicação é simples: no sistema de promoção por mérito, pessoas muito boas em dada especialidade são promovidas para outras áreas, para as quais podem ser menos aptas (claro, isso só ocorre quando a promoção leva o profissional a uma área em que suas habilidades atuais não são fundamentais). Dessa forma, cair nas garras do Princípio de Peter torna-se inevitável, levando a empresa a uma perda geral de eficiência ao longo do tempo.

A solução, segundo os cientistas, é reservar 50% das promoções para os piores profissionais da empresa – a chance de que eles “se encontrem” nos cargos aos quais são promovidos é muito maior.

Que desenvolvedor de software nunca topou com esse tipo de problema? Aquele cara, ótimo desenvolvedor, acaba sendo promovido à gerente (e aceita, seja pela grana, pelo status ou por falta de opção) e é simplesmente um zero à esquerda na função. É claro que isso acontece em qualquer área, mas é nesta em que eu tenho experiência.

Podemos tirar duas lições disso:

• Se, por ser um ótimo desenvolvedor, você for agraciado com uma promoção para outra área, pense duas vezes antes de aceitar – isso pode significar o fim da sua carreira como profissional competente. Se a empresa não lhe der opção (é bem comum que só se consiga um aumento aceitando uma promoção-bomba dessas), procure outro lugar – quando você realmente é competente, escolhas não faltam.
• Se você se tornar um empreendedor, primeiro busque ajuda especializada caso não se sinta à vontade com as tarefas necessárias nesse seu “novo cargo”. Você pode ser um ótimo designer com uma ótima ideia, mas isso não quer dizer que será um bom empresário. Além disso, pense bem na política de promoção que vai utilizar se a empresa for bem sucedida. Um exemplo: pode ser muito mais satisfatório recompensar os bons funcionários com melhorias salariais do que promovê-los a cargos para os quais eles não possuem aptidão.

Cuidado com o DRY nos seus testes

Don’t Repeat Yourself é um dos princípios de desenvolvimento de software mais “badalados” nos últimos tempos. O problema é que, como tudo que se torna popular, isso acaba sendo abusado. Numa tentativa de criar código limpo é comum criar código difícil de entender. Isso afeta principalmente os testes.

Testes devem ser extremamente legíveis. Não deve existir sobrecarga cognitiva, isto é, não deve ser necessário entender o código do teste para então entender o comportamento que ele especifica – isso deve ficar claro rapidamente. Exemplos de sobrecarga são a necessidade de “ficar pulando” entre vários arquivos ou “descriptografando” lógica mágica para entender o código do teste.

É fácil, então, identificar dois tipos de recursos que podem causar problemas no entendimento dos testes – há uma tênue linha separando o bom e o mal uso deles: macros e “magia negra” em forma de código Ruby.

Macros devem ser utilizadas com muito cuidado. É interessante utilizar macros que encapsulam código simples para economizar tempo na criação dos testes, como essa macro para especificar ações autenticadas com o Authlogic:

def login_as(user)
  activate_authlogic   #this is from Authlogic::TestCase
  UserSession.create({:email => user.email, :password => user.password})
end

Macros com muito código ou que utilizam outras macros devem ser evitadas.

Um problema provavelmente mais grave é a utlização de algumas técnicas de “magia negra” no código. Aquela técnica super obscura e bacana envolvendo o Enumerable que você viu num blog esses dias não deve ser usada nos testes (nem na lógica de negócios, na minha opinião): foque sempre nos idiomas comuns da linguagem. Por simples falha da minha memória agora, segue um exemplo bobo, mas válido:

# truque menos conhecido
%w(this is a test) * ", "    #=> "this, is, a, test"
 
# idioma comum
%w(this is a test).join(", ")    #=> "this, is, a, test"

Os testes, quando usados corretamente, também são a porta de entrada de novos desenvolvedores ao código já existente na aplicação. Pode ser que sua equipe seja formada por Rubistas experientes que conheçam todos os truques envolvidos, mas a adaptação de um profissional com menos experiência na linguagem pode ser muito facilitada por testes com código simples e altamente legível, mesmo que isso “custe” alguma repetição ou uso de construções mais comuns.

A conclusão é: em todo seu código e principalmente nos testes, evite o uso de macros que escondem muito código ou lógica relevante ao comportamento especificado e também prefira idiomas comuns, mesmo que você saiba técnicas “ninja” da linguagem.