Evidência empírica para a escolha do paradigma de programação para resolver um problema

11

O wiki C2 tem uma discussão sobre evidências empíricas para programação orientada a objetos que basicamente conclui que não há nada além do apelo à autoridade. Isso foi editado pela última vez em 2008. A discussão aqui parece confirmar isso: perguntas sobre se o OO está desatualizado , quando a programação funcional é uma má escolha e as vantagens e desvantagens da AOP são respondidas com a opinião dos colaboradores, sem depender de evidências.

Obviamente, as opiniões de profissionais estabelecidos e de renome são bem-vindas e valiosas, mas são mais plausíveis quando são consistentes com dados experimentais. Essa evidência existe? Eu sei que a engenharia de software baseada em evidências é uma coisa, mas posso praticá-la nesse contexto? Especificamente, se eu tiver um problema específico Pque quero resolver escrevendo software, existe um conjunto de conhecimentos, estudos e pesquisas que me permitiriam ver como o resultado de resolver problemas como esse Pdepende da escolha do paradigma de programação?

Eu sei que qual paradigma aparece como "a resposta certa" pode depender de quais métricas um estudo em particular presta atenção, em quais condições o estudo mantém constante ou varia e, sem dúvida, também em outros fatores. Isso não afeta meu desejo de encontrar essas informações e apreciá-las criticamente.

Torna-se claro que algumas pessoas pensam que estou procurando uma solução "ligue a manivela" - alguma máquina de salsicha na qual coloco informações sobre o meu problema e da qual surge uma palavra como "funcional" ou "estruturada". Esta não é minha intenção. O que estou procurando é pesquisar como - com muitas advertências e suposições que não vou abordar aqui, mas uma boa literatura sobre o assunto - certas propriedades do software variam dependendo do problema e da escolha do paradigma.

Em outras palavras: algumas pessoas dizem que "OO oferece melhor flexibilidade" ou "programas funcionais têm menos bugs" - (parte do) o que estou pedindo é a evidência disso. O resto está pedindo evidências contra isso, ou as suposições sob as quais essas declarações são verdadeiras, ou evidências mostrando que essas considerações não são importantes. Há muitas opiniões sobre por que um paradigma é melhor que outro; existe algo objetivo por trás de algum desses?

Comunidade
fonte
1
pesquisa na web para baseadas em evidências de engenharia de software mostra links abundância
mosquito
@gnat O EBSE trata de resumir sistematicamente a literatura e tirar conclusões gerais sobre como podemos melhorar a prática. Minha pergunta é se essa literatura existe; se há o suficiente para que revisões sistemáticas ou meta-análises sejam produtivas.

Respostas:

12

Para a versão anterior, consulte a Revisão 1 desta resposta . No entanto, os comentários e edições da pergunta esclarecem melhor o que a pergunta está buscando e permitem que eu seja mais claro.

Sim, a engenharia de software baseada em evidências (EBSE) é uma coisa. Parece haver alguns esforços em relação aos bancos de dados do EBSE, como este na Universidade de Durham e no SEED, iniciado por um professor da Cal Poly . Todos esses esforços, bem como os discutidos em vários documentos, podem ser encontrados no servidor IEEE Xplore ou na Biblioteca Digital ACM(assinatura ou compra necessária para muitos artigos em ambos), são baseadas em medicamentos baseados em evidências. Eles fornecem revisões de literatura de dados empíricos publicados (observação e experimento). De fato, a inclusão de "revisão de literatura" em uma sequência de pesquisa em qualquer pesquisa de publicação gera informações sobre a maioria dos tópicos - mais de 14.000 ocorrências no ACM e mais de 1.000 no banco de dados IEEE (quando limitado a apenas tópicos de computação).

Olhando para os tipos gerais de tópicos discutidos nessas bases de dados EBSE e revisões de literatura, vejo uma discussão comum - eles tendem a ser independentes da tecnologia. A ênfase parece estar principalmente centrada no processo e na metodologia, e não nas ferramentas específicas usadas para conduzir a engenharia de software.

Portanto, esse conceito existe na engenharia de software. A Academia está ciente do conceito baseado em evidências e pode aplicá-lo com sucesso à engenharia de software.

