Você já recusou fazer alguma implementação?

38 respostas
moacirjava

Bom dia caríssimos gujeiros!

Seguinte, queria saber a opinião de vocês a respeito de um fato que aconteceu comigo a algumas semanas atrás.
Estava eu em casa num belo sabadão de folga e me chamaram para ir a BH resolver um problema de um sistema foi que concebido de maneira bem errada. Fui até lá vi que o problema era grave e isso me custou duas semanas de trabalho ininterrupto. Eu avisei os diretores que eu poderia trabalhar em cima de uma emergência, mas que não recomendaria vender o sistema a outros clientes justamente pela quantidade excessiva de gambiarras e bugs. Agora eles querem que eu faça customizações e outras implementações em cima de emaranhado de gambs.
E eu pergunto algum de vocês já disse: “-Não vou fazer isso!” a seus diretores?

38 Respostas

Roger75

Mas se pagar bem, que mal tem? :slight_smile:

WRYEL

Interessante pergunta, a um ano atrás eu me faria a mesma, porém, não sei se é a decisão mais certa que eu tenho tomado … Daqui pra frente eu apenas alerto e quando possível tento dar uma solução melhor para os possíveis problemas “e” dos problemas que de fato que vão ocorrer, e caso eles ocorra, a culpa não será minha. Foi se a época que por aqui você podia vestir a camisa pelas empresas … Uma boa parte das empresas só visam o lucro a curto prazo e não se importam muito com a qualidade dos sistemas que vendem … :?

edit: Faça das minhas palavras as mesmas do Roger75 :wink:

luiscesarinfo

Se os diretores estão cientes dos problemas que implicam essa customização e ainda sim querem que você o faça, então não acho que você tenha como falar não. Seria insubordinação. A não ser que tecnicamente, não seja possível realizar essas alterações. Aí você terá argumentos para embasar sua negativa.

Mande email “com cópia para todo mundo” documentando suas preocupações e a decisão dos seus gestores.

Minha opinião.

[]'s

Polverini

WRYEL:
Interessante pergunta, a um ano atrás eu me faria a mesma, porém, não sei se é a decisão mais certa que eu tenho tomado … Daqui pra frente eu apenas alerto e quando possível tento dar uma solução melhor para os possíveis problemas “e” dos problemas que de fato que vão ocorrer, e caso eles ocorra, a culpa não será minha. Foi se a época que por aqui você podia vestir a camisa pelas empresas … Uma boa parte das empresas só visam o lucro a curto prazo e não se importam muito com a qualidade dos sistemas que vendem … :?

edit: Faça das minhas palavras as mesmas do Roger75 :wink:

Concordo, mostra a melhor solução e a M**** que pode dar usando o XGH, ai eles que decidam!

Luiz_Aguiar

Afinal oq importa é o dinheiro né?! Então pode-se fazer qualquer porcaria por dinheiro e quem comprar que se lasque.

Ai depois ficam “xingando muito no twitter” quando o banco online não funciona, quando o sistema de telefonia manda fatura errada, quando net muda a velocidade da sua conexão por engano… e assim caminha a humanidade capitalista.

[]s

fabiocsilva

O ideal seria pedir para refazer o sistema de maneira apropriada. Provavelmente eles não vão aceitar, mas já passei por uma situação semelhante e recebi sinal verde(com um prazo apertadíssimo, é claro) para a nova versão. Caso não tenha jeito, procure deixar da maneira mais clara possível que não foi uma decisão sua continuar com o projeto. Se for possível veja até se tem como assinar um documento. Digo isso porque gerente não escreve código, logo a responsabilidade vai cair na sua mão…

moacirjava

Luiz Aguiar:
Afinal oq importa é o dinheiro né?! Então pode-se fazer qualquer porcaria por dinheiro e quem comprar que se lasque.

Ai depois ficam “xingando muito no twitter” quando o banco online não funciona, quando o sistema de telefonia manda fatura errada, quando net muda a velocidade da sua conexão por engano… e assim caminha a humanidade capitalista.

[]s

Foda né…

