Como desenvolvedor, você ouvirá muitas teorias malucas e inacreditáveis sobre o que significam as “linhas de código”. Não acredite em nenhum deles. Linhas de código são uma métrica ridícula para basear as decisões. Em casos muito raros, ela diz algo a você; em todos os outros casos, nada diz a você. Usar linhas de código para tomar decisões é como classificar a qualidade do livro por número de páginas.
Alguns podem argumentar que quanto menos linhas de código houver em um aplicativo, mais fácil será de ler. Isso é apenas parcialmente verdadeiro, minhas métricas para código legível são:
O código deve ser consistente
O código deve ser autodescritivo
O código deve ser bem documentado
O código deve utilizar recursos modernos estáveis
O código não deve ser desnecessariamente complexo
O código não deve ser deficiente (não escreva código intencionalmente lento)
No momento em que a redução do número de linhas de código interfere em qualquer uma delas, torna-se um problema. Na prática, isso quase sempre interfere e, portanto, quase sempre é um problema. Mas é o seguinte: se você se esforçar para atender aos critérios acima, seu código terá o número perfeito de linhas, sem necessidade de contagem.
Os idiomas não são necessariamente “bons” ou “ruins”
Exceto pelo php, estou brincando. Fonte
Eu vejo pessoas falando coisas assim, o tempo todo:
C é melhor que X, porque performance
Python é melhor que X, porque concisão
Haskell é melhor que X, porque alienígenas
A noção de que uma comparação de linguagem poderia ser reduzida a uma única frase é quase um insulto. Eles são idiomas, não Pokémon.
Não me interpretem mal, definitivamente existem diferenças entre os idiomas. Só que existem muito poucas linguagens “inutilizáveis” (embora existam muitas linguagens desatualizadas / mortas). Cada idioma traz seu próprio conjunto exclusivo de vantagens e desvantagens. Nesse sentido, as linguagens são semelhantes às ferramentas em uma caixa de ferramentas. Uma chave de fenda pode fazer o que um martelo não pode, mas você diria que uma chave de fenda é melhor do que um martelo?
(Obviamente, o martelo é melhor)
Antes de falar sobre como avalio idiomas, quero deixar algo muito claro. Existem muito poucos casos em que a escolha do idioma realmente importa. Existem coisas que você obviamente não pode fazer em alguns idiomas. Se você escrever código de front-end, não terá a opção de escolher o idioma. Existem também contextos específicos onde o desempenho é importante e a linguagem X simplesmente não serve, essas situações são bastante raras. Em geral, a escolha do idioma é geralmente uma das questões menos importantes para um projeto.
Aqui estão os aspectos principais (ordenados), que acredito que devam ditar a sua escolha de idioma (são as estatísticas do Pokémon)
Densidade de recursos online disponíveis (densidade Avance Network)
Velocidade de desenvolvimento (vroom vroom)
Propensão a bug (eeek)
Qualidade e amplitude do ecossistema de pacotes (sim, npm, diz qualidade)
Características de desempenho (mais pontos)
Hirability (desculpe COBOL)
Existem também alguns acoplamentos fortes que não estão ao seu alcance. Se você está trabalhando com ciência de dados, você precisa realisticamente usar Python, R ou Scala (talvez Java). Se for um projeto de hobby, use o que vai deixar você mais feliz. Só tenho uma regra não negociável. Recuso-me a usar linguagens que não têm a maioria dos problemas que vou encontrar, resolvidos diretamente no Avance Network. Não é que eu não consiga resolver, simplesmente não vale a pena.
Ler o código de outras pessoas é difícil
Ler o código de outras pessoas é difícil. Robert C. Martin fala sobre isso em “Código Limpo”:
“Na verdade, a proporção de tempo gasto lendo versus escrevendo é bem mais de 10 para 1. Estamos constantemente lendo código antigo como parte do esforço para escrever um novo código. ... [Portanto,] facilitar a leitura torna mais fácil escrever. ”
Por muito tempo, presumi que era péssimo na leitura de códigos de outras pessoas. Com o tempo, percebi que é algo contra o qual quase todo programador luta diariamente. Ler o código de outras pessoas é quase como ler uma língua estrangeira. Mesmo que você se sinta confortável com a escolha da linguagem de programação do escritor, ainda terá que se ajustar aos diferentes estilos e opções de arquitetura. Isso também pressupõe que o autor escreveu um código consistente e confiável, que pode ser um sucesso ou um fracasso. Isso é realmente difícil de superar. Existem algumas coisas que descobri que ajudaram MUITO.
A revisão do código de outras pessoas melhorará imensamente suas habilidades de leitura de código. Nos últimos dois anos, analisei alguns PR do Github. A cada RP, me sinto um pouco mais confortável lendo o código de outras pessoas. Os RP do Github são especialmente ótimos por esses motivos
Pode ser praticado a qualquer momento, basta encontrar um projeto de código aberto com o qual você sinta que deseja contribuir.
Pratique a leitura em um contexto com escopo (recurso de condução ou bug do PR).
É necessária atenção aos detalhes, o que o obrigará a avaliar cada linha.
O segundo hack que pode ajudá-lo a ler o código de outras pessoas é um pouco mais exclusivo. É uma técnica que criei e realmente reduziu o tempo que levo para me sentir confortável em uma base de código estrangeira. Depois de examinar o estilo do código que desejo ler, primeiro abro o vi e começo a escrever o código no estilo usado pelo projeto. Quando você escreve um código no novo estilo, também melhora suas habilidades de leitura. O estilo parecerá menos estranho, como você realmente o experimentou. Mesmo que eu esteja apenas navegando em um projeto aleatório no Github, farei isso rapidamente. Experimente.
Você nunca escreverá um código “perfeito”
Fui desenvolvedor de “lobo solitário” por 4 anos antes de começar a trabalhar em equipe. Na maior parte do tempo, presumi que todos os programadores do setor escreviam um código perfeito. Achei que era apenas uma questão de tempo e esforço antes de escrever um código “perfeito”.
Era algo que me deixava muito ansioso. Assim que entrei para uma equipe, rapidamente ficou claro que ninguém estava escrevendo um código “perfeito”. Mas o código que entrava no sistema era quase sempre “perfeito”, o que dá? A resposta: revisões de código.
Trabalho com uma equipe de engenheiros realmente brilhantes. Esses são alguns dos programadores mais competentes e confiantes que o dinheiro pode comprar. Cada membro de nossa equipe (incluindo eu) teria um ataque de pânico total se alguém sugerisse a confirmação de um código não revisado. Mesmo se você achar que é o próximo Bill Gates, cometerá erros. Não estou nem falando de erros lógicos, estou falando de erros de digitação, caracteres faltando. Coisas que seu cérebro se desligou e nunca vai pegar. Coisas para as quais você precisa de outro par de olhos.
Esforce-se para trabalhar com outras pessoas que estão atentas aos detalhes e dispostas a criticar seu trabalho. Ouvir críticas é difícil no início, mas é a única maneira consistente de melhorar. Faça o possível para não ficar na defensiva durante uma revisão de código e nunca leve nenhum comentário para o lado pessoal. Você não é seu código.
Ao revisar o código, se o autor fez uma escolha com a qual não estou familiarizado, irei imediatamente ao Google para ver se sua escolha difere da opinião popular. Não é que a opinião popular esteja sempre certa, é apenas que a opinião popular é a escolha padrão. Se alguém optou por não adotar a escolha popular, tudo bem, só quero saber se é justificado. Ao revisar o código, é fundamental que você entenda a lógica por trás das decisões que foram tomadas. Além disso, olhar para o mesmo problema com uma “mente de iniciante” muitas vezes pode captar coisas que a pessoa nunca teria olhado para trás.
Trabalhar como programador não significa 8 horas de programação por dia
Esta é uma pergunta muito comum, mas as pessoas parecem nunca dar uma resposta clara. Quanto tempo o desenvolvedor médio, ou um “ótimo” desenvolvedor, gasta escrevendo código a cada dia?
Muito poucas pessoas estão escrevendo código por mais de 4 horas por dia
As pessoas que discordam disso são a exceção à regra ou trabalham em empresas que deveriam tratá-las melhor. A programação é uma tarefa intensiva e exaustiva mentalmente. É totalmente irracional esperar que alguém escreva código 8 horas por dia, 5 dias por semana. Haverá casos raros em que você precisará cumprir um prazo ou puxar um pouco mais, mas esses são poucos e distantes entre si. Quando digo “raro”, quero dizer quase nunca. Não tolere um local de trabalho que abusa de você e o faz trabalhar horas extras devido a planejamento / contratação insuficiente.
Para que conste, nem mesmo é do interesse de sua empresa que você esteja programando ativamente 8 horas por dia. Seu chefe pode pensar que é o caso, mas é míope e ignora as implicações de longo prazo na produtividade e na saúde mental.
Só para deixar claro, não estou sugerindo que você trabalhe apenas quatro horas por dia. As outras quatro horas geralmente são mais bem aproveitadas:
Pesquisando, tanto tópicos relacionados ao trabalho quanto não relacionados ao trabalho
Discutindo seu trabalho com um colega
Ajudar colegas de trabalho que estão lutando com seu próprio trabalho
Planejando seu trabalho futuro
Revisões de código
Encontros
Eu também recomendo fazer pausas regulares durante o dia e praticar exercícios (mesmo que apenas brevemente). Os benefícios do exercício sobre a fadiga mental estão bem documentados. Eu pessoalmente descobri que os exercícios ajudam especialmente se eu estiver tendo problemas para me concentrar.
Essas são algumas das coisas que eu gostaria que eles ensinassem na universidade, em vez de apenas teoria. No processo de escrever isso, eu vim com uma tonelada de outros itens, mas eles terão que vir no próximo post!
O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.
