Divagações

Ascenção e Queda de Scrum

Bom, para os que não sabem ainda, eu trabalho como Analista de TI na Universidade Federal do ABC. Ano passado (2009), tive a difícil missão de criar uma divisão de desenvolvimento de sistemas, de forma que ela atendesse um monte de demandas. Além disso, o TI já tinha 3 anos de existência e nunca tinha-se sequer rascunhado uma divisão de desenvolvimento, porque as primeiras chefias do Núcleo de TI tinham a idéia de que não haveria desenvolvimento de software dentro da UFABC. Enfim, problemas à parte…

Estudos foram feitos. Já havia uma série de scripts escritos todos em Ruby para facilitar um número de tarefas, e também já existiam dois projetos de Rails publicados, então parecia no mínimo estranho usar uma linguagem ágil, com um framework ágil (que inclusive possui geradores de código) e adotar uma metodologia tradicional. Artigos também com o do professor Xexéo, da UFRJ, auxiliaram a mostrar que existe uma frente acadêmica que abraça mudanças (já escrevi em posts anteriores que o Brasil é um país que valoriza mais do que deveria os diplomas e títulos). Anyway, aos fatos:

(more…)

By Maurício Szabo, ago

A importância do código-fonte

Talvez o nome deste post seja estranho, em um blog tão focado à programação. Porém, vale um pouco de história.

De duas semanas para cá, estou escrevendo um artigo para tentar apresentar no Workshop Brasileiro de Métodos Ágeis. Inclusive, eu recomendo a todos que trabalham a um certo tempo com uma linguagem, tecnologia, etc, que escrevam um artigo sobre o assunto, mesmo que não seja em formato científico, só para organizar as idéias. Ajuda bastante a focalizar seus próximos passos. Porém, esse não é o assunto. O assunto é bem simples, na verdade:

Design de Software.

Tentei traçar as origens da tal “metodologia em cascata”, e não consegui. O artigo mais antigo que eu cheguei foi de Winston Royce, em 1970 (sim, 1970 – é difícil de acreditar que a maioria das metodologias de desenvolvimento de software de hoje se baseiam numa idéia que surgiu a 40 anos atrás), e Royce sequer nomeia a metodologia. Na verdade, ele apresenta o desenho típico de uma metodologia em cascata e comenta: “a implementação acima é arriscada e convida à falhas”. Seria possível que, na informática, alguém em 1970 apresenta o modelo que mais tarde seria chamado de “cascata”, diz para as pessoas não usarem, e as pessoas começam a usá-lo? Bom, sendo informática, eu não duvido de nada (nem de doutores em engenharia de software citando que até uma metodologia em cascata é melhor do que as metodologias ágeis – sim, eu ouvi isso). Enfim…

Mas, voltando ao tópico – a metodologia que Royce propôe enfatiza a documentação. Mais tarde, essa documentação seria unificada pela UML, e uma série de estudiosos iriam “contribuir” para a tal UML, criando mais e mais diagramas… além daquelas coisas obsoletas, tipo fluxograma, “teste de mesa”, etc etc. Aqui, vale a pena citar Jack Reeves, que pergunta em seu artigo (de 1992): “O que é design de software?”. O artigo é extenso, mas transcrevo umas partes aqui:

O objetivo final de qualquer atividade de engenharia é algum tipo de documentação. Quando um trabalho de design foi completado, a documentação é entregue à manufatura. Eles são um grupo completamente diferente, com habilidades completamente diferentes do time do design. Se a documentação realmente representa um design completo, o time da manufatura pode proceder para construir o produto. De fato, eles podem proceder para construir uma grande parte do produto, sem qualquer intervenção dos designers. Depois de revisar o ciclo de desenvolvimento de software, da forma que eu entendo, eu concluo que a única documentação de um software que, na verdade, satisfaz o critério de uma documentação de design é o código-fonte.
(more…)

By Maurício Szabo, ago

A arte de desenvolver

Pode parecer estranho, mas desenvolver aplicativos é uma arte. É difícil, de verdade, fazer as pessoas entenderem isso.

Programação precisa de conceitos? Ótimo, música e pintura também. Também é necessário aprender a pensar da forma que a ferramenta que você usa para desenvolver (ou tocar, em caso de música) pede. Provavelmente, o improviso que você faria em um violão não será o mesmo de um violino, ou de um piano – da mesma forma, o código que se escreve em uma linguagem não segue os mesmos padrões de outras linguagens, e tentar negar isso é absurdo no mínimo.

