O que é uma boa metáfora de programação? [fechadas]

Refiro-me a explicar ao não programador o que é programação. Fiz questão de procurar perguntas semelhantes antes de criar esta, mas as poucas que encontrei pareciam se esquivar da pergunta e gostaria especificamente de ver algumas metáforas ou analogias. Pessoalmente, acho mais fácil explicar algo técnico a alguém através do uso de metáforas ou analogias.

A razão pela qual estou interessado nisso é porque muitas pessoas encontram o trabalho de um programador diariamente, mas se você perguntar à pessoa comum o que um programador é ou faz, elas realmente não sabem. Isso leva a certas situações de mal-entendidos (ex. "[...] mas eu pensei que você era bom com computadores!")

Eu realmente gostaria de encontrar o melhor por aí. Eu gostaria de poder explicar facilmente a alguém sobre o que é a minha escolha de carreira. Claro, pelo menos a ideia geral.

Pessoalmente, não tenho uma sólida, mas há muito tempo penso sobre isso e, em geral, atraí-me para a metáfora da 'linguagem', na qual conhecemos uma linguagem que os computadores entendem e, portanto, somos capazes de dizer aos computadores o que devem fazer. fazer, ou "ensiná-los", a resolver nossos problemas.

Por exemplo:

Imagine que, em uma realidade alternativa, existem robôs humanóides com inteligência artificial e algumas pessoas possam se comunicar com eles através de um idioma comum, que é uma variação do inglês. Essas pessoas que podem se comunicar com os robôs são capazes de ensiná-los a resolver certos problemas ou realizar certas tarefas, como fazer nossas tarefas.

Bem, embora robôs como esse ainda não existam, os programadores de nosso tempo são como essas pessoas, mas, em vez de se comunicarem com os robôs, eles se comunicam com os computadores. Os programadores "ensinam" os computadores a executar determinadas tarefas ou resolver certos problemas por meio do software que eles criam usando essa "linguagem comum".

Programadores e essa "linguagem comum" são o que nos fornece coisas como email, sites, videogames, processadores de texto, telefones inteligentes ( para simplificar ) e muitas outras coisas que usamos diariamente.

Não pretendo colocar a programação no trono nem nada, é apenas a melhor metáfora que eu poderia inventar.

Tenho certeza de que alguém encontrará algum problema com esse, provavelmente é um pouco artificial, mas, novamente, é por isso que estou fazendo essa pergunta.

É como ter que escrever instruções passo a passo detalhadas sobre como dirigir para algum lugar. Mas você geralmente precisa adicionar planos de contingência para coisas como 'e se houver um engarrafamento' ou 'e se um caminhão quebrar na faixa de curva'.

E, às vezes, você precisa se aprofundar ainda mais e explicar as regras da estrada, como em que lado seguir ou o que fazer no sinal vermelho. E às vezes você precisa explicar exatamente como o volante ou o pedal do acelerador funcionam.

E, geralmente, depois de descrever tudo isso com detalhes exatos, o cliente diz "isso é perfeito, exceto que ele precisa trabalhar para alguém que dirige um hovercraft"

Escrevo instruções muito, muito detalhadas para uma máquina muito, muito burra.

Eu uso a metáfora "Nós escrevemos receitas de tricô ", que é amigável para a avó.

Fundamentação da petição:

• O tricô é um processo mecânico bastante simples, no qual você basicamente precisa seguir instruções detalhadas exatamente para obter algo com isso.
• A maioria das instruções de tricô é para vários tamanhos. Isso fornece ifinstruções e matemática e loops.
• Você encontra o erro na receita quando o exército de avós zangadas vem com seus suéteres de buggy!

Não é uma analogia muito boa, mas quando as pessoas me dizem para consertar sua máquina, digo: "Eu sou o cara que desenha os carros. Eu não sou o mecânico!"

Quando criança, li uma descrição muito boa da programação: é como dizer a um robô como executar uma tarefa cotidiana comum, como ir à escola. Então você pode dizer para "Ir para a escola!", Mas não sabe como. Então você diz para "sair, virar à esquerda, continuar andando até chegar à escola, virar à esquerda, entrar e sentar". Mas há uma estrada no caminho! Então você precisa dizer para "parar na estrada, verificar se não há tráfego, atravessar a rua e continuar andando" em algum lugar no meio. E as portas? Então você adiciona "verifique se a porta da escola está aberta. Se não estiver, abra-a". lá. Eventualmente, você tem um programa que pode dizer ao seu robô como chegar à escola sozinho.

Isso se encaixa muito bem com o Logo, onde você instrui a tartaruga exatamente dessa maneira a criar formas complexas.

A programação é como uma caixa de chocolates . Às vezes, você encontra o que procura imediatamente, mas na maioria das vezes são necessárias muitas tentativas e erros. Às vezes você pega coco.

