Como posso pedir ao meu chefe (de maneira educada) que comente seu código?

72

Eu estou sendo ensinado pelo meu chefe (acabei de terminar a escola e ele queria alguém com pouca experiência em programação, então ele me escolheu para me treinar no que aquela empresa é especializada) e começou a trabalhar com ASP.NET MVC , alguns HTML e CSS. Estou bem com as coisas de web design que ele me dá (é bem simples de entender sem precisar de esclarecimentos).

Mas, por exemplo, ele me dá uma tarefa para fazer com a ASP.NET MVC, ele explica isso muito bem. Mas ele não explica nada no código que acabou de me dar. (Usamos o controle de origem no Visual Studio 2013 ), por isso é, literalmente, centenas de linhas de código, sem nenhum plano de fundo o que é suposto fazer. O tipo de código que estou vendo é um código que eu nunca vi antes, então é muito difícil tentar descobrir.

Eu tentaria fazer mais perguntas, mas ele está sempre trabalhando (é assunto dele), e eu sinto que ele pode ficar irritado com todas essas perguntas que tenho em minhas mãos.

Então, apenas algo que vai ajudar a minha saída até que eu tenha controle sobre as coisas, como posso pedir ao meu chefe para colocar comentários em seu código que ele me dá, mas educadamente?

    
por Aidan Quinn 09.02.2015 / 10:01
fonte

17 respostas

130

Você está no "fim profundo" e, na minha opinião, essa é a melhor maneira de aprender. Não porque você está olhando para coisas sobre as quais você não tem a menor idéia, mas porque isso obriga você a ter mais recursos e descobrir quais componentes desempenham qual papel em um sistema que você é novato.

Não ajuda que o seu chefe esteja ocupado demais para lidar com alguém que é curioso (e você está totalmente dentro do seu direito de ser curioso; você está interessado em aprender, o que é bom). Mas, infelizmente, pedir ao seu superior que mude seu estilo e abordagem em prol de seu aprendizado pode não cair muito bem, especialmente porque você está lidando com alguém que diz estar ocupado.

Estar sentado diante de milhares de linhas de código com as quais você não está familiarizado é a norma. Você não pode sempre ter isso explicado em preto e branco com comentários. No entanto, por uma questão de aprendizagem, enquanto você é novo para ele, se você sente que você definitivamente tem que pedir-lhe comentários - talvez explique o porquê. Explique que é por causa do fato de você não querer incomodá-lo com perguntas já que ele está sempre ocupado. Não só isso acontecerá muito menos como se você estivesse dizendo a ele para fazer algo, mas também abre a palavra para discussões sobre como ele poderia, em vez disso, preferir colocar a questão pedindo tempo de lado.

    
por 09.02.2015 / 10:09
fonte
75

Primeiro, rastejar por milhares de linhas de código não familiar e se sentir perdido é como todo projeto de software está, em todo lugar, desde o início dos tempos.

A maior diferença entre você e um programador experiente é que você não está acostumado com isso.

Alguns pontos a ter em atenção:

  1. Com esforço suficiente, todo código é compreensível. Muitas pessoas se sentem frustradas se não conseguem descobrir algo em poucos minutos. Seja mais paciente do que isso.

  2. Um bom chefe é o mais aberto possível a interrupções e perguntas. Um bom funcionário faz o máximo possível para minimizar interrupções e dúvidas. Seja consciente disso.

  3. As interrupções são mais caras que as perguntas. Você pode fazer melhor uso do seu tempo e do tempo do seu chefe, consolidando suas discussões, e nunca terminando uma conversa, sentindo-se confuso.

  4. Seu chefe é um programador melhor que você. (Provavelmente.) Isso não quer dizer que você não pode ser mais strong em algumas áreas, mas no geral sua experiência é maior. Até que você tenha muita experiência, certifique-se de estar aprendendo com o conhecimento dele o máximo que puder.

  5. Se tiver certeza de que mais comentários ajudariam significativamente o código, pergunte ao seu chefe. "É difícil para mim entender o que está acontecendo em alguns lugares. Quando eu resolvo as coisas, você se importa se eu adicionar comentários?" Talvez ele odeie comentários. Talvez ele ame isso. Talvez ele seja indiferente.

