Quais fatores devem influenciar como eu determino quando abandonar um pequeno projeto com um amigo? [fechadas]


30

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.


3
Que tal apresentar as diretrizes de estilo de codificação acordadas e um processo de revisão de código? Evite quaisquer problemas controversos, basta colocar o suficiente no padrão para que você possa concordar.
Brandin 14/05

25
Quarta opção (se estiver sob uma licença permissiva): bifurque o código e continue trabalhando por conta própria.
Robert Harvey

4
Como o código é licenciado? Você pode bifurcar e continuar com outra pessoa?
Jaydee 14/05

14
Como @enderland menciona em sua resposta, há uma bandeira vermelha absolutamente enorme no que você escreveu: "Meu parceiro a 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á como ele o fez pela primeira vez. " Se você puder se afastar disso, faça-o. Quem realmente vale a pena trabalhar terá a humildade de aceitar que, às vezes, eles entendem errado.
Richard J Foster

3
Não importa o que você decida, as 10 mil linhas de código não serão perdidas: pense no que aprendeu ao escrevê-las; pense no prazer que você teve durante o tempo de codificação; e, aplicar o que você aprendeu em uma terceira / quarta / n + 1ª iteração (forçada) pode até torná-la melhor que a versão atual. Além disso, se você souber o que escrever 10k linhas de código, poderá escrever 10k linhas em um tempo relativamente curto; geralmente é o que escrever para fazer as coisas funcionarem é o que leva mais tempo.
Kasper van den Berg

Respostas:


26

Código imperfeito e enviado é melhor do que o código perfeito no quadro branco que nunca é enviado.

Dito isto ...

Aqueles de vocês com mais experiência ou que estiveram em situações semelhantes. O que você fez? O que você recomendaria que eu fizesse?

Eu consideraria o seguinte.

  • Qual é o objetivo deste projeto? Diversão? Dinheiro? Aprender?
    • Você está realmente cumprindo esse propósito?
  • Essa pessoa está realmente permitindo que você alcance melhor seus objetivos?
  • Quão perto você está do transporte?
  • Será que estas questões impedir você de lançar? Ou eles são uma questão de orgulho pessoal?
  • Existem benefícios em trabalhar com alguém de forma voluntária quando é frustrante?

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

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ê.

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.

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.


11
Obrigado por sua resposta. Estou cumprindo o objetivo de me divertir (quando não estiver brigando) e aprender. O tempo em que qualquer dinheiro deve ser ganho é uma história completamente diferente. Ele ajuda a realizar meus objetivos, mas acredito que ainda posso realizá-los por conta própria, ele ajuda na motivação. O jogo é um ótimo exemplo de característica, eu sinceramente não tenho idéia de quando ele pode ser lançado. Meu parceiro está tentando fazer uma mudança de 2D para 3D há meses, recuso desde que já ultrapassamos nosso escopo há muito tempo.
Douglas Gaskell 14/05

11
Eu estaria disposto a abandonar o projeto, se fosse apenas meu, teria sido abandonado meses atrás. Meu fator motivador para continuar é ter outra pessoa para trabalhar, mesmo que as lutas internas me façam questionar alguns dias. A única coisa que me impede de abandoná-lo é uma amizade como uma conexão com ele fora da codificação, eu preferiria evitar jogar isso com o projeto. É claro que essa não é uma explicação muito lógica, uma vez que os sentimentos pessoais deles estão envolvidos, realmente obscurece minhas capacidades de tomada de decisão.
Douglas Gaskell 14/05

11
a maneira mais rápida de perder um amigo é trabalhar com ele como iguais!

58

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.


Obrigado Gnasher, eu vejo o número 2 periodicamente, embora não tenhamos um cronograma real, então não tenho certeza da validade da resposta. Vou dormir sobre isso e ver o que estou pensando no AM, isso precisa de muita deliberação antes de tomar uma decisão.
Douglas Gaskell

11
"Se for essa situação, fuja." - e, em geral, se você não consegue chegar perto do consenso sobre quais são seus objetivos, não pode cooperar com alguém. Parece que ele não vai consentir que você altere o código "dele", não importa o motivo.
Steve Jessop

Bem, parece que a pressão do tempo não é o motivo para recusar mudanças.
gnasher729

11
Esta é uma ótima resposta. Você não pode forçar alguém a mudar de atitude! No entanto, parece que há muito tempo e esforço investidos no projeto, tanto do lado dele quanto do seu. Meu pensamento pode ser que ele não queira alterar seu código, porque ele não entende a maneira como você acha que isso deve ser feito. Ou é isso ou ele está convencido, mas se é que ele não entende, tente ter em mente que ele pode estar frustrado e pense que você está "falando baixo" com ele, mesmo que você queira muito bem. Meu conselho é tentar conversar com ele quando vocês dois quiserem.
Zfrisch

^ + É fácil ficar ofendido por alguém quando você começa no mesmo nível e ele o ultrapassa em habilidade. Não estou dizendo que esse é certamente o caso, mas certamente parece que pode ter algo a ver com isso.
Zfrisch

12

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.


2
Obrigado pela resposta. Engraçado que você mencionou seu primeiro ponto. Ele está tentando encontrar e trazer um programador iniciante que ele possa ensinar para ajudar no projeto. Eu só poderia esperar que isso acabasse terrivelmente se houvesse duas pessoas seguindo o mesmo estilo de hack e esquecer. Gosto da segunda opção, faça-a, envie-a e deixe-a em branco. O problema em que posso me deparar é que estamos no meio do caminho, criando uma LLC, para que tenhamos um nome para enviar nosso jogo. Ambos os usos terão uma participação de 50%, é claro. No entanto, eu poderia terminar e seguir em frente. O projeto é grande, isso pode demorar um pouco.
Douglas Gaskell

