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.

“This is one of the reasons I encourage entrepreneurs to bootstrap instead of taking outside money. On day one, a bootstrapped company sets out to make money. They have no choice, really. On day one a funded company sets out to spend money. They hire, they buy, they invest, they spend. Making money isn’t important yet. They practice spending, not making.”

– Jason Fried (37signals) em “Making money takes practice like playing the piano takes practice”

Escrevi dois posts para, no fim das contas, não conseguir expressar a mensagem. Minha falha foi tentar explicar demais o raciocínio ao invés de simplesmente expressar a conclusão (e ainda causei alguns acidentes no caminho). Pronto, através das palavras do Jason Fried, está aí tudo que eu quis dizer sobre o tema.

PS: Sim, os dois posts anteriores foram para o limbo. Como em todo processo criativo iterativo, as tentativas fracassadas podem ser descartadas.

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

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.

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.

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.

No entanto, é preciso ter bastante cuidado. Métricas são como muletas: muito úteis quando você não consegue andar sem a ajuda delas mas, se você utilizá-las sem necessidade, vai enfraquecer suas pernas.

Um bom exemplo disso é uma métrica muito utilizada por quem escreve testes: a cobertura de código. É uma ferramenta muito útil quando é preciso “correr atrás” do prejuízo, isto é, adicionar testes a código sem cobertura. Nesse caso, é prática comum estabelecer uma porcentagem de cobertura a ser atingida dentro de um prazo limitado. Mas, se você pratica BDD/TDD consistentemente e não deixa código importante sem cobertura, é realmente necessário confirmar isso com um gráfico ou uma porcentagem?

O uso e confiança cega em métricas mesmo sem necessidade de um amparo como esse pode levar à má aplicação da técnica do desenvolvimento guiado por testes, já que ela passa a ser baseada em um número artificial – é muito fácil ter 100% de cobertura de código com uma suíte de testes ruim. Antes uma suite boa mas que, conscientemente, não passa por cada linha de código do que uma suite que execute cada linha, mas seja um lixo como especificação e ferramenta de refactoring.

Mais um exemplo de fragilidade fica claro no famoso e cantado aos quatro ventos code to test ratio: ao utilizar um framework de testes verboso, é fácil obter uma razão de linhas de teste por linhas de código muito maior do que utilizando um framework mais compacto ou macros. Me desculpe quem utiliza e divulga esse número como algum indicativo de qualidade, mas essa medida é simplesmente ridícula, além de totalmente ilusória.

Uma técnica comum é utilizar um mock ou stub na classe Time do Ruby para manipular o horário de acordo com o desejado. Isso vai contra um princípio importante do uso de fake objects em testes: “Não use fakes em objetos que não são seus“. Na maioria do tempo isso pode não causar problemas, mas alterar o comportamento de uma classe usada internamente pela linguagem não soa bem e pode causar bugs difíceis de rastrear.

Aí entra a gem time-warp. Ela ainda trabalha sobre as classes do Ruby, mas provê uma camada específica para testes para todo código executado em um bloco definido pelo programador. Um exemplo de uso (da nossa aplicação feita para o Rails Rumble):

it "should only silence tweets with the desired word inside the configured time interval" do
  pretend_now_is(Time.now.utc.beginning_of_day + 1.hour) do
    tweet1.sent_at = 2.minutes.ago
    tweet2.sent_at = 32.minutes.from_now
    tweet3.sent_at = 1.hour.from_now
 
    collection = [tweet1, tweet2, tweet3]
 
    Silencer.apply(collection, {:word => "soccer", :until => 30.minutes.from_now})
  end
 
  tweet1.should be_filtered
  tweet2.should be_filtered
  tweet3.should_not be_filtered
end

A gem adiciona o método “pretend_now_is”, que recebe um parâmetro com o horário desejado e um bloco. Dentro desse bloco, todo código executado é “transportado no tempo” para o horário definido. Além de tornar a manipulação das classes de tempo mais segura, o código fica muito mais elegante.

Veja mais detalhes no README da gem.

Não, ainda não sou uma pessoa super-mega-produtiva, mas aqui está como consegui aumentar minha produtividade usando alguns truques (e o incrível sistema operacional que é o Mac OS X em conjunto com ótimas aplicações):

