Costuma-se ouvir que um determinado projeto de sistema é muito elogiado na sua fase inicial, mas depois começa a apresentar problemas na fase final. Essa fenômeno tem uma causa fundamental: muitas vezes, só nos preocupamos se o sistema consegue rodar na fase inicial, e ignoramos algo mais importante — se o sistema consegue se manter estável a longo prazo.
O projeto APRO justamente pode ser reavaliado sob essa perspectiva.
**A armadilha da complexidade**
Qualquer sistema real, uma vez utilizado em larga escala, enfrentará um problema inevitável: demandas que aumentam continuamente, bugs que precisam ser corrigidos, várias situações de limite que surgem sem parar. Essas mudanças em si não são ruins; o problema é se o sistema consegue suportar a soma dessas mudanças.
Se, toda vez que surge um problema novo, só conseguimos resolver com regras cada vez mais complexas, o sistema ficará cada vez mais inchado, e o custo de manutenção subirá exponencialmente, aí está o desastre. A arquitetura do APRO parece ter considerado esse ponto, mas na prática, ainda é preciso ver se realmente consegue controlar a explosão de complexidade.
**O teste da consistência**
No processo de evolução das versões do sistema, regras antigas, novos parâmetros e comportamentos históricos frequentemente coexistem. Para que o sistema funcione bem a longo prazo, é necessário garantir que toda a evolução seja logicamente consistente, e não que a cada atualização se crie uma nova armadilha.
Para projetos como o APRO, que valorizam bastante a restrição estrutural, esse problema é especialmente sério. Porque, se as regras forem quebradas com frequência, o custo de confiança dos usuários dispara, e isso é muito difícil de reverter.
**A rotina do tratamento de exceções**
Outro ponto que costuma passar despercebido: projetos de sistema não são "eventualmente erros", mas sim situações de exceção que acontecem diariamente. Como lidar elegantemente com essas exceções diárias, sem fazer o sistema perder sua lógica geral, é o que realmente demonstra se um projeto é realmente maduro.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
8 gostos
Recompensa
8
5
Republicar
Partilhar
Comentar
0/400
BoredRiceBall
· 12-24 19:51
Mais uma vez essa história de "ver o design da arquitetura", para ser honesto, o APRO me parece suspeito, o conjunto de regras vai acabar dando problema eventualmente.
Ver originalResponder0
MidnightMEVeater
· 12-24 19:50
Bom dia, ainda às três da manhã a ver esse tipo de coisa. Resumindo, sistemas baseados em regras acabam por morrer, não dá para saber quanto tempo o APRO vai aguentar.
---
Quando há muitas regras, começa a falhar, já vi esse esquema muitas vezes. O mais importante é que, uma vez que a confiança dos usuários se quebre, ela não se consegue consertar.
---
Tratamento de exceções se tornando rotina? Bem, isso é o cotidiano das negociações em dark pools, quem não está todos os dias corrigindo vulnerabilidades.
---
Explosão de complexidade, essa é a questão de ver se o APRO consegue sobreviver ou acaba simplesmente desmoronando.
---
Quando os custos de manutenção sobem drasticamente, é o momento em que o projeto começa a devorar seus próprios recursos.
---
Portanto, a última questão do APRO ainda é se consegue manter a consistência lógica, isso é muito mais difícil do que o código.
Ver originalResponder0
CryptoMotivator
· 12-24 19:50
Resumindo, é se consegue segurar a longo prazo, por mais que se exagere na fase inicial, no final não adianta nada.
Ver originalResponder0
FomoAnxiety
· 12-24 19:49
Começar cedo realmente não vale a pena, o que importa é quanto tempo consegue sustentar. Se a APRO realmente quer viver por mais tempo, vai depender de como vai fazer a manutenção posteriormente.
A estratégia de pilha de regras simplesmente não funciona, cedo ou tarde vai acabar se destruindo.
A questão da consistência é realmente um grande problema, uma vez que a confiança é quebrada, ela nunca mais volta.
Ver originalResponder0
GasGoblin
· 12-24 19:41
Para ser honesto, atualmente há muitos projetos que são apenas hype inicial e colapsam posteriormente. A análise do APRO ainda é bastante clara. O mais importante é ver se consegue resistir ao teste do uso real, não apenas falar bonito.
Costuma-se ouvir que um determinado projeto de sistema é muito elogiado na sua fase inicial, mas depois começa a apresentar problemas na fase final. Essa fenômeno tem uma causa fundamental: muitas vezes, só nos preocupamos se o sistema consegue rodar na fase inicial, e ignoramos algo mais importante — se o sistema consegue se manter estável a longo prazo.
O projeto APRO justamente pode ser reavaliado sob essa perspectiva.
**A armadilha da complexidade**
Qualquer sistema real, uma vez utilizado em larga escala, enfrentará um problema inevitável: demandas que aumentam continuamente, bugs que precisam ser corrigidos, várias situações de limite que surgem sem parar. Essas mudanças em si não são ruins; o problema é se o sistema consegue suportar a soma dessas mudanças.
Se, toda vez que surge um problema novo, só conseguimos resolver com regras cada vez mais complexas, o sistema ficará cada vez mais inchado, e o custo de manutenção subirá exponencialmente, aí está o desastre. A arquitetura do APRO parece ter considerado esse ponto, mas na prática, ainda é preciso ver se realmente consegue controlar a explosão de complexidade.
**O teste da consistência**
No processo de evolução das versões do sistema, regras antigas, novos parâmetros e comportamentos históricos frequentemente coexistem. Para que o sistema funcione bem a longo prazo, é necessário garantir que toda a evolução seja logicamente consistente, e não que a cada atualização se crie uma nova armadilha.
Para projetos como o APRO, que valorizam bastante a restrição estrutural, esse problema é especialmente sério. Porque, se as regras forem quebradas com frequência, o custo de confiança dos usuários dispara, e isso é muito difícil de reverter.
**A rotina do tratamento de exceções**
Outro ponto que costuma passar despercebido: projetos de sistema não são "eventualmente erros", mas sim situações de exceção que acontecem diariamente. Como lidar elegantemente com essas exceções diárias, sem fazer o sistema perder sua lógica geral, é o que realmente demonstra se um projeto é realmente maduro.