Bjarne Stroustrup também lê o "Micos"

Lembram-se dos posts recentes sobre o desencontro entre universidade e indústria? Pois parece que o criador do C++, Bjarne Stroustrup, também leu e resolveu escrever a sua versão, que aparece na Communications of the ACM de Janeiro 2010. O artigo se chama "What should we teach new software developers? Why?" (obrigado Guilherme pelo share no Reader).

Se você se interessa pelo tema, leia o artigo agora ou durante o feriado. É bem legal e mais bem escrito que os meus, apesar dos meus serem mais precisos e menos genéricos em suas colocações, modéstia a parte.

Um bom Natal para todos!

Papai Noel, me dê usuários no Natal

Sim, Dezembro é um mês lento para os miquinhos que só conseguem sonhar com sonecas debaixo de coqueiros em praias tropicais. Enquanto isso não acontece, vamos falar sobre aqueles que são ao mesmo tempo a bênção e a maldição de todo sistema: os usuários.

Ter usuários é uma benção. Se você não tem usuários, todo seu esforço foi em vão, inútil, jogado fora. Todo sistema quer ter usuários pra provar pra si mesmo que merece existir. Não ter usuários resulta em aposentadoria precoce.

Ao mesmo tempo, ter usuários é uma maldição terrível. A partir do instante em que o primeiro deles clica o primeiro botão no seu sistema novinho em folha e recém-lançado, seus problemas começam. Os problemas são:

1. Dados

Enquanto não há dados de ninguém no seu sistema além das coisas engraçadinhas que você colocou lá nos seus testes, você pode mudar e desmudar o que quiser. Quando aparece a primeira informação de verdade, você passa a ter problemas. Não é mais possível fazer aquelas pequenas ou grandes mudanças sem pensar no efeito das mudanças sobre os dados que estão lá. Infelizmente o efeito é muitas vezes devastador: além de mudar seu sistema, você precisa transformar os dados existentes em dados que tem as propriedades novas que você quer. Tudo isso, é claro, enquanto seus usuários não param de jogar dados que você não quer pra dentro do seu banco de dados.

A solução: ao projetar seu sistema, antecipe as dificuldades de migração de dados e crie mecanismos para fazê-la facilmente. Por exemplo, garanta que sua camada de modelo é capaz de duplicar toda escrita em dois canais diferentes e ler de ambos também. Assim, você conseguirá fazer uma transição suave durante a qual tudo é escrito nas duas bases de dados. Quando isso estiver funcionando, você pode desligar a escrita na base antiga e ir copiando os dados para a base nova, enquanto o sistema continua funcionando e lendo das duas bases.

2. Comportamentos

Seus usuários vão se esforçar pra aprender a usar seu sistema. Como não desistiram, presumo que seu sistema seja bom. Acontece que se você mudar qualquer coisa que atrapalhe o esforço que eles investiram no aprendizado, eles vão te odiar, mesmo que a mudança tenha sido pra melhor. Aliás, não importa o que você faça, alguém sempre vai odiar.

Imagine que seus usuários tinham um limite ridiculamente pequeno de dados que podiam guardar no seu site. Imagine agora que de um dia pro outro você acabe com os limites e permita uso ilimitado. Toda funcionalidade permaneceu inalterada. Eu aposto o dinheiro que você quiser que algum infeliz vai reclamar e dizer que preferia quando tinha limites, pois forçava ele a se organizar melhor. A vida é assim.

A solução: como eu queria ter uma solução pra esse problema... o máximo que se pode fazer é tornar cada  atualização a menor possível. Se você quer fazer várias atualizações, contenha-se e faça uma de cada vez para dar aos usuários o tempo pra se acostumarem com a nova forma de se usar o sistema. Se você quer fazer mudanças radicais, permita que os usuários retornem ao modo antigo de ser, pelo menos durante um tempo.

3. Comunicação

Você mudava qualquer coisa e só tinha de virar pro lado e avisar pro seu colega que a mudança estava pronta. Agora não é mais tão simples assim. Os usuários não entendem quando coisas mudam sem explicações. Toda vez que alguma coisa relevante mudar (tipo toda semana) você vai ter de dar um jeito de explicar aos usuários. O problema é que é difícil ser ouvido. Ninguém quer ler seu blog e ninguém lê as mensagens que você coloca na página de login. Se você deixa um espaço na página principal do seu sistema pra avisos importantes, os usuários logo desenvolvem cegueira seletiva e param de ver o que está lá.

A solução: se quiser mesmo comunicar com seu usuário, varie. A regra básica é colocar seu comunicado o mais próximo possível do local em que o usuário vai usar o que está escrito. Se é uma funcionalidade nova, coloque um "novo!" discreto ao lado do botão ou seja o que for. Um balão estilo estória em quadrinhos apontando para a novidade também é uma boa. Deixe que o comunicado seja uma surpresa. Outra coisa importante é deixar que o usuário retire o comunicado da tela e que ele não apareça mais.



Há outros problemas, é claro, mas esses ficam pra outros posts. Os micos de realejo vão dar uma parada para os feriados e férias, mas voltaremos no final de Janeiro a todo vapor.

Boas festas!

Quem faz a manutenção do seu sistema?

Saiu um artigo sobre manutenção de software na Communications of the ACM de Novembro. Manutenção é um dos meus assuntos favoritos, porque é bem mais difícil cuidar de sistemas existentes do que criar sistemas novos.

