Uma simples explicação de simplicidade. Capítulo 1: Teoricamente Simples

Uma explicação simples da simplicidade

PAC com áreas que teremos que visitar para responder à pergunta PRINCIPAL.

Prefácio

Muitas vezes ouvi conselhos: facilite.

E o que significa simples? Quando dizemos que o objeto X é simples, quais são nossas expectativas para X? Quando dizemos que algo é mais fácil que outro - como o avaliamos?

O que é mais fácil:
“Uma sentença pequena de cinco palavras” ou a palavra “desoxirribonucléico”?
"6 * 5" ou "481"?

Ou então:
Você tem uma tela de configurações. Cinco deles estão relacionados à programação, os outros cinco a notificações. Você precisa criar itens separados de "agendamento" e "notificação" no menu principal? Ou deixar todos os 10 pontos em uma tela? O que será mais fácil para o usuário?

Você pode dizer que isso é subjetivo. Que isso é determinado por um tipo de "senso de simplicidade", que para uma pessoa algo pode ser simples e para outro complexo.

Ok, então me diga por que o professor gasta tempo explicando algo mais fácil? Por que editar o texto, tentando facilitar? Por que os programadores gastam tempo revisando o código tentando descobrir em qual solução é mais fácil entender e expandir?

Se a simplicidade se correlacionar de alguma forma com a nossa avaliação, a melhor estratégia é a persuasão. Vamos fazer com que os leitores acreditem que o texto é simples. Ou colegas, acreditavam que nossa decisão não era difícil.

Mudará qualitativamente a interação deles com o resultado do nosso trabalho?

Não.

Seu texto não será mais fácil de ler porque é considerado simples. Não será mais fácil trabalhar com seu código, mesmo que todos ao seu redor pensem que sua complexidade é a mesma de uma banqueta.

Se você foi informado em uma entrevista que a empresa possui código limpo e boa documentação, e você acreditou, isso não afetará a simplicidade de trabalhar com o código.
Além disso, mesmo que todo o departamento acredite que o código esteja bem escrito e haja docas, isso também não afetará o resultado. Sua crença em seu código pode estar errada.

Se o código era espaguete - será espaguete. Se a "documentação" é o comentário do formato "aqui adicionei 2 números" - o código não possui documentação.
E nenhum desejo, confiança, etc. não ajudará aqui.

Isso não funciona pelo mesmo motivo ^{( ru , pt ),} pelo qual você não pode dar a 1 de seus amigos 1 cupcake se você tiver apenas 2 caixas de 2 cupcakes cada. Mesmo se você meditar toda a empresa por um ano que 2 + 2 = 5, isso não mudará a triste situação dos cupcakes.

Mais uma vez Existe um objeto, e algumas de suas características podem fazer você pensar ^{( ru )} que é simples. E se amanhã sua avaliação mudar e parar na marca "difícil", o objeto não se importará.

Pode-se concluir que simplicidade ou complexidade não depende de nossas expectativas. Pelo contrário, o objeto determina qual característica iremos dar a ele.

Eu queria entender que tipo de objeto espero ver na realidade, se estou convencido ^{( ru ) de} que é simples. E vice-versa, que características de um objeto real me fazem pensar que é simples.
Porque Bem, talvez isso facilite minha vida?)

Capítulo 1. Teoricamente simples

Neste capítulo, veremos os seguintes tópicos:

• Como fazer perguntas e por que isso é importante? ( Sequência de perguntas )
• Como os objetos, ações e seus executores estão relacionados? ( Simplicidade em ação , subjetividade objetiva )
• Como determinar a complexidade da ação? ( Fácil de usar , provavelmente simples )
• O que são sistemas e seus modelos e por que essa é uma maneira conveniente de descrever objetos? ( Sistematização da modelagem )

No final do capítulo, falaremos um pouco sobre a Navalha de Occam ( Blade Runner ). Um artigo sobre simplicidade pareceria estranho sem mencionar esse princípio.

1.1 Sequência de perguntas

Nossa pesquisa começa com uma pergunta. Fazer uma pergunta corretamente é muito importante. Uma pequena digressão:

