Oi. Meu colega de trabalho está desenvolvendo determinadas funcionalidades de um sistema das quais o meu trabalho depende. No entanto, ele escolhe nomes de variáveis terríveis, gosta de classes monolíticas, não escreve testes unitários, não usa padrões em situções óbvias e seu código é quase sempre pouco legível. Infelizmente, ele está há mais tempo do que eu na empresa e sempre acha que está certo em qualquer discussão. Se eu tentar criticá-lo (pedindo pra que ele tente fazer as coisas direito) certamente vai ficar um clima muito constrangedor entre nós. O que eu faço? Algum de voces já passou por algo parecido?
Poxa, e como hehehe 
Conflitos são inevitávies em um ambiente de trabalho, ninguem gosta de ser criticado
Eu acho que você deve falar com ele sim, mas tem que saber como falar
Por exemplo, ao invés de falar apenas isso que você fez é uma droga!! você pode tentar mostrando para ele as vantagens de se fazer um código limpo e bem estruturado, tentando mostrar para ele que todos irão ganhar, pois como a manutenção vai ser facilitada depois todos vão embora para casa mais cedo felizes
Existem formas e formas de se criticar alguém, o ideal é que mesmo criticando você mostre para ele o que ele já fez de bom e o que ele tem a ganhar seguindo a sua idéia
Bom, essa é a minha opinião
Imprima o código dele e queime no meio da sala… é um ato simbolico, aposto que vai ser
mais divertido que do constrangedor… 
Não tem mais ninguém do ‘teu’ lado que enxerga essas coisas? Nem alguém de cima?
“Já estive em situação bem pior”
Concordo com o André, você deve falar com ele com um certo jeito, sem clima de conflito.
O cara pode nem saber que está fazendo algo errado/estranho/feio. Tem muita gente que não vai atrás das coisas, não le foruns, revistas, livros, etc. Só aprende quando alguém ensina. No fim, ele vai te agradecer.
[]´s
Como o seu código depende do código dele, tente negociar com ele qual será a interface que o seu programa vai utilizar.
Por exemplo, se ele está desenvolvendo um objeto A que terão os métodos públicos X, Y e Z, tente negociar com ele apenas qual é a forma como você vai acesses métodos.
A forma como ele implementa o código internamente não deve interferir de forma alguma no seu trabalho, desde que funcione.
Ou seja, tente ver o código do seu colega como uma caixa preta. Você acessa através das interfaces negociadas e não se preocupa com o que tem dentro.
Mesmo que ele crie uma interface horrível e não aceite mudar, não tem problema. Tente encapsular as classes dele dentro de classes melhores para você através do padrão de projeto Façade.
Boa Sorte!
[quote=fabiofalci]Imprima o código dele e queime no meio da sala… é um ato simbolico, aposto que vai ser
mais divertido que do constrangedor…
[/quote]
Essa foi excelente!
Realmente iria ser divertido vêr o cara saindo do trabalho em uma camisa de força. Mas não esqueça de pedir para algum amigo seu filmar e colocar no YouTube.
Falando sério agora. Eu sugiro que você tente falar com o cara numa boa, para cumprir o seu papel de alertar, e depois deixe o barco seguir. No dia em que você for chefe você oriente o pessoal adequadamente. Se você gerar conflito você é que vai ser marcado como encrenqueiro.
Eu sei bem como é isso. Infelizmente há muito programador porco por aí, e ainda acha que tem razão.
Eu costumo a ser bem organizado: faço os testes unitários, escrevo os javadocs, faço comentários quando necessário, tento dar nomes a classes/métodos/atributos sempre auto-documentáveis… e tento sempre manter a simplicidade do código. Quem já trabalhou comigo sabe bem disso.
E por muitas vezes já tive problemas com colegas. E em quase todas as vezes eu consegui sempre bater um papo legal com o pessoal e pedir que todos fossem organizados também. Porém houveram dois casos complicados. Em um deles eu tinha uma boa posição na equipe e tive que levar isso para a gerência do projeto que acabou cortando o “porco” do projeto.
Em outro caso foi um projeto na qual eu comecei, então quando me afastei do projeto para tocar outro projeto na empresa, acabaram contratando um programador que veio do PHP. Até que pouco mais de 15 dias me chamaram para dar um help no projeto. Nem preciso contar o susto que tive. Juro que até hoje não entendo como aquele cara conseguiu fazer tanta porquisse em uma única classe. Enviei um email pro cara copiando gerente e o papa. Aí o gerente fez questão de defender o tal jagunço. Depois disso me recusei a fazer quaisquer manutenções em tal código, pois para entender do código do cara acho que só mesmo Deus, e olhe lá.
Reclamar ou pedir para o cara melhorar o codigo dele nao vai fazer com que ele se transforme num programador excelente da noite para o dia. Que tal aproveitar a deixa e comecar a fazer programacao em par para espalhar boas praticas por ai?
Depende muito da situação. Pode ser que o melhor seja mesmo bater de frente, como já sugeriram, dependendo do quão técnico o seu chefe for. Outra alternativa é tentar sugerir para o seu supervisor boas práticas. Aqueles plugins de análise de qualidade de código e cobertura de teste unitário podem ser seus aliados aí. Se o grupo é pequeno, uma única pessoa consegue mudar a cultura, desde que tenha o tato e a persistência necessários.
Já passei por estas situações também.
É bem complicado, mas também acho que você deveria fazer uma tentativa de falar com o cidadão, quem sabe vc dá sorte e ele te ouve e muda a maneira de programar.
Os caras que encontrei que faziam este tipo de coisa vieram de outras linguagens como (PHP, Delphi) e não haviam feito o dito cujo CURSO SUPERIOR na àrea (sei que existem exceções), ou seja, estes tipos detestam estudar; não querem ver teoria nem de longe, inglês então Ave Maria! O negócio deles geralmente é o seguinte: funcionou tá pronto, é partir para a próxima atividade, imediatistas de último grau. E por ser assim normalmente eles tem um égo enorme, na certa se protegem achando que vc é muito teórico, viaja na mionese e não produz p@##@ nenhuma.
Quando a pressão aumenta em cima deles, vc pode ouvir “Tô cansado de programar, acho que tá na hora de “virar” gerente ou algo assim…”. O pior é que muitos acabam conseguindo isso com parente ou oportunidade bomba (aquelas que pagam pouco e é do tipo abacaxi que ninguem quer).
Na real, se vc não tiver um gerente, líder de projeto para dizer que as coisas tem que seguir por um caminho mais organizado e eficiente vai ser dificil vc mudar esta situação.
Boa sorte
flws
Olha, estive nessa situação, mas comigo é um pouco diferente. Acho que estou no lugar do seu colega de trabalho. rs
Dizer que o trabalho do seu colega não é adequado não é e nem será conveniente.
Sobre padrões, ninguém é obrigado a usar. O código pode ser legível e fácil de se manter, mesmo sem eles.
Também conta, que, você está acostumado a codificar de uma maneira, e ele de outra(mas isso não quer dizer, que você é melhor que ele ou vice-versa).
A melhor maneira de resolver esses problemas de comunicação, é sentar e expor opiniões.
Nós nos expressamos e pensamos de maneiras diferentes, e isso não quer dizer que temos de ter a razão.
[quote=juliocbq]Também conta, que, você está acostumado a codificar de uma maneira, e ele de outra(mas isso não quer dizer, que você é melhor que ele ou vice-versa).[/quote]Ah não. Nem tudo é relativo. Até aceito que normalmente existem N soluções boas, agora se o colega do Vinicius insiste em usar uma das N^3 soluções que só pioram o problema, uma providência tem que ser tomada. É claro que, se você acabou de chegar e já está descendo o sarrafo, vai ficar tachado de chato, de pretensioso. Por isso que tem que ir na manha, comendo pelas beiradas, ou então fazer a trouxa e cair fora. Agora ninguém aqui é babá pra ficar limpando caca dos outros.
[quote=juliocbq]Sobre padrões, ninguém é obrigado a usar. O código pode ser legível e fácil de se manter, mesmo sem eles.[/quote]Se você é profissional, então é obrigado a seguir padrão, simples assim. Imagina se todo piloto resolvesse pousar o avião a seu modo? Ainda mais hoje em dia, que a IDE já vai completando pra você, dá mais trabalho fazer fora do padrão do que segui-lo.
[quote=rubinelli]Ah não. Nem tudo é relativo. Até aceito que normalmente existem N soluções boas, agora se o colega do Vinicius insiste em usar uma das N^3 soluções que só pioram o problema, uma providência tem que ser tomada. É claro que, se você acabou de chegar e já está descendo o sarrafo, vai ficar tachado de chato, de pretensioso. Por isso que tem que ir na manha, comendo pelas beiradas, ou então fazer a trouxa e cair fora. Agora ninguém aqui é babá pra ficar limpando caca dos outros.
Se você é profissional, então é obrigado a seguir padrão, simples assim. Imagina se todo piloto resolvesse pousar o avião a seu modo? Ainda mais hoje em dia, que a IDE já vai completando pra você, dá mais trabalho fazer fora do padrão do que segui-lo.
[/quote]
A questão não é ser “tachado” de pretensiovo. Você estará sendo pretencioso. Criticar o trabalho de um colega não é uma coisa bem vista em lugar algum, e pode ser ainda, que o trabalho dele seja melhor que o seu usando determinadas metodologias. O correto seria sentar e chegar a um consenso.(deixo claro que não estou pregando desorganização, e sim comunicação).
Porém, há pessoas resistentes a mudancas, que acham que seus métodos de trabalho sao os melhores e mais eficientes.
Ja passei por situacoes parecidas e por bater o peh e defender a minha posicao ate o ultimo eu acabei me desligando da ultima empresa que eu trabalhei ai no Brasil.
O pior de tudo eh que eu estava correto em um monte de pontos e todos os problemas que eu apontei apareceram durante o desenvolvimento de um projeto nosso e foi muito complicado contornar o problema no meio do caminho. No final das contas ng teve a humildade de admitir que eu estava correto e que o projeto tava virando um mostro horrivel.
Acho que voce tem algumas opcoes, pra nao bater diretamente de frente com colegas de trabalho.
-
defina algumas regras tipo, como vc disse test unitario, code review e coisas do tipo e apresenta isso pro seu gerente e explique o porque vc acha que seria uma boa ideia fazer isso. Assim se o seu gerente gostar da sua proposta e adotar isso como regra de desenvolvimento vc nao precisa ter nenhum mal estar com os seus colegas.
-
Usar ou nao design patterns vai do programador, vc nao pode forcar o sujeito a programar do jeito que vc acha certo, mas uma coisa que pode ser adotada pra melhorar o codigo eh, convencao de nomes de variaveis, classes, metodos etc, colocar no papel algumas boas praticas que devem ser seguidas e por ai vai.
Entao eu acho que essa eh a melhor maneira pra vc abordar isso com os seus colegas, coloca tudo no papel e apresenta pra sua gerencia, com vantagens, desvantagens, e tudo mais.
So pra complementar, como o colega que postou antes de mim disse, tem sempre gente que pensa que a sua maneira de trabalhar eh a melhor e o outro ta errado, vc acha que ele nao faz as coisas direito porque ele nao faz testes unitarios ou coloca nomes adequados nas coisas, design patterns e etc… ele por outro lado provavelmente pensa que vc perde muito tempo fazendo teste e pensando em nomes mais legiveis pra metodos por exemplo.
Acho que tudo tem que ser analisado dentro do contexto da sua empresa tb pra analisar se vale a pena brigar por fazer as coisas de outro jeito (que talvez seja melhor) ou ficar na sua e deixar tudo mundo trabalhar do seu jeito, eu acho seguir alguns padroes eh bom pra toda a equipe mas talvez testes unitarios ou design patterns nao fazem tanta diferenca que valha a pena colocar em risco a "paz! na equipe.
//Daniel
Convenção de Nomes é uma solução ótima. Boa parte da degradação do código se deve ao mal uso de nomes de variáveis, classes, etc…
Siga umas das opções:
1 - Argumente diretamente com ele.
2 - Ignore o código dele e reze para ele ver a qualidade de seu trabalho e tentar seguir.
3 - Mude de empresa.
4 - Refatore tudo que for dele.
Não se preocupe em ser taxado, isso é normal quando vc apresenta um trabalho de qualidade. Falsa humildade não leva a nada.
Ps: Tenha certeza que o SEU trabalho é de qualdiade inquestionável para não se dar mal em qualquer uma das alternativas.
sim eu concordo que convenção de nomes é uma coisa legal… testes, documentação também… quando tem essas coisas otimo… infelizmente quando não tem pode ser pior ainda, pode ser que quem está fora do normal da empresa é você, buscando essas cosias, e não a outra pessoa escrevendo código dessa forma… talvez imediatalista…
o meu conselho para o seu caso seria tentar aproveitar uma conversa informal para fazer “ele perceber” a sua opinião quanto a falta dessas coisas… vai indo aos poucos… expoe sua opinião sobre a convenção de nomes por exemplo e deixe que ele tire suas proprias conclusões, com certeza vai lembrar do código dele, mais não vai achar que você está reclamando… o que facilita as coisas e de uma forma até que sutil… é serio, quebra um galhão…
Se o seu colega de trabalho (coisa meio Silvio Santos isso) frequenta o GUJ, talvez agora você não precise fazer nada.