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

25

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?

Comunidade
fonte
Se você escreveu um pedaço de código, resolveu essencialmente um problema. Se você é bom nisso, esta peça resolve uma CLASSE de problemas. Se você é realmente bom, é extensível a uma metaclasse de problemas. E então você perde o interesse: não há necessidade de aperfeiçoar uma bicicleta se houver problemas de projeto não resolvidos. A emoção da resolução de problemas advém do surgimento de coisas novas, não do polimento de velhos problemas para a perfeição.
Deer Hunter
2
bons projetos de software "transferem" muita repetibilidade para o controle de 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 versõ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, diga-me uma empresa de construção que construiu 500 pontes - todos com a mesma equipe
mosquito
@gnat - é um excelente insight e uma perspectiva que eu ainda não havia ponderado. Outros aspectos do SDLC se tornam muito mais eficientes devido a essa repetição.
1
@ GlenH7 expandiu-lo na resposta , principalmente para incluir fotos de pontes :)
mosquito
Quantos problemas Frank Lloyd Wright teve que resolver em suas 1000 estruturas versus Anders Hejsberg na definição de seus meros 5 idiomas? Wright conseguiu tomar decisões por decreto, Anders teve que justificar decisões para muitas pessoas tão inteligentes e conhecedoras quanto ele. Aposto que Anders teve que resolver muitos outros problemas. Portanto, os números que você joga no mix são apenas o que você está escolhendo contar e não os números comparáveis ​​quantificáveis ​​REAIS. Então, eu gosto da pergunta, apenas não gosto do raciocínio / exemplos que a inspiram. A eficiência do SW melhorou tremendamente ao longo dos anos.
Dunk

Respostas:

10

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.

Thomas Owens
fonte
depende do que realmente está sendo reutilizado, pode até cair na Aquisição do CMMI, ou seja, não no trabalho de desenvolvimento.
Imel96
1
Mas o CMMI não teve sucesso de maneira significativa. Nenhuma das "aplicações matadoras" do século 21 foi construída por pessoas preocupadas com a matriz de maturidade do CMMI. Algumas pessoas brilhantes tiveram uma idéia e a implementaram, e depois contrataram pessoas mais brilhantes para aumentar a escala da solução. Por outro lado, projetos que provavelmente prestaram menos atenção a padrões como o CMMI falharam miseravelmente, por exemplo, a tentativa do Departamento de Defesa dos EUA de criar um novo aplicativo de folha de pagamento.
Kevin cline
1
@kevincline Não importa se o CMMI teve ou não sucesso. Na indústria aeroespacial / de defesa, vejo o CMMI em minha organização e nas empresas com as quais trabalhamos, nas quais somos subcontratados e nos quais subcontratamos. No entanto, o que quero dizer é que, para melhorar o processo, você precisa identificar seus processos. O CMMI é uma ferramenta única para fazer exatamente isso. Existem outros por aí, e você pode definir o seu. Depois de ter processos, você pode defini-los, medi-los e melhorá-los.
Thomas Owens
1
@ Kevin: "Aplicações assassinas" são, por natureza, "fora do mainstream". Portanto, não seria de surpreender que a maior parte do trabalho novo e inovador tenha sido criada por experimentação e pirataria, e não por algum processo disciplinado. Embora "aplicação matadora" seja da própria definição. É um aplicativo que se torna um modismo realmente um "aplicativo matador" ou é o programa DoD que permite que o Jet Fighters voe com segurança e os impeça de abater seus aliados mais em um "aplicativo matador". Os modismos freqüentemente não exigem nenhuma habilidade / inovação (por exemplo, rocha de animais de estimação, bambolê) ......
Dunk
... incluindo muitos aplicativos populares "fad". Visto que grandes projetos do tipo DoD quase sempre exigem uma quantidade enorme de habilidade e processo. Além disso, sua visão do fracasso do CMMI provavelmente diz mais sobre a sua experiência (ou a falta dela) em setores que usam o CMMI do que o próprio CMMI. O CMMI não é perfeito, e provavelmente nem bom, mas, no mínimo, leva as empresas a pelo menos tentar anotar e seguir um processo e até tentar melhorá-lo. Se isso é tudo o que o CMMI realiza, é um sucesso.
Dunk
5

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.

