A reutilização de software impede a repetibilidade do processo

Reutilização de código como um problema

Eu estava pensando sobre essa questão sobre a entrega de software e voltei à questão da repetibilidade e / ou reprodutibilidade . Eles são importantes, porque se você não repetir um projeto, fica mais difícil melhorar o processo usado para criar o projeto. A engenharia envolve a melhoria constante dos processos envolvidos no projeto e na construção, a fim de produzir projetos de maior qualidade.

O software pode depender muito da reutilização devido à sua forma digital. Em vez de reescrever um módulo, basta chamá-lo novamente ou copiá-lo para o outro sistema. Alguns exemplos são autenticação / login ou talvez uma função de log. Existem muitos exemplos conhecidos para essas categorias, e a sabedoria convencional é reutilizar o que existe em vez de criar o seu próprio.

Algumas comparações com outras disciplinas

Construção

Por outro lado, a construção de sistemas físicos (edifícios, pontes) não é nem de longe tão reutilizável. É verdade que o projeto de uma casa pode ser reutilizado várias vezes para criar a mesma cópia da casa, mas a construção deve ser executada a cada vez. Cortar e colar não funciona assim no mundo analógico. Os projetos de pontes são menos reutilizáveis ​​que as casas porque as condições do local variam.

Os construtores mestres são especialistas reconhecidos por terem projetado e / ou construído dezenas, centenas ou milhares de coisas em sua área. Por exemplo, Frank Lloyd Wright , arquiteto e designer de renome mundial designed more than 1,000 structures and completed 532 works. Compare isso com Anders Hejlsberg, que criou “apenas” cinco idiomas (Turbo Pascal; Delphi; J ++; C #; TypeScript). De muitas maneiras, é uma comparação injusta porque os domínios são diferentes. Mas em um nível amplo, a produção quantificável de duas pessoas muito inteligentes é muito diferente.

Artes marciais

Os artistas marciais dirão que o domínio de um movimento vem apenas de milhares de repetições. Depois que uma boa parte dessas repetições é realizada, muitos artistas marciais ficam surpresos com a forma como um kata ou forma complexo anteriormente percebido se tornou simples. Os instrutores desses alunos também notarão como o movimento se torna mais fluido e objetivo, além de ter uma economia de movimento. Da mesma forma, artistas marciais experientes são capazes de captar katas mais complexas mais rapidamente do que estudantes menos experientes. A experiência da repetição deu a eles uma estrutura ou processo que lhes permite aprender mais rapidamente.

Carpintaria

Os marceneiros experimentam uma transformação semelhante. Os carpinteiros amadores sempre se referem ao primeiro projeto que exigia muitas gavetas. Se eles concluírem o projeto, obterão uma nova apreciação pelas eficiências que as linhas de montagem produzem. Existem outros benefícios, como uma melhor compreensão de como dispor as peças das gavetas no estoque de chapas para maximizar o uso da madeira. Comparados aos entusiastas, os marceneiros profissionais são capazes de projetar, iniciar e construir itens mais rapidamente, fabricados várias vezes antes. Eles também adquirem a capacidade de ver problemas inerentes ao design de outra pessoa que cometeram esse erro em seu trabalho.

Então, a reutilização de software impede que os desenvolvedores se tornem mais proficientes?

De muitas maneiras, o design e a construção de software são sempre novos. Não repetimos trabalhos anteriores, porque, se podemos reutilizar um módulo, biblioteca ou sistema, o fazemos. Preferencialmente, estenderemos um sistema existente antes de reescrever tudo do zero. Mas a repetição é o que nos permite encontrar eficiência no design e na construção. Qualquer pessoa que pratique um esporte ou atividade física lhe dirá que a repetição é a chave para se tornar um bom praticante.

Minha pergunta: a capacidade de reutilização do software impede a melhoria e a eficiência necessárias do processo decorrentes da repetição de um projeto?

A capacidade de reutilizar o software não impede a melhoria do processo.

Se você pensar nos processos que envolvem a criação de software - desenvolvendo requisitos, projetando o sistema, implementando o sistema, implantando o sistema, gerenciando requisitos, gerenciando configurações, verificando e validando o produto de trabalho, rastreando alterações e vários outros (consulte o Áreas de processo do CMMI para uma possível divisão das atividades principais no desenvolvimento de software) - elas são repetidas em todos os projetos, independentemente da quantidade de reutilização. Além disso, cada uma delas possui algum tipo de medida quantitativa e qualitativa que pode ser usada para determinar quão bom é esse processo ou atividade em particular e, como resultado, quão bom é o processo de desenvolvimento como um todo.

Em um extremo, podemos assumir uma linha de produtos de software robusta. No outro, você pode assumir o desenvolvimento greenfield. Ainda é necessário executar todos esses processos, em graus variados, embora possam ocorrer em taxas diferentes ou talvez em sequências diferentes. Por exemplo, em uma grande quantidade de reutilização, uma porcentagem maior do tempo alocado pode ser gasta em atividades de integração e verificação / validação no nível do sistema (requisitos V&V, testes de integração, testes de sistema, testes de aceitação). Com novos esforços de desenvolvimento, uma porcentagem maior do tempo pode ser necessária no design e na implementação. Contanto que você execute um processo pelo menos uma vez durante o curso de um projeto, é possível medi-lo (quantitativa e qualitativamente). Depois de fazer os ajustes e ver como esses ajustes afetam alguma medida da área do processo ou da capacidade geral de fornecer software,

A chave para a melhoria de processos é ter algum tipo de detalhamento lógico de suas atividades e processos, determinar como medi-las (de preferência de forma consistente) e como entender essas medições para fazer alterações no processo com algum objetivo. Não se trata de repetir o projeto, mas de consistência em como você repete o processo.

Eu acho que a ideia de que outras disciplinas de engenharia não fazem uso de reutilização está errada. Mesmo ao projetar edifícios / máquinas, você ainda possui componentes que são usados ​​por muitos outros projetos. Por exemplo, você projeta seus próprios parafusos? Motores? Portas ou janelas? Claro que não. Geralmente, eles são projetados por pessoas diferentes que os usam em produtos diferentes. E eles geralmente são padronizados, o que promove ainda mais reutilização.

Eu acho que o problema gosta de complexidade. Você simplesmente não pode comparar a complexidade até dos edifícios mais complexos com o software complexo. É uma ideia geralmente aceita que a complexidade do software é o que dificulta a abordagem do lado da engenharia. No momento em que existe um processo que permite criar software de qualidade aceitável, você descobre que a complexidade do software necessária para criar saltos em ordem de magnitude. Portanto, o processo não pode ser usado. Portanto, se tivéssemos que repetir parte de software várias vezes até estarmos satisfeitos com o resultado, nunca terminaríamos esse software.

É por isso que o código limpo é promovido. Pode-se dizer que a capacidade de alterar códigos antigos com base em novas experiências é uma forma de reutilização do design. Portanto, em vez de criar software diferente várias vezes, refatamos e refinamos um único software reutilizando novas experiências e projetos em problemas antigos. Tudo isso enquanto tenta fazer com que o software faça a mesma coisa.

O software é diferente do que a maioria das outras disciplinas; portanto, a economia de onde gastamos melhor nosso tempo é frequentemente diferente.

Na construção, você gasta uma certa quantidade de tempo e dinheiro em uma planta (e o software é muito mais parecido com a produção de uma planta do que com a construção de um edifício); então, grosso modo, muito mais na construção de uma ou mais vezes. Portanto, vale a pena trabalhar bastante para obter o modelo correto. Mais especificamente à sua pergunta - vale a pena repetir o esforço de fazer tudo do zero para melhorar o produto final.

No software, quando você possui o modelo, é muito mais barato fabricar o produto do que fabricá-lo. Pelo menos na maioria das vezes - se o software for incorporado em um marcapasso, você estará muito mais próximo da situação de um construtor de pontes de alguma maneira. Mas, em geral, a reutilização de software pode economizar 90% do custo do seu maior item de orçamento, contra 90% de um item de orçamento muito menor para a construção de uma ponte. Portanto, a reutilização ganha com muito mais frequência.

Quanto à produtividade - quando você constrói, digamos, uma ponte, você enfrenta restrições realmente significativas do mundo real. Imagine se os arquitetos recebessem grandes somas de dinheiro para projetar pontes para jogos on-line multijogador maciços, onde os custos de construção eram próximos de 0 e a limitação era significativamente menor que o mundo real. Eles projetariam pontes que são assustadoramente complexas para os padrões de pontes do mundo real. A fase do projeto pode demorar um pouco mais.

Além disso, há um número limitado de pontes a serem construídas e, como o design é uma parte pequena do custo, você pode pagar pelo melhor, e alguns dos melhores podem fazer a maior parte do design. Existem centenas de milhares de desenvolvedores de software, e basicamente todos eles têm um enorme estoque de coisas que fariam se tivessem tempo. Você não encontrará um cara que faça uma parte enorme de tudo isso - é meio surpreendente que existam pessoas que meio que se aproximam, realmente.

Seu ponto de vista real parece ser que podemos estar perdendo algo reutilizando, em vez de tentar repetir e melhorar as coisas. Eu acho que você tem razão. O problema é que, embora provavelmente seja mais eficiente globalmente reescrever algumas das coisas fundamentais e tentar melhorá-las, quem assume isso assume todo o risco e provavelmente não a recompensa. (Há também um enorme problema prático do inferno da dependência, que provavelmente tira parte da vitória de reescrever as coisas, mas não ao ponto de que não valeria a pena, pelo menos olhando para o cenário global. Direitos autorais e patentes também podem forçar um esforço de reengenharia proposto a refazer um pouco do trabalho de reescrita para refazer partes menores do código existente).

Em termos de aprendizagem a partir da repetição - em todas as disciplinas isso acontece menos no design do que na construção, porque não é menos repetição, portanto, menos chance de aprender, e talvez menos benefícios. Além disso, o processo de design provavelmente não é tão repetitivo. É um pouco como ter um processo para escrever um romance. Um bom processo quase certamente pode ajudar, e o software geralmente é muito mais colaborativo que um romance, mas repetir um processo quando o objetivo é inventar algo novo é problemático. Até romancistas aprendem com o passado, muito, mas um processo repetível é um fator secundário para empreendimentos criativos. E se alguma parte do desenvolvimento de software é realmente realmente repetível, por que um computador não está fazendo isso?

A capacidade de reutilização do software impede a melhoria e a eficiência necessárias do processo decorrentes da repetição de um projeto?

Trabalhei como engenheiro de sistemas e software no mesmo grande projeto nos últimos 17 anos, aliás (pensando na referência do Airbus A380 em seu primeiro link) na indústria aeronáutica, apesar de minhas responsabilidades estarem no setor de aeronaves militares. Histórias como essa são basicamente pura ficção e, na verdade, são realmente engraçadas de assistir quando você tem uma visão privilegiada.

Mas para sua pergunta breve e concisa: Pela minha experiência, eu diria que sim e não.

Primeiro, deixe-me dizer que sou a favor da reciclagem de software em todas as formas (bem, talvez nem todas ...). As vantagens de reutilizar praticamente qualquer coisa, de trechos e algoritmos de código de recortar e colar, a módulos de código e bibliotecas de funções inteiras, são em geral muito melhores do que sempre começar do início novamente (para pressionar um pouco).

A desvantagem é, como você ressalta (ou pelo menos deduz), que quando você adiciona funcionalidade simplesmente reunindo um determinado conjunto de componentes (e, sim, estou simplificando isso ao extremo), você realmente não evolui como um programador, engenheiro ou qualquer outra coisa.

Só de olhar para os engenheiros de software ao meu redor no trabalho, sei por experiência longa que a maioria deles não sabe e, pior ainda, não tem interesse em aprender nada sobre o produto que estamos construindo, exceto o mínimo necessário para produzir o documento ou o pedaço de código ao qual eles estão atribuídos.

Estou discutindo um pouco sobre o assunto aqui, mas o que quero dizer é que, quando os programadores não precisam aprender para que realmente será usado o código que estão construindo, e não precisam aprender o funcionamento interno do sistema, pois podem simplesmente reutilize componentes já escritos e testados, a maioria deles não se preocupará em fazê-lo.

É verdade que isso também se deve a outras circunstâncias, como a de que o produto que estamos construindo é incrivelmente complexo e seria impossível para uma pessoa aprender sobre tudo isso (e estou falando apenas de um dos computadores da aeronave - o mais complexo deles, mas ainda).

Se nossos engenheiros de software não tivessem a opção de reutilizar tanto código, estou convencido de que eles se tornariam melhores em sua profissão em geral e em ativos muito maiores para o projeto especificamente.

Ah, e você deve ter notado que eu falo muito sobre eles aqui. É claro que também estou incluído entre esses engenheiros de software. A exceção é que eu pareço ser muito mais curioso e ansioso para aprender coisas novas do que as outras :-) Quando confrontado com uma nova tarefa, sempre tomo a responsabilidade de aprender o máximo possível sobre ela, tanto no forma de fatos e estudando o código fonte (sim, eu também gosto disso).

