A questão da componentização

Legal vc tocar neste assunto.

Eu me preocupo muito com a isolabilidade. Gosto da idéia da componentização (com isolabilidade), pois isso me facilita a manutenção ou modificação. Como Descartes disse: “dividir o problema em tantas partes quantas fossem necessárias para melhor poder resolvê-lo”

Mas existe uma coisa que me incomoda quando de alguma forma o projeto evolui e preciso adicionar algum detalhe novo no componente: O número de construtores, por exemplo, pode ficar grande dependendo do número de parametros e tipos necessários. Nem sempre o adapter é uma solução ideal à este problema. Gostaria de conhecer outras experiências e estrategias de solução quanto a isso.

vc podia dar um exemplo disso:

Qual recurso e como se diferencia das outras versões?

Oi Luiz Augusto, o exemplo do MySQL é apenas hipotético.

Percebo que a maior parte das merdas que vejo em nosso meio se deve a um mal entendimento dos termos.

É por isto que no meu blog estou tentando trabalhar em cima de conceitos básicos como componente, valor, qualidade, etc.

Excelente texto, Kico!!!

Achei interessante este ponto:

Eu costumo comentar com meus colegas que, quando eu precisar fazer algo que já fiz, pensarei em componentizar (hoje só escrevo minhas ferramentas dessa forma). Já cheguei a criar webservices pra fazer operações para apenas um pedaço do sistema, sem a menor possibilidade de isso vir a ser reaproveitado (porque era algo muito específico), apenas pra venderem a solução (“Usamos webservices e blá blá blá…”). Nessa hora, caímos na questão: por que eu vou querer componentizar algo que não será reutilizado? Isso só gera trabalho adicional, desperdiçando tempo que poderia ser aproveitado componentizando o que realmente importa.

Quando você diz que o excesso de componentes leva ao excesso de integrações pensei logo no meu exemplo acima. Tive que fazer um webservice, disponibilizá-lo em um container, fazer a chamada em um ponto onde eu simplesmente poderia usar uma linha de código (a funcionalidade era um simples cálculo matemático de 5ª série). Sem contar a perda de performance envolvida na integração.

Sua conclusão não poderia ter sido melhor

Parece que existe uma relação componente-ego que faz desenvolvedores quererem componentizar tudo. Os componentes precisam ser pensados pra serem bem feitos e ter essa mentalidade mostra um bom grau de maturidade.

Parabéns pelo texto, Kico! Sou leitor de carteirinha do seu blog e gosto muito da sua forma de expor opiniões.

kicolobo
Excelente texto, mesmo. E você escreve de uma forma mais “humana”, dá gosto de ler.

A questão da componentização prévia que você coloca, para mim, é uma versão da “otimização prévia” (citaram isso nos seus comentários), que constantemente ocorre em projetos. Algo como “não preciso disso agora, mas com certeza vou precisar amanhã”. Mas vai mesmo precisar? Tem tanta certeza assim, ainda mais quando é uma regra de negócio?

Me situando no assunto, “nasci e fui criado” em um ambiente em que “brotam” componentes/classes mágicas: o Delphi. E, apesar das facilidades que essa arquitetura voltada à componentes provê, facilmente somos levados ao erro de criar grande dependência de certas soluções, além de, como exposto no texto, haver muita necessidade de integrações entre esses componentes. Você passa mais tempo juntando os pedaços que programando.

Mas estou crescendo . Acho que ainda nessa encarnação estarei programando em um nível decente.

Abraços.

Que bom que gostaram, mas sabe: o grande desafio pra mim tá sendo a conscientização dos níveis gerenciais (principalmente os que não tem muita vivência técnica) a respeito desta questão. Isto porque muitas vezes é feita uma cobrança injusta em cima do desenvolvedor de que o código deve ser componentizável sempre.

Sempre? Eu sinceramente acho cruel, porque o que este povo se esquece é que quando você está implementando determinada funcionalidade, em um primeiro momento ela sempre é específica. Sempre é feita para aquele primeiro caso em que a situação aparece. Então pedir para que o pobre desenvolvedor já implemente algo genérico de cara - sem que tenha sequer visto a segunda ocorrência - acaba por minar a produtividade (como eu odeio esta palavra, “produtividade”) da equipe inteira com uma generalização desnecessária (naquele momento).

