[quote=caiofilipini][quote=skill_ufmt]Outro dia vi o Shoes falando que conhece 4 caras que sabem OO de verdade, eu não conheço nenhum, mas gostaria de conhecer e trocar uma idéia.
[/quote]
Acho que foi o LIPE que falou isso. 
[]'s[/quote]
Ah hehe
ratificação então, o LIPE falou que conhecia 4 caras… 
De qualquer forma.
Apresenta pra nós ae LIPE : )
Ai!!! Como é que um cara realmente bom vai conseguir prefer 99% das mudanças:??? Desde quando o cliente é um cara previsível??? Nem Erici Gama mas os outros três carinhas lá que escreveu o livro com ele conseguiriam esta proesa!!!
Cara… isso é pior que um palavrão!
Quando você aplica um refactoring, você está mudando algo que realmente é necessário, e que realmente vai mudar com frequência.
Perder tempo é ficar achando que patterns vai deixar seu sistema completamente ileso à qualquer mudança! Vou enumerar os porques!!!
1 - Você deverá prever tudo que poderá acontecer!
2 - Um previsão vai levar você a outra previsão, que leva a outra, e outra, e outra…
3 - Você deverá aplicar patterns, por isso deverá definir bém quais patterns usar!
4 - Você deverá conhecer todos os patterns que serão utilizados, então terá que aprender!
5 - Quando se coloca um pattern no projeto, vc adiciona complexidade e burocracia no seu código. Então uma alteração que afetaria 2 classes afetará agora pelo menos 4 classes ou mais!
6 - Para adicionar um novo profissional para ajudá-lo, ele deverá conhecer patterns, logo, é um profissional mais caro!
7 - Fazer qualquer diagrama usando UML será uma aventura!
…
…
…
E para finalizar:
Mais de 90% do que você previu que seria alterado nunca será realmente alterado!
OU seja, só 10% do seu esforço realmente valeu a pena, e os outros 90% poderia ser usados para garantir que o sistema fosse entregue no prazo e poderia ser usado aplicando refactorings quando necessário!
[quote] 3 regras da OO:
Programe para interface.
Prefira delegação.
ENCAPSULE tudo que possa ser variável.
Se não obdecer as regras, nãos estais programando OO direito. [/quote]
Bom, recentemente tivemos uma discussão feia aqui no GUJ sobre isso… aquele tópico que começou falando de delphi e depois mudou para java beans, maldição ou salvação!.. lembra???
A conclusão que cheguei de tudo aquilo é que quanto mais patterns vc colocar no seu projeto, mais estruturado seu projeto fica, e menos OO!!!
O que você postou e que eu demarquei em cima está correto, mas não condiz com o que você defendeu até aqui, que é a utilização de patterns para deixar seu projeto flexível no caso de mudanças!!!
Só isso… hehe
Abraços!
Pena que um cara bom desse nao existe (ja que vc mencionou o Martin Fowler, eu por acaso trabalho com ele - e posso dizer com toda certeza que ele discorda veementemente da sua opiniao, preferindo refactorings e design evolutivo).
Tempo desperdicado eh bolar o sistema antes de comecar, jogar tudo fora e fazer de novo a cada dois meses. Ou entao ter aquele momento “xi, e agora marquinho?” e arregacar a arquitetura do sistema jogando OO, bons principios da programacao, patterns, prazos, o namoro e se deixar ate a mae do cliente pela janela.
Ja que voce concorda em pelo menos um ponto comigo, de que o Martin Fowler eh o cara, vale a pena dar uma lida no site dele, http://www.martinfowler.com - coisa que, pelo seu post, nota-se que voce nao fez.
Bom, aqui você cita:
Tudo isso é trabalho pra quem? Desenvolvedor ou Arquiteto?
Minha resposta é Arquiteto.
Se é Arquiteto, é de pensar que obrigatoriamente ele deveria fazer o que você citou ai em cima, ou não?
E se ele tem que fzer, que faça bem feito, concorda?
Quanto ao preço do profissional, você quer um cara que faça tudo isso ae
pra pagar uma mer… de salário para ele?
Ai vamos cair na discussão a desvalorização do conhecimento,
que não é o foco agora
Eu pagaria par aum cara que sabe tudo isso ae muito bem sim,
até porque não vou precisar de 20 caras desse ai na minha equipe,
um apenas bastaria, certo?
E ele é arquiteto e vai ta la para isso, desenvolvedor vai ta la pra ver o
que ele quer e fazer, todo desenvolvedor que se preze tem de saber pelo
menos o basicão de patterns, pelo meos pra ler algo do tipo,
se não é uma merda só depois e ai vem os seus queridos refactoring
para refazer tudo e deixar legalzinho.
Não to dizendo que refactoring é ruim, é bom claro, mas deve-se evitá-lo.
Se vai fazer alguma coisa que faça direito, não faça do jeito que precise
ficar refazendo. é logico isso, é melhor fazer algo 1 vez ou 3, 4?
Acho que você está aderindo a idéia de que Analisar o problema antes de fazer é solução ruim.
Mas os fatos e pesquisas mostram que somente quando gastasse tempo
com analise, arquitetura e bla blas, é que você tem sucesso no seu projeto.
Sair fazendo as coisas sem saber onde vai pisar mais tarde é burrice, concorda?
Nunca estaremos livres de refactoring, mas podemos diminuir ele ao extremo sim.
[quote] 3 regras da OO:
Programe para interface.
Prefira delegação.
ENCAPSULE tudo que possa ser variável.
Se não obdecer as regras, nãos estais programando OO direito.
Bom, recentemente tivemos uma discussão feia aqui no GUJ sobre isso… aquele tópico que começou falando de delphi e depois mudou para java beans, maldição ou salvação!.. lembra???
[/quote]
Lembro.
Acho que você está confundindo os dois paradigmas.
Padrões são aperfeiçoamentos no uso de OO, ou melhor, é como se deveria usar OO.
Os dois não adam separados de forma alguma.
Mas não mudei meu foco hehe
Realmente to te dizendo que os padrões,
servem a esse propósito primordialmente, e a uma série de outros em seguida.
E antes que alguém poste, é claro que padrões também têm suas desvantagens.
Abraços.
:!: design vident detected :!:
Parem de confundir a cabeça do cara que tá començando :hunf: não adianta porcaria nenhuma se enfiar num livro de patterns para j2ee sem saber o básico de j2ee. Tem que sofrer um pouco, ver que é uma merda abrir connection no servlet, que é uma desgraça colocar query string no meio do código, etc.
Quando ele perceber que está tendo trabalho demais, quer dizer que entendeu um pouco como a coisa funciona, e só então será útil estudar melhores formas de resolver os mesmo problemas.
Apressadinhos :XD:
Po, show, tem vaginha ae não?
Olha, vamos esclarecer heehe
Não sou a favor de prever 99%, como você mensionou, é impossível.
Mas também não sou a favor de 99% de Refactoring
Quanto aos artigos do martin, tenho lido alguns sim, apenas não cheguei a conclusão ainda de qual é a opinião formada dele hehe talvez por não ter lido todos ainda e nem o tão sonhado Refactoring dele que pretendo ler no próximo mês.
Mas ando lendo muita coisa sobre padrões e OO(Monografia sabe como é né ) para defender a monografia na próxima segunda, 28.
Estou apenas treinando meus argumentos e confrontando idéias que se parecem sólidas
Você disse que o Martin é a favor de refactoring, certo? mas até a que nível? refatorar tudo? 10%, 50%?
Estive vendo sobre IOC num artigo que é dele se não me engano, aquilo para mim aparentemente é OO pura, muita interface e tal.
Agora aquilo também é um padrão, certo?
Bom, já que tu é o cara e amigo do cara, poderia me dizer a opinião dele ou a sua, de como seria esse relacionamento entre Flexibilidade com padrões e optar por fazer merda ou quase merda e usar refactoring depois?
Estou partindo do principio onde estamos na primeira versão de um software sem finalização, não onde precisamos refatorar para usrgir uma segunda versão, ok?
Abraços.
[quote=LIPE]Parem de confundir a cabeça do cara que tá començando :hunf: não adianta porcaria nenhuma se enfiar num livro de patterns para j2ee sem saber o básico de j2ee. Tem que sofrer um pouco, ver que é uma merda abrir connection no servlet, que é uma desgraça colocar query string no meio do código, etc.
Quando ele perceber que está tendo trabalho demais, quer dizer que entendeu um pouco como a coisa funciona, e só então será útil estudar melhores formas de resolver os mesmo problemas.
Apressadinhos :XD:[/quote]
hehehe
Eu tentei dizer isso no meu segundo post mas a discussão se esquento heehhe
Vamos mudar de post então? abrir outro? um antigo?
[quote=Skill] Acho que você está aderindo a idéia de que Analisar o problema antes de fazer é solução ruim.
Mas os fatos e pesquisas mostram que somente quando gastasse tempo
com analise, arquitetura e bla blas, é que você tem sucesso no seu projeto. [/quote]
Sim, desde que você more lá na ìndia, onde a mão de Obra é Barata!!!
Afinal, no caso de uma alteração, você precisará de um analista, de um arquiteto e de um desenvolvedor para manter as documentações referente a análise e arquitetura atualizados com relação ao código nos casos de alterações!!!
Sim, podemos.
É só você fazer um contrato fechado com o cliente, onde uma vez que ele faça os requisitos, espere o sistema chegar pronto na mão dele. Evitar o máximo possível de Feedbak do cliente seria melhor ainda.
Evite reuniões com o cliente. Não deixe ele dar opinião sobre o sistema.
Não deixe o cliente testar o sistema antes dele ficar pronto! Caso ele ache que algo tenha que mudar, diga que precisará fazer um orçamento… daí, vc deverá meter a faca no orçamento. Assim ele desiste da mudança, e assim não haverá refactoring!!!
Que tal matarmos ele? seria mais fácil
Não Skill, isso também naum…
Se esse cliente morrer, vão colocar outro no lugar dele! Ai esse novo cliente pode acabar querendo mudar tudo que já tinha sido definido!
Isso só vai dar dor de cabeça!
Voces (Thiago e Kiviano) estao confundindo refactoring com retrabalho. Refactoring eh SEMPRE positivo, e deve ser encorajado no desenvolvimento de software, por melhorar a qualidade e coesao do design.
Retrabalho eh, geralmente, negativo. Logo, deve ser evitado a menos que sua necessidade seja maior do que a perda de tempo que ele causa.
A definicao de refactoring, que voces provavelmente nao leram, do site www.refactoring.com:
CV,
Mas é justamente isso que to tentando defender, que refatoração, não é fazer novamente, e sim “ajustar” o que ja está feito, sem grandes mudanças, e contanto que elas não interfiram no fluxo da aplicação.
Defendo que gaste-se tempo para fazer uma arquitetura confiável e com as boas práticas de OO e padrões, e que feito isso, como tudo é mutável, ajustamos através de refatoração, mas sem mudar o cerne da arquitetura com padrões.
Mas não que se use refatoração como meio de arrumar tudo. mudar estruturas e etc.
Não Skill, isso também naum…
Se esse cliente morrer, vão colocar outro no lugar dele! Ai esse novo cliente pode acabar querendo mudar tudo que já tinha sido definido!
Isso só vai dar dor de cabeça![/quote]
Malditos clientes hehehe
A nanotecnologia ou a IA podiam no futuro atuar em softwares fazendo com que esles se auto refatorem
Seria tão bom…
Leia o paragrafo que eu quotei de novo: refactoring eh exatamente mudar o fluxo da aplicacao sem mudar o comportamento externo! E ainda por cima eh a parte que eu negritei, diacho :evil:
E o que te leva a crer que mesmo tudo sendo mutável, “o cerne da arquitetura” tem que permanecer o mesmo?
kkk CV nervoso na área,
Talvez me espressie com as palavras erradas, mas eu queria dizer isso,
que no refatorar eu por exemplo mudaria a lógica de como busco o nome
de uma pessoa no módulo pessoa, mas o cliente que sempre requisita
essa consulta nem saberá que você mudou, pois esta mudança não implica
mudanças nele, que no caso é o externo ao modulo Pessoa.
[quote]
E o que te leva a crer que mesmo tudo sendo mutável, “o cerne da
arquitetura” tem que permanecer o mesmo?[/quote]
Se eu mudar o cerne da arquitura não estaria fazendo outra arquitetura?
isso não seria retrabalho?
não seria minha a culpa de não ter entendido ou adquirido os requisistos corretamente?
Isso ainda estaria encaixado num escopo de refatoração?
ou seria uma mudança geral?
isso sem considerar mudanças por parte do cliente que resolve que quer
tudo diferente.
Nao - enquanto o comportamento externo do metodo/classe/pacote/modulo/sistema for o mesmo, ainda eh refactoring.
Se voce quiser apontar um culpado, fique a vontade - eu aposto que voce e o seu cliente estao mais interessados em ver software funcionando e mais dinheiro no bolso de todo mundo. Mas, de qualquer forma, interessante a sua opiniao sobre o comportamento dos clientes. Como sugestao, leia isso: http://c2.com/cgi/wiki?EmbraceChange
Então quando mudo isso metodo/classe/pacote/modulo/sistema tenho meu cerne mudado e chegamos onde eu queria eheh
Bom, valeu pelas discussões, tenho certeza que incrementou bastante meus poderes defesa e meus poucos conhecimentos.
Como disse no começo estava apenas confrontando idéias, mas sou adepto das Metodologias Ágeis(XP, Scrum) e com foco extremo na minha equipe e não em papeladas.
Refactoring é sempre bom e necessário, desde que seja um refactoring e não uma mudança de cerne.
talvez os padrões possam endurecer o processo ágil, mas o processo ágeil também necessita de seus padrões.
Enfim, viva o refactoring, os padrões e as metodologias ágeis
Abraços.
só pra constar CV, o link não ta funcionado
É valeu pela discussão!
Como sempre, somo ótimos em mudar o assunto de um tópico… hehehe!!!
Skill, quando o bicho pegar no JRapido a gente vai ter oportunidade de discutir o assunto de novo e na prática!!! HEHEHEHE!!!
Que o XP, Refactoring e padrões de projeto bém empregados vivam felizes para sempre!
Até o próximo capítulo!!!