Ah - caramba, desviado de novo ... Minha desculpa é que eu não durmo há 32 horas, então minha capacidade de foco é um pouco ... o que eu estava dizendo?

Se alguém ainda estiver lendo, minha conclusão é que:

Sim , a reutilização em excesso de software gera menos engenheiros de software com conhecimento, o que os torna muito menos eficientes quando realmente precisam saber como as coisas funcionam. A análise de problemas é um bom exemplo, ou mesmo a capacidade de saber se uma solução de projeto sugerida é viável. E, claro, a melhoria de processos também é mais difícil de ser alcançada quando você realmente não sabe o que está fazendo :-)

e Não , reutilizar o software com cuidado , potencialmente oferece muito tempo livre para considerar e planejar melhorias no processo.

Como apontado na resposta aceita em outra pergunta dos programadores, analogias com a construção devem ser tomadas com cuidado:

uma leitura recomendada para isso é The Software Construction Analogy is Broken

o software é frequentemente comparado à construção. Infelizmente, essa analogia é falha e as lições aprendidas com a indústria da construção são suspeitas ...

O que observei é que bons projetos de software "transferem" muita repetibilidade para a garantia da qualidade.

Quando eu era testador em um projeto de 1,5 ano, realizamos ciclos de teste em lançamentos semanais de "ponto de verificação", cerca de 70 vezes o total no projeto. Isso foi ... bastante repetitivo, em voz baixa (poucas coisas mudam em uma semana). Testar compilações noturnas foi, naturalmente, ainda mais repetível - cerca de 500 vezes no projeto (poucos bugs divertidos eram muito raros para fazer a diferença).