Semáforos . Os carros estão se movendo ou parando. É fácil imaginar um semáforo configurando, mas o que acontece se você adicionar outro? Que tal um terço? Que tal uma cidade inteira? Um sistema de trânsito é composto por milhares de semáforos, cada um simples por si só, mas quando tomado como um todo, torna-se um sistema complexo. Se um desses semáforos avariar ou estiver desligado por apenas alguns segundos, ele lançará todo o sistema no caos. Se tudo estiver sincronizado, você apenas aproveita o passeio.

Um palestrante motivacional encontra as chaves para desbloquear o quebra-cabeça das motivações, sonhos e idéias das pessoas. Cada situação, cada pessoa é diferente. O que funcionou no passado pode não ser apropriado agora. Às vezes, uma chave pode ser reutilizada, mas precisa ser adaptada ao indivíduo. Outras vezes, a chave deve ser modelada novamente. O mais gratificante é quando a pessoa é destrancada e você a vê sair e conquistar o mundo. O mais devastador é quando você se sente próximo, mas simplesmente não é capaz de desbloquear o potencial.

Uma história de detetive , onde o detetive constrói seu caso lentamente, procurando pistas e coletando evidências. Metódico, inteligente e preciso vencerá o dia. Desleixado, ignorante e preguiçoso condenará o caso. Eventualmente, o trabalho estará diante de um júri de pares.

Uma máquina caça-níqueis . Você coloca todas as suas moedas e puxa a alavanca. Às vezes você ganha muito, às vezes fica sentado por horas e nada acontece. Às vezes, outra pessoa apenas caminha casualmente, puxa a alavanca uma vez e ganha o jackpot.

Música . Uma nota é bastante simples, mas uma medida é mais complexa. Uma música completa tem muitas medidas e muitas notas. Se uma nota estiver desativada, ela pode arruinar toda a apresentação. Se todas as notas são entregues com perfeição, a apresentação desaparece em segundo plano e apenas a música existe.

A melhor metáfora para qualquer coisa é ela mesma. Qualquer coisa diferente perderá alguma precisão. Como tal, escolher a melhor metáfora depende do que você deseja capturar especificamente sobre a programação. Como haverá muitas respostas aqui sobre metáforas de codificação, responderei com a metáfora clássica do processo de desenvolvimento como um todo:

Construção civil

O aspecto mais comum dessa metáfora é que um arquiteto físico é algo análogo a um arquiteto de software. Aqui estão alguns outros paralelos:

• As alterações são cada vez mais baratas quanto mais cedo você as realiza. Ou seja, você pode mover uma linha no papel agora ou 10 toneladas em cimento posteriormente.
• Um edifício sem um plano adequado tenderá a entrar em colapso
• Os construtores tentam implementar o que o cliente deseja. Se o cliente não descrever com precisão como ele quer que o prédio seja (ou houver alguma outra falha na comunicação), será caro mudar.
• Existem certas leis da física que não podem ser dobradas. Assim como um segundo andar com trezentos pés de largura não pode ser construído em um primeiro andar de 100 pés de largura, o recurso X não pode ser construído sem um subsistema robusto Y.

Obviamente, como qualquer metáfora, ela tem suas limitações. Algumas falhas:

• Os edifícios são de uso único; você constrói em algum lugar, e aí fica. Você não pode copiá-lo um milhão de vezes para um milhão de usuários diferentes, com um milhão de necessidades diferentes, com custo incremental zero.
• Os edifícios são consideravelmente mais imutáveis ​​que o software.
• Não há analogia clara para o custo do material de construção. Uma linha de código não custa nada - apenas o tempo necessário para produzi-la custa dinheiro.
• A arquitetura incremental possível (dependendo de quem você pergunta) possível com o software não é possível com a construção, onde você a projeta uma vez e depois a constrói.

Então, como qualquer analogia, depende do que você está tentando explicar. Desconfie de confiar demais em qualquer metáfora ou seu cliente começará a se perguntar quais serão os impostos sobre a propriedade em seu novo sistema de folha de pagamento.

Eu amo a analogia de Chris McMahon de desenvolvimento de software como a criação de música, particularmente música jazz.

Esta é Ella Fitzgerald e Count Basie fazendo a música One O'Clock Jump. A música é um blues de doze barras, que é o equivalente ao jazz de um aplicativo de banco de dados com uma interface do usuário. O que quero dizer: assim como todo programador construiu um aplicativo de banco de dados com uma interface do usuário, todo músico americano tocou blues de doze compassos. É uma estrutura em que muitas e muitas músicas estão penduradas, desde Count Basie a Jimi Hendrix e Ramones.

