Ideias de sistemas quase não funcionais

Ideias de sistema quase não funcionais

• "Vamos apenas torná-lo plugável"

  • A ideia é permitir que, quando uma implementação falhar, os desenvolvedores possam adicionar uma nova implementação com facilidade. Mas, na maioria dos casos, a funcionalidade que a API oferece não funciona com a facilidade esperada. Para que haja uma verdadeira capacidade de plugin, a segunda implementação precisa ser projetada desde o início.

• "Vamos apenas adicionar uma API"

  • Muitas vezes adiciona-se APIs para construir uma plataforma e atrair desenvolvedores. Porém, oferecer APIs exige esforço contínuo em compatibilidade e interoperabilidade, e disponibilizar uma API não significa necessariamente atrair usuários. Construir uma plataforma é um negócio sério, e não é fácil oferecer uma base econômica apenas com APIs.

• "Vamos fazer uma abstração a mais"

  • Há uma máxima de que um problema de ciência da computação pode ser resolvido com mais um nível de indireção. Porém, abstrair cedo demais pode gerar dificuldades de manutenção, segurança e otimização de desempenho. Abstrações adicionadas sem planejamento tornam a manutenção do código mais difícil.

• "Vamos tornar assíncrono"

  • A programação assíncrona já foi um tema de pesquisa antiga em ciência da computação. Frameworks web encapsulam isso bem, mas fora de um framework, ao tentar gerenciar a assíncronia diretamente, aumenta a chance de surgir um bug imprevisível.

• "Vamos adicionar controle de acesso depois"

  • A segurança do sistema deve ser considerada desde o início, mas costuma ser adicionada depois por causa da velocidade de lançamento no mercado. Se o controle de acesso não for considerado desde o começo sob a perspectiva de clientes e adversários, há maior chance de o produto precisar ser redesenhado depois.

• "Vamos sincronizar os dados"

  • A sincronização de dados é um problema extremamente difícil, com muitos desafios que só são resolvidos com experiência. Construir uma solução baseada em sincronização de dados quase nunca é desejável.

• "Vamos torná-lo multiplataforma"

  • Desenvolvimento multiplataforma é semelhante a construir sistemas operacionais, provedores de nuvem ou navegadores. Isso pode funcionar quando a plataforma é nova ou o aplicativo é simples, mas fica cada vez mais difícil com o tempo.

• "Vamos permitir escapar para o nativo"

  • Quando a multiplataforma é limitada, é comum permitir escapar para funcionalidades nativas. No entanto, isso pode conflitar com o estado mantido pelo framework e falha em 9 em cada 10 casos.

• Conclusão

  • Essas abordagens não falham em todos os casos, mas na maioria das vezes há um caminho melhor. É importante resolver os problemas com princípios básicos e evitar padrões de software com alta probabilidade de falha.

[ndrgrd]

No caso de plugins, o mais importante é projetar a interface filtrando ao máximo apenas os comportamentos essenciais.
Se a interface for criada apenas copiando uma estrutura aproximada do código atual, ela acaba virando uma interface desnecessária que fica presa àquela implementação, e é realmente comum que isso aconteça...

[GN⁺]

Opinião do Hacker News

• DSLs e APIs costumam funcionar com sucesso. Um motor de inferência como o TensorFlow também pode ser visto como uma DSL ou como uma API encapsulando uma DSL.

  • SQL, linguagens Shader e BPF também podem ser considerados exemplos semelhantes.
  • A abordagem de “só adicionar uma API” pode não dar certo. Assim como em UI, é preciso um tratamento cuidadoso e minucioso.

• DSLs às vezes funcionam muito bem. Vale consultar o jOOQ.org.

• O Elastic Load Balancer é um loop de controle que reage à carga de trabalho. Isso é, de certa forma, um produto.

• A falta de recursos é generalizada na maioria das indústrias. Dá para ver em erikbern.com e em “Goal: Process of Ongoing Improvement”.

• A detecção de anomalias não é um problema de sistemas distribuídos, mas quem teve problema com isso pode achar que é necessária.

  • O algoritmo Isolation Forest é às vezes milagroso. Em 2018, obtive bons resultados usando embeddings baseados em CNN para texto.

• A palavra “quase” é ineficaz neste contexto. É simplesmente pessimismo cínico.

• Muita gente tenta encontrar uma função de decisão mais refinada para exceções, mas na prática é simples: funciona quando eu faço, não funciona quando o anterior fez.

• “Domain Driven Design” é uma receita de desastre para desenhar aplicação de acordo com a estrutura do negócio.

  • Pode não dar problema em negócios pequenos, mas em um negócio de sucesso ou em crescimento, se arrependerá rapidamente.
  • Em vez disso, desenhe por camadas de recursos, e mantenha a lógica de negócio o mais próximo possível de linhas do banco de dados e fluxos de usuário.

• O loop de controle de resposta à carga é um componente básico e essencial. É usado em muitos sistemas.

• Trabalhei em projetos com várias DSLs, cache P2P e paralelismo híbrido, e a maioria deles funcionou bem.

  • O cache P2P não deu grandes resultados por não ser necessário.
  • É complexo, mas essa complexidade entrega recursos difíceis de alcançar por outro meio.

• A abordagem de “apenas sincronizar dados” pode dar dor de cabeça.

  • Muitos sistemas são desenhados para uma “escala da internet”, mas, na prática, são abaixo disso.
  • Essas equipes podem ser ingênuas ou, no pior caso, utilizam gerentes não técnicos para gastar dinheiro para consertar as coisas.

• Consegui executar com sucesso várias dessas ideias com sucesso. Então fica um pouco estranho