Agora, seguindo essa analogia "suspeita", diga-me uma empresa de construção que construiu 500 pontes - todas com a mesma equipe.

• Depois, diga-me uma empresa que tem usado quase sempre os mesmos tijolos e ferro em cada uma de suas novas pontes (aqui, refiro-me ao fato de que os lançamentos que testamos tinham basicamente os mesmos bits de código dia após dia, semana após semana). semana - "poucas coisas mudam").
  

Os construtores mestres são especialistas reconhecidos por terem projetado e / ou construído dezenas, centenas ou milhares de coisas em sua área.

Tudo bem, seguindo sua explicação de repetibilidade citada acima, posso dizer o que? Naquela época, nosso pequeno, não muito especial grupo de testadores verificou, veja acima ("cerca de 500") centenas de coisas em nossa área.

Quanto aos desenvolvedores de projetos, eles literalmente construíram ("construções noturnas") - veja, a palavra é a mesma e o significado é certo nesse contexto - centenas de coisas em sua área.

Se alguém quiser continuar com essa analogia "suspeita", até "milhares de coisas", essas quantias não são novamente espetaculares no desenvolvimento de software quando se olha para as coisas certas.

• Como exemplo, mais um dos meus projetos anteriores (novamente, nada espetacular, um tanto regular), desta vez no papel de desenvolvedor, já dura mais de 5 anos (8 lançamentos principais, dezenas de projetos menores). Havia pontos 5x52~=250de verificação semanais semelhantes ( deles), lançamentos noturnos semelhantes ( 5x365~=1800deles) e da mesma forma, as mesmas equipes de desenvolvimento / controle de qualidade trabalhando neles. Dia a dia, semana a semana, mês a mês, principalmente coisas repetitivas (não há muita mudança entre duas construções noturnas) - como prometido, na faixa de milhares de vezes (1800).