No final, no entanto, é possível que daqui a alguns meses você lembre de perguntar isso e pense: "Huh, eu me pergunto com o que eu tive um problema? Isso não é tão ruim assim. Hm, bem, não importa ".

    
por 09.02.2015 / 11:43
fonte
18

Se o seu chefe não tiver tempo para responder a todas as suas perguntas, por que você acha que ele terá tempo para comentar seu código legado? E, além disso, o que faz você pensar que seus comentários realmente descreveriam os fragmentos que você não entende por enquanto? Pela minha experiência, tentar mudar o estilo de programação dos seus chefes apenas perguntando a ele não funcionará, seja educado ou não.

A melhor coisa que você pode fazer em tal situação: comentar as partes do código que você precisa entender para fazer seu trabalho sozinho - depois de entender essas partes, é claro, e depois de obter um compromisso do seu chefe de que tudo estará bem. Se você ou seu chefe temerem que você possa quebrar alguma coisa adicionando comentários, adicione-os em uma agência separada e pergunte ao seu chefe se ele irá analisar seus comentários antes que eles sejam mesclados ao tronco. Como seu chefe tem apenas um orçamento de tempo restrito, tente descobrir o que determinada parte faz primeiro, investindo uma quantidade razoável de tempo. Se você realmente ficar preso, escreva sua pergunta em uma lista e pergunte ao seu chefe, por exemplo, uma vez por dia, em vez de perturbá-lo por 30 minutos. Pela minha experiência, essa abordagem funciona com a maioria das pessoas, mesmo que estejam muito ocupadas, desde que estejam dispostas a ajudá-lo - o que certamente é o caso em sua situação.

Dessa forma, você tem certeza de receber os comentários de que precisa, e seu chefe verá onde você precisa de informações adicionais e se acertar as coisas. E contanto que você se restrinja a comentar apenas as coisas não óbvias, há uma boa chance de seus comentários aumentarem a qualidade geral da base de código, o que pode não apenas trazer benefícios não apenas para você, mas também para todos os outros que tem que lidar com o código, incluindo seu chefe.

    
por 09.02.2015 / 10:13
fonte
8

Primeiramente, deixe que este seja um exemplo para você comentar seu código corretamente, gafanhoto!

Então, eu tenho que fazer isso o tempo todo. Eu tenho minha cópia local checada, e eu passo por ela e comento sozinha. (Eu posso tirar todos eles de volta se eu vou checar de volta - ou deixá-los, se ninguém se importar) Então quando eu realmente não posso ver mais, eu posso perguntar a alguém, aqui, eu acho que não isso (o que eu comentei), estou certo? Então você pode ter feito o comentário real, mas está feito e esse é o ponto.

    
por 09.02.2015 / 14:12
fonte
5

Isso é mais do que apenas uma solicitação pessoal. Você está tentando mudar hábitos / cultura, e isso não é fácil. Certamente não é algo que pode ser realizado por uma conversa no corredor ou por um e-mail. Vai levar algum esforço da sua parte.

Be the change that you wish to see in the world.

A citação pode ser falsamente atribuída a Mahatma Gandhi, mas é um conselho aplicável. Ao tentar decifrar a base de código, escreva os comentários que gostaria de ter visto, com o melhor de sua capacidade, e os comprometa, depois de ser examinado pelo seu chefe. Vantagens:

  • Você está sendo proativo, em vez de incomodativo.
  • Você está dando um bom exemplo. Na melhor das hipóteses, seu chefe / equipe verá os benefícios e seguirá o exemplo.
  • Alguns dos comentários provavelmente dirão /* Mystery parameter 3 */ ou /* 2015-02-09 AidanQuinn: Is this code ever called? */ - essas são oportunidades para seus colegas documentarem o código adequadamente ou corrigirem erros latentes.
  • Se, durante a revisão de pré-compromisso, descobrir que um comentário que você escreveu é impreciso, seus colegas agora sabem que o código não estava claro.