Especificamente, a pergunta aborda a aplicação de técnicas EBSE à seleção de um paradigma parece difícil, devido ao grande número de variáveis ​​envolvidas, forçando suposições a serem feitas, além de reduzir a capacidade de repetir o experimento ou observação. É dito exatamente na pergunta - "qual paradigma aparece como" a resposta certa "pode ​​depender de quais métricas um estudo específico presta atenção, de quais condições o estudo se mantém constante ou varia e, sem dúvida, de outros fatores também" . Embora isso não signifique estudar o paradigma "melhor" em uma determinada situação, torna qualquer tipo de revisão da literatura desses documentos incrivelmente difícil de concluir e ainda extrair informações entre eles.

Definitivamente, não existe uma solução "virar a manivela" para escolher um paradigma.

Dado um paradigma de programação, é possível encontrar estudos nos vários bancos de dados acadêmicos e do setor sobre como esse paradigma influencia vários aspectos do desenvolvimento de software - qualidade, defeitos, eficiência etc. - sob várias condições específicas, variando desde o conhecimento e a experiência do equipe para o domínio do problema. Qualquer artigo rigoroso deve identificar claramente as condições sob as quais os dados foram coletados e as suposições. O problema começa a tentar isolar os fatores que o tornam bom em cada uma dessas condições.

Academicamente, existem algumas afirmações fáceis de pesquisar. Por exemplo, a afirmação de que o paradigma funcional é bem adequado para aplicativos que exigem simultaneidade deriva do teorema de Church-Rosser . Por esse motivo, é provável que um sistema de software escrito em uma linguagem funcional tenha menos defeitos relacionados à simultaneidade do que o mesmo sistema escrito em uma linguagem processual ou orientada a objetos.

No entanto, do ponto de vista prático, uma equipe de software nem sempre pode usar "a melhor" ferramenta ou técnica para o trabalho apenas porque a pesquisa indica. Embora nos esforcemos para produzir sistemas de software da mais alta qualidade, operamos dentro de restrições. Muitas vezes, vejo essas restrições minimizadas (ou mesmo removidas da equação) ao discutir a eficácia de qualquer metodologia.

Como profissional, quando estou envolvido na escolha de tecnologias a serem usadas, tento identificar as melhores ferramentas possíveis. Mas então eu me restrico ao que é conhecido e bem compreendido pela equipe que tenho. Voltando ao meu exemplo anterior, se eu tiver uma equipe versada na criação de aplicativos simultâneos em C ++ e nenhuma experiência em Haskell, não faz sentido propor a criação do sistema em Haskell, pois provavelmente não será possível fazer isso. restrições de cronograma e orçamento, e minha qualidade provavelmente sofrerá devido à falta de experiência no conjunto de ferramentas.

Para recapitular, a engenharia de software baseada em evidências é geralmente uma coisa boa que existe e as revisões de literatura existem e estão prontamente disponíveis. No entanto, há aspectos da engenharia de software em que a aplicação de abordagens baseadas em evidências oferece pouco valor. A seleção de um paradigma de programação para um esforço de desenvolvimento em larga escala é uma delas.

Se você quiser descobrir como a orientação a objetos aborda a reutilização ou defeitos na programação funcional - você encontrará facilmente publicações sobre elas. No entanto, eu não encontrei (nem depositaria muita confiança) em uma publicação capaz de abordar efetivamente a seleção de paradigmas em toda a ampla gama de projetos de engenharia de software do mundo real.