• Não verifique seu e-mail mais de quatro vezes ao dia: se você está esperando algum e-mail importante, peça para quem for enviá-lo que te avise quando isso acontecer, usando, por exemplo, uma SMS;
• Não verifique seu e-mail se você sabe que não estará apto a agir sobre alguma mensagem imediatamente: por exemplo, verificar seu e-mail de trabalho no final da tarde de Sexta – deixe para fazer isso na Segunda;
• Livre-se dos feeds que você assina: você não vai realmente sentir falta deles sem ficar um tempo longe. Se, após alguns dias, você sentir muita falta de ler um deles, assine-o novamente, mas não verifique seus feeds mais do que uma vez ao dia. Essa é uma excelente técnica para descobrir o que é realmente importante dentre tudo que você consome;
• Deixe que as pessoas sejam seu filtro: acredite em mim, se algo é realmente importante (ou banal, mas “quente”), vai chegar a você. Você não precisa ficar garimpando. O recurso de “shared items” do Google Reader é excelente nesse ponto – estou à caminho de usar apenas ele, me livrando de todos os feeds que assino (são por volta de oito hoje). Quando realmente precisar encontrar algo, o Google é seu amigo;
• Desabilite notificações desnecessárias: como muitas do Growl ou os “contadores vermelhos” nos ícones de aplicações na Dock do OS X – mantenha apenas as que você realmente precisa (por exemplo, eu mantenho as notificações do Propane, já que é importante saber o que meus colegas de trabalho dizem no Campfire);
• Não use um monitor muito grande: isso pode parecer estranho, mas pesquisas mostram que, após aproximadamente 26 polegadas, o tamanho do monitor diminui a produtividade. É óbvio: muitas coisas no seu campo visual vão lhe distrair. Use o Spaces e divida as telas de acordo com a tarefa (uma para programação, uma para navegação na internet etc);
• Aumente o espaço livre na sua tela eliminando itens do seu Desktop: configura o Finder para não exibir discos rígidos (eu deixo apenas discos ópticos e dispositivos removíveis). Elimine da Dock as aplicações que você não usa muito frequentemente. Use o QuickSilver ou algo similar para acessar as aplicações e arquivos que você não usa frequentemente, apenas não deixe que eles se empilhem na Dock e no Desktop;
• Elimine da Menu Bar os itens que você não precisa, como o ícone de status do Bluetooth, o indicador AM/PM se você usa o formato americano (é fácil saber isso olhando pela janela), o ícone do Time Machine etc;
• Use o Adium e configure-o para que fique oculto a menos que seja a aplicação ativa (veja aqui: ativo, inativo, configurações 1, configurações 2);
• Use o Fluid para criar SSBs para as aplicações web que você precisa para trabalhar: o motivo para isso é evitar ter um browser repleto de abas abertas te distraindo enquanto você usa uma aplicação para trabalhar. Com as aplicações Fluid você pode focar apenas na tarefa à mão;
• Use o Tags para facilitar o processo de organização e busca de arquivos.

É difícil tomar algumas dessas ações, como se livrar dos feeds que você assina – especialmente porque o número de feeds assinados geralmente é motivo de “disputazinhas” entre nerds/geeks. É estupidez pura, como competir para ver quem dorme menos e fica acordado programando por mais tempo.

De qualquer modo, dê uma chance. Após algum tempo (eu recomendo tentar por, pelo menos, dez dias), você vai sentir falta das coisas que realmente precisa e pode tê-las novamente assim que quiser.

Update: Como bem notado pelo ArthurGeek, a imagem de configuração do Adium para que a lista de contatos se esconda automaticamente estava errada (a que eu chamei de “configuração 2″). Arrumei o link e deixo aqui também: http://yfrog.com/avpicture12xp.

–

Também em inglês.

A intenção é ter algo que possa ser consumido em pouco tempo, resultando numa base sólida para o desenvolvedor profissional (ou seja, não há tópicos básicos para iniciantes) e, ao mesmo tempo, ser mantido como referência (o asterisco denota meus itens preferidos).

Vídeos de conferências:

• Don’t Mock Yourself Out – David Chelimsky
• The Grand Unified Theory – Jim Weirich*
• Mock Dialogue – Joe O’Brien and Jim Weirich
• SOLID Object-Oriented Design- Sandi Metz*
• Testing Heresies – Francis Hwang*
• What Makes Code Beautiful? – Marcel Molina Jr

Artigos/Slides:

• Common REST mistakes
• Functional Programming For The Rest of Us* – finalmente alguém que explica programação funcional de forma simples, sem querer parecer um “sabe-tudo”
• How I Explained REST to My Wife* – ótimo artigo, sempre uma referência ímpar
• On The Shortness of Life: An Introduction to Seneca
• Smart Model, Dumb Controller – focado em Rails, mas vale para qualquer MVC
• Top ten things ten years of professional software development has taught me
• Web2.0: Why we got here and what’s next