Para os que programam mesmo, sempre há aquele amigo que quando lê um código, praticamente em qualquer linguagem, aponta na hora aonde está o erro. Ele está simplesmente adivinhando? Há uma máxima que a maioria das pessoas de desenvolvimento de sistemas esquece: “O código é muito mais lido do que escrito”. Da mesma forma, há uma citação atribuída à Donald Knuth, professor de renome da universidade de Stanford que diz: “Code is written for humans to read and only incidentally for computers to execute”. Continuando com o compacto, ao mesmo tempo em que um desenhista precisa ver muitos desenhos, visitar galerias de arte, ver as tendências, o programador deve também estar atento a essas coisas. Há um framework muito legal que as pessoas estão falando? Leia o código dele. Faça um pequeno projeto. Aprenda uma nova linguagem, nem que seja Haskell, Lisp, Smalltalk, ou outras linguagens que quase não tem repercursão comercial. No mínimo, você terá feito algo inútil. No máximo, você estudará uma linguagem nova e tentará aproveitar conceitos interessantes dela em outros projetos.

(more…)

By Maurício Szabo, ago

Liberdade – fora com ela!

Imaginemos uma situação hipotética: você vai até uma loja de roupas famosa, que possui as roupas mais duráveis e bonitas e escolhe uma calça. Na hora que você vai pagar, você tem o seguinte diálogo com o atendente:

Atendente: Bom dia, senhor. Antes de pagar, o senhor sabe que você não pode usar essa calça para ir para festas, não sabe?
Você: Desculpe… como assim?
A: O fabricante dessa calça proíbe terminantemente de usar a calça em festas, baladas, raves, ou similares…
V: Como é?
A: E também, você vai encontrar na etiqueta da calça um site. Note que apenas as roupas listadas naquele site podem ser usadas com essa calça…
V: Desculpe, do que você está falando? Quer dizer que o fabricante recomenda as roupas que eu posso usar com essa calça?
A: Não, senhor, o senhor entendeu mal. O fabricante proíbe que você use qualquer outra roupa com essa calça. Caso o senhor seja pego usando uma roupa diferente do que ele citou no site, confiscaremos a calça e o senhor terá que pagar uma multa…
V: Desculpe, eu gostaria…
A: Aproveitando, o senhor não pode modificá-la, alterá-la, tingí-la…….

Parece absurdo? Bom, de fato é. Mas então, por que as pessoas concordam que a Apple faça isso com seus produtos? O mais novo brinquedinho deles, o iPad, é tão restritivo quando o iPhone, que por si só já é o maior absurdo tecnológico da história – mas não, é Apple! Tem que ser bom, não?

(more…)

By Maurício Szabo, ago

A saga da busca em bancos de dados

Num mundo perfeito, todos os sistemas de armazenamento se conversariam, a nível do servidor e não do cliente, e jamais precisaríamos manualmente definir por “joins”, ou seja lá qual a forma que seu banco de dados faz.

Claro, o mundo não é perfeito.

Nesse caso, precisamos no mínimo padronizar uma forma de buscar dados. A maioria dos sistemas relacionais entende SQL, embora isso também não seja padronizado. Pior ainda, se for necessário buscar uma informação que está em uma tabela da base de dados X, e uní-la (join) com uma da base de dados Y, temos que fazer a busca manualmente.

Entra, aí, uma idéia.
(more…)

By Maurício Szabo, ago

A importância de vegetar um pouco

Parece estranho o título de um post assim, mas vamos lá:

Quem nunca parou para olhar o céu, imaginar desenhos nas nuvens? Quem nunca ficou escutando uma música, e parou tudo o que estava fazendo só para ouvir a letra, imaginar um cenário, sei lá? Pegar uma folha de papel, encher ela com desenhos de bonecos ou escrever as primeiras palavras que vem na sua cabeça, por menos sentido que elas façam?

Pra que tudo isso? Vegetar faz bem, por menos sentido que isso pareça fazer. Faz bem não pensar em nada de vez em quando, liberar sua mente de qualquer idéia, e deixar que as coisas fluam. Parece meio loucura isso, mas eu sempre sinto que eu produzo mais quando não estou pensando ativamente naquilo que estou fazendo, simplesmente deixando “fluir”. É como tocar piano – quanto mais você tenta acertar o movimento das duas mãos, mais difícil fica. Mas quando você “esquece” de prestar atenção, parece que a coisa vai mais fácil.

(more…)

By Maurício Szabo, ago