Evite reescrever ou refatorar quando fizer isso, e a introdução de comentários deve ser quase isenta de riscos. Se você reescrever qualquer coisa, mantenha essas mudanças como commits separados.

(Antes de embarcar neste projeto, certifique-se de que suas expectativas de comentários sejam razoáveis. Se sua idéia de código bem comentado estiver fora da norma ( Exemplo 1 , Exemplo 2 ), então você só estará fazendo de bobo de você mesmo.)

    
por 10.02.2015 / 07:49
fonte
5

Eu não pediria comentários adicionais, mas aqui estão algumas ideias para você:

  1. Agende um encontro com seu chefe e faça com que ele passe pelo código em alto nível. Isso deve começar. Eu esperaria algumas horas para talvez meio dia para que você possa se atualizar. Isso deve incluir design geral, padrões usados, etc.
  2. Crie um projeto de testes e comece a escrever testes de unidade em relação ao código, isso ajudará você a entendê-lo sem afetá-lo. Você também pode encontrar alguns bugs!
  3. Depure o código conforme necessário para entender certas áreas.
  4. Faça um aprimoramento ou remova o backlog e trabalhe nele.

Os comentários são OK, mas se o código for escrito de maneira direta, deve ser compreensível depois de alguns dias.

Além disso, não espere entender tudo, é melhor se concentrar primeiro nas áreas-chave e expandir o conhecimento da base de código conforme necessário.

    
por 09.02.2015 / 18:06
fonte
2

Eu tenho estado em uma situação muito semelhante à sua há aproximadamente um ano atrás. Comecei a trabalhar com pouca experiência em programação (embora eu já conhecesse um pouco de OO e algumas outras linguagens) e a única pessoa que me ensinou teve muito pouco tempo. Ele sempre foi útil, mas eu senti que não gostaria de fazer todas as perguntas que eu tinha.

Outros já sugeriram coisas extremamente úteis aqui (por exemplo, escrever testes unitários, mas por experiência própria, isso é algo que teria ido um pouco longe demais para mim a partir do zero, ou comentando partes do código, mas isso pode ser difícil dependendo do primeiro ponto / pergunta que eu vou fazer em um minuto). Os seguintes pontos resumem o que eu fiz e o que me ajudou, mas depende muito de onde exatamente estão seus problemas.

Além disso, tenho que concordar com o @AK_ que disse que você realmente não precisa de comentários em C #. Isso pode não ser 100% correto (acho que há áreas em que os comentários definitivamente ajudam, por exemplo, o código com reflexos pesados), mas em essência é. Se você escrever realmente 'código limpo' com métodos e variáveis bem nomeados, e tiver muitas pequenas 'mordidas' de código, eles serão quase totalmente desnecessários. Toda vez que senti a necessidade de comentários ao ler o código até então, depois que entendi o que ele fazia, fiquei muito insatisfeito com a forma como foi feito e pensei que poderia ter sido mais claro, em primeiro lugar, com uma boa refatoração. Edit: Estou falando especificamente sobre comentários do C # , não documentação (seja documentação separada ou comentários em XML), pois acho que a documentação é sempre importante.

  • Identifique exatamente quais são seus problemas e se você pode categorizá-los. Ou seja, você ainda tem problemas com a própria linguagem ou não entende uma sintaxe específica (por exemplo, expressões lambda e LINQ em geral, ou Reflection)? Se você não entende linhas de código, você não vai entender o que todo o método / bloco faz, então, você mesmo vai comentar. Em vez disso, pegue um bom livro ('C # in a Nutshell' foi para mim, mas eu ouvi que 'C # in Depth' é espetacular também) e leia as coisas que você encontra. Categorizar esses problemas de antemão torna isso mais fácil, pois você pode preencher 'lacunas maiores' de uma só vez, ou até mesmo perguntar ao seu chefe sobre isso, já que não são mais muitas perguntas, mas explicar um único assunto ou as construções mais usadas para que você pode obter um enorme 'impulso' nesta área rapidamente.

  • Paralelamente ao acima, tentei me familiarizar com 'codificação limpa' e com as melhores práticas gerais (sem linguagem específica). O efeito disso pode não ser imediato, mas será compensado mais cedo ou mais tarde, seja quando você precisar estender o material existente ou se perguntar por que alguém criou tantos métodos pequenos em vez de um onde tudo está contido; -)

  • Entenda os padrões de design comuns. Eles podem estar aparecendo aqui e ali no código que você está lendo, e se você os reconhecer, isso lhe dará imediatamente um momento do a-ha. Mesmo se você entender o que o código que você vê lá, você pode se perguntar por que isso é feito dessa maneira, e descobrir isso sozinho não é tão fácil assim.

