Eu me encontrei em uma situação difícil ultimamente. Estou trabalhando em um jogo com um colega de programação há quase 8 meses. Nós dois começamos a programar em agosto do ano passado, ele é um estudante do segundo ano do ensino médio, sou técnico de suporte de TI por profissão e sou um programador autodidata com vários livros e assinaturas on-line.
O problema que tenho visto constantemente é que, à medida que escrevemos um pedaço de código, muitas vezes ele é um pouco hackeado, tem muitas falhas e, se é um novo conceito para um de nós, cheio de soluções ingênuas. Está tudo bem, estamos aprendendo, espero que nosso código seja um pouco hackeado no início ou no segundo passe. O problema se apresenta quando se trata de realmente consertar e refatorar aqueles comportamentos cortados em conjunto.
Meu parceiro manterá seu comportamento recém-pavimentado, recusando-se descaradamente a ver qualquer erro no momento em que começar a funcionar. Reivindicando quase a perfeição de uma parte da estrutura que eu não posso nem tentar usar, mesmo que ela tenha comentários e métodos e campos adequadamente nomeados. Não importa o quanto eu tente, simplesmente não consigo fazê-lo ver as falhas óbvias que impedirão novas mudanças ou expansão do comportamento sem quebrá-lo completamente e tudo o que está tão intimamente ligado a eles pode estar na mesma classe. As soluções invadidas permanecem permanentemente invadidas, os projetos mal pensados permanecem como estavam quando foram concebidos e testados pela primeira vez.
Eu gasto tanto tempo cuidando do novo código quanto escrevendo sozinho, sou uma perda do que fazer. Meu parceiro perdeu esta noite e deixou claro que não importa o que, não importa a referência, não importa a prática comum, não importa a prova irrefutável, seu código permanecerá do jeito que ele fez pela primeira vez. Mesmo que livros inteiros tenham sido escritos sobre o motivo de você querer evitar fazer algo, ele se recusará a reconhecer a validade deles, alegando que é apenas a opinião de alguém.
Tenho interesse em nosso projeto, mas não tenho certeza se posso continuar trabalhando com meu parceiro. Parece que tenho três opções em aberto para mim.
- Pare de se preocupar com o funcionamento da base de código além do ponto de compilação e lide apenas com a tentativa de manter e analisar o comportamento que quase não avança. Esperando que uma vez que as coisas comecem a se deteriorar seriamente, ele verá isso e tentará fazer mais do que apenas colocar uma banda sobre o design fundamentalmente defeituoso.
- Mantenha os argumentos sem fim sobre questões que foram descobertas há uma década por outros indivíduos muito mais capazes.
- Pare de programar neste projeto, abandonando quase 10.000 linhas do meu código e inúmeras horas se arrastando pelo design e tente encontrar um novo projeto por conta própria.
Que abordagem posso adotar para determinar se vale a pena continuar com este projeto com essa pessoa? Ou que fatores devem influenciar minha decisão? Escrevemos muito código e não quero desistir disso, a menos que seja necessário.
fonte
Respostas:
Código imperfeito e enviado é melhor do que o código perfeito no quadro branco que nunca é enviado.
Dito isto ...
Eu consideraria o seguinte.
Considere o exposto acima, tente pensar no trabalho adicional necessário.
Você precisa descobrir suas prioridades e determinar se os problemas relacionados ao trabalho com essa pessoa valem a pena. Não podemos descobrir isso para você.
Você sabe que não deseja trabalhar com esse tipo de pessoa.
Você está fazendo um projeto como esse, provavelmente porque quer aprender programação e encontrar elegância no ofício em si.
fonte
Isso pode ser uma coisa cultural. Em algumas culturas, admitir que cometeu um erro é algo inédito, e pedir a alguém para admitir que cometeu um erro é a coisa mais rude que você pode fazer. Se for essa situação, fuja.
Na minha experiência com pessoas muito inteligentes, se você lhes disser que algo que eles estão fazendo é menos que perfeito, eles (1) fornecerão a você uma razão correta e fácil de entender por que o que eles estão fazendo é realmente certo, (2) dirão você que eles sabem que está errado, mas não têm tempo para corrigi-lo por causa de prioridades ou (3) obrigado por apontá-lo e corrigi-lo.
Recusar-se a aprender é o pior atributo que um desenvolvedor de software poderia ter. Deixe-o nisso. A vida é muito curta e preciosa para desperdiçar seu tempo com ele.
fonte
Possivelmente, a maneira mais fácil é trazer alguém para o projeto - ou você está errado e a base de código dele é inteligente demais para você, ou você está certa e inteligente demais para todos. Você descobrirá em breve e obterá backup se for um código de nível de lixo, complicado e programador júnior.
Por outro lado, um produto em funcionamento vale qualquer número de anos de código claro, elegante e bem ajustado. Faça o jogo, envie-o, vá embora - deixe-o para mantê-lo e não funcione na v2.
fonte
Aqui estão algumas idéias, mesmo que algumas sejam mutuamente exclusivas.
Responsabilidades de fonte separadas. Se você trabalha no Módulo A e ele no Módulo B, pode competir com seus diferentes estilos. Ele está liberando recursos de trabalho com frequência? Ele chega a um ponto em que precisa reescrever seu código do zero? Refatore o código dos seus módulos e não toque nele,
Deixe-o fazer a manutenção de seu pior código. Se ele faz isso com sucesso, você evitou uma tarefa terrível. Se ele não for capaz, ele sentirá a dor.
Considere isso do ponto de vista do usuário ou do negócio. Em alguns casos, você só precisa de um produto viável que o Google ou a Microsoft comprem. Em outro, você está lançando um produto no mercado e dar suporte a milhares de clientes com códigos corrompidos ou invadidos será um inferno. Não é o mesmo se o seu código controla drones com mísseis nucleares ou faz vídeos felizes para adolescentes.
Ele faz as aulas, você faz os testes. A refatoração do código com testes é mais fácil e segura. Dessa forma, você não precisará procurar dentro do código apenas a barra Junit. Isso pressupõe que A) você está programando testes, B) o código do seu colega é testável. Se você achar difícil criar os testes durante a fase de codificação, este será pior.
Ir juntos para treinamento ou eventos. Quando você não sabe o caminho certo, é bastante natural usar o único caminho que você conhece. Ver o código do outro pode não resolver tudo, mas não custa tentar.
Encontre seus pontos fortes complementares. A refatoração às vezes pode ser divertida. Se ele escreve coisas que pelo menos funcionam, você pode fazer a refatoração. Ele pode fazer picos para explorar soluções que não terminam em código de produção.
Ele pode não querer reescrever o código, mas pode concordar em escrever melhor o novo código. Entendo que reescrever é difícil, chato e pode quebrar as coisas. Cultive algumas ilhas de qualidade. Dessa forma, ele terá bons exemplos de como fazer as coisas.
Use a regra dos escoteiros . Deixe as coisas intocadas, a menos que você precise trabalhar nisso. Se um módulo está mal escrito, mas funciona e não precisa ser alterado, deixe-o assim. Se você precisar corrigir um bug ou concluir um recurso, melhore-o um pouco. Depois de algum tempo, os 20% das aulas que você muda 80% das vezes vão melhorar. Mais ilhas de qualidade.
Não podemos sugerir qual é a melhor solução sem conhecer os dois. Boa sorte.
fonte
Ok, aqui está uma resposta que você provavelmente não vai gostar.
Aqui está o meu raciocínio. Você provavelmente está tentando ganhar dinheiro. Para ganhar dinheiro, você precisa enviar os recursos completos rapidamente. Ninguém pagará mais por um jogo de computador 'bem codificado'.
A maioria das empresas tem o mesmo problema. Refatore o código existente para torná-lo 'melhor', às vezes até objetivamente melhor em termos de velocidade ou confiabilidade OU escreva novos recursos.
99% do tempo eles escolhem escrever os novos recursos devido ao resultado de uma simples análise de custo-benefício.
fonte
Eu gosto de todas as respostas até agora. Tomando um dos pontos da resposta de enderland :
Eu gostaria de reservar um tempo para conectar-se à troca de pilha de revisão de código . É um lugar maravilhoso onde você pode obter seu código criticado por profissionais. E honestamente, muitas das revisões de código são extremamente úteis para os envolvidos - os solicitantes, os que respondem e aqueles que os tropeçam e os lêem. Você raramente recebe críticas úteis em um ambiente profissional (o que pode ser o caso nos locais em que trabalhei por qualquer motivo).
Meu conselho é publicar um pouco do seu código para revisão. Eu não sugeriria usá-lo como munição para provar que esse cara estava errado - duvido que ele leve isso a sério -, mas você pode obter informações muito úteis tanto no código que você escreveu quanto no código que ele escreveu. Eu recomendo enviar os trechos de código com os quais você mais luta. Com toda a probabilidade, vocês dois estão errados até certo ponto e podem usar a revisão como uma maneira de convencer um terceiro objetivo a intervir. Isso fará algumas coisas:
Você pode se desconectar da tensão emocional da situação.
Você recebe aconselhamento profissional em tempo real. Um grande impulso para o que você está aprendendo.
Alguém lhe dirá que você está errado. O que é bom, porque quem faz programação por qualquer período de tempo vai ouvir isso. Você pode lidar mal com isso como esse cara com quem está trabalhando ou pode aprender a lidar com isso.
Acho que se você usar as revisões de código da maneira certa, terá muito a ganhar ao lidar com essa pessoa extremamente frustrante. E é muito mais interativo do que um livro ou site que diz "faça isso, porque é o caminho certo na maioria das vezes".
Da mesma forma, há a troca de pilhas de desenvolvedores de jogos . Não é um lugar para postar código para revisão, mas para perguntar sobre conceitos / idéias com os quais você está tendo problemas. Mais uma vez, esse lugar é extremamente útil para todos os envolvidos.
Você já deve ter visto esses dois sites antes; Eu só queria ter certeza de que eles fazem parte do seu conjunto de ferramentas.
fonte
Parece sem esperança. Eu provavelmente desistiria e seguiria em frente se pensasse sobre isso como você; definitivamente chega uma hora de ir embora e você pode estar lá.
Se você ainda não está pronto para ir embora, precisa encontrar uma maneira de chegar a um melhor acordo sobre seu processo. Parece que você tem padrões de codificação, mas não padrões acordados. Da próxima vez que você chegar a uma encruzilhada, da próxima vez que quiser usar um pouco de código e seu amigo quiser deixá-lo em paz, comece a conversar ao longo das seguintes linhas:
douglas: Eu quero mudar isso porque X, que está aqui em nossas diretrizes.
amigo: Tudo bem como é.
douglas: Então você está dizendo que devemos mudar as diretrizes?
amigo: Não, eu apenas acho que está tudo bem.
douglas: Então, quais são as diretrizes?
amigo: eu não sei - você escreveu.
douglas: Que diretrizes você escreveria?
amigo: eu não escreveria diretrizes. É uma perda de tempo.
douglas: Então devemos jogar fora as diretrizes e escrever qualquer porcaria que estamos pensando no momento?
amigo: Isso não é uma porcaria.
Douglas: É perfeito? É ideal?
amigo: faz o trabalho; vamos para o próximo recurso.
douglas: Existe algo em que possamos concordar, que X é um bom código e Y é um código ruim?
amigo: me deixe em paz; Eu só quero codificar!
Bem, isso não correu bem, certo? Acho que sinto que você e Buddy querem coisas diferentes. Se houver algo em que você possa concordar, ótimo; começar a partir daí e construir sobre ele. Mas você não pode fazê-lo concordar em querer o que você quer - assim como você não pode fazer o que ele parece querer. Se você puder encontrar esse desejo comum e chegar a um acordo comum a partir daí, talvez possa trabalhar juntos.
Douglas: O que você quer?
amigo: eu só quero codificar.
douglas: Eu também quero codificar, mas quero sentir orgulho do meu código.
amigo: tenho orgulho do meu código.
douglas: Aqui está uma função da qual me orgulho - o que você acha disso?
camarada: Bem, tudo bem, mas você não deve recalcular o X dentro do loop; é ineficiente.
douglas: Então você está dizendo que devemos sempre calcular valores constantes fora dos loops?
amigo: Bem, duh!
douglas: Você acha que isso deveria estar em nossas diretrizes?
amigo: claro.
douglas: OK, vou adicioná-lo às nossas diretrizes e atualizar meu código ...
Douglas: Como está agora?
amigo: Tudo bem.
Agora Buddy está contribuindo para as diretrizes (ainda que indiretamente), e por isso tem um senso de propriedade. Talvez - apenas talvez - ele comece a levá-los mais a sério. Eu acho que estaria inclinado a limpar a lousa e começar de novo com as diretrizes, deixando que a maioria ou todas venham de Buddy primeiro. Vá em frente e escreva códigos de merda para que ele sinta a necessidade de adicionar às diretrizes; que eles venham dele. Talvez então ele comece a entender o motivo deles.
Mas se você preferir desistir e seguir em frente - isso também pode não ser uma opção tão ruim.
fonte
Supondo que você decida abandonar o projeto:
fonte
Você provavelmente deve abandonar o projeto.
Sem saber mais sobre isso, então você nos disse, eu especularia que o atrito que você está enfrentando esteja relacionado à experiência.
Mesmo que você não seja um programador por profissão como profissional de TI, provavelmente aprendeu da maneira mais difícil fazer as coisas corretamente da primeira vez, sua referência ao seu futuro indica que você o ferrou no passado e aprendeu não para.
O seu aluno do segundo ano do ensino médio, mesmo que seja bastante talentoso, provavelmente não tem a perspectiva de ter feito isso (se você é como eu, repetidamente :).
Ele / ela nunca realmente acreditará no valor de consertar as coisas à medida que avança até que ele / ela tenha cicatrizes por não fazer isso ou seja orientado em uma cultura com excepcional disciplina de engenharia, ou ambas.
Essa pessoa pode ser sua parceira de programação, mas não é a sua parceira de projeto, portanto, fazer esse jogo como um projeto de pares provavelmente é uma causa perdida. A menos que você esteja preparado para apenas comer o custo futuro. Talvez o relacionamento seja valioso o suficiente para você. Nesse caso, dê à bainha corda suficiente para se enforcar e ajude a limpar a bagunça quando essa pessoa for forçada a reconhecer o problema.
Caso contrário, promova e faça um projeto com um colega ou faça um projeto de mentor / mentorado onde essa é a dinâmica desde o início.
fonte
Para adicionar pontos adicionais a todas as ótimas respostas:
fonte
Você deve continuar fazendo o seu código da maneira que achar melhor, com comentários e coisas assim e fazer uma cópia da sua versão do código (caso ele mude seu código).
Não lute, não fique bravo, apenas sorria quando vir suas más decisões.
Apenas reclame como usuário, se estiver funcionando, não reclame.
Não desista também, é importante se acostumar com pessoas diferentes de você, que acontecerão em um trabalho real.
fonte