Thomas Owens
fonte
A seção sobre a integridade de Turing ignora compromissos, que é o que eu quero ver exposto e comparado. Deixe-me dar um exemplo específico. Muitas pessoas me dizem que a programação funcional é ótima para evitar erros de simultaneidade. Agora descobrimos que Scheme é, como Pascal, completo de Turing. Portanto, deve ser possível escrever código de segurança de concorrência proceduralmente. Acordado. Mas isso é ótimo ? Existem vantagens em escolher um método? Essas vantagens podem ser medidas?
1
@GrahamLee Confirmar ou rejeitar sua hipótese requer evidência objetiva, que não existe. Existem razões subjetivas para criar um novo paradigma e um novo modelo de representação exata das mesmas capacidades computacionais - e isso não se restringe às linguagens de programação, mas também à representação matemática subjacente das referidas linguagens . Essas razões objetivas incluem visar um grupo demográfico específico (matemático computacional versus analista de negócios - sua maneira de pensar é diferente, requer um paradigma diferente).
Thomas Owens
2
@ Thomas: sua implicação de que as práticas de programação são exclusivamente opacas à ciência é peculiar. Há muita pesquisa em andamento. Um exemplo frequentemente citado é o grupo de pesquisa de Lutz Prechelt . Não conheço a área suficientemente bem para saber se alguém abordou as questões específicas de Graham, mas não há razão para acreditar que elas não sejam tratáveis ​​pelo tipo de método usado por Prechelt e outros.
29412 Cris
1
@ Chris, eu não acredito que eles sejam opacos à ciência. No entanto, acredito que há algumas coisas que, quando Graham diz na pergunta, acrescenta "muitas advertências e suposições" à pesquisa, não é mais útil para os profissionais. Nesse ponto, de uma perspectiva prática nas trincheiras, é simplesmente mais eficaz basear suas decisões na história e na experiência. Ter dados válidos, válidos e válidos é uma coisa muito boa. Mas chega um momento em que é muito difícil obter ou é válido apenas em uma situação muito específica que não é útil para a indústria.
Thomas Owens
1
@ Thomas duvido disso. A prática médica geral é pelo menos tão situacional e sensível ao contexto quanto a engenharia de software e, er, há evidências de que o GP baseado em evidências produz melhorias mensuráveis. É basicamente uma questão de quantidade e qualidade da pesquisa.
Cris
7

Eu tenho lido The Art of Unix Programming de Eric S. Raymond. Ele tem algumas idéias históricas muito interessantes sobre coisas que agora tomamos como garantidas. Ele cita alguns bons estudos do software IEEE que usam evidências empíricas como densidade de defeitos. Essa pode ser uma boa fonte se você estiver procurando por estudos no estilo acadêmico.

Mesmo técnicas como modularizar usando funções nem sempre eram práticas comuns. Uma das minhas citações favoritas do livro até agora:

Dennis Ritchie incentivou a modularidade dizendo a todos que as chamadas de funções eram realmente muito baratas em C. Todo mundo começou a escrever pequenas funções e modularizar. Anos depois, descobrimos que as chamadas de função ainda eram caras no PDP-11, e o código VAX gastava 50% de seu tempo na instrução CALLS. Dennis havia mentido para nós! Mas era tarde demais; Estávamos todos viciados ...

- Steve Johnson

No entanto, existem realmente dois problemas em ser empírico. A primeira é que a qualidade do código é uma coisa muito subjetiva. O código pode ser terrível e ainda estar correto. A percepção das pessoas sobre um paradigma de programação é uma métrica muito válida, porque o código é escrito para que as pessoas leiam tanto quanto para computadores, se não mais.

O segundo problema é que 50% dos desenvolvedores têm talento abaixo da média na programação. Não importa se o seu desenvolvedor de topo é mais produtivo usando programação funcional se as lutas "ralé" para escrever trabalhando software de usá-lo, vamos software sozinho lindos e bem arquitetado. Da mesma forma com as linguagens de programação TMTOWTDI , seu desenvolvedor principal ainda escreverá um código modular e limpo, mas codificadores menos talentosos gravarão ruído de linha devido à falta de estrutura imposta.

É por isso que acho que a OOP subiu ao topo em popularidade, apesar de suas deficiências. Não é tão restritivo que atrapalha os mais talentosos, mas sua estrutura fornece uma maneira concisa de se comunicar e impor bons princípios de design aos menos talentosos.

Em nossa linha de trabalho, temos a tendência de avaliar uma solução baseada apenas em seus méritos técnicos. Um empreendimento bem-sucedido também deve levar em consideração o lado humano da equação.