E sabem, pra mim a causa raíz disto tudo é uma má compreensão em cima do que vêm a ser os conceitos da nossa área: componente, qualidade, valor, etc. Não sei com relação a vocês, mas vejo as pessoas usando estes conceitos coloquialmente muitas vezes sem pensar no que são de fato. Vocês também tem esta impressão?

ps:
e Delphi rocks né TerraSkilll? - morro de saudades daquele negócio.

Começo dizendo que concordo com tudo que você escreveu Kicolobo, excelente discurso. Acredito que a sua conclusão denota bem o a situação em relação a criação de componentes.

Você alertou ( se entendi bem ) que criar componentes não é tão simples como a maioria pensa. Verdade, porem acredito que seja muito mais difícil do que você tentou dizer.

Kicolobo:

Como pode ser visto, um componente não é algo fácil de ser construído. Estamos lidando com uma criatura complexa e difícil de ser encontrada. É por isto que não me sinto à vontade quando vejo este conceito representado por metáforas visuais como peças de quebra-cabeça ou um mero cubo. Elas transmitem a ideia de que estamos lidando com algo simples o que não é o caso.

Pensar só não é suficiente na minha opinião, alem de pensar é preciso: conhecer profundamente o contexto da empresa, o mercado no qual ela é inserida, a dinâmica do contexto interno e externo no qual esta empresa participa, poder, recursos humanos que entenda e compreenda a necessidade e o valor de se construir componentes, saber administrar o tempo e etc… a lista é grande.

Perceba que em uma visão mais ampla o sistema que sua empresa fornece será visto como um componente fora dos limites dela e por causa disto ele terá que ter condições de se adaptar ao novo ambiente para coexistir - este ponto coloca em jogo muitas questões relacionadas a construção de componentes. Aqui muitos fogem pras colinas a procura de gambiarras.

Enfim, simplesmente…sorria.

P.S suas fotos são engraçadas.

flws

kicolobo:

[…] muitas vezes é feita uma cobrança injusta em cima do desenvolvedor de que o código deve ser componentizável sempre.

[…]

E sabem, pra mim a causa raíz disto tudo é uma má compreensão em cima do que vêm a ser os conceitos da nossa área: componente, qualidade, valor, etc. Não sei com relação a vocês, mas vejo as pessoas usando estes conceitos coloquialmente muitas vezes sem pensar no que são de fato. Vocês também tem esta impressão?

Não só tenho essa impressão como já li isso em manuais da qualidade (“O desenvolvedor deve primar pela qualidade sempre construindo componentes que blá blá blá…”). A qualidade não está no componente, está no código. Se o código é de um componente racional, ótimo, se é de uma classe de negócio do sistema, excelente!

Com isso perde-se muito tempo tentando adivinhar como será a repetição e começam os códigos macarrônicos pra prever qualquer tipo de uso e a mais alta “flexibilidade” possível.

Já vi, inclusive, empresas onde cada setor tinha o seu componente próprio que fazia a mesma coisa do componente do vizinho. A melhor parte era você passar um tempão aprendendo como aquela merda funcionava e, depois, ir pro outro setor pra prestigiar outra cagada. Tem horas que eu me sinto um papel higiênico de bits…

Acho que esse texto do kiko é só um “port” para componentes do bom e velho principio KISS, que deve ser utilizado sempre.

Se voce for ver o mesmo que acontece com os componentes acontece tambem com os design patterns, quando a gente descobre sobre eles. Está sempre tentando usar algum de alguma forma, nem que tenhamos que criar problemas que não temos para poder solucioná-los com os patterns.

Muito bom o texto.

kicolobo:

Oi gente, tudo bem?

Aqui estou eu mais uma vez levantando um ponto polêmico.
Já faz algum tempo que venho testemunhando horrores na questão da componentização e, acredito, isto se deve ao fato de que as pessoas não pensam muito no que vêm de fato a ser o conceito de componente.

Então nas minhas “investigações filosóficas”, acabei escrevendo um post sobre o assunto no meu blog: http://www.itexto.net/devkico/?p=1169