Por favor, não use o texto acima como eu fazendo suposições sobre sua 'habilidade', muitas vezes alterno acidentalmente entre falar sobre minhas experiências e falar 'para você'. É principalmente como o que eu encontrei , e o que eu fiz . Como outros já disseram, isso pode ser uma experiência muito boa e é praticamente o padrão no trabalho ler o código que não é seu e que você não sabe muito a respeito. Mas pode ser realmente gratificante finalmente entender o que está acontecendo lá e se reconhecer ficando melhor com essa 'habilidade' particular. Tome isso como uma oportunidade para aprender um lote em pouco tempo, boa sorte! :)

    
por 10.02.2015 / 08:07
fonte
1

Você provavelmente não vai conseguir que ele mude de estilo.

O que você pode fazer é fazer muitas perguntas e anotar as respostas.

Eu herdei uma enorme base de código no meu último trabalho, pouca documentação e poucos comentários. Então eu tentaria meia hora com o mesmo problema, então se eu ainda não conseguisse descobrir, eu iria perguntar a alguém que escreveu, ou soube como usá-lo. Então eu documentaria todas as coisas que ele me disse. A maioria foi em nossa documentação, alguns entraram no código como comentários. Depois de um ano lá, praticamente escrevi uma grande parte de nossa documentação e sabia muito sobre a base de código.

Boa sorte!

    
por 09.02.2015 / 23:42
fonte
1

Eu estava tendo o mesmo problema. Sou estudante de phyzist e tenho uma boa experiência de programação. Eu estava programando em muitas línguas, mas nada para uma aplicação premium.

Candidatei-me a um trabalho para desenvolvedor da Web e eles instantaneamente me colocaram no back-end da programação da web. Quando o chefe me mostrou a API de base para o aplicativo REST do nó, eu estava pensando que eu iria jogar fora. Eu nunca vi funções com callback e sintaxe tão estranha. E eu pergunto ao meu chefe que eu tenho um problema Se não entendi nada no código. Ele triste não, ele triste que eu tenho 1 mês para descobrir isso e nesse meio tempo eu vou fazer um CMS para me testar com outro frontender.

Bem e eu fui uma linha de código no momento e google cada coisa que eu não sei. Então, uma semana se passou e eu estava familiarizado com o código o suficiente para que eu pudesse colaborar com o front ender. Meu código no começo foi uma porcaria, mas me ver 3 meses depois disso! Estou codificando melhor e mais rápido que o nosso arquiteto de software!

Sugiro que você nunca pare de aprender! Minha moto - > Continue aprendendo e mantenha a calma :) Não dependa do chefe seja independente e pergunte a ele diretamente, mas apenas os problemas mais difíceis. Porque você será feliz depois de descobrir por sua própria resarch. E lembre-se quando você parar de aprender algo errado, aprenda o dia como ser um bom programador.