- Ok, Deep Thought, qual é a PRINCIPAL CONDIÇÃO DE SIMPLICIDADE?
Eu preciso pensar sobre isso.
...
...
N milhões de anos depois ...
- $$$<42.$

// Baseado em um lindo livro

Temos uma resposta, mas não dá nada. Todas as informações sobre ele estão contidas na pergunta, mas a pergunta não era muito específica. Não podemos provar que $$$<42$ - realmente a condição principal e não pode mostrar o contrário.

A pergunta deve limitar o escopo de possíveis respostas.

"O que é simples?" - Não é uma pergunta muito específica. Vamos esclarecer isso. No início do artigo, já fizemos parte desse caminho:

Quando dizemos que o objeto X é simples, o que esperamos dele?

De acordo com minhas observações, existem dois casos principais:

1. X é um objeto que não se divide em suas partes componentes. Aqui a palavra "simples" pode ser substituída pela palavra "elementar".
   
   Isto é um tijolo. E, de certa forma, ele é simples.
2. X é simples de executar a ação que precisamos com ele. Por exemplo, um sofá é simples, se quisermos deitar, e complicado, se precisarmos elevá-lo ao nono andar.

O caso em que o objeto é elementar é compreensível. Mas e se estivermos interessados ​​em complexidade no contexto da ação?

Vamos pensar sobre isso. Realizamos ações com o objeto.

Existem três entidades principais nesta frase:

• Ações - uma descrição do que está acontecendo.
• Executores de ações - estamos escondidos sob a palavra.
• Objetos são o que a ação ocorre.

Então, estamos interessados ​​nas seguintes perguntas:

• Como avaliar a simplicidade de uma ação, dependendo do objeto com o qual é executada?
• Qual é a relação entre a ação e seu executor?

Responderemos abaixo.

1.2 Facilidade de uso

Vamos olhar para a ação.

Simplicidade de ação é algo que depende inversamente de sua complexidade. Quanto mais complexa a ação, menos simples - é óbvia. Chegamos à seguinte pergunta:

Como determinar a complexidade da ação?

O que podemos fazer com a ação? Podemos dividi-lo em uma sequência de outros! A ação “leia o artigo” pode ser dividida em: “leia o primeiro parágrafo”, “leia o segundo”, etc. Eles, por sua vez, se decompõem como "leia a primeira frase", "leia a segunda" ...



Dessa maneira, chegamos a ações cuja diferença de complexidade não será importante para nós e não dependerá do objeto com o qual ele é executado (por exemplo, leia uma carta). Vamos chamar essas ações de elementares.

Em seguida, a complexidade da ação para um objeto específico pode ser medida nas ações elementares nas quais ele é dividido.

As ações são equivalentes quando divididas na mesma sequência de ações.

O que mais caracteriza a ação?

Algoritmo

Descrição da sequência de ações que constituem outra ação, chamarei de algoritmo ^{( ru , en )} .

O algoritmo pode ser descrito genericamente, por exemplo:
Leitura: leia frases até o texto acabar.
Nesta forma, a leitura é aplicável a muitos textos.

No entanto, como você entende, o número de ações de “leitura de sentenças” dependerá do número de sentenças no texto.

Resultado

As ações são realizadas por uma razão, elas levam a alguma coisa. Então deixe nossas ações terem resultados!

O resultado é uma alteração no estado do sistema em que a ação ocorreu. Você pressionou o botão, e sua transição para o estado “ligado” e a luz que acendeu na cozinha é o resultado dessa ação. Você lê uma palavra e o resultado é uma mudança no estado do seu cérebro.

Ações diferentes podem levar ao mesmo resultado.

Comunicação com objetos

De volta aos objetos. Como dissemos, você pode executar ações diferentes com eles. Precisamos de uma maneira de entender para quais ações essa ou aquela entidade é "pretendida".

Vou começar com um exemplo.

"E como eu arrasto esta mala?"
- Ele tem uma caneta do lado!

