Bom dia pessoal!
Aqui onde trabalho temos cada absurdo entre um begin e end, queria saber se nas empresas de vocês também é assim? Existe coisa difícil de compreender e dar manutenção?
Existe. Sempre existe um estagiário, um colega não tão cuidadoso ou um sistema legado com uma tecnologia inerentemente difícil (onde será difícil também montar o ambiente para recompilar a solução, pois ele é velho, seus componentes são difíceis de encontrar, etc). Quando se trabalha em equipe, é inevitável.
Agora, já trabalhei em equipes que o pessoal, no geral, era muito bom. Aí tinhamos no geral códigos usando muitos recursos da linguagem (o que poderia complicar para um iniciante), mas muito simples de manter, pois eram muito organizados.
[quote=ViniGodoy]Existe. Sempre existe um estagiário, um colega não tão cuidadoso ou um sistema legado com uma tecnologia inerentemente difícil (onde será difícil também montar o ambiente para recompilar a solução, pois ele é velho, seus componentes são difíceis de encontrar, etc). Quando se trabalha em equipe, é inevitável.
Agora, já trabalhei em equipes que o pessoal, no geral, era muito bom. Aí tinhamos no geral códigos usando muitos recursos da linguagem (o que poderia complicar para um iniciante), mas muito simples de manter, pois eram muito organizados.[/quote]
Que história é essa? agora todo estágiario por não ter experiência é um mal programador? ele nao pode ter estudado o suficiente para entender e manter um código padrozinado ?
Concerteza! 
Já vi código tipo:
for (int i = 0; i < lista.size(); i++)
if (condição = true)
i = 10000000;
}
A parte do i = 10000000; era para sair do loop! :shock:
Existem pessoas que apenas sabem Java, mas não querem aprimorar seus conhecimentos. Uma equipe boa em Java é cara, e não é facil de se manter.
É mais fácil ter um Sênior que arquitete tudo e 2 profissionais que façam o código funcionar do que 3 pessoas que saibam OO e estejam sempre aprimorando.
Oi,
Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.
Acredito ser um diferencial e uma boa pratica.
Tchauzin!
[quote=lina]Oi,
Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.
Acredito ser um diferencial e uma boa pratica.
Tchauzin![/quote]
Concordo!
[quote=moacirjava][quote=lina]Oi,
Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.
Acredito ser um diferencial e uma boa pratica.
Tchauzin![/quote]
Concordo![/quote]
Concordo! [2]
Aonde trabalho a empresa usa um gerador de código Apyon, uma palhaçada o código gerado, e no mais existem ‘‘programadores’’ marmanjos de mais de 30 anos/ alguns até formados que não tem a mínima lógica de programação.
Sim.
A experiência é fundamental fazer um bom código.
É difícil vc ter experiência suficiente para saber dividir bem classes sem ter experiência profissional.
Também é difícil você fazer bons sistemas multi-thread sem experiência, ou se preocupar em ter boas práticas de programação.
As exceções, com certeza, serão de estagiários que já tiveram experiência profissional prévia.
Tal como um médico tem que fazer residência para ser um bom médico, um estagiário tem que programar um bocado até se tornar um bom programador.
Já trabalhei em lugares que o uso de recursos mais avançados da linguagem era desencorajado, para não dificultar a vida dos iniciantes.
(Mesmo que você solucionasse um problema em 5 ao invés de 100 linhas).
Se utilizasse assim mesmo, você virava o “pai” do código e era o único a dar manutenção…
Já trabalhei em lugares que o uso de recursos mais avançados da linguagem era desencorajado, para não dificultar a vida dos iniciantes.
(Mesmo que você solucionasse um problema em 5 ao invés de 100 linhas).
Se utilizasse assim mesmo, você virava o “pai” do código e era o único a dar manutenção…[/quote]
Puxa, no final é o projeto que tem que se adequar ao estagiário e não o contrário ?!! :shock:
Caraca, deve ser osso escrever 100 linhas só para deixar mais fácil para o estagiário…
O problema das 100 linhas é a chance que ela pode gerar de aparecer um bug, contra as 5 linhas que poderiam reduzir isto.
É, sempre tem alguem que não é muito bom escrevendo códigos.
Já peguei uns pra manutenção que me deixou incredulo com a criatividade para gambiarras que as pessoas deixam nos códigos para “apenas funcionar”, que é a visão que programadores não muito bons tem.
Mas sobre estagiario, eu sou um, mas só pelo fato de que estava fora da area e programei uns 4 anos só por diversão.
Já trabalhei em lugares que o uso de recursos mais avançados da linguagem era desencorajado, para não dificultar a vida dos iniciantes.
(Mesmo que você solucionasse um problema em 5 ao invés de 100 linhas).
Se utilizasse assim mesmo, você virava o “pai” do código e era o único a dar manutenção…[/quote]
Mas acredito que é dever de todo iniciante sair do nível de iniciante, é preciso conhecer a linguagem em toda a sua plenitude sob pena de produzir código verboso muitas vezes mal projetado por conta de ter que fazer muita coisa “no braço”. Acho que o código mais avançado muitas vezes é mal documentado incluindo as fontes de onde ele foi tirado, nesse caso vale a pena ao terminar de se produzir um código que utilize recursos avançados fornecer a fonte de onde aquele conhecimento foi tirado, chegando até mesmo a criar algum documento ensinando o uso do recurso, para que dessa forma os iniciantes cresçam junto com o pessoal mais “avançado”.
Eu fico revoltado de dar manutenção em códigos gambiarrados. Além de ser muuito mais difícil, parece que você vicia em escrever código do mesmo jeito. Sem contar que além de você se preocupar com as regras do negócio vc tem de se preocupar em decifrar o que aquele POG tá fazendo… “Ai… I love this job…”
[quote=lina]Oi,
Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.
Acredito ser um diferencial e uma boa pratica.
Tchauzin![/quote]
Revisor de código, é só que faltava.
Gambiarras em blocos de código são facilmente refatoráveis, já a arquitetura do sistema não.
Existem POG feitas as vezes sem querer sem o conhecimento prévio das regras, mas eu sempre que encontro já perco algum tempo para refazer e reestrutar quela porcaria, pra sair algo descente e mais bem feito.
[quote=m4rkk][quote=ViniGodoy]Existe. Sempre existe um estagiário, um colega não tão cuidadoso ou um sistema legado com uma tecnologia inerentemente difícil (onde será difícil também montar o ambiente para recompilar a solução, pois ele é velho, seus componentes são difíceis de encontrar, etc). Quando se trabalha em equipe, é inevitável.
Agora, já trabalhei em equipes que o pessoal, no geral, era muito bom. Aí tinhamos no geral códigos usando muitos recursos da linguagem (o que poderia complicar para um iniciante), mas muito simples de manter, pois eram muito organizados.[/quote]
Que história é essa? agora todo estágiario por não ter experiência é um mal programador? ele nao pode ter estudado o suficiente para entender e manter um código padrozinado ?[/quote]
Suponho que você seja estagiário (eu sou) e digo que já vi péssimos códigos de profissionais. Com relação ao seu comentário acho difícil (não impossível) estagiário ter estudado o suficiente para entender e manter um código padrozinado, ele está num período de aprendizado, merece suporte da equipe (na minha opinião sim) mas não deve depender da mesma para fazer sua tarefa e aprender a correr atrás para se tornar um profissional melhor.
Flw
[quote=FrancoC][quote=lina]Oi,
Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.
Acredito ser um diferencial e uma boa pratica.
Tchauzin![/quote]
Revisor de código, é só que faltava.
Gambiarras em blocos de código são facilmente refatoráveis, já a arquitetura do sistema não.[/quote]
Oi,
O que tem de errado revisar o código de outro? medo?
Tchauzin!
[quote=lina][quote=FrancoC][quote=lina]Oi,
Uma maneira de diminuir (não acabar) com isso seria a utilização de técnicas/metodologia de desenvolvimento, como XP, Scrum etc…
A empresa onde trabalho utiliza a técnica XP - Extreming Programming. Existe um Implementador, Revisor e Testador.
Acredito ser um diferencial e uma boa pratica.
Tchauzin![/quote]
Revisor de código, é só que faltava.
Gambiarras em blocos de código são facilmente refatoráveis, já a arquitetura do sistema não.[/quote]
Oi,
O que tem de errado revisar o código de outro? medo?
Tchauzin![/quote]
Concordo! Aqui na empresa se tivéssemos uma pessoa para fazer esse tipo de revisão, teríamos códigos muito mais fáceis e padronizados para dar manutenção. Sem falar que é possível achar alguns bugs.
Conheço uma empresa que o códigos passam pela seguinte bateria de testes:
:arrow: Teste de funcionalidade;
:arrow: Teste de white box;
Caso seja reprovado no segundo, o código volta para o programador para que ele reescreva de forma correta e padronizada.
Aqui também tem revisor, nao faz muita diferença eu acho.
Mas eu acho que não ia gostar de trabalhar pra revisar código dos outros.