Por que o código dos outros é sempre ruim?
Sabe por que o código fonte dos outros é ruim? Porque os programadores começam o projeto sem saber quais partes do Software precisam de código realmente bom e, pior, não refatoram no decorrer do projeto. Estas partes do Software são as que mais sofrem manutenção, as mais sujeitas à bugs e alterações futuras. Para facilitar a explicação vamos chamar estas partes de Partes Relevantes.
Pois bem, sabemos que o código não vai ficar bom em 100% das partes do Software. Então, a chave é fazer o código bem feito onde ele precisa ser bem feito, ou seja, nas Partes Relevantes. O problema? No início de todo projeto sempre há aquela preocupação em fazer tudo genérico, bonito, organizado, etc. E justamente neste momento sabemos muito pouco sobre as Partes Relevantes. Como resultado, acabamos perdendo muito tempo implementando coisas bonitas e genéricas onde não precisava e isso toma justamente o tempo que deveríamos dedicar à… quem? quem? às Partes Relevantes do Software.
Então um outro programador assume o nosso código e, obvimante, ele terá que mexer…bem, você sabe aonde. E não importa o quanto seu código está bom nas outras partes pois ele não vai nem entrar nelas. Você teve sim a preocupação em fazer um código bom, mas fez isso no lugar errado pois não sobrou tempo para fazer no lugar certo. Por isso, o outro programador vai achar que o seu código é uma merda pois ele sabe do código bom que ele é capaz de fazer (mesmo que ele o faça onde não precisa) e está vendo a parte do seu código que até você tem vergonha. Então ele vai ficar dando palpites no seu código – mas agora é fácil, pois neste momento as Partes Relevantes são evidentes. Até que um dia ele precisa implementar um conjunto de funcionalidades novas e o ciclo se repete (outro assume, critica, faz bem onde não precisava e mal onde precisava). E assim continuamos achando sempre que o nosso código é melhor do que o dos outros pois sempre analisamos no final, numa atividade onde uma das coisas mais importantes é entender realmente o que precisa ser feito.
Mas eu desconfio que este ciclo poderia ser quebrado se a Refatoração fosse levada a sério. Eu disse: LEVADA A SÉRIO! Não falo do mito da refatoração no final do projeto. Falo em Refatorar sempre que adicionar uma nova funcionalidade, por menor que seja. Falo em adaptar o código existente para que esta nova funcionalidade se encaixe como uma luva sem a necessidade de “ifs” para tratar casos não previstos. Se o caso não foi previsto eu não vou colocar um “if” (ou violar os princípios de OOP) para que funcione, eu vou mudar o código existente para que ela se encaixe como se tivesse sido prevista desde o início.
Quando você Refatora corretamente o código fica melhor com o tempo pois a cada nova funcionalidade você entende melhor o que precisa fazer. A cada funcionalidade nova você entende melhor quais são as Partes Relevantes. Por outro lado, quando você não Refatora o código fica ruim com o tempo pois você está ignorando o que está aprendendo de novo sobre o que precisa de fato ser feito.
Tweet
Beck, atualmente temos desenvolvido na RIA Labs da forma como sempre sonhamos: com tempo para desenvolvimento. Isso não tem acontecido por acaso, mas devido a uma política de planejamento dos novos contratos, que ao serem assinados, pedem um prazo factível, com o máximo de detalhamento possível sendo mostrado claramente para o cliente.
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
Falou bonito, Beck. Mas para isso acontecer é necessário, também, um bom planejamento como bem disse o Ved; o que muitas vezes é deixado de lado na maioria dos casos devido ao prazo.
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.
Sinceramente,
Pensar em código bem feito em partes relevantes, particularmente, é pensar pequeno.
A muito tempo que se bate na tecla das best-practices.
Todo o código tem de ter qualidade, não apenas partes dele.
> Pensar em código bem feito em partes relevantes,
> particularmente, é pensar pequeno.
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.
Acho que refatoração é um retrabalho. Na minha opinião o código deve ser implementado da melhor maneira possível, não importando se é relevante ou não. Vejo que o importante é você ter um padrão e desde que seja produtivo e de qualidade não haverá a necessidade de refatoração.
As técnicas de desenvolvimento estão em constante evolução, se refatorarmos sempre que evoluirmos, nosso código nunca ficará pronto.
Levando-se em conta que o tempo é escasso e precioso, o importante é o reaproveitamento do código e melhorá-lo sempre com as lições aprendidas em um novo projeto.
Um abraço,
Marcelo de Francisco
Marcelo,
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
Beck,
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
E aí, Beck!
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
Por favor como consigo entrar em contato com o Beck Novaes??
obrigado
Beck Novaes,
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