Projeto “k”: Análise de complexidade

A medida que o desenvolvimento do “Projeto k” avança — aos trancos, devido a meus outros compromissos — se torna muito claro o quanto ainda estou longe de uma release alpha. Isso não é surpresa pra mim ou mesmo me desanima: quando iniciei o projeto eu tinha uma boa idéia da complexidade envolvida.

Ainda assim acho interessante compartilhar a complexidade de cada parte que o projeto envolve, já que esse nível de detalhamento eu ainda não possuia quando comecei a trabalhar. Segue, em ordem do mais simples ao mais complexo, os items envolvidos no desenvolvimento do “k”:

1. Infra: Sempre tive um conhecimento de intermediário para avançado da Infra envolvida: Servidor web (Apache) e RDBMS (PostgreSQL). Alie-se isso ao fato de que hoje em dia instalar e configurar essas coisas é trivial e é fácil entender porque a infra é, de longe, a parte mais fácil do projeto.
   Isso não significa, entretanto, que a infra é simplória: existem algumas configurações específicas (em particular com o Apache) que demandam um pouco de pesquisa e testes.
2. Modelagem da Base de Dados: Com a exceção de casos muito específicos, meu conhecimento de Modelagem sempre foi excelente (não é à toa que geralmente tenho uma ótima avaliação quando ministro este conteúdo em cursos). Considero — não sem um pouco de otimismo — que a modelagem da base em cima da qual o “k” vai rodar esteja uns 95% concluída. Esses 5% restantes não estão verdadeiramente faltando, apenas figuram como uma espécie de “gordura” para o caso de eu não ter previsto alguma coisa.
   Ainda assim, devido ao fato de que outros pontos são de uma complexidade considerável, como vocês verão a seguir, ainda não estou utilizando verdadeiramente a base de dados (este ponto começará, lentamente, a ser implementado em breve).
3. Logs: Algo que — desonfio — o mercado criminosamente ignora. Confesso que me surpreendi um pouco com a complexidade de logs que serão usados no “k”, mas devia ter imaginado. Em virtude da complexidade do projeto, mesmo utilizando um exclente componente pra isso (Monolog, é claro), os níveis e estruturas envolvidas nos logs de execução, erros, etc… são bem complexos. Isso está aproximadamente 85% definido (já existem correções a fazer) e uns 10% implementado de fato. A boa notícia é que justamnte devido ao Monolog a implementação disso não será muito trabalhosa.
4. Fluxo lógico: Mais um ponto que o mercado ignora. Esse eu não desconfio, eu sei. Acho absurdo um projeto a partir de uma certa complexidade não possuir um desenho de fluxo (leia-se fluxograma). O “k” possui um fluxograma e sub-fluxogramas. Decidi por trabalhar dessa forma para que seja possível detalhar partes do fluxo sem criar um diagrama monstruoso. Uso o Dia para isso, um software excelente e mais do que competente para esse tipo de coisa.
5. Programação Server-Side (PHP, dã!): Como o “k” trata de algo que não é comum no mercado (uma das razões pelas quais tem sido tão interessante trabalhar nele), às vezes faltam artigos e tutoriais a respeito. Pontos (como sempre) para a documentação oficial e para os comentários que se encontram por lá. Às vezes, como já aconteceu durante o desenvolvimento do “k”, o código mostrado no comentário é de qualidade duvidosa, mas de um valor imprescindível em termos de “pistas” de como chegar onde eu quero. É muito complicado dar muito mais explicação nesse ponto sem entregar muito sobre o projeto, então por enquanto paro por aqui.
6. Programação Client-Side: Absolutamente a parte que será mais complexa para mim. Tenho um conhecimento considerável de HTML, CSS e JavaScript, mas confesso que parei no tempo e esse mercado anda caótico demais para acompanhar de fato. Some-se a isso o fato de que tenho idéias bem interessantes para a interface do “k” e certamente precisarei de ajuda quando chegar nos detalhes mais complexos dessa parte. Por conta de tudo isso, o desenvolvimento Client-Side é de longe a parte menos trabalhada no projeto.
   Ainda assim não significa que eu não tenha feito nada de interessante. Na realidade fiz um componente JS bem bacana para uma das principais partes da interface (não se animem demais, não é nada inovador, na verdade há dezenas (centenas?) de componentes idênticos ou até mesmo muito melhores por aí).

Aas decisões mais bacanas que tomei como imutáveis ao iniciar o projeto foram:

• Mesmo em um eventual (e cada vez mais improvável) fracasso, o “k” será divulgado de qualquer maneira, seja para servir de exemplo, cautionary tale, ou como ajuda na parte educacional.
• Falando em educação, TODO o material produzido no desenvolvimento (ERD, Fluxogramas, código-fonte, etc, etc, etc…) será disponibilizado como Open Source.

Segue a luta. Espero poder contar mais em breve =)

Originally published at Er Galvão Abbott.