Karl Bielefeldt
fonte
"a qualidade do código é uma coisa muito subjetiva" concordou - você deve ter cuidado com o que mede, e a percepção é um fator importante. Mas a percepção, como muitas outras coisas, também é maleável: observe a ascensão e a queda da ascensão da programação funcional para ver que o que as pessoas pensam de como trabalham não está diretamente relacionado à maneira como trabalham. Também recentemente reli o TAOUP. Parte da minha motivação para essa pergunta é ver na literatura inicial soluções para problemas atuais na engenharia de software.
+1, "O segundo problema é que 50% dos desenvolvedores têm talento de programação abaixo da média". Esta frase é um alívio para mim. É melhor do que muitos comprimidos Tentei :)
NoChance
3

Existem concursos de programação que usam um sistema de classificação por computador e permitem escrever em vários idiomas e publicar todos os tipos de resultados e coisas. Aposto que eles têm bons dados para você. Aqui está uma lista de 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

Imagino que você possa fazer comparações significativas de soluções para problemas muito simples e claros, como soma de quadrados ou séries de Fibonacci, ou desenhar uma linha reta usando o algoritmo de linha de Bresenham. A maioria das tarefas de programação do mundo real não possui postagens claras e cada idioma tem seus pontos positivos. Grande parte do benefício de um idioma é subjetivo. Você pode encontrar dados mais significativos pesquisando a felicidade do programador e do cliente do que contando linhas de código ou número de defeitos.

Lembro que, quando passei meio dia escrevendo um dos meus primeiros programas do Awk, pensei que levaria uma semana inteira para fazer a "mesma coisa" em Java. Mas isso é porque minha solução Java teria se concentrado em ser robusta, onde a solução Awk era rápida e suja e exigia alguns ajustes manuais na entrada e na saída e era realmente descartável quando eu terminava. Awk e Java são ótimos, mas não para as mesmas coisas.

Acho que o que estou dizendo é que, para aplicativos do mundo real, comparar linguagens ou ferramentas de maneira significativa é extremamente difícil - o problema das maçãs e laranjas antigas. Boa sorte! Eu adoraria ver o que você descobriu.

GlenPeterson
fonte
2

Estou estudando maneiras diferentes de desenvolver software há mais de 30 anos. Há uma escassez de boas evidências publicadas sobre a escolha de um paradigma.

Eu montei uma grande bibliografia ASCII pesquisável. Isso inclui muitos papéis e artigos do IEEE e ACM. Eu identifico os itens com o tipo de evidência fornecida. Aqui estão as tags mais comuns:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Agora pesquise PARADIGM e conte as tags

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Se você quiser ir mais fundo, http://cse.csusb.edu/dick/lab.html e espero que ajude ...

Richard John Botting
fonte
1

Parece que, em muitos casos, não existe um corpus de pesquisa grande o suficiente ou de qualidade alta o suficiente para permitir tirar conclusões gerais sobre se uma prática em engenharia de software é melhor que outra. Eu estava procurando especificamente uma pesquisa para trabalhar em diferentes paradigmas, mas a falta de disponibilidade não se limita a essa arena, portanto, enquadrarei minha resposta em um sentido mais amplo.

Um artigo de 2004, Engenharia de Software Baseada em Evidências , de Kitchenham et al. , Aborda de maneira sucinta os benefícios a serem derivados de uma abordagem baseada em evidências e os problemas com a implementação na engenharia de software. Não discutirei os benefícios aqui (está claro na pergunta que eu gostaria de poder trabalhar dessa maneira), mas os problemas são relevantes como resposta à pergunta que fiz.

  • Em primeiro lugar, se você não é membro do ACM, provavelmente não consegue ler o link acima, o que cobre o primeiro problema: nem toda a pesquisa existente está realmente disponível para os profissionais.
  • muita prática de engenharia de software continua em segredo como parte de processos comercialmente confidenciais, portanto não há visibilidade do que funcionou ou não para essas pessoas.
  • engenharia de software é uma prática hábil, por isso é difícil (não impossível, apenas difícil) organizar um estudo adequadamente cego.
  • as diferentes partes do ciclo de vida do software afetam os resultados uns dos outros em uma extensão difícil de controlar em qualquer experimento.
  • como evidenciado pelas discussões aqui, muitos profissionais não vêem "a literatura" (ou o lado acadêmico da engenharia de software em geral) como relevante para o seu trabalho.