Assim a gente pode levantar a questão. Na posição de vocês, como esta questão está sendo levada? Se sentem pressionados a componentizar antes do reuso real surgir?

Não sou a melhor pessoa para falar do assunto, pois sou novo ainda em Java.
No entanto estou vendo nesse semestre na faculdade uma matéria que se chama
programação modular.

Nela observei que se você favorece muito uma tática/estratégia A
acaba desfavorecendo muito um outro ponto B, pois no fim eles podem estar
relacionados inversamente.

Sendo assim guardei para mim uma dica que o professor deu…
Praticar bastante para saber ao certo onde, quando e como aplicar
uma estratégia pré-definida em conceitos de POO ou XP

Li todo seu tópico e achei que é excelente!
Suas idéias são realistas e eu também penso
do mesmo ponto de vista que o seu.

Realmente é complicado tratar o assunto de componentização
em empresas que pressionem os Desenvolvedores a criar
softwares muito rápido e pensando em componentização. Resultado
disso é componente não testado em outras ocasiões, como você
mesmo já citou.

Concordo com você quando fala que o segredo é observar o ambiente
ao ser redor e ir aprendendo a identificar a componentização onde é possível
usá-la.

Parabéns pelo seu Artigo.
Ele demonstrou sua preocupação com o tema e finalizou chamando a atenção
para o fato do Desenvolvedor observar o que lhe está ao redor e aprender
a identificar componentizações possíveis.

Abraço e sucesso

Só pra tua pegunta não passar em branco, Luiz. Pela descrição do teu cenário parece se encaixar no que o kiko indica que não deveria ser componetizado. Quando precisa de muito parâmetro é porque está tratando de situações muito específicas em cada caso que é usado. O número grande de parâmetros no construtor também é indicativo de muita responsabilidade para o mesmo objeto/componente.

Como você provavelmente já tem vários casos em que os componentes são usados, você pode tentar identificar exatamente os trechos em que eles sempre são iguais e isolar esta parte daquelas em que eles diferem. E esta parte em que sempre são iguais talvez sejam os grandes candidatos a serem componetizados.

Absolutamente!

Na minha percepção, este problema ainda está relacionado com a separação técnico/gestor. Podemos observar que na maioria das faculdades, cursos, etc. as disciplinas ténicas são completamente dissociadas da gestão da entrega de valor. Por exemplo, componentes, código modular, refatoração, etc. são tidas como coisas técnicas, “de peão”, e quando fala-se em gerir a entrega de valor você tem definição de processos, documentação, diagramas, etc. No final das contas, essa separação cria técnicos e gestores alienados, de maneira que um ignora completamente o trabalho do outro, e na tentativa de cada um de aplicar “as melhores práticas”, um acaba anulando o outro. E veja, não se trata de metodologias tradicionais x ágeis, por que é muito fácil cair nessa armadilha utilizando métodos ágeis. Se você fizer um curso de Scrum por exemplo, o foco é uma receitinha de bolo: divida em iterações com reuniões no início e no fim, eleja um PO e um SM, faça reuniõe diárias e “puff”, a mágica acontece.

Bom, mas como esse cenário poderia ser revertido ? Pra começar, acho que todo trabalhador do conhecimento deveria conhecer alguma coisa sobre gestão. Não só de gestão de projetos, mas de uma maneira geral. Vale lembrar que a gestão acontece em diversos níveis (estratégica, operacional, etc.) e penso que cada um deveria gerir pelo menos o próprio trabalho. Eu acho que isso é importante justamente para que o desenvolvedor possa entender qual é o seu papel dentro da cadeia de valor do produto/serviço que ele ou a empresa oferece. Da mesma maneira, acho que um gerente que não tenha pelo menos alguma (boa) experiência técnica vai ser um gerente manco, daqueles que mais atrapalham do que ajudam.

Enfim, acho que essa sequência de raciocínio me leva a concluir que uma determinada prática ou técnica só é boa ou ruim dentro de um determinado contexto, e para fazer essa avaliação é preciso critério.

bacana o texto, mas como tenho pouca vivência ficou um pouco abstrato.

