Há um mês troquei de empresa. Saí de uma empresa pequena que tem uma preocupação grande com a qualidade (tanto de codificação quanto de “produto final” – o que o cliente vê) e fui para uma empresa maior, mas menos preocupada com a qualidade do código.
Essa empresa onde estou agora não se importa, por exemplo, se o CSS que está sendo usado na página tem 100 ou 1000 linhas. Não se importa se o projeto está utilizando versionamento ou se foi feito backup. Dá até pra cometer o gravíssimo erro de colocar informações de sessão expostas no cookie que ninguém percebe, pois ninguém valida e revisa o código.
E típica empresa onde os gerentes chegam e cobram resultados que invariavelmente são urgentes. O famoso “faz funcionar”. Como estou começando, me dão manutenção pra fazer (em projetos já entregues) e essa manutenção é em cima de um código feio, não documentado (e não comentado)… um código que mistura a view com a regra do negócio, que possui métodos com centenas de linhas… enfim, quase sempre são códigos horríveis de dar manutenção – e devido a essas características, atrasos são muito frequentes. No entanto as pessoas hierarquicamente acima de mim não estão nem um pouco preocupadas com a qualidade interna do projeto. Querem apenas o resultado e querem que fique bom para o cliente. E no prazo estipulado.
Eu constantemente fico receoso de o meu futuro nessa empresa estar comprometido (leia-se: tenho receio de ser demitido) por conta dessa herança maldita, de metodologias inexistentes, de uma programação às vezes gambiarrenta e outras vezes complicada demais quando deveria ser simples (para terem uma ideia, hoje eu passei o dia todo tentando submeter um conjunto de checkboxes para o controller (tarefa trivial e simples!), porque a forma como a query estava montada… dava vontade de apagar tudo e começar do zero ao invés de implementar em código bagunçado).
Enfim, acho que já passei a mensagem. Gostaria de saber como é o dia-a-dia na empresa de vocês e como lidam com a pressão de pessoas que não sabem nada do aspecto técnico e se preocupam simplesmente em cobrar por erroneamente acharem que a culpa de a coisa andar lentamente é do desenvolvedor atual e não do infeliz que concebeu tudo torto inicialmente.
Pois é cara, nem todo local se preocupa com o produto mas apenas com o resultado.
Eles querem que esteja pronto mas sem qualidade. Mas também querem que não aconteçam erro algum.
Infelizmente é assim em muitos lugares. O jeito é tocar a vida e continuar estudando. [=
Para um dia tu pegar um lugar melhor. [=
P
perdeu
tenta refatorar alguma coisas, vai demora mais pra vc organizar o codigo e tal ja outras tem q se reescitas mesmo. haha vc trabalha com asp classico?
A
AbelBueno
É dificil mudar a mentalidade das pessoas.
Se seus chefes acreditam que essa é a melhor forma de desenvolver, sobra pouco que você possa fazer.
Recomendo que troque de empresa novamente.
E dessa vez você já tem um item a mais na hora de escolher.
Y
YvGa
Bom, esse eh o mundo real para a maioria de nos.
AbelBueno:
É dificil mudar a mentalidade das pessoas.
Se seus chefes acreditam que essa é a melhor forma de desenvolver, sobra pouco que você possa fazer.
Recomendo que troque de empresa novamente.
E dessa vez você já tem um item a mais na hora de escolher.
Discordo completamente. A culpa nao eh dos chefes, a culpa eh nossa, desenvolvedores, que fazemos porcarias de codigo pra todo lado e temos o habito de por a culpa nas pancadas dos gerentes nas mesas.
Codigo bom eh mais rapido, mais produtivo, mais eficiente e mais lucrativo do que codigo ruim. Entao nenhum chefe/diretor/gerente prefere codigo ruim.
O ponto eh que eles ja estao fartos de ouvir essa conversa de codigo bom, codigo bonito, design patterns, blablabla, e na hora do pega pra capar, a produtividade eh baixa e a resultado pessimo.
O ponto eh, se voce mudar de empresa, muito provavelmente vai cair em outra como essa, e depois outra e outra e outra e assim por diante. Nenhuma empresa das que dao valor a qualidade de codigo e todas essas coisas darao chance a alguem que nao sabe como fazer quando pega uma aplicacao ruim.
O meu conselho é: relaxe, faça seu trabalho, voce nao foi o primeiro, nem será o ultimo a mexer nessa aplicacao ai, entao eles ja tem uma boa nocao de quanto tempo leva pra alguem se adaptar a ela. Se voce nao esta conseguindo, procure ajuda, pergunte aos outros, nao assuma a posicao: “ah eu nao vou mexer nessa porcaria.” Nao me leve a mal, mas voce ja deveria saber o que fazer quando pega codigo ruim pela frente, ja devia saber como refatorar e trabalhar nele aos poucos para melhorar a qualidade. E mesmo assim nao deixar a produtividade de lado.
Continue estudando, sempre, porque vai precisar. Se eles te demitirem, paciencia, voce arruma outra coisa, mas tente.
V
victorcosta
Código ruim tem em todo projeto trabalhado por vários programadores e com certa complexidade e prazo apertado. Acostume-se com isso. Dificilmente alguém vai fazer o código ideal de primeira quando está programando algo que nunca fez antes. E aí se ele não tem tempo pra refatorar depois fica o código feio lá…
Tem tempo disponível? Refatore. Não tem? Faça mais um POG que faça funcionar oq vc quer. Importante é deixar o cliente ou gerente feliz. Pelo menos eu penso assim…
Se não quer enfrentar isso vai ter que procurar uma empresa onde os projetos não tenham prazo apertado, os programadores já tem experiência no que fazem e se preocupam com a qualidade do código. Mas isso é difícil achar…
I
Ironlynx
++!
Não adianta ficar reclamando do codigo ruim.E muitas vezes, quando se faz algo novo, o codigo e de pessima qualidade.Acabei de refatorar um codigo de uma importação de dados que tinha quase 3mil linhas.Com as 100 atuais ja acho grande o bastante.
htraos,
as situações por descritas são mais do que normais.E não reclame de codigo CSS com 1000 linhas.Quer algo pior?Pegue esse mesmo codigo CSS, e ao inves de por num arquivinho isolado, o cara copiou e colou em 200 paginas html…imagine que seu gerente quer a mudança do design em 1 hora… :roll:
P
PoneyMan
htraos:
Boa noite.
Há um mês troquei de empresa. Saí de uma empresa pequena que tem uma preocupação grande com a qualidade (tanto de codificação quanto de “produto final” – o que o cliente vê) e fui para uma empresa maior, mas menos preocupada com a qualidade do código.
Empresa pequena normalmente é mais fácil manter a qualidade do código pq os sistemas são poucos, a equipe é pequena, e as folgas que aparecem ou cobrança por prazo não é tão grande assim.
Temos programadores pra que ? Se eles já não implementam direito, a culpa não é da empresa…
Quem tá com a mão na massa é o pedreiro (programador). Se ele vê que determinado bloco está ruim, que coloque outro e continue a levantar o muro (projeto).
Agora esperar que o engenheiro fique monitorando isto e tenha esta obrigação é demais.
Da mesma forma o CSS ou outra peça de software. Todo o código é de responsabilidade do programador. Se está uma merda, a culpa é dele.
Mas isto é assim na maioria dos lugares, inclusive onde trabalho. É coisa natural, não sei pq vc estranha. Imagino q deve ter pouca idade e pouca experiencia profissional.
Se meu gestor me pede algo, ele vem, combina comigo o prazo e sou responsável por dizer quanto tempo vai levar.
A partir daí ele está certo em me cobrar pelo prazo, pois combinamos juntos, portanto não foi imposto, mas tb não foi definido por mim.
Cabe a mim, fazer o melhor dentro deste prazo que combinamos, pois existem outros na equipe que também dependem do meu trabalho e se eu atraso, atraso os outros.
Novamente te digo, isto é o comum por aí. Pegar projeto já feito para dar manutenção e achar que vai encontrar 15 design patterns implementados é ser muito inocente.
Te digo mais…já vi programador que odeia comentar código e programa assim, sem nada mesmo, apenas código.
Ele e somente ele é responsável por deixar isto para as gerações futuras.Quer brigar com alguém de ter que enfretar o inferno para entender a lógica da app ?
Busca esse safado no inferno !
Eu sou a favor do código comentado, mas tem gente que não é e estes quando pegam sistemas que mantenho, adoram, pq o código + comentários ajudam em muito a eles não terem que ficar perguntando o que é o que no projeto.
Dica: Só tente consertar o que está cagado se você tiver tempo no seu prazo ou se isto decididamente não oferece risco ao cumprimento do cronograma.
Se vc não se acostumar a consertar o avião durante o voô, não só seu futuro ai na empresa estará comprometido como em qualquer outro lugar!
Volto a te dizer: De nada adianta código lindo se o prazo foi estourado. O custo do seu atraso em entregar a tarefa pode ser muito maior que vc pensa.
Não necessariamente, os seus pares ou chefe irá querer conversar abertamente sobre isto com vc, mas com certeza vc perceberá o efeito quando alguém for fired.
Pra chegar no ponto do burn, o programador já deve ter pisado na bola algumas vezes.
htraos:
Enfim, acho que já passei a mensagem. Gostaria de saber como é o dia-a-dia na empresa de vocês e como lidam com a pressão de pessoas que não sabem nada do aspecto técnico e se preocupam simplesmente em cobrar por erroneamente acharem que a culpa de a coisa andar lentamente é do desenvolvedor atual e não do infeliz que concebeu tudo torto inicialmente.
Dica 2: Manda quem pode, obedece quem tem juízo.
Eu não questiono meu chefe sobre algumas coisas pois confio e acredito que suas decisões são as melhores com o conjunto de informações que tem.
Cabe a você tb não ficar pelos cantinhos reclamando e chorando e conversar com a chefia quando possível.
Se vc não mostra adequadamente a situação que tem para consertar, como espera que ele entenda e até rediscuta prazos ?
Quando digo mostrar adequadamente, é vc estudar a encrenca antes e na hora de conversar, saber apresentar as informações de forma correta, sem ser tendenciosa, sem distorcer e sabendo do que está falando. Olha, tem muitos por aí que falham miseravelmente nesta parte e lógico, jogam a culpa no gerente que não lhes ouve, é autoritário, não lhe entende e todo blá-blá-blá já conhecido.
Imagino que algum aprendizado vc está tirando desta situação, até para corrigir certas idéias suas que por ventura achava que tinha razão.
Existe lugares melhores bem como piores deste que vc está. Aproveite este e siga em frente.
B
bestlinux
Sinceramente: Isso é a coisa mais normal do mundo (infelizmente)
Engraçado…você lê diversas coisas que devem ser aplicados em um projeto: testes unitarios, verificação constante da qualidade do projeto, documentação, feedback, refatoração, etc…etc…etc…e mais um monte de coisas que quando você lê parece um mundo da “Disney” em relação ao mundo que você trabalha.
Você chega pela manha para trabalhar, liga seu computador, abre sua caixa de email, e olha um email do cliente com este assunto:
Seu gestor olha para você…você olha para ele e vem a famosa frase:
“Quanto tempo demora para corrigir isso ? A mulher ta soltando fogo pela boca.”
Você pensando: “Bom, aquele código ta um lixo, vou corrigir agora, e essa merda vai dar problema de novo. Ou se alguém pegar no futuro, ta ferrado. Acho que vou levar no minimo umas 8h para refatorar aquilo e resolver o problema de uma vez por todas.”
Você falando com o seu gestor: “Ah cara, para ficar certinho…teriamos que gastar umas 8h nisso, fazer uma refatoração (jogando seu peixe para o gestor tentar engolir e aceitar a refatoração e você se sentir como um “bom profissional”), mas se for para corrigir nessa “correria” ai…umas 4h e ta resolvido (jogando seu peixe para se manter no trabalho e ganhar a estrelinha de “bom menino” com o Cliente e o com o Gestor)”
Gestor: “Blz, corrige rápido, depois a gente ve essa refatoração. Por que a mulher ta cuspindo fogo pela boca e já ta ameaçando procurar outro fornecedor”
Bom…você arruma o problema em 3h. O Gestor fica feliz, o Cliente fica feliz. O Gestor fala para o Diretor que conseguimos apagar o “Incêndio” com o Cliente.
Conclusão: Você resolveu o problema em 3h. Deixou todos os seus superiores felizes. E principalmente: Deixou o cliente feliz. E eles nem ao menos sabem o que você fez. Se você se manter assim, deixando o tempo todo o “Gestor” e “Cliente” feliz, provavelmente você ira receber um reajuste ou talvez sera promovido de cargo.
Essa é a “dura” realidade de “algumas” empresas. Mas arrisco dizer: As empresas hoje em dia buscam “bombeiros” e não “detetives” para analisar e investigar a melhor solução para o problema.
O problema é: Nessas condições que coloquei acima, quem futuramente ira ter mais beneficios($$$) dentro desta empresa: O “bombeiro” ou o “detetive” ?
Obs: Todo esse texto acima, foi um caso real.
C
CAMPEAO2011
liga no 0800
T
tguerra
victorcosta:
Código ruim tem em todo projeto trabalhado por vários programadores e com certa complexidade e prazo apertado. Acostume-se com isso. Dificilmente alguém vai fazer o código ideal de primeira quando está programando algo que nunca fez antes. E aí se ele não tem tempo pra refatorar depois fica o código feio lá…
Tem tempo disponível? Refatore. Não tem? Faça mais um POG que faça funcionar oq vc quer. Importante é deixar o cliente ou gerente feliz. Pelo menos eu penso assim…
Se não quer enfrentar isso vai ter que procurar uma empresa onde os projetos não tenham prazo apertado, os programadores já tem experiência no que fazem e se preocupam com a qualidade do código. Mas isso é difícil achar…
Isso é fato, código ruim tem realmente em todo projeto trabalho por vários programadores, pois mesmo que exista um padrão de codificação na empresa, muita gente tem “preguiça” de seguir esse padrão e simplesmente faz funcionar de qualquer maneira, afinal, em empresa grande a preocupação é em entregar para o cliente o mais rápido possível…
F
fabim
Refactoring nao é algo que vc faz pq a empresa determina. É algo que vc faz em benefício proprio.
Semana passada refatorei uma classe de 2700 linhas em 800. Tive aquele feeling de que num futuro proximo isso seria alterado.
Resultado: hoje chegou manutencao nela. Quem ganha com isso: EU.
Consigo fazer tudo em 40% do tempo e ainda da pra vir no guj responder alguns topicos
P
PoneyMan
bestlinux:
Sinceramente: Isso é a coisa mais normal do mundo (infelizmente)
…
…
…
Gestor: “Blz, corrige rápido, depois a gente ve essa refatoração. Por que a mulher ta cuspindo fogo pela boca e já ta ameaçando procurar outro fornecedor”
Bom…você arruma o problema em 3h. O Gestor fica feliz, o Cliente fica feliz. O Gestor fala para o Diretor que conseguimos apagar o “Incêndio” com o Cliente.
Conclusão: Você resolveu o problema em 3h. Deixou todos os seus superiores felizes. E principalmente: Deixou o cliente feliz. E eles nem ao menos sabem o que você fez. Se você se manter assim, deixando o tempo todo o “Gestor” e “Cliente” feliz, provavelmente você ira receber um reajuste ou talvez sera promovido de cargo.
Essa é a “dura” realidade de “algumas” empresas. Mas arrisco dizer: As empresas hoje em dia buscam “bombeiros” e não “detetives” para analisar e investigar a melhor solução para o problema.
O problema é: Nessas condições que coloquei acima, quem futuramente ira ter mais beneficios($$$) dentro desta empresa: O “bombeiro” ou o “detetive” ?
Obs: Todo esse texto acima, foi um caso real.
Parabéns !
Conseguiu passar fielmente como é realmente a vida.
Detetive precisamos sim, mas na maior parte do tempo é o bombeiro que entra em cena. Vai depender do prazo e urgência.
Essa é a vida. Ou ele acostuma-se ou morre perante o mercado.
I
igor_ks
No teu caso, eu seria pro-ativo e nas reunioes com os programadores eu falaria de fazer uma reuniao de boas praticas, clean code etc. Quando sobrar tempo, refatorar os codigos
Senao daqui 5/10 anos, esse sistema vai estar totalmente “imanutenivel” (nao sei se isso existe, mas da pra entender huaiehe)
S
soaresinfo
Cara, já que você é novo na empresa, não nade contra a maré. Feito isso, você tem uma ótima oportunidade nas mãos e que pode impulsionar sua carreira. Você pode tentar mudar o paradigma da empresa e criar uma organização de todo o processo de desenvolvimento. A sugestão é ir sugerindo pequenas mudanças. Assim você vai puxando a responsabilidade para você. Depois de algum tempo, se não houver muita resistência, você será o cara que organizou a TI da empresa.
B
bestlinux
Dica: Tome muito cuidado com essas palavras: “organizou a TI da empresa”.
Para você “organizar” é uma coisa, para seu gestor e seus superiores “organizar” é outra.
A
adriano_si
Não sei se sou o único maluco do mundo, mas minha dica é pra pular fora desse barco…
Não existe manutenção de avião em vôo, da feita que o Sistema lá em cima para de funcionar, a merda cai…
Produto ou empresa quem mantém Sistemas na base do apagar incêndio, tendem a terem os seus projetos fracassados.
Hoje trabalho em projeto assim e testifico 100% do que todos falaram aqui, mas não me conformo com isso, pode até “ser a música que toca atualmente”, mas com certeza não é a que quero dançar. Tanto que toda e qualquer manutenção minha, sempre vai um pequeno Refactor da solução, como não concebi a bagaça, não me sinto culpado pelo ato, mas minha chefe está ciente de que sempre que codifico, faço algum refactor, ela quis argumentar comigo quando começamos o Projeto, mas eu não arredo o pé. Código limpo hoje, embora demore mais, evita que eu apague o mesmo incêndio umas 30 vezes…
Essa semana peguei um código que estava repetido em 6 métodos diferentes dentro da mesma classe… Ou seja, 6 caras que deram manutenção no código, cada um criou o seu próprio, da forma que achava melhor, sem sequer se preocupar se já havia algo pronto no Sistema… Caracaaaaaaaa véio, nunca que vou concordar com isso, perdi 1 dia de trabalho a mais da minha tarefa colocando isso em 1 só lugar e avaliando os impactos da mudança no Sistema inteiro… ai de quem discordar… heueheuehueehu
Amanhã, serei eu de novo que vou dar manutenção nessa merda. Portanto concordo que o mercado é assim, mas cabe a nós mudarmos essa cultura…
Como o amigo acima falou, os caras estão cansados de ouvir blá blá de programador sobre refatoração e design patterns e blá blá blá… que na verdade só atrasa o projeto e não melhora em nada, mas se você sabe o que está fazendo, faça, sem medo, eu ganhei coragem e comecei a fazer, depois disso, ví que dá certo, o dia que parar de dar, parto pra outra…
Sempre haverá alguém com a cabeça igual a sua, disposto a lhe contratar… na pior das hipóteses, volte para sua antiga empresa, que é pequena, mas trabalha certo. Trabalhando certo, logo deixará de ser pequena.
É nisso que eu acredito.
Abs []
F
fabim
adriano_si:
Não sei se sou o único maluco do mundo, mas minha dica é pra pular fora desse barco…
Não existe manutenção de avião em vôo, da feita que o Sistema lá em cima para de funcionar, a merda cai…
Produto ou empresa quem mantém Sistemas na base do apagar incêndio, tendem a terem os seus projetos fracassados.
Abs []
Depende irmao. Conheco uns Sistemas “zumbis” assim que sobrevivem a mais de 5 anos e nao tem data pra acabar.
Se o cliente ta pagando, e pagando MUITO, e vc recebendo bem, quero ver largar mao disso pra ganhar MENOS por algo LINDO, com designs perfeitos num mundo Orientado a Objetos Perfeitos.
A
AbelBueno
Concordo com quase tudo o que disse, menos com esse trecho:
Acho que as empresas que valorizam qualidade de código não querem saber se você sabe lidar com aplicação ruim, querem saber se você consegue produzir qualidade.
A questão principal para mim não é nem a qualidade do código atual, mas a filosofia da empresa para o desenvolvimento dos produtos.
Apesar do código porco ser realmente culpa do programador, geralmente vem de cima uma cultura para melhorar a qualidade do código/produto.
Implantar revisão de código, teste automatizado, entre outros é visto por muitos gerentes por aí como perda de tempo.
Se essa filosofia imediatista de “faz funcionar” incomoda, recomendo sim procurar um lugar com outra cultura.
A minha esperança é que essas consultorias que ganham no projeto e na manutenção (do projeto que não funcionou) fechem as portas por falta de desenvolvedores.
Infelizmente, sempre terá aqueles que preferem ganhar o seu salário independente da qualidade do que produz.
Para mim isso é equivalente ao médico que por desleixo deixa bisturi dentro do paciente após operação…
Ou engenheiro que aceita construir prédio com areia da praia e depois vê o negócio cair.
Enquanto não formos mais críticos com relação aos empregos que escolhermos ou ao modo de desenvolvermos a realidade continuará sendo essa: código mal feito funcionando a base de remendos.
K
kicolobo
Eu lido da seguinte forma: não choro e resolvo
Simples assim.
N
neofito
boone:
Temos programadores pra que ? Se eles já não implementam direito, a culpa não é da empresa…
Quem tá com a mão na massa é o pedreiro (programador). Se ele vê que determinado bloco está ruim, que coloque outro e continue a levantar o muro (projeto).
Agora esperar que o engenheiro fique monitorando isto e tenha esta obrigação é demais.
Da mesma forma o CSS ou outra peça de software. Todo o código é de responsabilidade do programador. Se está uma merda, a culpa é dele.
Eu ia escrever um monte de coisas explicando o porquê de chamar o gerente de projeto de “engenheiro” e o programador de “pedreiro” é a coisa mais absurda q eu já vi, mas só vou escrever isto: é muito triste ouvir isso de um programador.
N
neofito
htraos:
Boa noite.
Há um mês troquei de empresa. Saí de uma empresa pequena que tem uma preocupação grande com a qualidade (tanto de codificação quanto de “produto final” – o que o cliente vê) e fui para uma empresa maior, mas menos preocupada com a qualidade do código.
Quanto as respostas anteriores, nunca ouvi tanta besteira assim na minha vida toda. É por isso que vejo tanto código maluco, projetos de R$800 mil afundando e toda sorte de maluquices nas empresas onde trabalho.
Você deve tentar convencer os gerentes que um código melhor resulta em manutenções mais rápidas, e que você vai embutir um tempo para refatoração em todas manutenções que você vai fazer. Se o gerente aceitar, ótimo. Caso contrário, encontre um outro emprego primeiro, depois pule fora. Dê preferencia a projetos onde você terá que desenvolver coisas novas, e não onde há apenas manutenção. Veja bem, eu disse preferência, sempre haverá manutenção. Normalmente as más empresas, geralmente consultorias e agências de publicidade, vendem o sistema com um prazo absurdo, entregam e depois contratam programadores para consertarem a cagada que fizeram.
Caso você consiga convencer seus superiores de que há necessidade de refatorar, vou dar algumas dicas. A primeira, e a mais importante: refatorar um sistema não é fácil. Pelo contrário, é bem difícil. Não é qualquer zé mané que conserta um sistema médio. É preciso técnica especializada e unidade da equipe em atingir esse objetivo.
Se o sistema for pequeno, a refatoração será mais fácil. No caso de um sistema médio, a mesma pode se tornar um pesadelo se as técnicas corretas não forem usadas. Primeiramente, você vai precisar do básico: sistema de controle de versão, um ambiente de homologação, etc. Depois, você vai precisar de técnica. Você vai precisar fazer testes unitários e de aceitação automatizados para garantir que você não quebre nada no sistema. Aconselho os livros abaixo: Test Driven Development: By Example The Art of Unit Testing: With Examples in .Net Working Effectively with Legacy Code
Há outros, mas esses são fundamentais.
Os testes unitários servem para você fazer o sistema crescer saudavelmente, permitem que você refatore e tenha uma resposta rápida, mas não 100% precisa, da alteração que você realizou. Os testes de aceitação servem para você testar o sistema como um todo, uma funcionalidade do início ao fim. Geralmente eu escrevo testes de aceitação e depois testes unitários.
B
bestlinux
neófito:
htraos:
Boa noite.
Há um mês troquei de empresa. Saí de uma empresa pequena que tem uma preocupação grande com a qualidade (tanto de codificação quanto de “produto final” – o que o cliente vê) e fui para uma empresa maior, mas menos preocupada com a qualidade do código.
Quanto as respostas anteriores, nunca ouvi tanta besteira assim na minha vida toda. É por isso que vejo tanto código maluco, projetos de R$800 mil afundando e toda sorte de maluquices nas empresas onde trabalho.
Você deve tentar convencer os gerentes que um código melhor resulta em manutenções mais rápidas, e que você vai embutir um tempo para refatoração em todas manutenções que você vai fazer. Se o gerente aceitar, ótimo. Caso contrário, encontre um outro emprego primeiro, depois pule fora. Dê preferencia a projetos onde você terá que desenvolver coisas novas, e não onde há apenas manutenção. Veja bem, eu disse preferência, sempre haverá manutenção. Normalmente as más empresas, geralmente consultorias e agências de publicidade, vendem o sistema com um prazo absurdo, entregam e depois contratam programadores para consertarem a cagada que fizeram.
Caso você consiga convencer seus superiores de que há necessidade de refatorar, vou dar algumas dicas. A primeira, e a mais importante: refatorar um sistema não é fácil. Pelo contrário, é bem difícil. Não é qualquer zé mané que conserta um sistema médio. É preciso técnica especializada e unidade da equipe em atingir esse objetivo.
Se o sistema for pequeno, a refatoração será mais fácil. No caso de um sistema médio, a mesma pode se tornar um pesadelo se as técnicas corretas não forem usadas. Primeiramente, você vai precisar do básico: sistema de controle de versão, um ambiente de homologação, etc. Depois, você vai precisar de técnica. Você vai precisar fazer testes unitários e de aceitação automatizados para garantir que você não quebre nada no sistema. Aconselho os livros abaixo: Test Driven Development: By Example The Art of Unit Testing: With Examples in .Net Working Effectively with Legacy Code
Há outros, mas esses são fundamentais.
Os testes unitários servem para você fazer o sistema crescer saudavelmente, permitem que você refatore e tenha uma resposta rápida, mas não 100% precisa, da alteração que você realizou. Os testes de aceitação servem para você testar o sistema como um todo, uma funcionalidade do início ao fim. Geralmente eu escrevo testes de aceitação e depois testes unitários.
:D
É…infelizmente essa não é a minha realidade. Tenho familia para sustentar. Já pensei igual a você. Se não tenho chances de “modificar” a arquitetura de desenvolvimento na empresa que trabalho (refatorar, testes unitarios, etc…etc…) vou tentar arranjar outro emprego. Porém, a maioria das empresas que eu achava que tinha o “perfeito” ambiente de trabalho, não pagavam muito bem. Por isso, estou na empresa que estou hoje e trabalhando de “bombeiro”. Mas…todo ano tenho um reajuste e em Fevereiro estarei mudando de cargo. No meu caso, veja bem, no meu “momento” hoje…não sairia daqui…só por que tem uma empresa aqui do lado…que tem a “Fantastica Fabrica de Chocolate” la dentro. Mas não é por isso…que não estudo as boas praticas e concordo com elas…caso “apareça” uma melhor oportunidade, sim…claro que gostaria de tentar.
O problema é: Ate quando você vai fazer isso ? Pular de “galho em ganho” ? Sera que isso é bem visto no mercado ?
M
maior_abandonado
bestlinux:
Sinceramente: Isso é a coisa mais normal do mundo (infelizmente)
…
…
…
Gestor: “Blz, corrige rápido, depois a gente ve essa refatoração. Por que a mulher ta cuspindo fogo pela boca e já ta ameaçando procurar outro fornecedor”
Bom…você arruma o problema em 3h. O Gestor fica feliz, o Cliente fica feliz. O Gestor fala para o Diretor que conseguimos apagar o “Incêndio” com o Cliente.
Conclusão: Você resolveu o problema em 3h. Deixou todos os seus superiores felizes. E principalmente: Deixou o cliente feliz. E eles nem ao menos sabem o que você fez. Se você se manter assim, deixando o tempo todo o “Gestor” e “Cliente” feliz, provavelmente você ira receber um reajuste ou talvez sera promovido de cargo.
Essa é a “dura” realidade de “algumas” empresas. Mas arrisco dizer: As empresas hoje em dia buscam “bombeiros” e não “detetives” para analisar e investigar a melhor solução para o problema.
O problema é: Nessas condições que coloquei acima, quem futuramente ira ter mais beneficios($$$) dentro desta empresa: O “bombeiro” ou o “detetive” ?
Obs: Todo esse texto acima, foi um caso real.
também achei isso muito bem escrito… acostume-se com isso por que é o que mais se tem no mercado mesmo, e acrescentando, é bom para você ser o detetive no inicio de projetos, é um bom privilegio que alguns conseguem ser o detetive (alguns que não precisam se sujeitar a serem bombeiros), mas além de detetive, é bom para a sua carreira ser bombeiro, então sempre que puder esteja preparado para ser os dois.
N
neofito
E quem disse que eu pulo de galho em galho? E quem disse que não tenho família? Bom profissional, profissional com técnica, é valorizado. Veja bem, o tipo de empresa que faz o que está descrito neste tópico são consultorias, agências de publicidade, etc. Geralmente as empresas que desenvolvem para seu uso estão interessadas em qualidade, porque o sistema delas faz parte do próprio negócio. Se o sistema falha, há prejuízo. É tudo uma questão de decidir em qual lado você vai ficar.
B
bestlinux
E quem disse que eu pulo de galho em galho? E quem disse que não tenho família? Bom profissional, profissional com técnica, é valorizado. Veja bem, o tipo de empresa que faz o que está descrito neste tópico são consultorias, agências de publicidade, etc. Geralmente as empresas que desenvolvem para seu uso estão interessadas em qualidade, porque o sistema delas faz parte do próprio negócio. Se o sistema falha, há prejuízo. É tudo uma questão de decidir em qual lado você vai ficar.
Desculpe…já trabalhei como CLT em um setor de desenvolvimento de uma grande empresa no qual utilizava o “proprio” software 24x7. Não era assim, infelizmente, bem que eu gostaria que fosse. Creio que não podemos “generalizar”.
N
neofito
E quem disse que eu pulo de galho em galho? E quem disse que não tenho família? Bom profissional, profissional com técnica, é valorizado. Veja bem, o tipo de empresa que faz o que está descrito neste tópico são consultorias, agências de publicidade, etc. Geralmente as empresas que desenvolvem para seu uso estão interessadas em qualidade, porque o sistema delas faz parte do próprio negócio. Se o sistema falha, há prejuízo. É tudo uma questão de decidir em qual lado você vai ficar.
Desculpe…já trabalhei como CLT em um setor de desenvolvimento de uma grande empresa no qual utilizava o “proprio” software 24x7. Não era assim, infelizmente, bem que eu gostaria que fosse. Creio que não podemos “generalizar”.
Realmente, não podemos generalizar. Há casos e casos. Mas continuo com minha opinião, se você procurar, acaba encontrando um lugar melhor.
A
adriano_si
fabim:
Depende irmao. Conheco uns Sistemas “zumbis” assim que sobrevivem a mais de 5 anos e nao tem data pra acabar.
Se o cliente ta pagando, e pagando MUITO, e vc recebendo bem, quero ver largar mao disso pra ganhar MENOS por algo LINDO, com designs perfeitos num mundo Orientado a Objetos Perfeitos.
Bom, repito, acho que sou o único doido do mundo, porque já larguei, e acredite, pra ganhar 50% a menos…
Ah, com família e tudo… minha forma de pensar é esta (que não quer dizer que é a mais correta do mundo): um ambiente assim, me deixará ferrado e destruído, como PJ se eu deixar chegar a esse ponto, quem se ferra sou eu. Logo, todo dinheiro ganho, será gasto com recuperação da saúde. Fazendo a matemática, saio para um lugar onde me satisfarei e viverei em paz. Não gastarei horrores com patologias adiquiridas… heuehueehuehe
Agora claro galera, isso vai de perfil pra perfil. Tenho conhecidos que conseguem e gostam de viver no meio do incêndio… realmente no meu Post anterior eu me equivoquei ao não citar os perfis… Ao colega criador do tópico, basta você achar o seu perfil.
Abs []
Y
YvGa
Nao Adriano, voce nao eh o unico, eu tbm ja fiz isso e fiz recentemente. Nao era 50%, mas sai pra ganhar menos. Os motivos nao sao por codigo ruim, mas porque eu estava de saco cheio das disputas politicas dentro da empresa.
Nao discordo de voce, o que eu quis dizer com a minha frase é que eu acho que muitos dos que vivem chorando porque pegam codigo ruim pela frente, na verdade nao sao capazes de produzir codigo decente. Entao chora porque nao entende o codigo, mas nao consegue arrumar. É obrigação do bom programador arrumar o que esta errado e existem tecnicas e ferramentas que possibilitam isso, cabe a nós aprender com quem ja passou por isso e usá-las.
As empresas que exigem que voce produza qualidade muito raramente vao te ensinar a fazer isso, a nao ser que voce aceite ganhar pouco, elas vao querer que voce ja seja capaz de produzir codigo de qualidade, o que é muito raro entre os que costumeiramente reclamam de codigo ruim.
Nao me entenda mal, eu tambem nao gosto de codigo ruim, mas cada vez mais eu tenho aprendido a lidar com eles.
É justamente esse o ponto, voce nao tem que convencer ninguem de nada, voce tem que fazer e pronto. Se algo precisa ser refatorado voce tem que refatorar e ponto. E nao é aceitavel que voce demore mais do que 10% (ok, 20% em alguns casos) a mais do que demoraria pra fazer sem refatorar. Se alguem disser que vai levar 2 dias pra fazer algo que poderia ser feito em quatro horas, em nome de uma suposta melhoria de design, ninguem aceita. Se disser que vai levar 5 ou 6 é obvio que qualquer gerente vai concordar. Voce vai perder muito tempo de qualquer jeito até entender o que o código de fato faz e depois pra descobrir todos os efeitos colaterais que pode causar. Ora, entao porque ja nao comeca aplicando testes em cima do legado? Alem de proteger as falhas que voce pode causar, ele te ajuda a entender o que o codigo faz e uma vez que voce entendeu e pos testes, fica bem mais facil refatora AQUELA AREA (e nada mais) em que voce esta mexendo.
Nao sao todos que podem escolher onde vao trabalhar, mas sao muitos os que leem blogs sobre codigo bonito e acham que as empresas tem ter a base de codigo limpinha, certinha, só esperando por eles.
Sobre os livro que voce citou sao extraordinarios, (Refactoring, TDD e Working Effectivelly with Legacy Code, Clean Code, entre alguns outros) Ninguem deveria se dizer programador enquanto nao os conhecesse ainda que superficialmente. Claro, o dominio do que esta ali so vem com a pratica, mas o conceito bem formado todos deveriamos ter.