Se você aprender com o chefe, nunca será melhor que ele defina seu próprio padrão, aprenda digitação cega, VIM ou VIM para o seu IDE, Linux wmii, para que você um dia vá além do chefe e seja melhor do que ele!

    
por 12.02.2015 / 08:19
fonte
0

Como outros já mencionaram, isso é bastante comum, mas isso não significa que você só precisa engolir tudo. Você não precisa entender tanto do código com a profundidade que pensa, e há estratégias concretas para tornar o "deep end" muito mais superficial:

  • Encontre algo no código relacionado à tarefa em questão. Normalmente, o mais fácil de procurar é algo visível para o usuário, como o rótulo do botão na GUI. Anote onde você encontrou. Este será o seu ponto de ancoragem.
  • Agora, pesquise o código a um passo e anote isso. Quem cria o botão? Qual código é chamado quando o botão é clicado?
  • O controle de origem costuma ser útil para encontrar código que esteja a um passo de distância. Descubra quando o código que você está vendo foi adicionado ou alterado, e veja o que mais foi verificado ao mesmo tempo e por quê.
  • Repita até que você entenda o suficiente para fazer a alteração, além de um nível mais profundo, para ter certeza de que não está perdendo nada.
  • Se você ficar preso a qualquer momento, agora você tem uma pergunta muito específica a ser feita. Por exemplo, "não consigo descobrir de onde esse botão é instanciado".
por 11.02.2015 / 18:03
fonte
0

Aqui estão meus $ 0,02 sobre o assunto. Não estou sugerindo uma resposta exclusiva, muito do que foi dito aqui é bastante relevante.

Eu tentaria um pouco de engenharia social para organizar as coisas de modo que seu chefe achasse mais fácil / menos demorado comentar algo do seu código do que não fazê-lo.

Agora, isso pode ser bem fácil se você estiver disposto a assumir um grande risco e irritá-lo - mas não queremos fazer isso. (Nota: Você pode deixar de ser capaz de fazer qualquer coisa sem ele escrever ou ditar comentários para você, você insistir e importuná-lo sobre isso interminavelmente, etc.)

Qual é a alternativa, então? Algumas idéias, dependendo da circunstância.

Opção 1

  1. Aproveite o tempo para entender uma parte de seu código como fazendo X.
  2. Agora pense em uma maneira razoável de Y a entender mal isso.
  3. Diga ao chefe (por e-mail ou diga no café da manhã ou não) que você está tentando descobrir.
  4. Adicione um comentário dizendo que não está claro o que o código significa, mas você entende isso como Y; tente tornar este comentário visível para ele - mas não tente muito!
  5. Aja assumindo Y - e faça certeza que seu chefe perceba sua ação (para que você não perca tempo trabalhando por um longo tempo com uma suposição falsa).
  6. O chefe deve tomar a iniciativa de corrigir você. Neste ponto, diga-lhe algo como "Eu realmente gostaria que este código tivesse alguns comentários para me impedir de fazer a suposição errada. Corrigirei o comentário que adicionei para mim. Você acha que poderia me ajudar com alguma descrição geral?" Eu não sou experiente o suficiente para descobrir a intenção exata, e eu sou apenas um par de frases que faria o truque ". Ou alguma coisa ..

Opção 2

Você está em treinamento. Tente organizar uma reunião semanal (adicional?) De freqüência fixa com ele. Nesta reunião, passe por cima de algum código - mas você precisa se preparar o suficiente para ele não ter que explicar cada linha. Em algum momento - espero - ele perceberá que pode pular a reunião se tiver acabado de adicionar os comentários.

Opção 3

