Como desenvolvedor, você ouvirá muitas teorias loucas e incríveis sobre o significado de "linhas de código". Não acredite em um único. Linhas de código são métricas ridículas. Em casos muito raros, ela diz algo, geralmente nada. Usar linhas de código para tomar decisões é como avaliar a qualidade do livro pela contagem de páginas.

Alguns podem dizer que quanto menos linhas de código em um aplicativo, mais fácil é ler. Isto é apenas parcialmente verdade. Aqui estão minhas métricas para código legível:

• O código deve ser consistente
  
• O código deve ser informativo.
  
• O código deve estar bem documentado.
  
• O código deve usar funções modernas estáveis.
  
• O código não precisa ser muito complicado
  
• O código não deve ser ineficiente (não intencionalmente escreva código lento)

Se a redução do número de linhas de código contradizer qualquer uma dessas métricas, isso se tornará um problema. Na prática, quase sempre interfere e, portanto, quase sempre é um problema. Mas eis o seguinte: se você se esforçar para atender aos critérios acima, seu código terá o número ideal de linhas - e você não precisará contá-las .

Os idiomas não são necessariamente "bons" ou "ruins"


Exceto php, é claro (uma piada). Fonte

Vejo pessoas dizendo essas coisas o tempo todo:

• C é melhor que X por causa do desempenho
  
• Python é melhor que X por causa da brevidade
  
• Haskell é melhor que X por causa de alienígenas

A idéia de que as comparações de idiomas podem ser reduzidas a uma frase é quase ofensiva. São idiomas, não Pokémon.

Não me interpretem mal, definitivamente existem diferenças entre os idiomas. Simplesmente não há praticamente línguas "inúteis" (embora existam muitas desatualizadas / mortas). Cada idioma tem seu próprio conjunto exclusivo de compromissos. Nesse sentido, eles se parecem com uma caixa de ferramentas. Uma chave de fenda pode fazer o que um martelo não pode, mas alguém dirá que uma chave de fenda é melhor que um martelo?

(Obviamente, o martelo é melhor)

Antes de falar sobre avaliação de linguagem, quero esclarecer uma coisa. Escolher um idioma muito raramente importa . Obviamente, algumas coisas não podem ser feitas em alguns idiomas. Se você está escrevendo para um frontend, não tem escolha. Existem contextos específicos em que o desempenho é importante e a linguagem X simplesmente não é adequada, mas essas situações são bastante raras. Em geral, a seleção de idiomas é geralmente uma das questões menos importantes para um projeto.

Aqui estão os principais aspectos em ordem, que, na minha opinião, devem influenciar a escolha do idioma (sem métricas específicas):

• Densidade dos recursos online disponíveis (densidade do StackOverflow)
  
• Velocidade de desenvolvimento
  
• Predisposição de erro
  
• A qualidade e a cobertura de um ecossistema de pacotes (sim, npm, falando sobre qualidade)
  
• Desempenho (mais pontos)
  
• Oportunidade de emprego (Desculpe, COBOL)

Alguns fatores importantes além da sua influência. Se você trabalha no campo da ciência de dados, realmente precisa usar Python, R ou Scala (possivelmente Java). Se este é um projeto de hobby, use o que você gosta. Eu tenho apenas uma regra indiscutível. Recuso-me a usar idiomas se a maioria dos possíveis problemas com esse idioma ainda não tiver sido resolvida no StackOverflow. Não é que eu não possa resolvê-los, simplesmente não vale o tempo.

É difícil ler o código de outra pessoa

Ler o código de outra pessoa é difícil. Robert K. Martin fala sobre isso no Pure Code: “De fato, a proporção de tempo para ler e escrever código é bem superior a 10 para 1. Lemos constantemente o código antigo quando tentamos escrever um novo código. ... [Portanto] aquilo que simplifica sua leitura também simplifica sua escrita. "

Por um longo tempo, pensei que estava apenas fraco em ler o código de outra pessoa. Com o tempo, percebi que quase todos os programadores enfrentam esse problema todos os dias. Ler o código de outra pessoa é como ler um texto em um idioma estrangeiro. Mesmo que você se sinta à vontade para escolher a linguagem de programação do autor do código, ainda precisará se adaptar a vários estilos e opções de arquitetura. Ele também pressupõe que o autor tenha escrito um código consistente e confiável, que pode ou não ser verdadeiro. Isso é realmente difícil. Existem algumas coisas que me ajudaram MUITO.

Uma revisão do código de outra pessoa melhorará muito suas habilidades. Nos últimos dois anos, fiz vários comentários sobre as solicitações de piscina no Github. A cada novo, sinto-me um pouco mais confiante em ler o código de outra pessoa. As solicitações de pool do GitHub são especialmente úteis pelos seguintes motivos:

• Aqui você pode realizar uma revisão a qualquer momento, basta encontrar um projeto de código aberto no qual deseja contribuir.
  