pra entender de verdade, só vendo exemplos de componentes mal feitos que são usados na vida real, e a maneira mais correta que o problema poderia ter sido resolvido.

rmendes08 escreveu:

Da mesma maneira, acho que um gerente que não tenha pelo menos alguma (boa) experiência técnica vai ser um gerente manco, daqueles que mais atrapalham do que ajudam.

E se eu disser que a grande maioria dos gerentes são desse perfil? Fazendo uma analogia com o assunto deste tópico, imagine que o tal gerente ouviu falar num-sei-onde que “a componentização proporciona reúso e melhora a produtividade”. Blz. O que o cara normalmente vislumbra é a possibilidade de melhorar magicamente a produtividade; vamos implantar agora a norma de que tudo que vai ser criado tenha que ser componentizado (ou documentado até em detalhes desnecessários, ou acompanhado de diagramas e classes de teste…)

É assim que um gerente desse pensa. O cara foi promovido não porque tenha conhecimento, mas porque sabe influenciar a equipe (= boa lábia).

MarkKnopfler:

É assim que um gerente desse pensa. O cara foi promovido não porque tenha conhecimento, mas porque sabe influenciar a equipe (= boa lábia).

Eu não posso concordar com tudo o que foi postado aqui porque eu não to vendo as formas como estão trabalhando, mas concordo que nem pra tudo é necessário fazer modularização, componenização, diagrama de classe ou classes de testes… Até o momento eu não ví ninguem dando exemplos concretos ou definindo os níveis onde isso deve ou não ocorrer.

por exemplo sobre UML… vejo gente fazendo diagrama de tudo quanto é rebimboca:

O cara vai conseguir influenciar qualquer equipe se, como o kiko lobo disse, provar e mostrar utilizades e valores maiores.

Luiz Augusto Prado escreveu:

O cara vai conseguir influenciar qualquer equipe se, como o kiko lobo disse, provar e mostrar utilizades e valores maiores.

“Influenciar” era antes de ser promovido. Depois que virou patrão, muitas vezes temos que é que baixar a cabeça (eu não duro 6 meses em uma empresa assim).

Mas o que eu queria mesmo era parabenizar o sr. kicolobo pelo blog, simplesmente fantástico. Recomendo!!

Só para mostrar um outro lado da moeda (apesar de concordar com quase tudo que foi dito até agora).

Acho que muitas vezes entregamos soluções abaixo do recomendável, por falta de reaproveitamento.

Um exemplo que penso agora, é autenticação de usuários.

Alguns recursos que esse componente teria:

• Usar hash “salteado” de senha com algoritmo específico (como scrypt) .
• Reset de senha com confirmação por email.
• Bloqueio de usuário ao errar a senha N vezes.
• Bloqueio de ip origem ao efetuar múltiplas tentativas (evitar ataques)
• Opção de se lembrar do usuário, para não digitar senha sempre.

Enfim, uma pequena lista de requisitos básicos para autenticação.
Mas quem tem tempo de implementar tudo isso a cada novo projeto?

Acho que pra esse tipo de funcionalidades, componentes (ou serviços) seriam muito bem vindos.

AbelBueno:

Só para mostrar um outro lado da moeda (apesar de concordar com quase tudo que foi dito até agora).

Acho que muitas vezes entregamos soluções abaixo do recomendável, por falta de reaproveitamento.

Um exemplo que penso agora, é autenticação de usuários.

Alguns recursos que esse componente teria:

• Usar hash “salteado” de senha com algoritmo específico (como scrypt) .
• Reset de senha com confirmação por email.
• Bloqueio de usuário ao errar a senha N vezes.
• Bloqueio de ip origem ao efetuar múltiplas tentativas (evitar ataques)
• Opção de se lembrar do usuário, para não digitar senha sempre.

Enfim, uma pequena lista de requisitos básicos para autenticação.
Mas quem tem tempo de implementar tudo isso a cada novo projeto?

Acho que pra esse tipo de funcionalidades, componentes (ou serviços) seriam muito bem vindos.

Sim! Exatamente!
Porque se não separar por móludo (ou componente), fica parecendo gambiarra.