Realmente pagando bem que mal tem. A única coisa que me chateia é a forma com a qual ficam referindo depois, tipo, “fulano é quem fez… chama o fulano a culpa é dele… ah fulando que se vire quem mandou fazer assim…”

finotti

Infelizmente a maioria das empresas que eu conheço trabalham dessa forma.
Já passei muita raiva com a postura de alguns gerentes/diretores em algumas empresas onde trabalhei. Hoje em dia, alerto o gerente sobre o problema e fico com a consciência tranquila. A decisão de vender ou não um sistema mal feito foge do meu escopo. Então, cada um com seus problemas… Sei que vai ser ruim dar manutenção e/ou acrescentar novas funcionalidades ao sistema gambiarrado, mas são os ossos do ofício.

moacirjava

wellington.nogueira:
Esse tópico é esclarecedor
http://www.guj.com.br/java/243635
Olhe com cuidado para os itens: 8, 10. Mas não se esqueça de ler os demais. Creio que teu projeto deva se encaixar ;)

Realmente a urgência das modificações seguiram essa metodologia.

moacirjava

Luiz Aguiar:
Afinal oq importa é o dinheiro né?! Então pode-se fazer qualquer porcaria por dinheiro e quem comprar que se lasque.

Ai depois ficam “xingando muito no twitter” quando o banco online não funciona, quando o sistema de telefonia manda fatura errada, quando net muda a velocidade da sua conexão por engano… e assim caminha a humanidade capitalista.

[]s

Gostei da sua colocação!

adriano_si

A situação é complicada, mas creio que as coisas devam realmente serem colocadas no papel, que é assim que esse tipo de empresa funciona, quase como um contrato mesmo.

Como alguns colegas falaram, depois a bagaça cai no teu colo e ninguém lembra que foi avisado previamente, todo mundo vem te perguntar o que aconteceu de errado e a culpa passa a ser tua…

Sério, se for pra fazer, jogue a responsabilidade para quem realmente a tem.

“Pagando bem, que mal tem”… seguindo essa lógica, transforme-se em assassino de aluguel Moacir, paga melhor e o trabalho sujo não precisa de manutenção… heuehueheuehueheueheuheueh

Abs []

moacirjava

Boa.

R

Luiz Aguiar:
Afinal oq importa é o dinheiro né?! Então pode-se fazer qualquer porcaria por dinheiro e quem comprar que se lasque.

Ai depois ficam “xingando muito no twitter” quando o banco online não funciona, quando o sistema de telefonia manda fatura errada, quando net muda a velocidade da sua conexão por engano… e assim caminha a humanidade capitalista.

[]s

E ele faz oq então,perde o emprego?

douglaskd

é cara…acho que você tem que ficar ligeiro…

adriano_si

raf4ever:
Luiz Aguiar:
Afinal oq importa é o dinheiro né?! Então pode-se fazer qualquer porcaria por dinheiro e quem comprar que se lasque.

Ai depois ficam “xingando muito no twitter” quando o banco online não funciona, quando o sistema de telefonia manda fatura errada, quando net muda a velocidade da sua conexão por engano… e assim caminha a humanidade capitalista.

[]s

E ele faz oq então,perde o emprego?

Não é o caso… o que é discutido é o simples fato de cagar e andar para o problema desde que estejam pagando por isso…

Isso é leviano e na minha opnião totalmente anti-profissional. Não a toa, nossa profissão é marginalizada e depois muitos desenvolvedores ficam P. da vidas quando são chamados de peões…

Ser profissional é ir muito além do quanto se paga, ser profissional é ser responsável, principalmente para com o trabalho que se entrega… Porque não perder o emprego ?? eu pergunto que futuro há em uma empresa onde um profissional diz que um trabalho está porco e ainda assim o gerente manda fazer e entregar porco mesmo ???

Enfim…

R

adriano_si:
raf4ever:
Luiz Aguiar:
Afinal oq importa é o dinheiro né?! Então pode-se fazer qualquer porcaria por dinheiro e quem comprar que se lasque.

Ai depois ficam “xingando muito no twitter” quando o banco online não funciona, quando o sistema de telefonia manda fatura errada, quando net muda a velocidade da sua conexão por engano… e assim caminha a humanidade capitalista.