20
Você não deseja, sob nenhuma circunstância, entrar em um relacionamento comercial juridicamente vinculativo com uma pessoa assim.
gnasher729

3
@ douglasg14b traz um junior para ensinar .. pobre garoto. Sugira que você traga um cara experiente ", pois ele aceleraria muito mais rápido e ajudaria a finalizar o produto". Coloque sua mira em uma linha de chegada - ou vocês dois pretendem trabalhar nesse hobby para todo o sempre? (vi isso acontecer, até que ele obtém cancelada)
gbjbaanb

Eu pretendo terminar, definitivamente. Embora eu acredite que foi um projeto muito grande para ser abordado como nosso primeiro. Começou como um design simples, não deveria estar nem perto da escala que está agora. O limite do nosso escopo é constantemente pressionado pelo recurso do meu parceiro, sou parcialmente culpado por isso, porque permito que isso aconteça e até concordo com alguns recursos. O objetivo é que, se deixados sozinhos, provavelmente estamos concluindo em um ano. Felizmente, como eu o programei, as peças podem ser facilmente retiradas e colocadas em outros projetos posteriormente.
Douglas Gaskell

4
Pense no código como pertencendo ao projeto, não a você. Se você possui propriedade conjunta do produto, pode reutilizar todo o código do seu próximo projeto. Se você não tem idéia de quem é o dono, faça essa discussão agora. Boa sorte.
Gbjbaanb

9

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.


4

Ok, aqui está uma resposta que você provavelmente não vai gostar.

Não 'corrija' o código, a menos que ele não consiga implementar o recurso.

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.


15
Isso se enquadra no argumento da "dívida técnica", certo? Quando você escreve esse novo recurso (ou modifica um existente), leva três vezes mais tempo e produz dez vezes mais erros do que seria necessário se você continuasse sua refatoração? Nesse caso, talvez pular a refatoração fosse uma economia falsa.
Ben Aaronson

11
Você pensaria assim, mas trabalhei em muitas empresas de sucesso e (quase) nunca vejo a refatoração em alta prioridade. Minha conclusão é que simplesmente não compensa.
Ewan

Isso é justo o suficiente e tenho certeza de que há uma série de opiniões sobre isso, apenas parece não abordar de uma forma ou de outra uma omissão significativa da resposta. Também posso estar errado, mas lendo as entrelinhas da pergunta, acho que o código incorreto com o qual o OP está preocupado pode ser muito pior do que o tipo de código que você está pensando.
Ben Aaronson

heh, sim! mas também parece que o custo de fazer as alterações é muito alto. Na minha resposta, tento dar o objetivo 'você está nisso pelo dinheiro?' resposta, além de minha visão subjetiva de onde o equilíbrio de mentiras de probabilidade
Ewan

11
Isso é razoável em alguns casos, mas se o "código de trabalho" de alguém estiver fazendo com que outra pessoa gaste 2x mais tempo em seu código ou na integração de sistemas ou em trabalhos futuros, não será mais uma decisão simples de "expedição contra expedição". Muitos projetos de larga escala morrem porque não tomam decisões para fazer o que é certo e não rápido.
Enderland

3

Eu gosto de todas as respostas até agora. Tomando um dos pontos da resposta de enderland :

Existem benefícios em trabalhar com alguém de forma voluntária quando é frustrante?

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.


2

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.


2

Supondo que você decida abandonar o projeto:

  • Bifurque o código e refatore-o, usando-o como um item de portfólio 'antes / depois'
  • Como o objetivo era (principalmente ou parcialmente) aprender a programar e como aprender algo leva de 2 a 4 vezes mais do que você já sabe, esse trabalho não é realmente desperdiçado.
  • O "anexo de custo irrecuperável" (o investimento que você já fez em um empreendimento antes de aprender que era uma má idéia) é um dos erros humanos mais comuns na tomada de decisões
  • Para manter a amizade, enquadre sua decisão como priorizando a amizade sobre a codificação

1

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.


1

Para adicionar pontos adicionais a todas as ótimas respostas:

  • Quanto mais esforço será necessário para concluir o projeto? Observe que terminar os "últimos 10%" leva muito mais tempo do que as pessoas esperam. Isso inclui testar / ajustar o jogo, corrigir a usabilidade, lidar com uma variedade de plataformas-alvo, liberar, ... Se for um jogo para iOS, haverá assinatura de código e revisão da Apple. Honestamente, o acabamento pode demorar até os primeiros "90%". E será mais difícil se o código for tão ruim quanto você sugere. (Você pode começar a testá-lo agora?)
  • Realisticamente, qual a probabilidade de as pessoas gostarem do seu jogo?
  • Cuidado com a heurística " custo irrecuperável " ". Avalie esse investimento de 10.000 linhas de código à luz do quadro geral, olhando para trás em um produto acabado e sem otimismo indevido.
  • Você pode continuar se demorar mais 3 anos? Vocês dois têm estilos de desenvolvimento diferentes (não é um bom jogo de equipe). Parece que você está perto do fim de sua paciência e, se continuar, pode ser difícil continuar sendo amigo.

3
Os "últimos 10%" levam muito mais tempo se 90% do código for lixo :-(
gnasher729

0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.