Void Podcast #010 – Pimenta na complexidade dos outros é refresco!

Olá desenvolvedores, designers, analistas, arquitetos, DBAs (ainda?!) e loucos em geral!

Bem-vindos ao Void Podcast. Trata-se de uma conversa, de três bons amigos, geograficamente afastados, em clima de bar, sobre (quase) qualquer assunto.

Agora, discutimos sobre a complexidade nossa de cada dia. Há o melhor do complexo, do simples e da vaidade infinita do homem.  Participe do bate-papo acalorado entre o (professor) Leandro Daniel (@leandronet), o (filosófico) Elemar Jr (@elemarjr) e o (inventivo Fowler) Arrobinha (vulgo @vquaiato).

Você tem complexo do quê? Complexo é cult?! Participe, comente, critique!

Vida longa e próspera. Seja simples e seja feliz.

Nota do Editor: Não deixe de ouvir a seção especial de erros de gravação no final deste episódio. 🙂


Ouça


Download

VoidPodcast010 – Complexidade (62,7 MB)

Links

Anúncios

4 respostas em “Void Podcast #010 – Pimenta na complexidade dos outros é refresco!

  1. Acho que deveríamos separar a complexidade computacional (http://pt.wikipedia.org/wiki/Complexidade_computacional), aquela que vemos na faculdade, no mestrado e tal, da complexidade acidental. Entendo que incluir uma determinada funcionalidade, que não foi requisitada, pode gerar mais complexidade, por conta de ter mais códigos, mais testes, perca de desempenho ou algo do tipo. Mas isso, por se só, não é complexidade computacional.

    Já pensando no dia a dia, creio que a melhor forma de evitar a complexidade é buscar simplicidade e objetividade. Sempre procuro dividir grandes problemas, desenvolvendo assim pequenas soluções. E se por acaso veio uma ideia genial de uma funcionalidade x, que não demandou muito tempo de desenvolvimento, mostro ao meu superior, caso não seja aprovado é retirado.

    Em fim, é um assunto complexo que envolve muitas variantes. Rs…

    Obrigado por mais um void. 😉

  2. Fala galera do void,

    Deixa eu tentar contribuir…

    Gostei da definição usada pelo Leandro sobre complexidade essencial e complexidade acidental. Pra mim toda complexidade acidental é ruim (sem exceção) e também já vi muitos problemas criados por adicionar features como “brinde” em projetos, pra mim é sim complexidade acidental.

    Enfim, como tudo na vida do arquiteto de software, devemos saber ponderar para encontrar soluções “equilibradas” (essa palavra subjetiva e mágica). Adicionar feature sem o usuário pedir é ruim. O problema é que a grande maioria dos usuários não sabe pedir. Tem que saber pesar a balança.

    A mágica pra mim na área de TI, o elo perdido está justamente aí. Eu sou da opinião do “combinado não sai caro”. Por isso entra a comunicação aqui como um fator determinante. É importante conseguir extrair essa informação do usuário final. Dialogar com ele, prototipar, encontrar uma forma dele entender o que você está dizendo pra ele poder te dar a informação do quão relevante essa feature é pra ele. Criar idéias mesmo que imprecisas de custos também norteia a solução.

    Mesmo no caso do Elemar, que o usuário não está próximo, existem outras formas de se fazer isso. Eleger usuários chaves pra dialogar é uma forma de extrair essa informação. O Elemar que é um business man já pensou em montar um grupo de trabalho, escolher clientes chave que queiram contribuir para o produto em troca de descontos ou outros benefícios em serviços?

    Sobre o lance dos patterns eu continuo gostando deles. A questão é: “qual a sua motivação para usá-los?”. Essa coisa de pensar em código bonito me parece um caminho que leva para o lado negro da força. Código bonito é sempre o teu. O código do outro é sempre feio. Tá na natureza do desenvolvedor isso. Código bonito é aquele que você entende, é simples e é claro. Só o seu é assim porque só você tem a compreensão do problema neste nível. Nunca alguém vai olhar para o seu código e mandar alguém esculpir um busto seu na porta da empresa dele pq teu código é o máximo.

    Usar patterns para dizer q teu código é “GoF compliant”, “Fowler compliant” é pura complexidade acidental. Entenda o problema e proponha a solução. Vou citar 2 exemplos práticos.

    1) Num caso eu tinha um problema de integração e o usuário simplesmente queria uma solução que funcionasse e suportasse diversos formatos diferentes, partindo do princípio que ninguém ia nunca adequar-se aos formatos de integração proposto por ele e ele sempre ia ter que seguir os padrões ditados por seus clientes. A solução final foi um “motor” de integração com a parte de threading e controle deste processamento separada dos formatos via um strategy. O usuário não sabe nem q tá rolando lá. Faz 6 anos que o mesmo motor tá lá rodando com diversos novos formatos. Nesse caso, o usuário também não sabia que ele queria uma interface pra monitorar os processos que tiveram erros, rastrear reprocessamentos e mensagens de integração tocadas na mão. Tudo isso contribuiu para uma sobrevida surpreendente do projeto. A mesma interface de monitoração escrita a 6 anos atrás está sendo usada até hoje (nesse caso sem nenhuma evolução funcional).
    2) Outro caso era um outro projeto que por ser de uma natureza de “produto” como o do Elemar, tinha manutenção a longo prazo como um requisito não funcional, assim como a possibilidade de permitir que terceiros desenvolvessem coisas em cima da aplicação. Componentes desenvolvidos por times diferentes (internos e terceiros) precisavam conversar entre si sem se conhecerem. Sem dúvida nenhuma usei command e chain of responsibility. Quando alguém questionou a complexidade, minha pergunta foi: “vc conhece outra forma de desacoplar a comunicação entre os componentes e atender o requisito?”. Solução focada para o tamanho do problema.

    O problema é que esses requisitos estão sempre mascarados. Assim como vários outros. Raros usuários pensam em requisitos relacionados a “operação” de uma aplicação, como no exemplo 1 citado acima.

    Parabéns novamente pelo void.

    Abraço,

    Eric Lemes

  3. Pingback: SNIPPET: Sobre complexidade acidental « Elemar DEV

  4. Pingback: SNIPPET: Sobre complexidade acidental | Elemar JR

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s