[]s

E ele faz oq então,perde o emprego?

Não é o caso… o que é discutido é o simples fato de cagar e andar para o problema desde que estejam pagando por isso…

Isso é leviano e na minha opnião totalmente anti-profissional. Não a toa, nossa profissão é marginalizada e depois muitos desenvolvedores ficam P. da vidas quando são chamados de peões…

Ser profissional é ir muito além do quanto se paga, ser profissional é ser responsável, principalmente para com o trabalho que se entrega… Porque não perder o emprego ?? eu pergunto que futuro há em uma empresa onde um profissional diz que um trabalho está porco e ainda assim o gerente manda fazer e entregar porco mesmo ???

Enfim…

Concordo contigo,mas repito minha pergunta.

ViniGodoy

Sim, já me recusei a fazer alguns trabalhos. Até porque, seus mesmos diretores irão exigir que você dê garantias após a entrega do produto, que vc não poderá dar.

Eu prefiro deixar claro para eles também o custo que isso está representando. Mostre que as manutenções nesse sistema são caras e onerosas, e quantifique em horas de trabalho o tempo necessário para correção de bugs e a frequência que eles ocorrem.

Para falar com administradores, use a lingua dos administradores: planilhas de custos, prazos e horas.

R

ViniGodoy:
Sim, já me recusei a fazer alguns trabalhos. Até porque, seus mesmos diretores irão exigir que você dê garantias após a entrega do produto, que vc não poderá dar.

Eu prefiro deixar claro para eles também o custo que isso está representando. Mostre que as manutenções nesse sistema são caras e onerosas, e quantifique em horas de trabalho o tempo necessário para correção de bugs e a frequência que eles ocorrem.

Para falar com administradores, use a lingua dos administradores: planilhas de custos, prazos e horas.

Isso depende muito também da situação do profissional,vc é experiente e conhece o “jogo”,como fica um estagiário/iniciante numa situação dessas?

Luiz_Aguiar

Sim… ele não perde o emprego… ele vai procurar uma empresa mais decente para trabalhar, simples assim.

já passei casos reais assim que realmente a primeira opção que parecia era ser demitido, mas a empresa acabou revendo vários conceitos de trabalho e de como lidar com seus projetos e clientes… mas isso seve ser um caso mais de exceção do que regra.

[]s

rogelgarcia

Ninguém comentou sobre … mas

Não recomendo fazer isso não… basicamente o que você estará fazendo é: Olha todo mundo… a porcaria que os gestores tão querendo fazer!

R

rogelgarcia:
Ninguém comentou sobre … mas

Não recomendo fazer isso não… basicamente o que você estará fazendo é: Olha todo mundo… a porcaria que os gestores tão querendo fazer!

Tambem conhecido como jogar a m*** no ventilador rss

rogelgarcia

Exatamente!. hehehe

As pessoas não costumam gostar de quem faz isso… principalmente em uma empresa ruim.

Apesar de que dá vontade… dá

johnny_quest

Mas é melhor mandar um email para todos os gerentes, avisando de que eles tem uma bomba em mãos,
do que não falar nada e a bomba ficar em suas mãos. Isso somente é uma prova de que não foi por
falta de aviso que uma hora a situação iria ficar complicada.

O problema é quando você envia o email, avisa todo mundo, e quando a bomba depois explode(projeto atrasa, baixa qualidade),
o gerente chega em você e simplesmente diz que isso não era para ter acontecido, que paga seu salário para não ter
esses problemas,

mas quando você tentou melhorar o código, avisando que iria ter problemas, esse mesmo gerente falou que qualidade era perda de tempo e dinheiro.

A solução nesses casos é procurar outra empresa melhor, conforme já disseram isso.

D

Dá uma respirada funda.

Tá sentindo o cheiro?

Eu to sentindo daqui o cheiro da merda.

ÓBVIO, QUE VAI DAR MERDA CAPITÃO.

Cara a coisa já começa toda errada quando não se respeita o cliente. A nossa mentalidade (da área como um todo) está toda errada. Não existe preocupação com o cliente, existe preocupação com o prazo e acham que isso é respeitar o cliente. Entregou foda-se, fatura e já era.

