Muito interessante este post, e de fato tem razão sobre a refatoração! Mas não podemos esquecer do planejamento do projeto, com uma boa direção o projeto sairá bem feito.

Sobre perde tempo fazendo códigos bons onde não precisava, acho meio ruim este termo, pois todo o projeto precisa de códigos bons, sei que os prazos são apertados,porém o que diferencia um software do outro é a qualidade geral, não adianta nada você fazer um super calculadora que você coloca um valor apenas e te retorna a previsão do tempo, se a interface e detalhes “irrelevantes” não estiverem bem programado, estamos na era RIA, onde as transições e “firulas” são tão relevantes quanto o “background” do projeto.

Este é um assunto subjetivo onde existem varias opiniões, e não se deve esquecer que existem situações para cada caso.

Mas entendo que é realmente difícil definir o que é ou não relevante no projeto… mas é um ponto importante.

enfim.. gostei do post muito bom.. só fui ler hoje, em 2010 hehehe..

abracos parabens pelo trabalho

obrigado

Falou tudo agora. Me lembrei de um tempo atrás quando eu pedi um prazo maior para liberar novas funcionalidades no sistema porque era necessário fazer um refactoring… me olharam com uma cara estranha … os prazos são sempre muito curtos, e as necessidades de negócio são reais. Identificar com precisão as Partes Relevantes logo no começo é importantíssimo, e difícil de se fazer.

Abraço!

Elvis Fernandes

Eu entendo o teu ponto de vista, porém não acho que é perda de tempo fazer um bom código mesmo pra funcionalidades que o cliente não usará, se essas funcionalidades foram previstas e orçadas, o problema do não uso é do cliente, a partir do momento que ele solicitou e pagou eu tenho que fazer bem feito. Acho interessante os métodos ágeis, porém, o que tenho visto é que as empresas que tenham um método de desenvolvimento mais burocrático como o CMMI ou MPS/Br têm mais credibilidade que os que usam o XP por exemplo.
Quero deixar claro que não sou contra os modelos ágeis, mas eu penso que tudo que é combinado não é caro e se o cliente pedir algo que não foi combinado o cronograma e o orçamento do projeto devem ser alterado.

Um abraço,
Marcelo de Francisco

O maior problema é que o Software muda o tempo todo durante o ciclo de desenvolvimento – não é atoa que todo produto do Google fica em Beta durante vários anos. O cliente nunca sabe o que quer e a gerência de requisitos não é perfeita. Quantas vezes não perdemos tempo implementando coisas que na verdade não servem pra nada? Sabe aquelas funcionalidade que o usuário pede e depois ele raramente usa? E você perdeu um baita tempo implementando da melhor forma possível? Este é um dos motivos da Refatoração. Além, é claro, dos inúmeros outros que podem ser visto no livro de um dos maiores conhecedores de desenvolvimento de Software e OOP do mundo: Martin Fowler. Ele e o Kent Beck que cunharam o termo Refatoração. Hoje em dia todo IDE descente tem funcionalidades para suporte à Refatoração. De modo que se as empresas que Desenvolvem IDEs acham isso importante e as pessoas que conhecem muito sobre Desenvolvimento de Software também acham, deve haver algum motivo. E não acredito que é porque eles são incapazes de fazer bem feito desde o início. Ao contrário, acho que eles são os maiores interessados em não perder tempo.

[]‘s

Um abraço,
Marcelo de Francisco

Cada um tem sua opinião e isso deve ser respeitado, obviamente. Mas seria bom que, principalmente aqueles que criticam, tivessem a coragem de deixar o seu nome verdadeiro.

Eu, ao contrário de “pensar pequeno”, chamaria isso de “ser realista”. E a realidade é que o mercado, o prazo e o custo nos pressiona o tempo todo com relação a qualidade do código. Eu trabalho com desenvolvimento de Software há 10 anos e posso afirmar que na maioria dos casos as Best-Practices vão pro saco na hora que o bicho pega. E muitas vezes o bicho pega porque perde-se tempo fazendo o que não precisava. Assim, as Best-Practices de hoje acabam, ironicamente, gerando as Bad-Practices de amanha. Eu vejo isso acontecer com muita freqüência.

Sim, é preciso planejamento. Sim, é preciso metodologia. Mas isto já é um tanto evidente, não é mesmo? Isto todo mundo já fala há muito tempo. O que não é evidente e que eu quis trazer a tona é que dadas as condições realistas do mercado a saída é priorizar, focar, refatorar e ter a consciência que você só vai saber o que precisava ser feito de verdade próximo do final do projeto. Ao contrário de pensar pequeno isto é querer fazer o melhor trabalho possível onde realmente faz a diferença… assim até sobra tempo para fazer cada vez mais e melhor… para fazer, inclusive, funcionalidades não previstas mas que agregam muito mais valor ao produto final do que um código lindo e desnecessário que nunca será modificado e que nada significa para o usuário. O pensar grande e querer aplicar as super técnicas, as super best-practices e os super Design Patterns desde o início, onde talvez não seja necessário, é que pode fazer o programador quebrar a cara.

A muito tempo que se bate na tecla das best-practices.
Todo o código tem de ter qualidade, não apenas partes dele.

Acho preferível priorizar qualidade de design, código e testes a adicionar N funcionalidades e depois ficar se perguntando da merda que foi escrita. Porém o cliente, muitas vezes, não entende isso. Qualidade de software para um cliente “leigo” é diferente da qualidade de software para o desenvolvedor.

Outro aspecto que conta bastante é a metodologia de desenvolvimento da equipe e como ela se comporta em relação a essa.

Enfim, daria um belo livro toda essa conversa. =P

Abraço,
Vítor Avelino.

Numa situação como essa, é possível sim escrever código bom, mas num ambiente inóspito e insalubre, como em agências de publicidade, por exemplo, escrever código de qualidade é praticamente impossível! Os prazos simplesmente não deixam.

Mas acredito que com a profissionalização constante dos desenvolvedores, isso tem se modificado.

Escrever um código bom é muito gratificante!

Grande abraço,

Ved