A alça é uma tira de couro do lado de fora da mala, pregada com rebites. Mas nós, neste caso, não nos importamos. Estamos preocupados que haja um objeto na mala em que você possa se agarrar.

Todos esses objetos chamaremos de identificadores. Eles podem estar no copo, porta, mala ou balde.



Chegamos à conclusão de que temos duas descrições de caneta do exemplo:

1. Como tiras de couro pregadas em uma mala.
2. Como um conceito para um assunto a ser abordado.

O primeiro é uma descrição da implementação ^{( en )} .

O segundo é a descrição da interface.

Uma interface é um objeto que armazena informações sobre como você pode interagir com um objeto que a implementa.

Por que eles são necessários? É simples: na maioria das vezes não estamos interessados ​​em como um objeto é implementado.
Quando queremos acender a luz, estamos procurando um interruptor, e não importa como ele funcione, é importante que possamos ativar / desativar seu estado.
Quando vemos um botão, já sabemos que ele pode ser clicado.
Quando nos dizem que em algum lugar há uma caneta - já sabemos que você pode pegá-la.
E é muito conveniente.

Sumário

Uma ação é uma sequência de outras ações que definem seu algoritmo. O resultado da ação é algum tipo de alteração do sistema.

A complexidade de uma ação é igual ao número de ações elementares de seu algoritmo para um objeto específico.

O relacionamento entre objetos e ações determina a interface do objeto. Ele armazena informações sobre quais ações podem ser executadas com o objeto.

Nossa próxima pergunta:
Qual é a relação entre a ação e seu executor?

1.3 Subjetividade objetiva

Você pode razoavelmente notar:

“Mas se você executar as mesmas ações, os resultados poderão ser diferentes! Se um professor de física puder ler rapidamente um artigo sobre teoria das cordas e entender tudo, então não alcançarei nada com a mesma abordagem. E para obter um resultado semelhante, tenho que procurar definições através da palavra, ler outros artigos e gastar muito mais ação. ”

Este é um bom ponto. Eu tenho uma resposta para isso.

Como qualquer tarefa, a nossa tem condições iniciais. Se você os alterar, altere a tarefa em si. E isso leva ao fato de que sua implementação requer ações diferentes.

Você está lendo um artigo. Suponha que você leia algumas páginas e deixe de lado. Agora, para que o artigo seja lido, você precisa gastar menos ação. Mas a complexidade do artigo em si mudou disso? Não. A ação que você executará com ela foi alterada. Foi: “leia o artigo”, tornou-se: “folhear o artigo até o momento em que terminei e ler até o final”.

O que devemos fazer com as ações? Vamos corrigir o resultado desejado. Como lembramos, pode ser alcançado de diferentes maneiras.

Além disso, podemos dividir os artistas em aproximadamente os mesmos grupos. Há um número limitado desses grupos, se não tivermos um número infinito de artistas.

Agora, para cada grupo, descrevemos as ações que o levarão ao resultado desejado.

Temos um conjunto de ações para cada um dos grupos de artistas. Mas o que fazer agora com complexidade?

1.4 Provavelmente apenas

Temos um conjunto de ações. Cada um deles pertence a um determinado grupo de artistas. Sabemos como calcular a complexidade de cada uma dessas ações para cada objeto específico.

Mas e se tentarmos definir a probabilidade do artista entrar em um dos grupos?
O problema se transforma em uma tarefa teórica clássica.

Temos a magnitude da complexidade das ações.Temos a probabilidade de executar cada uma das ações por uma pessoa aleatória.

Podemos encontrar a "média" da nossa complexidade. Essa é a chamada expectativa matemática ^{( ru )} . Para fazer isso, precisamos multiplicar cada complexidade da ação com o objeto pela probabilidade de sua ocorrência.

De onde obter essas probabilidades e como dividir os artistas em grupos, se você ainda não sabe quem executará ações especificamente com o objeto? Boa pergunta!

Sua consideração está além do escopo de nosso artigo, mas darei um exemplo interessante em minha opinião.

