Aqui está uma citação de Linus Torvalds para 2006 :

Sou um grande defensor do desenvolvimento de código em torno de dados, e não vice-versa, e acho que essa é uma das razões pelas quais o git foi bem-sucedido ... Na verdade, eu argumento que a diferença entre um programador ruim e um bom é se ele pensa mais. importante seu código ou suas estruturas de dados. Programadores ruins se preocupam com o código. Bons programadores se preocupam com estruturas de dados e seus relacionamentos.

O que é muito semelhante à "regra de envio" de Eric Raymond de 2003 :

Transforme conhecimento em dados para que a lógica do programa se torne estúpida e confiável.

Aqui está apenas um resumo de idéias como o pensamento de Rob Pike em 1989 :

Os dados dominam. Se você escolher as estruturas de dados corretas e organizar tudo bem, os algoritmos quase sempre serão evidentes. Estruturas de dados, não algoritmos, desempenham um papel central na programação.

Ele cita Fred Brooks de 1975 :

A apresentação é a essência da programação

Por trás do domínio está a engenhosidade que faz
programas econômicos e rápidos. Este é quase sempre o resultado.
avanço estratégico, habilidade não tática. Às vezes, tão estratégico
uma inovação é um algoritmo, como uma transformação rápida de Fourier,
proposto por Cooley e Tukey, ou substituindo as comparações n ² por n log n ao classificar.

Mais frequentemente, uma inovação estratégica ocorre como resultado da apresentação
dados ou tabelas. O núcleo do programa está aqui. Mostre-me os fluxogramas sem mostrar as tabelas, e eu continuarei extraviado. Me mostre o seu
tabelas e fluxogramas provavelmente não são necessários: serão óbvios.

Então, por quase meio século, as pessoas inteligentes disseram repetidamente: concentre-se nos dados primeiro. Mas, às vezes, parece que esse é o conselho mais inteligente que todos esquecem.

Vou dar alguns exemplos reais.

Sistema altamente escalável que falhou

Este sistema foi criado originalmente com a expectativa de incrível escalabilidade com uma grande carga na CPU. Nada síncrono. Em todos os lugares, retornos de chamada, filas e pools de trabalho.

Mas havia dois problemas. A primeira foi que a "carga do processador" não era tão intensa - uma tarefa levou no máximo alguns milissegundos. Portanto, a maior parte da arquitetura fez mais mal do que bem. O segundo problema era que o "sistema distribuído altamente escalável" na verdade só funcionava em uma máquina. Porque Porque toda a comunicação entre componentes assíncronos foi realizada usando arquivos no sistema de arquivos local, que agora se tornou um gargalo para qualquer dimensionamento. O design original não estava vinculado aos dados, com exceção da proteção de arquivos locais em nome da "simplicidade". A parte principal do projeto foi dedicada a toda essa arquitetura adicional, que era "obviamente" necessária para lidar com a "carga pesada" na CPU.

Arquitetura orientada a serviços que ainda orienta dados

Esse sistema seguiu o design de microsserviços a partir de aplicativos de uso único com APIs REST. Um dos componentes era um banco de dados no qual os documentos são armazenados (principalmente respostas a formulários padrão e outros documentos eletrônicos). Naturalmente, ela definiu a API para salvar e recuperar dados, mas rapidamente houve a necessidade de funcionalidades de pesquisa mais complexas. Os desenvolvedores consideraram que adicionar essa função a um documento existente da API contradiz os princípios do design do microsserviço. Como 'search' é essencialmente diferente de 'get / put', a arquitetura não deve combiná-los. Além disso, eles planejavam usar uma ferramenta de terceiros para trabalhar com o índice; portanto, a criação de uma nova 'pesquisa' de serviço também fazia sentido por esse motivo.

Como resultado, foram criadas uma API de pesquisa e um índice de pesquisa, que basicamente se tornaram uma duplicata dos dados no banco de dados principal. Esses dados foram atualizados dinamicamente, portanto, qualquer componente que alterou os dados do documento por meio da API principal do banco de dados também deve enviar uma solicitação para atualizar o índice por meio da API de pesquisa. Usando a API REST, isso não pode ser feito sem uma condição de corrida; portanto, os dois conjuntos de dados ocasionalmente ficam fora de sincronia.

Apesar do prometido pela arquitetura, as duas APIs estavam intimamente relacionadas por meio de suas dependências de dados. Mais tarde, os desenvolvedores reconheceram que o índice de pesquisa deveria ser combinado com um serviço de documentos comum, e isso tornava o sistema muito mais sustentável. Fazer um funciona no nível dos dados, mas não no nível do verbo.