10 entre 10 clientes preferem que se atrase a entrega mas que seja entregue um sistema decente, em vez de entregar “no prazo” (utopia) cheio de bugs nojentos.

Isso pq o cliente nem vê o código por dentro.

Isso pq o cliente dificilmente sabe se o sistema está rápido ou pesado pois não tem essa referência.

Cara não tenho dados para afirmar isso com precisão, mas acredito que os entregáveis gerados hoje no mercado como um todo estão bem abaixo de um padrão mínimo de qualidade. Gambiarras imperam.

Já passei por uma situação dessas como a do autor do tópico, de ter que mexer em sistema podre, direto no cliente, etc…fiz o que dava.

Claro que poderia melhorar absurdamente o sistema com calma depois, mas levaria meses, nem citei pq sabia que não teria budget para isso e nem interesse da empresa que represento, o que é um absurdo, produto podre no mercado.

Esse negócio de que os gerentes autorizaram e depois a culpa não é sua é balela. É seu nome que estará lá no controlador de versão amigão, daqui 6 meses quando alguém mexer nos fontes nem vão olhar quem fez a merda desde o começo, o último que mexeu foi você, a culpa é sua, é teu nome se queimando.

É que não temos muita escolha, mas tendo o poder da escolha, entrar em projeto porco nunca é uma boa. Como eu disse é seu nome que está lá no projeto, no project, no histórico, em qualquer lugar. Não importa se tem o nome de mais 10 desenvolvedores, eu NÃO gosto de ver meu nome em projeto que não dá certo. Depois quando o cliente bate o pau na mesa violentamente e a bomba estoura em um diretor fodão ou no presidente da sua empresa, ninguém quer saber quem errou o IF amigão, o efeito cascata vem legal, você se queima em 2 lugares, na sua empresa e fecha uma porta no cliente também pois sempre tem a possibildade de um dia vc ir pra lá. Acontece aos montes de atuar em um projeto do cliente X via consultoria e depois “virar cliente”. Só que quando dá uma merda dessas esquece. Torça ainda para nunca pedirem recomendação sua lá.

Quer pegar essa bucha de canhão pega, mas faça um dossiê detalhado antes e deixe bem claro, antecipe a merda que vai dar, pq vai dar, cliente besta só conheci um até hoje que não reclamava de nada.

ViniGodoy

Ele provavelmente vai ter alguém técnico que poderá dar respaldo. Basta chamar esse colega, e pedir para ele explicar para o chefe.
Se o iniciante está sozinho no projeto, então ele é o único responsável, e deve agir como tal. A palavra dele é lei, e é obrigação dele sinalizar o problema.

Eu dificilmente recuso uma implementação, só em casos muitíssimo críticos. Mas nos casos feios é sempre bom deixar a chefia bem alerta e deixar claro o quanto isso está custanto. Não é incomum vc ter que manter um projeto ruim por algum tempo, até que chefia decida refaze-lo.

johnny_quest

Recusar uma implementação ainda não.

Mas já cheguei a falar para os gerentes que a forma com que o projeto está mal estruturado irá
impactar diretamente na produtividade.

Por exemplo, semana passada recebi um projeto para corrigir vários bugs,
mas para se testar qualquer correção é um parto nesse projeto, pois nem o administrador consegue
acessar as telas do sistema, e no final para somente corrigir um erro, praticamente se precisa
pedir a benção do papa, mudar registros em 8 tabelas, cadastrar informações em 3 telas diferentes,
fora que o arquiteto ainda tem que analisar a requisição para ver se permite que o usuário pode ter autorização de acesso à tela
com bug.

Esse projeto é extremamente burocrático e engessado, e falei para o arquiteto que modelou esse projeto que somente irei corrigir
os problemas quando disponibilizar contas com autorização de acesso.

Mas eu tomei essa atitude para mostrar que não é possível ser produtivo, e para que não me cobrem depois pela minha demora em disponibilizar as correções.

josenaldo

Assumir responsabilidade requer coragem. Uma vez que você diz não, tem que dar algo em troca. Diga que não vai fazer X, mas que vai fazer Y. E faça bem feito. Assim, com o tempo, você vai ter o respeito de seus diretores.

