Vamos examinar os métodos de construção de software inventados em cerca de 70 anos de sua existência. Não são tantos quanto pode parecer. Mas o suficiente para ficar perplexo.
Adágio
O homem é adaptativo por natureza. Você vai, por exemplo, para a cozinha, onde o frango está girando na grelha. O cheiro atinge o nariz e, se ficar com fome, vai até salivar. Depois de cerca de cinco minutos, você para de cheirar. A única coisa que lembra comida é um pedaço de carne girando atrás do vidro do forno com asas abertas. O cheiro ainda está lá, você pode medi-lo, mas a informação dos receptores é bloqueada pelo cérebro.
Isso está acontecendo em todo lugar, e a engenharia de software não é exceção. Começamos com "descobertas maravilhosas" de que "o espírito da iluminação nos prepara", passamos suavemente para a rotina, vergonha e confusão, sprints-shmints, encapsulamento-polimorfismo-nacionalidade e, oh merda, um pedaço de carne é girando no forno, ameaçando queimar até o fim, apesar da estimulação regular do material acima da média do hospital.
Na década de 1960, um homem curioso chamado Richard B. Doss descobriu que na América, saturada com o workaholism protestante, 70-80% das pessoas trabalham muito abaixo de sua capacidade de trabalho. Além disso, ao contrário de um manipulador robótico, um trabalhador de proteína é capaz de cortá-lo rapidamente. Os estudos foram repetidos em "zero" e "décimos" com o mesmo resultado. Tal situação afeta a saúde, para dizer o mínimo, não importa.
O objetivo do texto não é dissuadir você de produtividade insuficiente ou dar qualquer conselho. Examinaremos brevemente os métodos de construção de software inventados em cerca de 70 anos de sua existência.
Três caminhos
Não vou puxar a borracha, vou começar pelo principal. Existem apenas três maneiras de desenvolver software. Sim, três é um bom número, linda. Portanto:
Método de cima para baixo . É quando, a princípio, eles pensam globalmente “o que fazer”, depois “como fazer”, e então o fazem, se sobrar tempo.
Caminho ascendente . É quando eles fazem pela primeira vez, aos poucos, em pequenas partes. Eles pensam "o quê, sim como" só nessa parte, não se preocupando com o global e duradouro.
Caminho em espiral . Começamos a pensar globalmente, mas quando o alarme toca, acordamos e lançamos o protótipo. E assim várias vezes, acumulando experiência, até que apareça uma solução de acordo com os requisitos.
Desenvolvimento de cima para baixo
Na linguagem comum, todos os métodos de cima para baixo são chamados de “cachoeiras”. Se você já foi informado sobre a existência de várias peças de ajiles, então essa "simplicidade é pior do que roubo" deve levantar suspeitas.
A descida do método às massas ocorre na década de 1960, complementando organicamente as exigências da programação estruturada para lavar as mãos antes de comer e usar talheres e guardanapos. A tarefa global foi dividida em subtarefas menores, que, por sua vez, em outras ainda mais detalhadas, e assim por diante, até o nível de um bloco estrutural que pode ser implementado diretamente em uma linguagem de programação. A propósito, os testes para esses blocos são escritos em paralelo, olá para os TDDs da década de 1960.
O provérbio russo “Meça sete vezes - corte uma vez” é quase o método de cima para baixo.
Na versão ortodoxa da "cachoeira", o feedback do cliente só vem após a entrega. Trabalhamos um ano, rolamos o piano para fora dos arbustos, saiu "não muito bem", alguns retoques finais são necessários. Enquanto isso, o cliente deu origem a uma longa lista de novos recursos. Não acostumado a trabalhar em tal esquema é um pouco estúpido. Portanto, em uma versão humanizada, é possível retornar à etapa anterior para esclarecimentos a partir de qualquer ponto, resultando em uma "cascata de retornos".
As vantagens do método são claras. Quanto mais pensado no início, menos trabalho desnecessário terá que ser feito no meio e no final. Excluem-se múltiplas reinvenções de bicicletas, duplicação de funções e erros.
No entanto, se inicialmente houver muitas funções, não será fácil gerar a repartição correta. Precisamos de bons analistas, designers com experiência nestas áreas temáticas. E mesmo neste caso, existe o risco de atrasar o planejamento da implementação por um período indecente.
No futuro, o método foi melhorado repetidamente, por exemplo o método V , onde as etapas de desenvolvimento ao longo da inclinação esquerda da letra "V" correspondem às etapas de testes e aceitação da subida à direita. O nível horizontal mostra imediatamente qual documento de projeto do contratante serve como base para o documento de aceitação do cliente.
É claro que as melhorias não podem superar as limitações fundamentais do método. É por isso que eles têm princípios. Isso não significa que o método seja ruim. Ele apenas corre riscos desse tipo. Se você puder evitar os riscos, então está tudo bem, começamos a pensar e aproveitar os benefícios ao longo do caminho.
Desenvolvimento upstream
Na verdade, o método ascendente é ainda mais antigo do que o descendente. Na década de 1950, o Fortran e o Cobol já existiam, mas não havia uma ideia clara de como construir software. Portanto, agimos da maneira mais natural: hoje faremos uma coisa, amanhã faremos outra, então um dia iremos colar em uma terceira. Se você precisa implementar várias tarefas, selecionamos as mais importantes.
Às vezes, o método também é chamado de incremental, aparentemente por analogia com
i++
. Adicionada uma função - incremento. Se você quiser esticar o globo na projeção de Mercator, também pode chamar o método da espiral de incremental, mas falaremos mais sobre isso posteriormente. Eles também gostam de descrever o método na forma de um ciclo, embora para
i++
os valores finais não são definidos, então você terá que "cavar" daqui até a hora do almoço. Continuando com o tema dos provérbios russos, temos um ditado “gira como um esquilo em uma roda” - trata-se apenas do método ascendente.
A técnica foi e continua sendo a mais típica para o desenvolvimento interno. Seus programadores precisam fazer o que a empresa precisa ontem. Para pensar de forma mais global, a década de 1960 viu o surgimento das "casas de software" - grandes escritórios de design para o desenvolvimento de sistemas personalizados, incluindo monstros como a IBM .
Toda essa construção de software para cima continuou sem mudanças significativas até a década de 1990. A principal batalha para combinar as teorias acadêmicas com a prática da engenharia contornou o porto seguro porque foi travada na selva dos métodos de cima para baixo e em espiral.
Na década de 1990, houve uma forte tendência de substituir os programadores "domésticos" por consultores externos. Um dos motivos é a complicação de tecnologias e especialização, o que é difícil de conseguir dentro de uma empresa para a qual a engenharia de software é uma atividade secundária. O software doméstico agora é desenvolvido por equipes temporárias
Em tal situação, um método simples de função por função parece mais uma vez apropriado. Mas trabalhar com um empreiteiro de jornada diária requer mais supervisão do que trabalhadores assalariados em tempo integral. A abordagem precisa ser adaptada, evitando procedimentos burocráticos. Na verdade, para "emitir os termos de referência" requer planejamento geral e documentos relevantes, isto é, vollensnolens, seria necessário mudar para métodos formais de cima para baixo ou em espiral. E por que uma transportadora ou fabricante de automóveis precisa disso, por exemplo? As pessoas só querem resolver um pequeno problema interno, calcular lá o salário ou reduzir o calendário de férias.
Demanda cria oferta, no final da década de 1990 surgiram os chamados métodos ágeis que, no mínimo, permitiam ao cliente manter o controle, e a empreiteira aos poucos foi entendendo o que, de fato, estavam implementando.
O que melhorou:
- o planejamento ainda é curto, mas cobre mais de uma função, e seu grupo, enquanto o prazo do estágio é estritamente limitado;
- um registro do que foi feito é mantido;
- teoricamente, o tempo deve ser alocado para simplificar e limpar o código (refatoração);
- em teoria, os riscos de regressão devem ser combatidos com testes abrangentes.
Por que estou escrevendo "teoricamente"? Na prática, quando o orçamento é limitado ou com problemas de tempo, esses dois pontos são sacrificados em primeiro lugar. A "vaca sagrada" em ajiles não é a qualidade do código, como os autores pretendiam, mas o prazo para a próxima função.
Duplicação de código, complicações desnecessárias, adiadas "para mais tarde" implementações ineficazes - se você não limpar o que foi feito antes, a dívida técnica aumenta. Quanto mais tarde a dívida for paga, mais você terá que pagar no final: tempo, dias de trabalho, erros, falhas, trabalho lento, etc.
Após cerca de 10-15 anos, os autores do "Manifesto Ajaila" começaram a soar o alarme: "Pessoal, o que vocês estão fazendo, nós quisemos dizer outra coisa." Eles estão um tanto corretos, o desenvolvimento de baixo para cima é tão simples e atraente que todos esses procedimentos adicionais parecem desnecessários.
Vamos resumir o que há de bom no desenvolvimento de baixo para cima. Em primeiro lugar, o limite de entrada é drasticamente reduzido. Começar do zero não requer especialistas caros em análise e design com experiência. Embora toda a construção possa durar indefinidamente, os primeiros quartéis serão erguidos em breve e você poderá começar a se estabelecer neles. É mais fácil gerenciar o processo, os pontos de controle e as metas locais são transparentes.
Os problemas, como no caso das “cachoeiras”, são fundamentais. É mais fácil gerenciar o processo, mas quase impossível - o resultado final, uma vez que não está claramente registrado em qualquer lugar. Os riscos são repassados ao cliente: deixe o product owner pensar que ele tem uma cabeça grande. Se a equipe lida com a arquitetura técnica com experiência, testes e refatoração (até um certo limite de complexidade), então a arquitetura funcional é ruim. Simplificação da declaração do problema, a própria "refatoração", agora o modelo de domínio, ajudaria a se livrar do código extravagante e caro de manter, mas não há ninguém para fazê-lo. E não tem modelo, pra ser sincero, toda a semântica está nas cabeças e no código.
Mas não há razão para ficar chateado, lembre-se do sprint mais desastroso da história mundial: 5 dias de criação e um bilhão e meio de anos de refatoração contínua.
Engenharia espiral
As limitações em “cascata” mencionadas acima tornaram-se claras na década de 1970, após a implementação massiva das metodologias correspondentes como SADT / IDEF . Ao mesmo tempo, trabalhamos em métodos ascendentes em projetos “caseiros” com outros problemas, o que criou uma sensação de beco sem saída. Portanto, os pesquisadores intrigados com o problema (principalmente Barry Boehm ), coçando os nabos, emitiram em meados da década de 1980 uma visão atualizada do processo de construção de software em forma de espiral .
A lógica do raciocínio em "espiral" é aproximadamente a seguinte. Sim, à medida que a complexidade das tarefas aumenta, gastamos cada vez mais tempo em análise e design, o risco de erros nesta fase aumenta. Mas, implementando funções individuais sem um plano geral, corremos o risco de cometer erros não menos e acabamos com peças ineficazes ou simplesmente incompatíveis. Portanto, deixaremos de lado o design "vaca sagrada", mas a) limitaremos o prazo para isso eb) verificaremos rigidamente as decisões tomadas, lançando um protótipo completo.
O ponto "b" é muito importante. Com o desenvolvimento ascendente, você também produz algo constantemente, correções de bugs, novos recursos. Mas funcionará se o sistema já estiver em operação e em manutenção. E se não? Imagine que um cliente deseja um sistema de controle de tráfego de trens e, em algumas semanas, você mostra a ele telas para inserir informações sobre o material rodante e um simulador de horários. Não é sério.
O protótipo deve incluir a maioria das funções, mesmo que não totalmente implementadas ou mesmo com "stubs". Do protótipo completo, respectivamente, obtemos feedback completo: aqui eles erraram, não entenderam a essência dos requisitos, não levaram em consideração o ambiente operacional, lá o formato de saída não corresponde ao formato de entrada, etc. Com esse feedback precioso, começamos a segunda rodada da espiral, acreditando razoavelmente que a chance de trazer o próximo protótipo ao nível de um produto acabado é alta. Para sistemas de tamanho médio (até um milhão de linhas de código aproximadamente), duas ou três iterações são suficientes.
Pelo que foi dito, está claro que atribuir a espiral a métodos incrementais é tão ridículo quanto as baleias são aos peixes, embora ambas tenham cauda.
O que há de bom na espiral? Reduzimos drasticamente os riscos de implantar para o cliente em vez de um produto, francamente progredindo, mas ao mesmo tempo não sacrificamos o design. Ou seja, a visão global da situação permanece, o resultado final pode ser gerenciado calculando o orçamento e o lucro. Todos, clientes e empreiteiros, podem ver a luz no fim do túnel. O cliente, se for sério em suas intenções, também não gritará: "Por que você está pondo no meu rabo, depois escorregando na minha tromba, mostra-me o elefante inteiro!" A cada volta, o elefante inteiro é visível.
Porém, em comparação com a crescente engenharia de software, é impossível gerenciar um pelotão de técnicos-programadores sem analistas e designers, e você terá que explicar este momento delicado ao cliente na justificativa de um preço mais alto. Após a fase de design da primeira rodada, os especialistas não ficam parados, mas continuam a morder a tarefa, esperando por feedback, mas na rodada final eles provavelmente não serão mais necessários. O comprimento da bobina pode ser de vários meses, mas geralmente custa de dois a três. Não parece um sprint extremo semanal, mas também não parece uma expectativa anual de um produto. Também não é fácil escolher quando, nesta fase, “basta desenhar” e é hora de começar a assentar os tijolos.
A implementação mais famosa e bem-sucedida da técnica espiral - MSF(Microsoft Solution Framework). Mais tarde, a Microsoft teve uma versão reduzida, aprimorada para métodos ascendentes e comercializada como MSF para Agile para projetos e equipes relativamente pequenos.
Em vez de um epílogo
Vovô Brooks descreveu quatro tipos de software que as pessoas constroem em seu livro mais vendido .
A imagem mostra que em algum ponto você pode parar de "apenas escrever um programa" e "por um preço exorbitante" querer torná-lo um produto (algo que é fornecido a muitos clientes diferentes) ou um complexo (algo que consiste em muitos programas e se integra perfeitamente ao ambiente do cliente, incluindo equipamentos). E se "escrever um programa", em geral, pode ser qualquer um dos métodos de construção suave, então seus planos excelentes para desenvolvimento posterior podem ser interrompidos pelas deficiências dos métodos de cima para baixo e de baixo para cima.
Nas condições em que o recurso humano de programadores-técnicos é excessivo com escassez e dificuldades na contratação de designers e analistas, ao invés de uma organização horizontal (“engenheiros de sistemas” fazem uma plataforma para “candidatos”), passam a usar uma vertical , onde cada equipa implementa as suas funções a partir das suas bicicletas. Do ponto de vista da gestão, o segundo método parece mais simples, mas apenas até o momento em que é introduzido um comando de “arquitetura” horizontal que, por meio de longa persuasão e coordenação, reduz os riscos dos mesmos erros repetitivos.
Por isso, talvez, possamos parar, pois a orientação inicial no espaço da informação deve ser suficiente. Existem palavras-chave e alguns links no texto, para que os curiosos possam se aprofundar no assunto.
Texto original no site "Mecânica da engenharia de software"