Você é um autor. E sua tarefa é escrever um artigo em um site que tenha seções temáticas. Quando você publica um artigo, ele aparece no feed geral e no feed de sua "seção". Seções têm assinantes, elas representam uma porcentagem da audiência do site. O feed compartilhado é mostrado para todos. Assumimos que aqueles inscritos em uma seção compreendem seu tópico, mas não os assinados - não.
Deixe nosso artigo ser sobre física. Analisamos o público e sabemos que 3% do público do site está inscrito na seção "física". Aprendemos que a probabilidade de um assinante desta seção inserir um artigo é de 80%. Também aprendemos que a probabilidade de visitar um artigo do feed geral é de 5%.

Quem é o nosso leitor em potencial e devemos "otimizar" o artigo para uma pessoa que não está inscrita na seção "física"? Em outras palavras, qual é a probabilidade de nosso artigo ser lido por uma pessoa versada em física?

Então, atenção, essa probabilidade é ... Cerca de 33%.

Um pouco mais de dois terços dos nossos leitores em potencial não entendem a física, e devemos levar isso em consideração.

Como isso aconteceu? Em resumo: uma alta probabilidade de visitar um artigo por uma pessoa versada em física é compensada por seu pequeno número. Uma pequena chance de visitar um artigo de um feed comum começa a desempenhar um papel significativo em nossa avaliação. Deseja saber mais sobre isso? Aqui está um link para um bom artigo sobre o teorema de Bayes ^{( ru , en )} .
Se você deseja verificar:


Conversamos sobre as ações e quem as executa. Hora de passar para a última pergunta.
Muitas vezes usamos a palavra objeto, mas ela não nos fornece nenhuma informação. Precisamos de alguma descrição, suficientemente abstrata para poder aplicá-la a muitas entidades e informativa o suficiente para podermos trabalhar com ela.

Como descrever os objetos com os quais trabalhamos?

1.5 Sistematização da modelagem

Decidi tentar descrever genericamente textos, tabelas, diagramas ... etc. Mas como fazer isso?

Vamos dar um passo atrás e ver como a “criação” deles acontece, talvez isso nos ajude.

Nós escrevemos o texto. Temos uma certa idéia, a formulamos em palavras e a anotamos. Além disso, a ideia pode não estar apenas na forma de outras palavras. Podemos descrever uma imagem, música, objetos matemáticos.

Estou escrevendo código. Eu tenho requisitos que eu traduzo em código. Eles podem ser expressos verbalmente ou representam uma imagem, por exemplo, um esboço da interface.
Nós fazemos um diagrama. Temos alguns objetos, os relacionamentos entre os quais descrevemos com esse esquema.

Há algo em comum nesses processos. Nós temos algum tipo de sistema. Nós o traduzimos para outro sistema, embora não necessariamente use os mesmos "termos".

Parece-me que a palavra "Modelagem" é adequada para descrever esse processo.

Portanto, um modelo é um sistema que descreve outro sistema usando a notação fornecida (termos).

Essa definição leva a uma pergunta razoável:

O que é um sistema?

Um sistema é uma coleção de alguns componentes. É definido pelo conjunto de seus possíveis estados e seu estado atual. Componentes do sistema frequentemente chamarei objetos.
Eles podem ser elementos (algo predefinido) e outros sistemas consistindo nesses elementos. Ainda existem coisas como conexões - elas aparecem quando queremos limitar ou determinar os possíveis estados de um objeto, dependendo de outros.

Um exemplo:
Existe um sistema de 2 moedas. Um deles está no estado "águia", o outro está no estado "caudas".
"Águia" e "caudas" são elementos do nosso sistema.

Uma moeda é um subsistema que consiste nos elementos "cara" e "coroa" e pode estar em um desses estados. Para a primeira moeda:



suponha que não possamos jogar moedas e, portanto, fazer alterações no sistema. Nesse caso, nosso sistema pode ser descrito como:



Se podemos jogar moedas, nosso sistema é descrito como:



Existem dependências entre alguns sistemas. Suponha que o estado da segunda moeda não possa ser igual ao estado da primeira.

Então, o conjunto de estados possíveis da moeda 2, levando em consideração nossa restrição, são todos os estados possíveis anteriores, exceto aquele em que a moeda 1 está localizada.