Este vídeo em particular é um ótimo exemplo de prática ágil. Ouça como a voz e o piano se influenciam. Isso é muito parecido com a programação em pares e muito parecido com o TDD: a voz faz alguma coisa; o piano responde; piano faz alguma coisa; a voz responde. E observe o contato visual. Essas pessoas estão intensamente conscientes do que está acontecendo instantaneamente. Eles não têm partituras (BDUF). Eles estão envolvidos em uma atividade que requer intensa concentração e habilidade, assim como um bom desenvolvimento de software. Eles também estão claramente cientes de que há uma audiência, assim como um bom desenvolvimento de software deve estar ciente das necessidades das pessoas que pagam as contas.

Aqui está o link para a postagem do blog em que ele a discute: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

Às vezes me refiro à programação para controlar zumbis irracionais . Resumindo minha postagem no blog :

• Como zumbis, os computadores com os quais operamos são muito burros. É difícil instruí-los a fazer qualquer coisa, a menos que as instruções sejam detalhadas
• O zumbi é agressivo e se perdermos pequenos detalhes nas instruções, deixar a criatura sem tratamento, ela pode esmagar tudo ao seu redor. O mesmo acontece com os computadores: a falta de detalhes nas instruções pode fazer com que seu programa trave e destrua seus dados.
• Você precisa saber mágica se quiser controlar um zumbi. O mesmo com a programação.
• Quanto mais pessoas com cérebro se reúnem em um só lugar, maior a probabilidade de que eles tenham computadores. Parece que o cérebro atrai computadores - da mesma forma que atrai zumbis.

Programar é como construir coisas com o Lego :

• Você está juntando vários pedaços pequenos para fazer coisas maiores
• Os pequenos pedaços vêm em um número limitado de formas e tamanhos
• As pequenas coisas só podem se encaixar de certas maneiras
• Brincar com essas coisas pode ser muito divertido

Programar um computador é como criar um filho ...

• Todo mundo discorda sobre o caminho certo para fazê-lo
• Mantém você acordado à noite
• Nunca faz o que você manda
• Não importa quantos livros você leia sobre o assunto, quando for fazer isso, sentirá que não tem ideia do que está fazendo.
• Depois de um tempo, você tende a ficar preguiçoso
• Você espera que ele tenha ótimos retornos no futuro, mas acabará tendo que mantê-lo até o final de sua vida útil.
• Nunca é tão limpo, inteligente ou seguro quanto você queria que fosse
• Quando você olha para trás mais tarde, você se pergunta o que diabos estava pensando
• Apesar de todo o estresse causado por você, você ama mesmo assim.

A principal diferença é que ficamos chateados se alguém rouba nosso código-fonte, mas geralmente ficamos felizes em ter alguém que tira nossos filhos de nossas mãos.

Programar é como construir uma fábrica ou uma linha de montagem.

Pense no software como uma máquina ou linha de montagem que existe dentro do computador. Algumas matérias-primas e componentes são alimentados na máquina e segue um conjunto de procedimentos para processá-los em algum produto final. Os procedimentos são configurados para executar uma operação específica em alguma matéria-prima ou componente para um conjunto específico de parâmetros (por exemplo, tempo, temperatura, distância etc.) em uma ordem específica. Se os detalhes da operação a ser executada estiverem incorretos, ou os sensores da máquina não estiverem calibrados corretamente, ou se alguma matéria-prima ou componente não estiver dentro dos padrões de qualidade esperados, isso poderá alterar o resultado da operação e o produto não sairá. como esperado.

Essa máquina é muito rígida em sua operação e entradas aceitáveis. Máquinas não questionam a inteligência dos projetistas nem seu ambiente operacional atual. Ele continuará a seguir os procedimentos, desde que direcionado. Mesmo que uma alteração nas matérias-primas ou nos componentes possa ter um efeito drástico no que aconteceu em operações posteriores, a máquina ainda executaria seus procedimentos. O processo precisaria ser revisto para ver quais alterações nos procedimentos eram necessárias para compensar e produzir o resultado desejado. Uma alteração no design ou na configuração do produto também pode exigir uma alteração significativa nas operações executadas ou em seu pedido. Embora os responsáveis ​​pela produção tenham aprendido rapidamente a importância de isolar as operações o máximo possível para reduzir os efeitos indesejáveis ​​entre eles, são feitas muitas suposições sobre a condição dos componentes quando eles passam pelo processamento; suposições que podem não ser detectadas até que o produto final esteja nas mãos do usuário em algum ambiente operacional diferente.

Ajudar um idiota rápido a passar em uma aula de matemática que exige um ensaio escrito.

A programação de computadores é como jogar um jogo de xadrez no qual o tamanho do tabuleiro, a quantidade de peças em jogo e as regras que as governam aumentam em tamanho e complexidade à medida que o jogo avança.

Escrever software é como ... Escrever! ^^

Os novos alunos das aulas de CS / Programação são, praticamente, como usuários não programados. O exemplo do robô é bom.