Projetos de vida mais longa, como Windows ou Java, ou AutoCAD podem durar 10, 20, 30 anos, o que explica facilmente a repetição de "milhares" de construções noturnas e testes noturnos.

O conceito de mudança de repetibilidade para o controle de qualidade se torna ainda mais proeminente com a integração contínua ...

a prática ... de mesclar todas as cópias de trabalho do desenvolvedor com uma linha principal compartilhada várias vezes ao dia ... O IC pode ser visto como uma intensificação das práticas de integração periódica.

Além dos testes de unidade automatizados, as organizações que usam o CI geralmente usam um servidor de compilação para implementar processos contínuos de aplicação do controle de qualidade em geral - pequenos esforços, aplicados com freqüência. Além de executar os testes de unidade e integração, esses processos executam testes estáticos e dinâmicos adicionais, medem e perfilam o desempenho, extraem e formatam a documentação do código-fonte e facilitam os processos manuais de controle de qualidade. Essa aplicação contínua de controle de qualidade visa melhorar a qualidade do software e reduzir o tempo necessário para entregá-lo, substituindo a prática tradicional de aplicar o controle de qualidade apóscompletando todo o desenvolvimento. Isso é muito semelhante à idéia original de integrar com mais frequência para facilitar a integração, aplicada apenas aos processos de controle de qualidade ...