Portanto, a resposta que procuro é "não", a evidência que estou procurando provavelmente não existe. Eu deveria escolher meu paradigma com base nos critérios populares existentes do que eu sei, do que é legal e da opinião de especialistas.


fonte
2
do resumo do artigo citado, ênfase minha: "O fator de habilidade significa que as experiências de engenharia de software são vulneráveis ​​ao viés do sujeito e do experimentador . O fator do ciclo de vida significa que é difícil determinar como as tecnologias se comportarão uma vez implantadas . Conclusões: a engenharia de software se beneficiaria de adotando o que pode da abordagem de evidência, desde que lide com os problemas específicos que surgem da natureza da engenharia de software ". À qual eu acrescentaria: boa sorte com isso! ;)
Steven A. Lowe
Steven: parte da motivação por trás do EBSE é passar de "Posso adivinhar os seguintes problemas, portanto, rejeitarei qualquer chance de sua solução funcionar" para analisar os resultados por seus próprios méritos. Há muito mais em um artigo do que seu resumo.
2
Agradeço seu entusiasmo. A ciência médica e o desenvolvimento de software são disciplinas radicalmente diferentes. Embora a analogia seja interessante, dificilmente é inovadora. O artigo completo está disponível aqui labada.inf.utfsm.cl/~gvaldes/ESE/docs/… A seção 5 reflete a incompatibilidade de impedâncias mencionada no resumo. Um mapeamento mais direto das técnicas médicas seria a depuração de sistemas existentes, não a construção de novos. ;) Se você deseja criar produtos melhores, crie equipes melhores. As pessoas são muito mais importantes do que as ferramentas (cf Peopleware)
Steven A. Lowe
1
adendo: o site da EBSE tem algumas informações úteis, dur.ac.uk/ebse/evidence.php seria especialmente útil para os novos no campo SE - mas faça as pesquisas com um bloco de sal, porque (1) as evidências disponíveis é escasso e (2) os resultados médios podem não ser relevantes para o desempenho de sua equipe de indivíduos específicos com habilidades e aptidões altamente especializadas.
Steven A. Lowe
0

Não acredito que esse tipo de estudo exista. Alguém poderia acreditar que não é o paradigma de programação que importa tanto quanto o algoritmo real que é usado. Por exemplo, dado que qualquer sistema não trivial, um que dependa de algoritmos de espaço pequeno, versus um que dependa de algoritmos de tempo pequeno, geraria métricas diferentes. Aquele que tiver o melhor tempo provavelmente seria considerado mais válido, a menos que o espaço seja um problema, o inverso é verdadeiro. Acho que é semelhante a pavimentar uma estrada. Embora o algoritmo ou a receita para a fabricação de materiais seja constante em todos os processos, seria possível que uma empresa pense que pavimentar duas faixas ao mesmo tempo (uma de cada lado da estrada) é melhor do que pavimentar duas faixas ao mesmo lado da estrada ao mesmo tempo . No final do dia, não importa, pois o processo de fazer o top preto ainda é o mesmo, a única diferença é a abordagem. Voltando à programação, se você tiver uma equipe de desenvolvedores C, escreva o código de maneira processual, se você tiver uma equipe de desenvolvedores Java, escreva-o no OO. Não se prenda tanto ao paradigma quanto à implementação do algoritmo. Porque no final do dia, você pode escrever Java como C e tentar escrever C como Java.

ATUALIZAR

Para responder ao comentário, graham me deixou:
Suponho que por arquitetura você quer dizer paradigma de programação. Se você for usar o Clojure, talvez você deva contratar uma equipe de programadores do Clojure. No entanto, com base em uma pesquisa rápida, o Clojure é uma linguagem baseada em Java que, por acaso, é funcional. Dada essa informação, eu pegaria os programadores Java (já que tecnicamente eles podem escrever Java e isso fornecerá os mesmos resultados) ou procurar programadores funcionais, como os desenvolvedores Haskell. Agora, em termos de escolha do que é melhor, é completamente dependente da sua equipe. Eu nunca teria uma equipe de especialistas em bancos de dados relacionais organizando uma solução em nuvem para mim, nem uma equipe de programadores funcionais criaria uma solução orientada a objetos para mim. Você tem que usar os pontos fortes da equipe e não ter a visão glorificada que tem em sua mente para o que uma equipe "deveria"

