Artesanato de Software
É comum ouvirmos por aà o termo “engenharia de software.” Existem livros sobre o assunto, disciplinas nas faculdades e até empresas que contratam “engenheiros de software.” Mas vamos deixar de lado o software por enquanto e pensar na engenharia, quando fazemos isso pensamos em uma forma estruturada e organizada para construir alguma coisa, se for engenharia civÃl então estamos falando de prédios e casas, se for engenharia mecânica de máquinas e assim por diante.
O que existe em comum entre essas formas de trabalhar é que todas tem suas peças e suas partes bem definidas, existem catálogos de peças e componentes. Existem especificações claras (as vezes nem tão claras) que determinam como as coisas devem ser encaixadas, juntadas, apertadas, afrouxadas, e por aà vai. As especificações podem ser encontradas, são elaboradas, verificadas, validadas e mais importate que tudo: controladas.
Então voltando ao software é engraçado falarmos em engenharia simplesmente porque não temos peças, componentes e nem catálogos. Não digo isso porque o software é abstrato e imaterial e sim porque ainda não temos a mesma maturidade que a engenharia. Costumo dizer que temos um artesanato de software, esse termo é engraçado porque aqui no Brasil isso nos remete a imaginar as pessoas que fazem artesanato e vendem em feirinhas. No entanto estou me referindo aos artesãos que trabalhavam no passado produzindo os bens de consumo, antes da revolução industrial.
Naquela época o que acontecia é que uma pessoa para produzir ou prestar serviços deveria ser aceita por um mestre-artesão que ensinaria o ofÃcio, depois de anos trabalhando praticamente de graça (não existiam leis que regulamentassem isso…) o aprendiz podia abrir a sua própria oficina e depois de algum tempo até ter seus aprendizes.
O resultado disso é que existiam “escolas” diferentes, isso é muito fácil de identificar quando falamos por exemplo de espadas, os mestres de espadas tinham suas formas de trabalhar que geravam espadas diferentes que eram melhores para situações de uso diferentes.
Mas porque isso tudo? Porque é exatamente isso que vivemos hoje no desenvolvimento de software! Embora falemos o tempo todo em engenharia, cada empresa acaba por desenvolver todos os pedaços e peças de seus sistemas muitas vezes sem nem mesmo avaliar o custo que haverá no futuro em manter essas peças!
Quando uma pessoa quer aprender o ofÃcio de desenvolvimento de sistemas, ela pode ler vários livros, mas a prática acontecerá sobre a tutela de um mestre artesão, tipicamente algum dos gurus da empresa onde essa pessoa for estagiar. Esse mestre artesão ensinará a sua escola, ou seja, a forma como se desenvolve software naquela empresa. Mesmo havendo por aà inúmeros frameworks e bibliotecas, ainda temos que aprender como juntar todas essas coisas, e é aà que está a arte do software.
Uma vez aprendendo aquela escola o aprendiz em algum tempo acaba por ser efetivado e depois de algum tempo talvez migrar para uma empresa nova, e aà será necessário aprender uma nova escola de desenvolvimento. O ciclo permanece se repetindo.
Não que esse modelo seja ruim, mas precisamos entender duas ideias que existem aqui:
- Artesanato não é engenharia, e por isso fica difÃcil atingirmos um modelo de reuso real
- O indivÃduo como artesão pode melhorar sua técnica de trabalho, considerando o interesse em melhorar suas habilidades
Sendo assim estou criticando o comportamento errado que temos as vezes de não ler manuais, livros e revistas, e tentarmos adivinhar como se usam as ferramentas. Essas “escolas” que existem dentro das empresas são na verdade nocivas ao desenvolvimento da área porque dificultam a evolução para uma real engenharia.
Porém estou sendo a favor do indÃviduo como artesão conforme exposto no livro The Pragmatic Programmer de Andrew Hunt e Davis Thomas, porque esse modelo favorece a evolução individual em relação a novas técnicas de desenvolvimento.
Bob Martin em sua palestra no Agile 2008 sugere o Manifesto for Software Craftsmanship considerando a visão número 2 que falei acima.
Então se quisermos tornar o desenvolvimento de software uma engenharia de fato, devemos primeiro aprender a ser bons artesãos, para que no futuro seja possÃvel termos bons engenheiros.
[...] Existem algumas outras disciplinas que fazem parte desse ciclo, cada curso tem a sua estrutura então não adianta falar de forma muito especÃfica. O objetivo é achar um caminho para que o aluno possa costurar essas informações. Sim porque diferente do que muitas pessoas acreditam o aluno deve ser um participante ativo e responsável pelo seu aprendizado também, não se pode ficar esperando simplesmente que o professor despeje toda a informação e pronto. O problema do isolamento é que no mercado de trabalho o aluno precisa saber encadear essas disciplinas formando um processo adequado, processo esse, aliás, que não conseguimos ensinar porque acaba não sobrando tempo. Isso é uma das coisas que reforça o artesanato de software. [...]
[...] Atualmente, o desenvolvimento de sistemas evoluiu muito e chegou ao artesanato de software (embora algumas pessoas preguem a engenharia…) o que também nos leva a desenvolver sistemas maiores e aà começamos a ter problemas com nossos clientes e usuários. Isto porque para fazer um sistema corporativo não podemos simplesmente sentar e sair programando. Precisamos identificar o que deve ser feito. O primeiro passo é identificar o problema, em seguida precisamos descrever o problema detalhadamente para então, tendo vislumbrado a solução do problema, consultar o nosso cliente/usuário para listar tudo que deve fazer parte do sistema (assumindo que a solução do problema realmente é um sistema.) [...]
[...] Identifique casos em que a variável de controle do loop é modificada – não é muito comum usarmos isso atualmente, com as regras e normas da bom artesanato de software, mas eventualmente o programador pode ter inserido uma condição na qual vai modificar a variável de controle causando retorno ou adiantamento do loop. [...]
[...] É muito comum acharmos nos livros de desenvolvimento de sistemas e de engenharia artesanato de software a defesa de que devemos preparar o software para reuso. No entanto, muitas vezes não fica claro como realizar isso na prática. É preciso entender que existem diferentes nÃveis de reuso, e mesmo copiar o código feito anteriormente e colar em um novo programa é um tipo de reuso (incipiente.) [...]
[...] e nos dedicarmos a melhorar nossas técnicas de desenvolvimento para evoluir a partir do artesanato de software, nossas aplicações podem ser executas em múltiplas plataformas sem precisarem ser [...]