Peça a outro colega que não compreenda o mesmo código que você. Vocês dois se aproximam do chefe em momentos diferentes, fazendo as mesmas perguntas. Essa é uma maneira infalível de fazê-lo perceber que ele não está fazendo algo ... mas nem todo mundo tem o luxo de colegas de trabalho úteis no mesmo projeto.

    
por 13.02.2015 / 10:39
fonte
0

So just something that will help my out until I get a grip on things, how can I ask my boss to put comments into his code that he gives me, but politely?

Se você não consegue entender o código, por que acha que os comentários são sua solução?

Eu não conheço seu estilo de programação, mas admito que, se o nome de funções e variáveis são enganosas, isso dificulta a compreensão de um código. Mas se nomes e funções ou até mesmo a organização do programa (classes, métodos, propriedades ...) forem de modo a tornar o código compreensível, então o código realmente falará consigo sozinho.

É melhor perguntar a ele sobre a arquitetura do programa e, se você quiser solicitá-lo, solicite nomes mais significativos para as funções; isso é mais conveniente para ele fazer.

    
por 15.02.2015 / 17:37
fonte
0

Mesmo que haja uma maneira de fazer isso educadamente, existem duas possibilidades sobre o que seu chefe vai pensar sobre os comentários em seu código:

  1. Ou os comentários em seu código seriam bons, ou

  2. Não é bom ter comentários em seu código.