Nesse caso, podemos dizer que o estado da moeda 2 determina o estado da moeda 1.

Agora vamos ver o que acontece se mudarmos o conjunto de estados possíveis das moedas adicionando uma "aresta" lá.

Podemos fazer todos os pares para os estados das moedas 1 e 2.



Nesse caso, estamos falando em limitar os possíveis estados da moeda 2.

ATUALIZAÇÃO:

Eu criei uma implementação de um exemplo de moeda em Java. Aqui está o repositório . Além disso, mostra como calcular a complexidade se você fizer um sorteio para uma ação elementar.

Voltar para os modelos

Chamamos o modelo de outro sistema, que é o primeiro mapeamento. Em geral, pode ser construído a partir de outros elementos. O modelo do sistema é o mapa, o próprio sistema é o território ^{( en )} . Ninguém se preocupa em construir modelos de outros modelos. Você pode desenhar um mapa do mapa ^{( en )} .

Vamos tentar construir modelos.

Vamos começar com os clássicos: a caixa preta.
Você tem: "entrada", "saída" e caixa. Você indica os componentes que gostaria de alterar para obter o resultado como "entrada", os componentes que representam o resultado como "saída" e o restante como uma caixa preta. Esse modelo não descreve as dependências internas do sistema, mas as oculta. Não sabemos como o resultado é obtido.



Essa abordagem é frequentemente usada nos casos em que queremos estudar a operação de um sistema, mas ao mesmo tempo não podemos "abri-lo". Por exemplo, em psicologia. Testamos as pessoas, elas as resolvem. Não sabemos o que está acontecendo na cabeça das pessoas neste momento. Mas, tendo coletado dados suficientes, você pode descrever a caixa do dispositivo, que fornecerá resultados semelhantes. Na parte Machine Ex Homo, examinamos isso com mais detalhes.

Agora vamos construir um modelo que exibe todo o conjunto de componentes e seus possíveis estados.

Você mora na Grécia antiga. Seu vizinho Zeno ^{( ru )} já o pegou. Esse filho Aidov invade sua casa todas as noites com outro mistério de quebrar o cérebro ^{( ru )} , e depois disso você passa uma noite sem dormir pensando. Você precisa dormir e, para isso, precisa calá-lo pelo menos por alguns dias.

A última vez que ele recorreu a uma história sobre Aquiles correndo atrás de uma tartaruga. Durante esta noite, seus olhos caíram em um dos baldes. Um pensamento interessante me ocorreu: examinar sua aporia com mais detalhes, usando baldes e pedras.

Você deseja permitir que você descubra a posição de Aquiles e a tartaruga em relação ao ponto de partida, em cada etapa da tartaruga. Temos: uma tartaruga que anda, Aquiles, que é 10 vezes mais rápida que uma tartaruga. E suas posições iniciais: 1000 etapas e 0 etapas.

Nosso modelo ainda não sabe representar números. E é absolutamente impossível distinguir onde fica Aquiles, onde está a tartaruga, onde está o caminho.

A representação dos números naturais é simples : pegue um balde, coloque o número de pedras igual a esse número.

Agora podemos descrever a velocidade e o caminho. Em um balde que indica a velocidade de Aquiles, haverá 10 pedras. No balde para a velocidade da tartaruga - uma pedra. Agora vamos para os "baldes do caminho" . Colocamos mil pedras na tartaruga, deixamos Aquiles vazio. Quando a tartaruga dá um passo, mudamos as pedras da velocidade para o caminho. Você terminou?

Ainda não. Não temos tinta para assinar baldes. Apenas pedras. Como lidar com isso?

Como alternativa, podemos colocar a "velocidade" do balde de tartaruga à direita do seu "balde de caminho". Faça o mesmo com os baldes de Aquiles. E empurre os baldes da tartaruga. Agora sabemos que, na combinação "dois baldes" - o balde direito é de alta velocidade e o esquerdo está viajando.