Eu já disse não várias vezes. Não faço e pronto. Nego já me pediu até coisa ilegal. E eu disse não.

E quer saber porque?

Porque depois ninguém vai lembrar que o diretor mandou fazer assim. Depois, a culpa é minha. Quando der merda, eu perderei o emprego, não por ter se recusado a fazer errado, mas por ter feito muito errado.

Meus colegas, no futuro, vão se lembrar apenas que eu é que fiz a merda. O cliente, vai lembrar é de mim. É meu nome que estará no commit.

Se eu posso errar? Claro que sim. Mas que não seja de propósito.

Se algum diretor já veio me dizer pra fazer ou vou pra rua? Várias vezes. Em todas elas eu dei a mesma resposta: então manda. Mas errado não faço. Vou fazer do jeito certo. E se o que eu vou fazer der errado, pode me mandar embora.

Quantas vezes eu fui pra rua: 0.
Quantas vezes eu ouvi “bem que você falou” ou “não acredito que você estava certo” ou algo do tipo: várias.

Se for pra sair, que seja por querer fazer o certo.

E quanto a “se pagar bem que mal tem”, façam-me um favor: lembrem-se disso e calem a boca antes de querer reclamar de algum político de roubando. Afinal de contas, corrupção tá pagando bem, então, que mal tem?

moacirjava

Sim… ele não perde o emprego… ele vai procurar uma empresa mais decente para trabalhar, simples assim.
Concordo. Não perde o emprego, arranja outro melhor ;)

Já fiz isso uma vez. A antiga empresa que trabalhei tinhamos 3 produtos: 1 só um cliente usava e os outros 2 tinhamos vários clientes todos reclamavam de atualizações que faziam rotinas pararem de funcionar. Comecei a ficar extramente chatiado com aquilo e disse várias vezes que o produto precisava ser restruturado. Não me deram muito ouvidos e sim mais responsabilidades. Fui embora…

maior_abandonado

dizer não ou ceder é uma questão de opinião, e as consequencias disso com certeza vão variar de ambiente para ambiente…

tem lugares que se você disser não vai ser mandado embora sim…

se você disser não, tenho embasamento nos motivos, seja bem categórico e fixo na sua opinião.

se você disser sim, deixe bem claro as consequências disso, por e-mail (não precisa copiar todos, mas copie todos os envolvidos), e preferencialmente deixe comentários de código também afirmando que foi feito dessa forma devido a especificação e que a alteração da mesma não foi permitida…

sim… isso é comum…

peerless

Achei que o trabalho de desenvolvedores de software fosse desenvolver software. :roll:

Está ruim? Coloca uns testes na sua alteração e vai corrigindo os elementos envolvidos nela (e, óbvio, coberto por testes também).

Falar que está ruim é muito, mas muito fácil. Não existe sistema “cheirando” flores no mercado e se tem, é até o primeiro criador de gambiarra colocar a mão no código. O problema nao eh o capitalismo como disseram lah para tras, mas sim os gambiarreiros do dia-a-dia.

kicolobo

É tudo uma questão de responsabilidade profissional.

É falta de responsabilidade profissional pra dizer o mínimo. Se uma implementação é porca, e vai gerar problemas para o seu cliente, você SABE disto, e mesmo assim faz, é sinal de que está cagando e andando pra quem está pagando suas contas e, ao menos inicialmente, CONFIOU no seu trabalho.
É quebra de confiança.

Me pergunto: será que a mesma pergunta pode ser aplicada a outras áreas, como por exemplo medicina ou engenharia civil?

Para um médico:
“Você já recusou fazer algum procedimento cirurgico?”

Para um engenheiro civíl:
“Você já recusou construir algo com base num cálculo estrutural mal feito?”

Na boa? Se continuarmos com esta postura cretina do “pagando bem que mal tem?”, no futuro (ou melhor, hoje mesmo) ninguém vai poder reclamar de falta de respeito profissional relacionada à nossa área.

Abram o olho.

L

kicolobo:
É tudo uma questão de responsabilidade profissional.

