A disciplina de engenharia de software deve ser iterativa, baseada em feedback, incremental, experimental e empírica. O trabalho manual não é suficiente; a engenharia é um amplificador que expande a criatividade, a colaboração e a inventividade. A entrega contínua tem princípios de engenharia em seu alicerce. Dave Farley aponta que se somos mais rigorosos no começo do projeto, iremos criar soluções melhores e mais inovadoras, além de gastar menos tempo corrigindo bugs em produção ou trabalhando em soluções alternativas para os deploys e configurações.
Dave Farley é consultor e desenvolvedor independente de software, e apresentou a palestra Taking Back "Software Engineering" no QCon London 2018.
O termo "Engenharia de Software" foi utilizado pela primeira vez em 1968 em uma conferência da NATO. Embora tenha havido progresso em relação à disciplina, software ainda não é engenharia; de acordo com Mary Shaw:
Tem havido um grande esforço ao longo dos anos nos métodos de desenvolvimento de software. Isso estabeleceu os métodos de produção que deram condições à prática comercial. Porém, não se estabeleceu uma base codificada para a tecnologia que é necessária para a prática de engenharia.
O InfoQ conversou com Farley sobre o que define a engenharia de software e seu porquê de ser importante, sobre como o trabalho manual se relaciona à engenharia, e como pode se desenvolver a mentalidade de engenharia.
InfoQ: Como você define "engenharia de software"?
Dave Farley: Penso que há uma série de equívocos entre os desenvolvedores de software sobre o que "engenharia" é, e pior ainda sobre o que "engenharia de software" é. Sinto que entro em um número surpreendente de conversas sobre "construir uma ponte" por alguma razão. Fazer algo pela primeira vez é muito diferente de fazer algo pela milésima vez. A engenharia é uma disciplina intensamente criativa! Pense na engenharia que envolve a criação de algo como o "Curiosity Rover" ou o "Falcon Heavy" ou o primeiro iPhone!
Nesse contexto, minha definição de engenharia seria: engenharia é a aplicação de uma abordagem empírica e científica para encontrar soluções eficientes para problemas práticos.
Para engenharia de software, imagino que existam algumas especificidades que DEVEM estar disponíveis para que seja possível alcançar esta "abordagem empírica e científica". Para mim, qualquer "Disciplina de Engenharia de Software" que valha seu nome deve ser:
- Iterativa
- Baseada em feedback
- Incremental
- Experimental
- Empírica
Minha palestra no QCon London sobre "Trazer de volta a Engenharia de Software" explorou em detalhes cada uma dessas ideias.
InfoQ: O que faz importante a engenharia de software?
Farley: Software é importante no mundo! Estranhamente, como desenvolvedores de software somos as pessoas que provavelmente mais mudarão o mundo neste momento. E essa disciplina ainda é nova, mas estamos e continuamos a crescer explosivamente.
Minha percepção é que talvez a maioria dos desenvolvedores nunca viram algo que poderiam chamar honestamente de "engenharia" aplicada ao desenvolvimento de software. Quando realmente aplicamos esses princípios, o que vemos é algo dramaticamente mais eficiente em termos de velocidade e qualidade.
Isso não é uma surpresa enquanto "Ciência", na qual a engenharia tem suas raízes; é a técnica mais eficaz de resolução de problemas da humanidade. Sinto que deveríamos aplicá-la ao árduo problema de desenvolvimento de software.
Outro ângulo dessa discussão é a evolução do desenvolvimento de software como profissão. O escândalo de emissões da Volkswagen levou muitas pessoas para a cadeia, incluindo desenvolvedores de software. Somos responsáveis pelas decisões que fazemos e pelo código que criamos, tanto moralmente quanto economicamente. Minha visão do nosso setor diz que geralmente ignoramos essas responsabilidades. E essas coisas serão impostas a nós, a menos que passemos a entender essas responsabilidades e a tomar o controle delas.
Um engenheiro que constrói uma ponte, ou um carro, ou um avião, que mata pessoas, será responsabilizado profissionalmente. Também enfrentaremos este tipo de desafio. Qual tipo de defesa teremos para nossas ações se não seguirmos disciplinas efetivas para teste, medição e avaliação de nossas ideias?
Meu último ponto, entretanto, é pessoal. Trabalhar com algo da disciplina de engenharia é MUITO mais divertido. Posso criar soluções melhores e mais inovativas para os problemas ou pegar problemas maiores, gastar menos tempo corrigindo bugs em produção ou procurando por soluções alternativas para os deploys e configurações; isso tudo se sou um pouco mais disciplinada no modo pelo qual abordo meu trabalho. Na minha opinião, a "engenharia" aproveita e amplifica minhas habilidades sem diminuir de qualquer modo os aspectos criativos do desenvolvimento de software.
InfoQ: Como o trabalho manual se relaciona com a engenharia?
Farley: Acredito que o movimento do "software artesanal" foi criado em resposta aos horrores da "grande cerimônia", no caso, os processos em estilo cascata dos anos 90 e início dos anos 2000. O trabalho manual é um passo além destas abordagens planejadas, que são fundamentalmente o modelo errado para processos que são variáveis e incluem uma quantidade significante de "descoberta".
O trabalho manual era o passo correto, mas se olharmos para a história da produção, o artesanato é um processo de baixa qualidade. Pense por um momento em um iPhone ou um avião-caça JetFighter feito à mão. Ou que tal um programa espacial artesanal?
O trabalho manual não é suficiente. A engenharia é um amplificador; não irá coibir a criatividade, a colaboração e a inventividade, irá expandi-las.
Concordo com muitas das ideias do movimento de software artesanal, em particular as ideias do estilo de treinamento de aprendizes e o aprendizado e melhoria contínuos, mas estas ideias são igualmente aplicáveis à disciplina de "engenharia de software" e tal disciplina nos leva além, mostrando uma direção a seguir quando estamos presos em algo e aumentando a qualidade e produtividade do nosso trabalho.
InfoQ: O que pode ser feito para desenvolver uma mentalidade de engenharia?
Farley: Ultimamente, creio que isso talvez seja uma mudança "de geração". Se pudermos concordar em alguns princípios para a "engenharia de software", então deveria ser ensinado, ser esperado e ser uma prática comum!
Penso que meus princípios são um bom ponto de partida: iterativo, baseado em feedback, incremental, experimental e empírico.
Estou um pouco enviesada nisso e também vejo que a abordagem de Entrega Contínua para o desenvolvimento é fundamentado nestes princípios de engenharia, mas deve ir muito mais fundo do que isso.
Creio que hoje há um grande consenso sobre o que realmente funciona do que já vi até aqui, ao menos entre as pessoas que podemos considerar nossos "líderes de pensamento" em nossa profissão. Então, agora pode ser uma boa oportunidade para, uma vez mais, tentar definir o que "engenharia de software" realmente significa.
Se pudéssemos concordar amplamente em alguma definição, talvez poderíamos começar a aconselhar os estabelecimentos de ensino e entidades profissionais a ensinar as coisas certas. Um exemplo trivial: quantas pessoas que já estudaram "Ciência da Computação" aprenderam sobre o "Método Científico" e a importância da "Experimentação" durante o curso? Quantas pessoas aprenderam "Ética" como parte desse curso "profissional"? Estas coisas são muito normais na maioria dos cursos e disciplinas de engenharia.
InfoQ: E sobre a atual geração de desenvolvedores, do júnior ao sênior em tecnologia? O que podem fazer para acompanhar a engenharia de software?
Farley: Meu conselho número um para qualquer desenvolvedor de software, júnior ou sênior, é adotar uma abordagem mais científica para resolver problemas e levar o método científico a sério.
Pense em termos de experimentos, recolher dados para tomar decisões, experimentar ideias. Não assuma que seu primeiro palpite está correto. Na verdade, assuma que todos os seus palpites estão errados e trabalhe de forma que 1) ajude a descobrir quão incorreto você está o mais rápido possível e 2) não o mate quando fizer as coisas erradas.
InfoQ: Qual é a diferença entre um "artesão" e um "engenheiro"?
Farley: Um artesão palpita sobre o que pode vir a trabalhar. Um engenheiro palpita e então mede seus palpites para ver onde está errado.