• Leitura em um contexto limitado (função única ou bug).
  
• Requer atenção aos detalhes, o que fará com que você aprecie cada linha.

A segunda técnica, que ajudará a ler o código de outra pessoa, é um pouco mais exclusiva. Essa é uma técnica que eu inventei e realmente reduziu a quantidade de tempo que eu preciso para me sentir confortável na base de código de outra pessoa. Depois de analisar o estilo de código que quero ler, primeiro abro o vi e começo a escrever o código no mesmo estilo. Quando você escreve um código em um novo estilo, ele também aprimora suas habilidades de leitura. O estilo se tornará menos estranho quando você o experimentar. Mesmo que eu assista a um projeto aleatório no Github, aplico rapidamente essa técnica. Tente você mesmo.

Você nunca escreverá código "perfeito"

Eu estava programando sozinho por quatro anos antes de começar a trabalhar em equipe. Na maior parte desse tempo, simplesmente assumi que todos os programadores do setor escreviam código perfeito. Decidi que era apenas uma questão de tempo e esforço antes de também escrever o código "perfeito".

Isso é algo que eu estava muito preocupado antes. Assim que entrei para a equipe, rapidamente ficou claro que ninguém estava escrevendo um código "perfeito". Mas o código incluído no sistema era quase sempre "perfeito". Como Resposta: revisão de código.

Eu trabalho com uma equipe de engenheiros realmente brilhantes. Estes são alguns dos programadores mais competentes e confiantes que você pode comprar por dinheiro. Cada membro da nossa equipe (incluindo eu) começará um verdadeiro ataque de pânico se alguém se oferecer para confirmar o código sem uma revisão. Mesmo se você pensa que é o próximo Bill Gates, com certeza cometerá erros. Eu nem estou falando de erros lógicos, estou falando de erros de digitação, caracteres perdidos. Que seu cérebro simplesmente não percebe. Para que servem outros olhos.

Tente trabalhar com outras pessoas atentas aos detalhes e dispostas a criticar o seu trabalho. Ouvir críticas é difícil no começo, mas é a única maneira consistente de melhorar a situação. Faça o possível para não assumir uma posição defensiva durante a revisão do código e nunca tome nenhum comentário pessoalmente. Você não é seu código.

Em uma revisão de código, se o autor fez uma escolha com a qual não estou familiarizado, pesquisarei imediatamente no Google se sua escolha for diferente da opinião popular. Não é que a opinião popular esteja sempre certa, apenas a opinião popular é a escolha padrão. Se alguém decidiu não aceitar a escolha popular, tudo bem, só quero saber que é justificada. Ao revisar o código, é muito importante que você entenda a lógica das decisões tomadas. Além disso, olhando para o mesmo problema da perspectiva de um iniciante , muitas vezes é possível notar coisas às quais uma pessoa nunca teria prestado atenção.

O trabalho de um programador não significa 8 horas de programação por dia

Essa é uma pergunta muito comum, mas as pessoas nunca dão uma resposta clara. Quanto o desenvolvedor médio ou o desenvolvedor "excelente" gasta escrevendo código todos os dias?

Muito poucos códigos mais de quatro horas por dia

Aqueles que discordam disso são exceções à regra ou trabalham para empresas que as exploram demais. A programação é uma tarefa mentalmente exaustiva e intensa. É completamente irracional esperar que alguém escreva o código 8 horas por dia, cinco dias por semana. Há momentos em que você precisa cumprir prazos ou fazer um pouco mais por sessão, mas há alguns deles e eles são raros. Quando digo "raramente", quero dizer quase nunca. Evite fluxos de trabalho que abusam de você e fazem você trabalhar horas extras devido a falta de planejamento / falta de pessoal.

Para o protocolo, mesmo a própria empresa não é lucrativa para você programar ativamente 8 horas por dia. Seu chefe pode pensar que sim, mas é míope e ignora as consequências a longo prazo, pois afeta a produtividade e a saúde mental.

Por uma questão de clareza, não sugiro que você trabalhe apenas quatro horas por dia. As quatro horas restantes geralmente são mais bem gastas em:

• Pesquisa, relacionada ao trabalho e não relacionada
  
• Discussão do seu trabalho com colegas
  
• Ajude colegas que têm problemas com seu próprio trabalho
  
• Planejamento futuro do trabalho
  
• Verificação de código
  
• Reuniões

Também recomendo fazer intervalos regulares durante o dia e praticar esportes (pelo menos não por muito tempo). Os benefícios do exercício para combater a fadiga mental estão bem documentados. Pessoalmente, achei que o exercício é especialmente útil se houver problemas com a concentração.

Essas são algumas coisas que eu gostaria de aprender na universidade, em vez de uma teoria pura. No processo de redação, pensei em várias outras nuances, mas esse é um tópico para um artigo separado!