É falta de responsabilidade profissional pra dizer o mínimo. Se uma implementação é porca, e vai gerar problemas para o seu cliente, você SABE disto, e mesmo assim faz, é sinal de que está cagando e andando pra quem está pagando suas contas e, ao menos inicialmente, CONFIOU no seu trabalho.
É quebra de confiança.

Me pergunto: será que a mesma pergunta pode ser aplicada a outras áreas, como por exemplo medicina ou engenharia civil?

Para um médico:
“Você já recusou fazer algum procedimento cirurgico?”

Para um engenheiro civíl:
“Você já recusou construir algo com base num cálculo estrutural mal feito?”

Na boa? Se continuarmos com esta postura cretina do “pagando bem que mal tem?”, no futuro (ou melhor, hoje mesmo) ninguém vai poder reclamar de falta de respeito profissional relacionada à nossa área.

Abram o olho.

Mandou bem.

(Eu que já me ferrei porque insisti em implementar uma coisa porca. Aprendi muito com essa cagada)

Y

wellington.nogueira:
peerless:
Achei que o trabalho de desenvolvedores de software fosse desenvolver software. :roll:

Está ruim? Coloca uns testes na sua alteração e vai corrigindo os elementos envolvidos nela (e, óbvio, coberto por testes também).


Assim é fácil de falar :wink: . Porém alguém tem que pagar a conta pelo refactoring e essa é a questão, não o como fazer.
Há refactorings que poucas horas resolvem e outros que precisam de dias, semanas, meses para serem corrigidos. Para o que custa poucas horas, sua sugestão atende. Mas e quando o tempo necessário passar de dias, semanas ou (pior dos casos) meses? Alguém tem que assumir o custo da correção/adequação pois o profissional encarredado de acertar terá que dispor do tempo para novas features para acertar o sistema e, normalmente, o cliente não paga por isso (se não for convencido). Essa questão passa a ser gerencial (ser gerencial não quer dizer, necessariamente, ser uma decisão do gerente :roll: ).

Ninguem se preocupa com quem esta pagando a conta quando se leva quatro horas pra fazer uma alteracao que poderia ser feita em uma se tivesse um codigo organizado.

Eu ouco esse “ah, mas tem que resolver rapido” todo dia, e cada vez que eu ouco isso eu tenho certeza que cada vez vai demorar mais pra se implementar qualquer coisa nesse ponto que tinha que ser resolvido rapido.

Em tempo, refactoring nao eh revolucao, refactoring sao pequenas alteracoes que podem ser feitas sem muito impacto, sem muita dor de cabeca. Voce nao precisa mexer no sistema inteiro pra extrair um metodo, renomear uma variavel, separar um pouco as responsabilidades. E quando voce tiver que fazer um grande alteracao aí sim voce refatora antes de alterar. Acredite refatorar pra depois arrumar é mais rapido em 90% dos casos.

Se usar da lei do escoteiro proposta pelo tio Bob as coisas vao melhorando bastante no codigo com o tempo: “Sempre suba um codigo melhor do que o que voce baixou”. Nem que seja uma variavelzinha com nome melhor, mas sempre melhore um pouco.

WellingtonRamos

Esse tópico é esclarecedor


Olhe com cuidado para os itens: 8, 10. Mas não se esqueça de ler os demais. Creio que teu projeto deva se encaixar :wink:

WellingtonRamos

Sim… ele não perde o emprego… ele vai procurar uma empresa mais decente para trabalhar, simples assim.
Concordo. Não perde o emprego, arranja outro melhor :wink:

WellingtonRamos

raf4ever:
ViniGodoy:
Sim, já me recusei a fazer alguns trabalhos. Até porque, seus mesmos diretores irão exigir que você dê garantias após a entrega do produto, que vc não poderá dar.

Eu prefiro deixar claro para eles também o custo que isso está representando. Mostre que as manutenções nesse sistema são caras e onerosas, e quantifique em horas de trabalho o tempo necessário para correção de bugs e a frequência que eles ocorrem.

Para falar com administradores, use a lingua dos administradores: planilhas de custos, prazos e horas.

Isso depende muito também da situação do profissional,vc é experiente e conhece o “jogo”,como fica um estagiário/iniciante numa situação dessas?