Se o seu chefe achar que os comentários em seu código não seriam bons, (e há argumentos muito bons para isso, ou seja, o código deve ser a documentação , e < em> nenhuma documentação jamais estipulará algo tão precisa e inequivocamente quanto o código que realmente o faz , então nada acontecerá.

Agora, se por acaso seu chefe achar que seria bom ter comentários em seu código, existe uma chance considerável de ele lhe dizer para estudar o código dele, entender como funciona e continuar adicionando comentários ao seu código você mesmo . (Existem argumentos muito bons para isso também, ou seja, você precisa aprender , e seu tempo é, por definição, muito mais valioso do que o seu .

Então, a menos que você esteja preparado para fazer isso, talvez seja melhor não dizer nada.

    
por 10.02.2015 / 10:57
fonte
0

Como engenheiro de software de 20 anos, trabalhando principalmente em assuntos relacionados à segurança (SF-PD), eu tenho que dizer que seu chefe pode não ser a pessoa que você quer ser seu exemplo. A falta de comentários é um sinal de um programador amador autodidata que nunca aprendeu como fazer o trabalho corretamente ou de um engenheiro inexperiente. Ou talvez um engenheiro que simplesmente não tenha tempo - prazos e expedientes podem fazer coisas horríveis com seu código! ;) É definitivamente um antipadrão para todos os engenheiros de software competentes.

Seu chefe pode ser um bom programador, mas parece que ele não é um bom engenheiro de software. Um engenheiro usa a experiência do grupo coletivo para evitar as armadilhas que outras pessoas já foram pegos por. Comentários efetivos fazem parte dessa experiência de grupo coletivo para software, da mesma forma que a análise de estresse faz parte da experiência coletiva do grupo para engenharia mecânica. O que conta como um comentário eficaz é mais fluido, e é definitivamente algo que você obtém da experiência.

A coisa mais básica é que os comentários não devem dizer o que uma linha de código faz. Há momentos em que os comentários para dizer o que uma função faz também são supérfluos (especialmente em C #). O excesso de comentários pode ser tão ineficaz (e um indicador da falta de experiência), porque você não consegue encontrar as coisas importantes na escória. Como um novato, você ainda pode estar trabalhando para descobrir o "o quê" do código, e para isso você só precisa ler e entender o que ele fez.

O importante para os comentários é que eles dizem PORQUE uma linha de código ou uma função faz o que faz, onde isso pode não ser óbvio. Você precisa configurar o módulo X antes do módulo Y? É importante verificar um código de retorno para ver se um arquivo já estava aberto ou estamos conscientemente ignorando o código de retorno porque isso foi verificado em algum outro lugar? O "porquê" do código será relevante para todos, independentemente da experiência - e será relevante para ele também daqui a 6 meses, quando se esquecer do bom motivo de fazer algo de uma maneira particular. Comentar não é só para outras pessoas, é para ajudar você no futuro também.

Se você quiser evitar incomodar seu chefe, faça perguntas inteligentes. Concentre-se em perguntar sobre o "porquê" e tente descobrir o "quê" (a menos que seja genuinamente obscuro). Nenhum bom chefe se importará em fazer perguntas se não forem o tipo de coisas que você poderia ter encontrado no R-ing TFM. E nenhum bom engenheiro se importará em fazer algo que facilite significativamente a vida de outro engenheiro, a um custo pequeno para eles. (Apenas não peça a ele para preencher comentários em toda a base de código!);

    
por 09.02.2015 / 13:40
fonte
0

Já na situação semelhante, eu diria

  1. Seu chefe pode querer que você aprenda o caminho sujo (andando pelo código que você não tem ideia) por um motivo. É assim que aprendemos mais em um mês no trabalho do que em um ano na faculdade, como mencionado em outras respostas.

  2. Esta é "a norma", como mencionado em outras respostas. Você deve estar mais preocupado sobre onde começar e como abordar e o que focar do que tentar entender cada linha de código imediatamente. Pergunte ao seu chefe sobre as ferramentas certas e maneiras de depurar / percorrer o código. Esse tipo de pergunta comprará alguns pontos para você.

  3. Em uma base regular, continue se aproximando do seu chefe para obter feedback sobre como você está indo, para ter uma idéia de onde você está em termos percentuais, supondo que seu chefe tenha visto um bom número de pessoas na mesma situação. idéia de como eles fizeram.

  4. Leve isso como uma oportunidade e, à medida que melhorar a compreensão do código, continue adicionando comentários que originalmente esperavam que perguntassem ao seu chefe.

por 09.02.2015 / 23:36
fonte
0

Se você realmente quer tentar pedir a ele para colocar comentários em seu código (eu não recomendo) eu sugiro encontrar um código que você precise editar que possa realmente usar alguns comentários (a maioria é autoexplicativa) e perguntar A pergunta sobre isso "Eu estava olhando para este código aqui e estou tentando descobrir [problema que você está tendo] e não consegui encontrar nenhum comentário para ajudar a explicar isso". Basicamente, tente mostrar que você se esforçou para entendê-lo e explicar por que é que ambos poderiam se beneficiar com os comentários.

Provavelmente, 90% do código bem escrito não precisa de comentários. Você só quer documentar as partes do código que foram otimizadas e se tornaram bastante tensas. Eu trabalhei em uma empresa uma vez que exigia que você documentasse cada parte do código que você modificou, basicamente os comentários acabaram sendo ativamente prejudiciais para a legibilidade do código, porque eles frequentemente se referiam ao código que havia sido removido ou modificado além do reconhecimento. Cuidado com os comentários ruins Eu passei uma semana depurando uma função e no final eu achei que o comentário que eu continuei lendo sobre definir tal e tal flag como "false" foi na verdade toda a questão que eu coloquei a bandeira como "true" e tudo funcionou como deveria.

    
por 10.02.2015 / 00:18
fonte
0

Se você quiser que os comentários no código entendam por que algo foi escrito, é bem provável que (considerando que você é novo) você ainda não entendeu as necessidades do negócio. Tenho certeza que você sabe toda a sintaxe e pode ler o código, mas a menos que você saiba o propósito de algum código, você se sentirá um pouco perdido.

Uma coisa que vem à mente é a programação em pares. Você diz que seu chefe está impressionado com o seu progresso, então você poderia sugerir trabalhar ao lado dele. Isso ajudará vocês dois a longo prazo. Seu chefe terá que explicar as coisas que ele considera como certas e você aprenderá mais sobre o negócio.

    
por 11.02.2015 / 10:51
fonte

Tags