Só pra definir e situar todo mundo, manutenção de software é o nome que se dá para a fase do ciclo de vida de um sistema que começa no instante em que o sistema é colocado em funcionamento. É comum se classificar em três os diferentes tipos de manutenção. O primeiro tipo é a manutenção corretiva, ou seja, corrigir bugs. O segundo tipo é a manutenção evolutiva, ou seja, acrescentar novas funcionalidades. O último tipo é a manutenção adaptativa, que significa mudar o sistema para se adaptar a mudanças no ambiente em que ele funciona - por exemplo, porque saiu o Internet Explorer 9 e seu sistema ficou todo quebrado.

Não gostei do artigo. Os problemas que os autores usam para motivar seus argumentos não são reais. O artigo até seria bom se tivesse sido escrito em 1989, mas vinte anos depois as coisas são diferentes. Na era da internet, todo software é software em evolução. Não existe mais o conceito de software que não é criado com a evolução e manutenção em mente. Nunca trabalhei em uma empresa que não achasse isso importante e não tentasse planejar de acordo.

É claro que existem problemas interessantes envolvendo a manutenção de software. Hoje vou falar sobre um deles: quem deve fazer a manutenção. Na semana que vem falarei sobre outros.

Primeiro, preciso fazer uma confissão. Eu adoro fazer manutenção. Corrigir bugs então, nem se fale. Posso passar dias, principalmente bugs em código que eu não escrevi. Não, eu não estou sendo irônico, eu sei que a maioria dos programadores detesta isso. Pois pra mim não tem nada mais divertido. Quando estou procurando bugs em código que eu não conheço, eu me sinto um detetive investigando um mistério. Preciso tentar descobrir o que o código faz, por que faz o que faz, o que estava passando pela cabeça do programador que o escreveu. E no final tem um prêmio concreto: remover o bug! Bom demais.

Também gosto muito de fazer a evolução de código que eu não escrevi. Gosto de olhar para o design do sistema e tentar pensar em um design mais adequado à mudança que eu quero fazer. Não tenho a mesma motivação para mudar código que eu mesmo fiz. Eu olho para aquilo e penso no trabalho que já deu pra escrever, e não quero mudar tudo de novo. Quando o código não é meu, não tenho esse bloqueio.

Bom, voltando ao assunto. É comum entregar a manutenção de sistemas existentes aos desenvolvedores menos experientes, deixando os programadores que tem super-poderes livres para trabalharem nas novas idéias que vão render um trilhão de dólares. Para mim, isso é um erro. Deixar a evolução nas mãos de pessoas que não conhecem bem os motivos por trás das decisões que levaram o sistema a ser como é leva inevitavelmente à degradação acelerada da qualidade do código. O desenvolvedor que faz mudanças pontuais sem levar em consideração o design geral do sistema torna o código cada vez menos estruturado.

Quando projetamos um sistema novo, temos um grau elevado de liberdade para tomar decisões técnicas. Existe um número quase infinito de caminhos corretos que vão levar ao sistema que queremos construir. Fazer manutenção, por outro lado, implica em trabalhar com muitas restrições. Existem muitas maneiras de se fazer o que precisa ser feito, mas poucas maneiras corretas.

A não ser que seu objetivo seja abandonar o sistema a curto prazo em prol de um novo sistema que está sendo desenvolvido, deixe que os melhores programadores cuidem dele. Assim ele vai crescer com saúde e alegria.

Ah, tem uma exceção: eu acho que corrigir bugs é a melhor forma de introduzir um novo desenvolvedor a um sistema existente. É uma tarefa concreta que exige que o programador aprenda muito sobre as entranhas do código e sobre o design dos componentes. É só garantir que todas as mudanças serão revisadas por um desenvolvedor experiente para que o exercício não vire um problema depois.

Se Fernando Pessoa também fosse mico

Se Fernando Pessoa fosse um mero micoderealejo, ao invés de escrever isso, ele talvez escreveria isso:

Fazer um software e reconhecê-lo mau depois de feito é uma das tragédias da alma. Sobretudo é grande quando se reconhece que essa obra é a melhor que se podia fazer. Mas ao escrever um software, saber de antemão que ele tem de ser imperfeito e falhado; ao está-lo escrevendo estar vendo que ele é imperfeito e falhado _isto é o máximo da tortura e da humilhação do espírito. Não só as linhas que escrevo sinto que me não satisfazem, mas sei que as que estou para escrever me não satisfarão, também. Sei-o tanto filosoficamente, como carnalmente, por uma entrevisão obscura e gladiolada. (...) E o maior castigo é o de saber que o que escrevo resulta inteiramente fútil, falhado e incerto. Em criança escrevia já meus códigos. Então escrevia-os muito maus, mas julgava-os perfeitos. Nunca mais tornarei a ter o prazer falso de produzir o programa perfeito. O que escrevo hoje é muito melhor. É melhor, mesmo, do que o que poderiam escrever os melhores. Mas está infinitamente abaixo daquilo que eu, não sei porquê, sinto que podia _ou talvez seja, que devia_ escrever. Choro sobre os meus códigos maus da infância como sobre uma criança morta, um filho morto, uma última esperança que fosse.

Vai me dizer que não concorda com o nosso Fernando Pessoa imaginário?

Por sugestão do Hermes, adaptei este texto de Fernando Pessoa substituindo 'versos' por 'linhas de código' ou apenas 'código'. Também substituí 'obra' por 'software' ou 'programa', e a parte que eu não consegui simplesmente aplicar um sed 's/verso/código/' | sed 's/obra/programa/' removi.

Por favor, não me crucifique pelo, digamos, plágio! Vai me dizer que nunca copiou-e-colou um código e aplicou alguns sed para acertar os detalhes?