Se é um estagiário/iniciante é quem está sinalizando isso, há algo realmente errado em todo o processo desse projeto.
Isso não é atribuição de um estag/iniciante. Se apenas ele está levantando a bandeira de fazer algo melhor, significa que ele deve trocar para um emprego melhor antes de contaminar-se com tudo que está errado a sua volta ou “ser limado” por reclamar demais :roll: .

WellingtonRamos

peerless:
Achei que o trabalho de desenvolvedores de software fosse desenvolver software. :roll:

Está ruim? Coloca uns testes na sua alteração e vai corrigindo os elementos envolvidos nela (e, óbvio, coberto por testes também).


Assim é fácil de falar :wink: . Porém alguém tem que pagar a conta pelo refactoring e essa é a questão, não o como fazer.
Há refactorings que poucas horas resolvem e outros que precisam de dias, semanas, meses para serem corrigidos. Para o que custa poucas horas, sua sugestão atende. Mas e quando o tempo necessário passar de dias, semanas ou (pior dos casos) meses? Alguém tem que assumir o custo da correção/adequação pois o profissional encarredado de acertar terá que dispor do tempo para novas features para acertar o sistema e, normalmente, o cliente não paga por isso (se não for convencido). Essa questão passa a ser gerencial (ser gerencial não quer dizer, necessariamente, ser uma decisão do gerente :roll: ).

WellingtonRamos

YvGa:
wellington.nogueira:
peerless:
Achei que o trabalho de desenvolvedores de software fosse desenvolver software. :roll:

Está ruim? Coloca uns testes na sua alteração e vai corrigindo os elementos envolvidos nela (e, óbvio, coberto por testes também).


Assim é fácil de falar :wink: . Porém alguém tem que pagar a conta pelo refactoring e essa é a questão, não o como fazer.
Há refactorings que poucas horas resolvem e outros que precisam de dias, semanas, meses para serem corrigidos. Para o que custa poucas horas, sua sugestão atende. Mas e quando o tempo necessário passar de dias, semanas ou (pior dos casos) meses? Alguém tem que assumir o custo da correção/adequação pois o profissional encarredado de acertar terá que dispor do tempo para novas features para acertar o sistema e, normalmente, o cliente não paga por isso (se não for convencido). Essa questão passa a ser gerencial (ser gerencial não quer dizer, necessariamente, ser uma decisão do gerente :roll: ).

Ninguem se preocupa com quem esta pagando a conta quando se leva quatro horas pra fazer uma alteracao que poderia ser feita em uma se tivesse um codigo organizado.

Eu ouco esse “ah, mas tem que resolver rapido” todo dia, e cada vez que eu ouco isso eu tenho certeza que cada vez vai demorar mais pra se implementar qualquer coisa nesse ponto que tinha que ser resolvido rapido.

Em tempo, refactoring nao eh revolucao, refactoring sao pequenas alteracoes que podem ser feitas sem muito impacto, sem muita dor de cabeca. Voce nao precisa mexer no sistema inteiro pra extrair um metodo, renomear uma variavel, separar um pouco as responsabilidades. E quando voce tiver que fazer um grande alteracao aí sim voce refatora antes de alterar. Acredite refatorar pra depois arrumar é mais rapido em 90% dos casos.

Se usar da lei do escoteiro proposta pelo tio Bob as coisas vao melhorando bastante no codigo com o tempo: “Sempre suba um codigo melhor do que o que voce baixou”. Nem que seja uma variavelzinha com nome melhor, mas sempre melhore um pouco.


Concordo plenamente contigo. Infelizmente, uma vez o código mal feito, precisa cada vez mais de pequenas alterações e essa soma de pequenas alterações pode se tornar uma grande alteração. É como um cancer, se pego no estágio inicial, é fácil curar 99% dos casos, mas se deixamos de lado, vai se espalhando e tornando-se cada vez mais complicado acertar.
Mas não há duvidas de que deve-se “refatorar” antes de alterar :wink: dá menos trabalho.

Criado 21 de junho de 2011
Ultima resposta 28 de jun. de 2011
Respostas 38
Participantes 22