Em um trecho do Autodesenvolvimento, eu comento que o maior feito de Tony Stark não foi a armadura em si. O feito foi o projeto inteiro. Imagine a quantidade de horas digitando código. Acho que, mesmo que ele tivesse todo o código de cabeça, não daria tempo de digitar todo o software daquela armadura. Não deixa de ser um desenvolvimento, mas eu compararia isso a operar o coração de alguém usando um clip de papel e whisky.
A resposta crua é: um desenvolvedor desenvolve. Como desenvolvedor, eu sempre apanhei para explicar o que exatamente eu fazia…
É, mas eu entendo que isso é simples demais. Então eu vou reformular a pergunta:
Como um desenvolvedor desenvolve? Quais as ações de um desenvolvedor?
O texto abaixo não ficou pronto para o livro, então segue a versão adaptada para o blog. Ja antecipo: não é nada como isso:
Planejamento
A parte de planejamento envolve definir quem vai fazer, quando vai fazer, até quando pode fazer, o que tem que fazer, o que precisa para fazer e por aí vai. O planejamento antes do desenvolvimento é estudado por uma ciência chamada “gerência de projeto” cujo objetivo é… bom, já sabem a resposta: gerenciar o projeto.
Nesta etapa o time de desenvolvimento é formado. As competências são avaliadas para garantir que o plano de projeto seja coerente com o que a empresa pode executar. Qualquer um pode montar qualquer plano de projeto, com qualquer prazo. Acertar são outros 500.
Normalmente, as etapas de planejamento contam muito com a influência do desenvolvedor, mas não necessariamente são executadas por ele. Eu tenho uma história legal sobre isso…
Um dia eu fui chamado para conversar com o meu chefe sobre um projeto. Ele disse:
-Me diga o prazo.
-Eu?
-O teu chute será melhor que o meu. Se depender de mim, eu vou te dar um prazo quase impossível.
Especificações
Especificar é maçante. É chato. MAS… É preciso. Qualquer atividade de desenvolvimento deve ter uma especificação, que é, no fundo no fundo, um detalhamento do que se quer construir.
“Deve ter uma tela touch e na tela touch deve ter um botão para acionar o menu de aplicativos”. Coisas deste tipo.
Todos os detalhes do funcionamento do futuro produto deveriam estar contidos na especificação. Deveriam, pois infelizmente, nem sempre é o caso. As vezes a especificação parte do cliente, chega a algum departamento comercial que “especifica de maneira genérica.”
Eu juro que já ouvi isso.
Uma especificação de maneira genérica é igual chegar em um restaurante, tal qual um sketch do Monty Python, e pedir:
-Garçom, eu quero carne.
-Mas qual senhor, um bife, picada, com algum molho?
-Ah, sei lá, carne.
A “Ação”
Escrever código, fazer diagramas. A atividade de desenvolvimento, quando precisa ser romantizada em filmes, normalmente termina tão distante da realidade que se formos comprar o que estão vendendo… O resumo é: não é daquele jeito.
Querem um exemplo? A pior parte dos filmes do Rocky, na qual coloca-se a rotina de acorda–come-treina-dorme com uma musiquinha funciona porque há movimento na tela. Agora imagine tentar fazer isso para um desenvolvedor de software: coloca-se um cara sentado. Por dias. Coloca-se um computador em sua frente. E uma tela, feito esta:
Todos devem concordar: não é emocionante para um filme e não há musica que salve. Aí começam a criar algumas abstrações: compiladores animados e gráficos que não colocam mensagem nenhuma na tela (ver o filme Swordfish).
A verdade, dura e simples, é:
- Longas horas contemplando uma “folha” ou “tela” em Branco (ou preto!)
- Rabiscos, Rabiscos, Rascunhos. Coisas para ajudar a organizar ideias.
- Um pouco de digitação. Um pouco de mouse clicando em componentes.
- Mais contemplação.
- Mais rabiscos.
- Mais um pouco de “ação”.
- E no outro dia, tudo de novo.
Tirando o conhecimento técnico de lado, fazer um projeto de hardware é muito parecido com ligar os pontos de blocos nos programas de criação de diagramas. Escrever software é, por enquanto, digitar. Definitivamente fazer hardware não é sair comprando sucata e montando algo.Criar um software não é acessar um terminal maluco de console e sair criando um monte de quadradinhos aleatórios…
Testes e debugging
Qualquer código escrito, no começo, sequer vai compilar, ou seja, vai virar programa, imagem e etc. Um projeto de hardware certamente vai ter alguns detalhes esquecidos. Depois da atividade criativa do desenvolvimento, temos a atividade de depuração, ou seja, varrer os erros do sistema. E mesmo depois disso, é conveniente testar o protótipo.
Testar coisas é complicado. Quando alguém constrói algo esperando que ele funcione, sua mente está orientada a não encontrar erros no seu projeto, afinal, um desenvolvedor faz coisas para funcionar. Em função disso, acaba que é preciso uma outra mente com o pensamento diametralmente oposto, ou seja, o testador, que está com a mente orientada para achar erros nos desenvolvimentos dos outros (afinal, o “produto” do desenvolvimento de um testador é o teste realizado, em si).
Porém, até mesmo o mais otimista desenvolvedor vai querer testar um mínimo das coisas que fez. é igual quando amarra-se uma corda: aquele “puxão” para ver se está firme e evitar acidentes.
Produção
Testado, depurado e funcionando, é hora do projeto virar um produto, para ganhar o mercado. O time de produção irá fabricar um lote inicial, para ser testado em “beta” em alguns clientes selecionados. Se houver erros, corrige-se até o produto ficar livre de erros (ou pelo menos dos erros conhecidos).
Uma vez liberado para produção, o produto é fabricado, nele serão feitos testes de fábrica e em seguida estes ganharão o mercado, sendo estas etapas finais já mínimas em atividades dos desenvolvedores que fizeram o seu trabalho direito.
Até agora, principalmente quando eu comento sobre a “ação” pode parecer que foi monótono. O pior é que não: a atividade de desenvolvimento é construtiva e construir coisas é sempre satisfatório. E a melhor parte de construir coisas é ver as pessoas usando-as. É ver que aquilo ajuda a transformar o mundo.