Pedaço de lama fantasticamente modular e configurável

Esse sistema era uma espécie de pipeline de implantação automatizada. A equipe de desenvolvimento original queria tornar uma ferramenta flexível o suficiente para resolver problemas de implantação em toda a empresa. Eles escreveram um conjunto de componentes de plug-in com um sistema de arquivos de configuração que não apenas configurou os componentes, mas também atuou como uma linguagem específica de domínio (DSL) para programar como os componentes se encaixam no pipeline.

Avanço rápido de alguns anos e a ferramenta se transformou em "o próprio programa". Havia uma longa lista de erros conhecidos que ninguém jamais havia corrigido. Ninguém queria tocar no código por medo de quebrar alguma coisa. Ninguém usou a flexibilidade do DSL. Todos os usuários copiaram e colaram a mesma configuração de trabalho garantida que todos os outros.

O que deu errado? Embora o documento original do projeto usasse frequentemente palavras como "modular", "desconectado", "expansível" e "personalizado", ele não disse nada sobre os dados. Assim, as dependências de dados entre os componentes foram processadas de maneira não regulamentada usando um blob JSON globalmente comum. Com o tempo, os componentes fizeram suposições cada vez mais não documentadas sobre o que está incluído ou não no blob JSON. Obviamente, o DSL permitiu que os componentes fossem reorganizados em qualquer ordem, mas a maioria das configurações não funcionou.

As lições

Eu escolhi esses três projetos, porque é fácil explicar a tese geral usando o exemplo deles, sem tocar nos outros. Uma vez tentei criar um site e, em vez disso, parei com algum tipo de banco de dados XML servil que nem sequer resolveu meus problemas de dados. Havia outro projeto que se transformou em uma aparência quebrada de metade da funcionalidade do make , novamente porque eu não achava o que realmente precisava. Eu já escrevi sobre o tempo gasto criando uma hierarquia interminável de classes OOP que deveria ter sido codificada nos dados .

Atualização:

Aparentemente, muitos ainda pensam que estou tentando tirar sarro de alguém. Meus verdadeiros colegas sabem que estou muito mais interessado em solucionar problemas reais e não culpar os que os geraram, mas, tudo bem, é isso que penso sobre os desenvolvedores envolvidos nesses projetos.

Honestamente, a primeira situação ocorreu claramente porque o arquiteto do sistema estava mais interessado em aplicar trabalhos científicos do que em resolver um problema real. Muitos de nós podem ser culpados por isso (eu também), mas isso realmente irrita nossos colegas. Afinal, eles terão que ajudar no suporte quando nos cansarmos de um brinquedo. Se você se reconhecer, não se ofenda, pare (embora eu prefira trabalhar com um sistema distribuído em um nó do que com qualquer sistema no meu "banco de dados XML").

No segundo exemplo, não há nada pessoal. Às vezes, parece que todos dizem que é maravilhoso compartilhar serviços, mas ninguém fala sobre quando é melhor não fazer isso. As pessoas aprendem o tempo todo com sua própria experiência amarga.

A terceira história realmente aconteceu com algumas das pessoas mais inteligentes com quem já trabalhei.

(Fim da atualização).

A pergunta "O que é dito sobre os problemas criados pelos dados?" É um teste decisivo bastante útil para um bom design do sistema. Também é muito conveniente para identificar "especialistas" falsos com seus conselhos. Problemas com a arquitetura de sistemas complexos e complicados são problemas de dados; portanto, especialistas falsos gostam de ignorá-los. Eles mostrarão uma arquitetura surpreendentemente bonita, mas não dirão nada sobre quais dados são adequados e (importante) para quais dados não são adequados.

Por exemplo, um especialista falso pode dizer que você deve usar o sistema pub / subs porque os sistemas pub / subs são fracamente acoplados e os componentes fracamente acoplados são mais sustentáveis. Parece bonito e fornece belos diagramas, mas é o inverso do pensamento. Pub / sub não torna seus componentes fracamente acoplados; O pub / sub em si é fracamente acoplado, o que pode ou não atender às suas necessidades de dados.

Por outro lado, uma arquitetura orientada a dados bem projetada é de grande importância. Programação funcional, malha de serviço, RPC, padrões de design, loops de eventos, qualquer que seja, todos têm seus próprios méritos. Mas, pessoalmente, vi que sistemas de produção muito mais bem-sucedidos funcionam em DBMSs antigos e chatos .