Repetibilidade? está ali, o máximo que se pode pensar.

Com o controle de qualidade frequente / contínuo, as coisas que dão errado rapidamente retornam aos desenvolvedores que são forçados a repetir as tentativas de fazê-lo corretamente até que os testes com falha sejam aprovados. De certo modo, esse ciclo de repetição até passar se assemelha ao código cata ,

um exercício de programação que ajuda um programador a aprimorar suas habilidades através da prática e repetição ...

Parte do que você diz é verdadeira: por exemplo, as bibliotecas resolvem funções não resolvidas por linguagens de alto nível que resolvem problemas não resolvidos pelo assembly que resolvem problemas não resolvidos pelo código de máquina. Quando você chama System.out.println () em java, está perdendo de vista como a CPU gera um dispositivo.

Então sim, você está perdendo alguma coisa. O que você ganha é a capacidade de se concentrar em problemas não resolvidos. Agora pode ser que você precise mergulhar em outros aspectos da tecnologia (por exemplo, como as redes funcionam) para resolver um problema. Mas você não precisa se tornar um especialista em leitura de linguagem de máquina quando tudo que você quer fazer é criar uma página da web.

Da mesma forma, os construtores de pontes estão resolvendo um problema ligeiramente diferente a cada vez (é um rio diferente). Eles não se preocupam em como criar vigas de aço com uma certa resistência à tração ou em usinar parafusos com uma certa tolerância. Eles deixam isso para especialistas que resolveram esse problema.

Observe atentamente e verá que toda a nossa sociedade e infraestrutura são construídas com 99% de reutilização e apenas 1% de progresso real. A maioria das coisas novas são apenas coisas antigas, com um pouco de algo extra adicionado ou removido. É o acúmulo de conhecimento humano. Você pode escrever código em uma linguagem de alto nível com bibliotecas decentes, porque alguém descobriu todas as coisas incrivelmente complicadas necessárias para chegar a esse ponto. Ele permite que você resolva problemas novos e interessantes.

Para juntar tudo isso e responder aos comentários: Você não precisa resolver problemas que já foram resolvidos para desenvolver proficiência. Além disso, muito do que você fará será reinventar a roda. Portanto, em suma, a resposta é não - você não precisa reimplementar as funções das bibliotecas para se tornar proficiente. Há muitas oportunidades, algumas rotineiras, outras criativas para aprimorar sua arte.

É tudo sobre recursos. Anos atrás, se você desenvolvesse projetos de software para computadores grandes de mainframe, eles poderiam estar presentes por 15 anos ou mais com um ambiente de desenvolvimento estático. O programa FORTRAN, escrito para calcular a folha de pagamento ou o programa COBOL, foi aperfeiçoado ao longo de décadas, porque estava sendo constantemente usado. Havia recursos para ver como isso poderia ser melhorado. Não temos mais esse tipo de ambiente lento para ajustar e aperfeiçoar as habilidades de um projeto específico. Mas nós pegamos as habilidades e as adaptamos aos próximos recursos do projeto, permitindo. Mas, no final, torna-se uma escolha de dinheiro gasto no novo projeto para fazer o trabalho, ou para fazer o novo trabalho com uma grande quantidade de revestimento de ouro. O revestimento de ouro de um projeto significa melhorá-lo até o enésimo grau e adicionar uma tonelada de sinos e assobios, mesmo que o usuário não

O melhor que podemos fazer é analisar o design geral de um novo projeto e ver como ele pode ser aprimorado com base na experiência passada da equipe. Mas é preciso que um arquiteto de software com experiência real tenha uma visão sobre o que é realmente considerado como melhorar o design para melhorar as habilidades, ou simplesmente incluir a última palavra da moda no desenvolvimento, como Agile, OOP etc.