Nos anos 80, usar Logo, Karel (ou ambientes de programação semelhantes), onde o usuário aprende a programar, assistindo o computador como um robô, em vez de um aparelho de TV com uma máquina de escrever, ajudou muito. Essas ferramentas eram comumente usadas no ensino médio e no ensino médio.

Essa programação prática ajudou os alunos a adquirir habilidades de resolução de problemas, mesmo que não estivessem relacionados ao computador !!!

Ou, mesmo que os alunos não se tornassem programadores.

Alguns colegas e universidades também aplicaram essas ferramentas nos cursos do primeiro ano.

Eu me pergunto por que muitas escolas de ensino médio abandonam o ensino de Logo e Karel ...

Gosto da analogia de Fred Brooks, do Mythical Man-Month, de que a programação é como realizar mágica.

(O) construto do programa, diferentemente das palavras do poeta, é real no sentido em que ele se move e trabalha, produzindo resultados visíveis separados do próprio construto. Imprime resultados, desenha imagens, produz sons, move os braços. A magia do mito e da lenda se tornou realidade em nosso tempo. Digita-se o encantamento correto em um teclado, e uma tela ganha vida, mostrando coisas que nunca existiram nem poderiam ser. ...

(Um) deve funcionar corretamente. O computador também se assemelha à magia do mito e da lenda. Se um personagem, uma pausa do encantamento não está estritamente na forma adequada, a mágica não funciona. Os seres humanos não estão acostumados a serem perfeitos, e poucas áreas de atividade humana o exigem. Ajustar-se ao requisito da perfeição é, penso eu, a parte mais difícil de aprender a programar.

"[...] mas eu pensei que você era bom com computadores!"

Geralmente, é uma tentativa de enganar um nerd para consertar um computador (você sente esse desejo de provar que está errado?). Minha resposta padrão:
sou programador. É como um engenheiro de automóveis - ele provavelmente não saberá como consertar o freio de você, Trabant '72, e certamente não faria isso se soubesse. Um mecânico faria isso!

Gosto do conceito de receita para cozinhar.

Programar é como exercer enormes quantidades de energia. Você pode fazer o computador fazer o que quiser. Você é limitado apenas pela sua imaginação e pela quantidade de tempo que está disposto a investir.

Programadores são como os criadores de uma casa. Podemos contar tudo sobre as casas que construímos. No entanto, se você nos perguntar a uma casa aleatória sobre a qual estamos passando na estrada, é provável que não saibamos muito sobre isso. Mas se você precisar de algo adicionado ou alterado nessa casa, podemos fazer isso acontecer, desde que o proprietário nos permita.

Em um dos antigos artigos de Chris Crawford sobre programação, ele comparou um programa complexo a uma burocracia, com várias agências que se comunicam transmitindo memorandos de um lado para outro. Eu descobri que essa é uma metáfora muito útil ao explicar o desenvolvimento de software.

Eu geralmente igualo a programação a um quebra-cabeça.

Para criar um novo projeto - você tem toneladas de peças, algumas das quais não pertencem a esta imagem, e você não tem uma prévia da aparência do quebra-cabeça quando terminar. Mas você conhece o tamanho e as cores gerais, portanto, as estimativas são possíveis, mas não necessariamente precisas.

Para modificar um projeto já existente - um gato apareceu e derrubou um pedaço do quebra-cabeça acabado. Vai levar algum tempo, mas a estrutura já está lá, então não deve ser tão ruim (dependendo de quanto precisa ser alterado).

Também ajuda na descrição do progresso. Um dos meus projetos recentes, em um ponto, eu estava pensando em como descrevê-lo, para que uma pessoa não técnica entendesse por que não sei por quanto tempo mais, e eu criei: Pense em um quebra-cabeça em que todos os peças de borda são feitas, assim como um pouco mais da metade se as peças internas. Os que restam são todos separados, o que tenho que fazer agora é preencher as lacunas.

É triste, mas a programação é um trabalho que pode ser entendido apenas aprendendo como fazê-lo.

A programação tem vários níveis diferentes de percepção e diferentes de lados diferentes.

Em nível baixo, é "escreva instruções muito, muito detalhadas para uma máquina muito, muito burra"

No próximo nível, está lidando com complexidade. Construindo uma nova metáfora para simplificar o trabalho. Como matemática superior.

De outro lado, o uso de tecnologias auxiliares, como controle de versão, código auto-documentado, construção e teste de projetos.

Por outro lado, sua interface de "usuário" em construção (não literalmente, refiro-me à API e também à interface do usuário), prevê possíveis erros (feitos pelo usuário, dados ou até por si) e corrige a reação aos erros.

E finalmente.

Metáfora para programação é literatura. Primeiro, preciso aprender o alfabeto. Mas escrever um romance até isso nem começa.