Woot4Moo
fonte
Como escolho contratar uma equipe de programadores Java ou uma equipe de programadores C? Devo treiná-los novamente em Clojure? Depois de escolher meu algoritmo, qual arquitetura é a "melhor" maneira de encapsulá-lo em uma solução de software, para determinados valores de "melhor"?
@GrahamLee see my update
Woot4Moo
Sinto que estamos discutindo o mesmo problema, mas em diferentes níveis de abstração. "Usar os pontos fortes da equipe que você tem" significaria nunca construir um computador, porque Bletchley Park não tinha ninguém com força na construção de computadores. Às vezes você tem que dizer "poderíamos criar uma solução melhor se usássemos essa coisa"; o que estou procurando são as informações sobre esses casos.
0

Diferentes paradigmas levam a diferentes soluções. Qual ajuste é 'melhor' depende em grande parte:

  • a solução
  • a equipe de desenvolvimento
  • o ambiente operacional

Não conheço nenhum estudo definitivo e, mesmo que houvesse um, não confiaria nele.

Esse é o trabalho do arquiteto.

Substituir a sabedoria do arquiteto pelas conclusões possivelmente irrelevantes de um estudo é uma receita para o desastre.

Nota: um comentário menciona a decisão sobre o "algoritmo" e a escolha do idioma. Algoritmos são o mecanismo estrutural central para linguagens procedurais. Linguagens orientadas a objetos se concentram em classes e padrões de colaboração / comunicação. Se você está convencido (como arquiteto) de que uma solução centrada em algoritmos é "a melhor", fique com linguagens procedurais ou funcionais.

Adendo: não confiar em estudos não é 'superstição', é senso comum. Os experimentos científicos devem ser objetivos e repetíveis. Os projetos de software são altamente subjetivos, mas ainda pior, são experimentos irrepetíveis . Você simplesmente não pode implementar um projeto X com a equipe Y, medir os resultados e reverter o tempo, apagar memórias e refazer o mesmo projeto com a mesma equipe. As informações descobertas ou implícitas pelos estudos podem ser úteis para o arquiteto, mas nunca podem ser definitivas.

Steven A. Lowe
fonte
1
Então, está fora do alcance de um arquiteto procurar trabalhos anteriores sobre os quais construir sua opinião? Provavelmente não - daí a questão de saber se e onde esses resultados podem ser encontrados.
2
Se houve um estudo definitivo com um método experimental razoável, os resultados do estudo podem ser interessantes; como está, essas respostas parecem afirmar que qualquer estudo é inútil, independentemente do método, que é um pouco não científico para o meu gosto
jk.
3
@ Steven: a palavra para não confiar nos resultados de um estudo verdadeiramente definitivo é "superstição". Talvez o que você realmente queira dizer é que você não acredita que possa haver estudos definitivos em SE (essa afirmação, obviamente, exigiria um grande e bem apoiado corpo de evidências).
29412 Cris
1
A qualidade de um método de software está em quão bem ele corresponde à necessidade humana local. Em geral, não é limitado pelas leis da física (Scotty). Levará um longo tempo até que o 'software' [disciplina] consiga destilar suas leis fundamentais imutáveis. Por exemplo, consulte "Métricas de qualidade de software: três métricas prejudiciais e duas métricas úteis" em ppi-int.com/newsletter/SyEN-046.php#feature e ppi-int.com/newsletter/SyEN-047.php#feature
Philip Oakley
1
@Cris: Para constar, não, não acredito que possa haver um estudo realmente definitivo nessa área; veja adendo. A idéia de que um estudo "definitivo" possa ser usado em vez de um julgamento de um especialista para tomar uma decisão arquitetônica crítica é "apelo à autoridade", que é uma forma de falácia lógica :) Na minha experiência - e eu não estou confuso acusações, apenas uma observação - a busca por tais coisas geralmente é uma tentativa de evitar a responsabilidade por uma decisão ou uma tentativa de apoiar uma decisão que já foi tomada.
Steven A. Lowe