Você olha para dois grupos de dois baldes. Para descobrir qual dos grupos de Aquiles você precisa subir, olhe no balde, conte as pedras nele, lembre-se de que a velocidade de Aquiles é de 10 passos e faça uma conclusão sobre a pertença dos baldes a Aquiles. E se queremos fazer algumas mudanças e igualar a velocidade de Aquiles à velocidade de uma tartaruga? Então, nossa maneira de verificar Aquiles geralmente deixa de funcionar!

Portanto, diante de baldes de velocidade e caminho, colocaremos um “balde de nome”. Agora tornou-se o mais à direita. E deixe nossa regra ter a seguinte aparência: se o balde do nome estiver vazio, os baldes que o seguem são tartarugas. E se houver uma pedra, esse grupo de baldes significa Aquiles.


Não desenhei pedras em S, mas acho claro que, no primeiro passo, o balde de Aquiles está vazio e a tartaruga contém 1000 pedras.

Você está se regozijando. Agora, Zenon terá que pensar muito sobre por que decidiu que poderia continuar para sempre o processo de divisão de pedras. Pelo menos você realmente espera que sim.
Infelizmente, isso não ajudou a melhorar seu sono. Zenão realmente não apareceu na noite seguinte, mas agora você mesmo está pensando profundamente. Chegará o momento em que as pedras não poderão ser divididas ^{( ru )} ?

Veja, para cada etapa, temos algum tipo de estado de cada um dos objetos que estamos considerando. A posição de Aquiles corresponde a um balde, as tartarugas ao outro. Para velocidades, a situação é semelhante. Nosso modelo descreve completamente todos os estados possíveis de todos os objetos do sistema simulado.

O texto também é um modelo do sistema. Os termos neste caso são palavras. Eles são definidos pelo seu significado, ou pela multiplicidade de significados, que é limitada dependendo do contexto.
Nossas sensações também são um modelo que nosso cérebro cria com base em informações vindas de fora.

Em resumo, você encontra modelos o tempo todo.

Você ainda se lembra por que todos nós fizemos isso? Apenas no caso: demos uma definição para o modelo e depois calculamos sua complexidade. Chegou a hora, vamos ver como isso pode ser aplicado.

Você é um designer de UX. Sua tarefa: fazer a página de configurações do aplicativo. Você sabe que eles não mudarão no futuro. Existem dez no total: cinco configurações gráficas e cinco de notificação.

Você pode deixá-los todos em uma tela. Você também teve a ideia de criar itens de "agendamento" e "notificações" na primeira tela e alternar para a tela correspondente com cinco configurações.



Vamos supor que nosso usuário tenha pouca memória e o hábito de ler de cima para baixo. Mas, ao mesmo tempo, ele é inteligente o suficiente para não cometer erros na seção, no caso em que agrupamos as opções. Ele não lê os nomes das telas e vai diretamente para os itens do menu.

Temos apenas 10 configurações, elas podem ser exibidas na tela com uma lista e o usuário simplesmente cutuca o item desejado. Acreditamos que o usuário não precise rolar a planilha nesse caso. Por outro lado, se o usuário precisar de configurações a partir do final, será mais fácil encontrá-las, porque ele não precisará ler a lista inteira; poderá pular metade dos pontos que não precisa.

Qual modelo nos dará uma interação mais simples?

Ações que um usuário pode executar com um item da lista: leia e cutucá-lo. Traduzido para o idioma da interface: o item de menu possui as propriedades de legibilidade e capacidade de PokéBoo. Como todos os pontos são curtos, a diferença na dificuldade de lê-los é negligenciada. Assumimos que as ações de “puxão” e “leitura” são elementares em nosso contexto. Sua complexidade é 1.

Esperamos que o usuário tenha a mesma probabilidade de exigir qualquer um dos itens. Não faz sentido aceitar qualquer um deles.

Claro, você já tem algum tipo de palpite sobre a resposta. Eu sugiro que você escreva, assim como escreva sua confiança de que sua resposta está correta. Por exemplo, em uma escala de 1 a 10, em que 10 tem certeza absoluta, 1 não tem certeza. Você precisará desses dados para compará-los com o resultado. Sob o spoiler "Decisão", haverá uma pesquisa. Infelizmente, o habr não permite fazer pesquisas em nenhum lugar do texto; portanto, o link leva aos formulários do Google. Lá você pode passar por isso e ver estatísticas sobre os resultados gerais.

