Meu trabalho ultimamente parece um mês sólido de “quase lá”. Estamos constantemente em um estado em que o sistema quase funciona, exceto por alguns bugs irritantes e um grande problema conhecido.
Resolver um sempre fazia com que o próximo problema aparecesse em poucas horas, e cada problema parecia mais fatal do que o anterior. Os últimos três dias, em particular, foram particularmente difíceis.
Tudo começou correndo contra o limite de tamanho para objetos beanstalk, em míseros 64kb. Estávamos tentando, por razões perfeitamente válidas, armazenar cerca de 30 MB de dados em um objeto (como uma tarefa em uma fila) e, claro, estava sufocando. Portanto, resolvemos isso adicionando o Redis à pilha de tecnologias que estamos usando. Portanto, agora o Beanstalk mantém a tarefa com um ponteiro para um objeto Redis
que contém a maior parte dos dados. Isso resolveu o problema do pé de feijão.
E então descobrimos que o sistema estava tentando processar tudo várias vezes por causa de timeouts de dados (carregar 25k registros do Mongo leva um pouco de tempo, curiosamente). O raciocínio amplo é que não estávamos bloqueando as programações conforme as encontramos, portanto, elas estavam sendo processadas várias vezes. Mais uma vez, o Redis veio em nosso socorro – devido à estrutura da tarefa (uma árvore de processos (nós) com dependências (arestas)) pudemos simplesmente rastrear onde cada processo estava (pendente, em execução, falhou ou concluído). Então isso resolveu o problema.
Tendo mudado isso, pensamos que estávamos em casa e secos. Não. A primeira questão nos deu um soco no rosto novamente com Mongo. Isso também tem um limite de tamanho de objeto, de 16 MB (para coleções não GridFS). Felizmente, resolver isso foi simplesmente dividir os dados em registros individuais (os dados eram congruentes com este formato).
Não tenho certeza de quanto disso faz sentido – o contexto é uma coisa engraçada – mas a essência disso é que a sensação constante de “quase lá” tem sido particularmente poderosa ultimamente. O que nos leva ao título deste post …
- 80% de X é consumido por 20% de Y *
- 80% do esforço é gasto em 20% de um projeto *
- 80% do SLOC em 20% do cronograma *
Esta é uma lei bastante universal, surgindo em quase tudo até certo ponto. É especialmente comum, ao que parece, no desenvolvimento de software. A maioria dos bits de software pode ser descrita como “um pouco de molho secreto com um monte de costuras para fazer funcionar”. E assim, 20% do código exige 80% do esforço. Ou 80% do valor é derivado de 20% do código. Ou, indo além, 80% do lucro de uma empresa é produzido por 20% de seus funcionários.
Então, como reconciliamos agendamento, planejamento e felicidade com o inerente “quase lá” que vem com o princípio de Pareto?
Outra vez, para aquele – de acordo com o tema deste post, vou deixá-lo 80% longo com 20% não dito.