Eufórico
fonte
Não é que outras disciplinas não reutilizem o design, a diferença é a quantidade de reutilização. Todos os objetos que você mencionou precisam ser fisicamente construídos para cada instanciação. Não posso simplesmente copiar e colar uma porta, por exemplo. A repetição resultante da construção leva à identificação de eficiências e melhorias que não são óbvias no início. Construa um conjunto de armários de cozinha e você descobrirá coisas novas entre o primeiro e o último. Você tem razão com a complexidade geral, pois a natureza virtual do software nos permite aumentar a complexidade sem saber.
1
@ GlenH7 O problema é que o desenvolvimento de software não está construindo. Seu design. Com a construção de coisas, você está fazendo a mesma coisa repetidamente. Mas com o design, você sempre tem objetivos e problemas diferentes. Você não deve compará-lo à construção do edifício, mas à criação do seu modelo.
Euphoric
2
Não tenho certeza se concordo plenamente com seu ponto de vista no desenvolvimento de software. O desenvolvimento de SW é design e construção. A construção deve fornecer um loop de feedback para o design. Nos domínios analógico e digital, bons arquitetos "sujam as mãos" e constroem para completar o ciclo de feedback. Mesmo se focarmos apenas no design, acho que a repetição do design identifica eficiências que levam a um melhor design. O SW não se repete como outros campos. Cada ponte requer modificação de uma abordagem geral, adaptando-a ao site em que está indo.
O SW dev não é tão complexo se comparado ao design que o arquiteto elaboraria. É que achamos difícil porque não tratamos o software como uma disciplina de engenharia adequada e porque continuamos reinventando as coisas. Se você soubesse o que se passava no projeto de outras coisas que você veria que a maioria software deve ser trivial, mas torná-lo difícil para nós :(
gbjbaanb
Para comparar com a ponte - você está certo, pontes são um problema resolvido. Você quer uma nova ponte, retire o pó dos designs antigos e faça alguns ajustes e terá uma nova ponte (exagerei aqui a simplicidade, é claro). Então, por que um serviço da Web não é construído de maneira semelhante em software? É por isso que o software não está projetando o IMHO, nós o tratamos mais como um ofício (ou arte), onde cada projeto é personalizado.
Gbjbaanb 17/07/2013
2

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?

psr
fonte
2

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.

Boise
fonte
O fato de a maioria dos desenvolvedores de sw não conseguir sobreviver sem conhecer o funcionamento interno do sistema é um forte indicador de reutilização extensiva? Também acho engraçado como as histórias de projetos do governo saem com um som simplesmente horrível, mas se você tivesse algum conhecimento sobre o trabalho do governo, entenderia como o autor não tem noção. Os martelos de US $ 1500 etc ... Todos se tornam compreensíveis quando você reconhece que os processos do governo exigiam 10 pessoas para revisar e obter cotações competitivas antes da compra OU simplesmente não estava movimentando fundos entre os baldes de contabilidade.
Dunk
Não me sinto à vontade em saber que um engenheiro de software que trabalha no "computador mais complexo" de uma aeronave não dorme há 32 horas. =)
RubberDuck
2

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").
    http://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/GoldenGateBridge-001.jpg/220px-GoldenGateBridge-001.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Ponte25Abril1.jpg/220px-Ponte25Abril1.jpg

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 ...

mosquito
fonte
1
Excelentes pontos, e acho que as fugas que foram revertidas para o conjunto de testes automatizados capturam parte da experiência que estou me referindo. Em relação às reivindicações da "mesma equipe", retiro a experiência de Wright. Com mais de 500 edifícios construídos, ele era um elemento comum para todos eles. Mas o argumento está correto e eu concordo com algumas das premissas.
@ GlenH7 sim, o impacto da repetição foi realmente profundo e foi muito além dos conjuntos de testes. Conhecimento acumulado em todos os lugares onde a repetição aconteceu - você sabe, tudo tende a se estabilizar após 20 ... 30 ... 50 vezes. Preparações noturnas / de ponto de verificação, envios de bugs (e toda a "vida útil dos bugs"), comunicação dev / QA / mgmt / sysadmins, documentando coisas etc. ter um efeito firehose em apresentar o meu ponto
mosquito
-1

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.

Amot
fonte
1
Acho que você aborda alguns pontos potencialmente válidos, mas não os vejo se unindo para responder à pergunta. E não concordo com sua proporção de 99: 1 para reutilização. Eu acho que superestima demais a quantidade de reutilização. Mesmo dentro do desenvolvedor de software, as taxas de reutilização não são nem de longe tão altas.
-2

É 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.

Edward
fonte
3
Entendo alguns dos pontos que você está tentando enfatizar, mas eles são baseados em presunção e desconhecimento. Eu desenvolvia para mainframes e posso garantir que a taxa de desenvolvimento era tão rápida quanto em sistemas abertos. O processo foi diferente, mas o ritmo foi o mesmo. Sua resposta seria mais forte, concentrando-se no componente de habilidades transferíveis e explicando as eficiências potenciais obtidas dessa maneira.
Você precisa olhar para a história, não havia novas tecnologias sendo lançadas todos os anos nos sistemas de mainframes para o CDC 6600 Kronos OS, por exemplo. Foi basicamente estático por 15 anos. Agora, as coisas mudam muito mais rapidamente e não há tempo para adquirir o conhecimento profundo ao longo de 15 anos. Não há programadores em Flash com 15 anos de experiência apenas em Flash, por exemplo. Depois de reler minha postagem, mantenho minha postagem original.
Edward