Aconselho que você pegue uma caneta, um pedaço de papel, abra a calculadora e calcule a dificuldade você mesmo. E só então abra o spoiler.


Inseri este exemplo no artigo na fase final de edição. Era importante para mim resumir do que estávamos falando. Vincule as informações dos capítulos anteriores de maneira compreensível. Para que você possa imaginá-lo facilmente e tentar usar o que falamos.

Eu estava enganado. Quando escrevi este exemplo, pensei que sabia qual seria a resposta. E agora estou muito surpreso. Não, isso não é verdade. Quando honestamente realizei todos os cálculos, o resultado me atingiu com muita força. Na minha cabeça, aconteceu algo como o seguinte:

- * Em uníssono * ESTAMOS ERRADOS ?!


...
...
...

Peço desculpas por uma digressão e exemplo tão volumosos. Talvez você não esteja pronto para ler mais e queira pensar novamente. E é uma boa escolha.

No início, há um índice, você pode marcar o artigo como favorito e retornar rapidamente a este local.

Você decidiu continuar? Então, temos o último tópico daqueles que eu queria levantar.

1.6 Blade Runner

Provavelmente você conhece a Navalha de Occam, mas, por precaução, lembrarei:
"Novas entidades não devem ser atraídas, a menos que seja absolutamente necessário."

Em geral, esse princípio é interpretado da seguinte forma: de todas as hipóteses, a mais provável é a descrita pelo subprograma mais curto (ou, mais simplesmente, a mais curta) ^{( ru , en1 , en2 )} .

Como é a vida real:
Se você acendeu a luz e a luz acendeu, as hipóteses podem ser as seguintes:

1. O interruptor fechou um circuito elétrico e a corrente passou através de uma lâmpada.
2. O interruptor chutou o pequeno gnomo, que ligava os fios, como resultado do qual o circuito se fechou e a corrente passou pela lâmpada.
3. O interruptor chutou o pequeno gnomo, que empurrava o carrinho em que o pequeno dragão estava sentado, assustado com uma chama, que derreteu a solda, que ligava os fios, como resultado do circuito fechado e a corrente atravessar a lâmpada.

Dessas hipóteses, é preferível uma que contenha menos entidades sem um gnomo. Se, ao ligar a lâmpada, você ouviu um palavrão silencioso no comutador, a segunda hipótese é preferível, porque o primeiro não explica por que o comutador xinga e o segundo contém entidades redundantes.

Eu serei honesto. Quando ouvi falar da Navalha de Occam pela primeira vez, não pensei em hipóteses. E sua formulação vaga na forma verbal me levou à idéia de que esse é um princípio geral - reduza o número de entidades que estão no seu sistema e tudo ficará legal.

Eu estava muito enganado .

Mas quando eu tinha uma descrição da simplicidade do sistema, percebi como corrigir minha interpretação incorreta desse princípio. E faça algo útil com isso.

Temos um sistema antes e depois de algumas mudanças.

Se a diferença na complexidade Antes e Depois for maior que a complexidade do processo de fazer a alteração, essa alteração será justificada. Entende-se que a mudança não afetou o resultado (pelo menos a parte que precisamos). Vamos chamá-lo ... Uma condição necessária para simplificação.

Mais uma vez: A

simplificação esperada do sistema após a mudança deve ser maior que a complexidade da própria mudança.

Se denotarmos a complexidade da mudança para$$C e , complexidade do sistema até$C_$$$C e depois como$C$$$$C’$ então temos:

$$$C’ - C > C_$ .
Também podemos expressar algum análogo de eficiência para nossa mudança.
$$$k = (C’-C)/C_$ .
Se $$k maior que um é uma alteração boa e kosher correspondente à condição de simplificação necessária. Se$k$
$$k é menor que 1, mas maior que 0 - isso significa que você simplifica o sistema, mas gasta mais esforço nele do que obtém lucro. Se$k$
$$k é menor que 0, então isso indica que não vale a pena fazer essa alteração. Você complica. Por que é necessário? Bem, por exemplo, você age em condições em que possui tempo limitado e gostaria de priorizar as alterações que deseja fazer. Muda com grande$k$

$$k deve ser considerado primeiro.$k$

Um exemplo:

Temos dois textos, um com um exemplo do outro sem.

Por um lado, aumentamos o volume do texto, complicando-o. Mas, por outro lado, graças a isso, alguns leitores não colocam no Google um "exemplo de navalha Occam", que é uma ação mais complicada do que apenas ler. Se, em nossa opinião, houver muitos desses leitores, a introdução de um exemplo simplificará nosso artigo.

Não devemos esquecer que também realizamos algumas ações para descrevê-lo, e eles tinham sua própria complexidade. Se gastássemos muitas ações e a simplificação não bastasse - a introdução de nossa essência “não compensa”.

Hmm, como tudo isso está relacionado à Navalha de Occam?

Vamos assumir que já temos vários sistemas. E sua complexidade depende diretamente do número de entidades (no mundo real isso nem sempre é verdade, como já descobrimos). Os resultados das ações com esses sistemas nos convêm.

Como o sistema já existe, então$$C e → 0 (você não precisa fazer nada para fazer alterações no sistema). Vamos pegar um sistema com um número mínimo de entidades e calcular$C_ \rightarrow 0$$$k em relação a outros sistemas. Nós entendemos isso$k$$$k será igual a menos infinito. Do ponto de vista da simplicidade, em tais condições, escolher um sistema diferente daquele que contém o menor número de objetos é uma solução infinitamente estúpida. Isso nos diz que, de todos os sistemas, devemos escolher o que contém o menor número de objetos.$k$ Hum.Suspeita semelhante à Navalha de Occam.

O que mais pode ser descrito usando essa condição?
Por exemplo, você pode avaliar quando vale a pena aplicar várias práticas de aprimoramento de código e quando é inútil.

De fato, se você escrever uma tarefa em uma universidade, cujo código será lido uma vez (ou não será lido, mas apenas veja como funciona), não se preocupe com a boa leitura.

Mas se você estiver escrevendo para um projeto OpenSource e centenas de pessoas trabalharem com seu código, ou escrever seu projeto que planeja desenvolver, você deverá cuidar da qualidade.

Se você estiver escrevendo um compêndio, avalie se precisará dele no futuro. Se o professor apenas verificar sua disponibilidade e todas as informações forem mais fáceis de encontrar no Google, por que complicá-las?

Se você estiver escrevendo um artigo, determine como vê a interação com ele. Por exemplo, este artigo não pretende ser lido apenas uma vez. Tentei otimizá-lo para uma pesquisa rápida. É por isso que, em cada parte, há um spoiler “Breve” e um sumário no início.

Ah, se tivéssemos uma maneira de descrever de alguma maneira como uma pessoa lerá nosso modelo e descobriremos a complexidade desse modelo para leitura. Poderíamos dizer com certeza como nossas ações afetarão a complexidade desse processo e aplicar nossa teoria em um grande número de problemas práticos.

Infelizmente, para isso, você precisa criar um algoritmo geral para ler pessoas de qualquer modelo. Se lhe pareceu que esta é uma tarefa muito difícil - você está certo.

Felizmente, eu já fiz parte deste trabalho.

No próximo capítulo, que será chamado Machine Ex Homo, veremos como nosso cérebro trabalha com informações. Falaremos sobre compreensão e como as informações que já conhecemos afetam a percepção do novo. Vejamos os estudos de psicólogos e neurobiólogos no campo do estudo da memória humana e criamos com base em nosso próprio modelo de memória. Com sua ajuda, explicaremos alguns efeitos psicológicos interessantes, como o efeito da frequência da palavra, o efeito da borda, ilusões de ótica. E haverá muito mais fotos.

Em suma - será interessante, eu prometo.


Licença:
CC BY-NC-SA 4.0