Aprenda a ler a fonte, Lucas

No cálculo da comunicação, escrever parágrafos coerentes que seus colegas seres humanos possam compreender e entender é longe mais difícil do que digitar algumas linhas de código de software que o intérprete ou o compilador não vai vomitar.

É por isso que, quando se trata de código, toda a documentação provavelmente é uma porcaria. E como escrever para pessoas é muito mais difícil do que escrever para máquinas, a documentação será continuar a não prestar para o futuro próximo. Há muito pouco que o senhor possa fazer a respeito.

Exceto por uma coisa.

O senhor pode aprender a ler a fonte, Luke.

O poder transformador do “código-fonte sempre incluído” em JavaScript é uma das principais razões pelas quais eu criei – e continuo acreditando em – o Lei de Atwood. Mesmo que o “view source” não esteja incluído (mas deveria estar), o senhor deve exigir acesso ao código-fonte subjacente da sua pilha. Não importa o que a documentação diga, o código-fonte é a verdade suprema, a melhor, mais definitiva e mais atualizada documentação que o senhor provavelmente encontrará. Isso será verdade para semprePortanto, quanto mais cedo o senhor aceitar isso, melhor será como desenvolvedor de software.

Eu tinha um artigo inteiro para escrever sobre isso, mas depois descobri que o O artigo de Brandon Bloom brilhante post sobre o assunto no Hacker News. Leia com atenção, pois ele explica a virtude de ler o código-fonte e em que contexto o senhor precisa para ler a fonte, muito melhor do que eu poderia:

Comecei a trabalhar profissionalmente com plataformas da Microsoft aos 15 anos de idade, mais ou menos. Trabalhei para a Microsoft como desenvolvedor de software, fazendo trabalho de integração no Visual Studio. Mais de dez anos depois de ter escrito uma linha de Visual Basic pela primeira vez, gostaria de nunca mais poder fazer links para uma biblioteca fechada.

Usar software é diferente de criar software. Quando o senhor usa a maioria dos softwares para sua função principal, é um caminho bem usado. Outros já encontraram os problemas e um número suficiente de pessoas se manifestou para que os principais colaboradores corrigissem o problema. Mas quando o senhor está criando um software, está fazendo algo novo. E há tantas maneiras de fazer isso que o senhor encontrará partes não utilizadas, cantos enferrujados e caminhos de código experimental inacabados. O senhor encontrará casos extremos que sabidamente estão quebrados, mas que foram contornados.

Às vezes, a documentação não está completa. Às vezes, ela está errada. O código-fonte nunca mente. Para um desenvolvedor experiente, ler o código-fonte pode ser mais rápido… especialmente se o senhor já estiver familiarizado com a arquitetura do pacote.
Estou em um espaço de trabalho compartilhado de médio porte com várias startups. Muitos dos outros CTOs e engenheiros procuram nossa equipe para pedir orientação e conselhos ocasionalmente. Quando as pessoas relatam um problema com sua pilha, a primeira pergunta que faço é: “Bem, o senhor leu o código-fonte?”

Eu incentivo os desenvolvedores a clonar no git tudo e qualquer coisa de que dependam. No início, todos têm medo. “Esse projeto é muito grande, nunca o encontrarei!” ou “Não sou inteligente o suficiente para entendê-lo” ou “Esse código é tão feio! Não aguento olhar para ele”. Mas o senhor não precisa pesquisar tudo, só precisa seguir o rastro. E se o senhor não consegue entender a plataforma abaixo de si, como poderá entender seu próprio software? E, na maioria das vezes, o que os desenvolvedores inexperientes consideram bonito é superficial, e o que eles consideram feio é um código pronto para a produção, endurecido pela batalha, criado por hackers mestres.
Agora, um ou dois anos depois, alguns desenvolvedores vieram até mim e me agradeceram por tê-los forçado a afundar ou nadar nas bases de código de outras pessoas. Eles estão melhores em seu ofício e se perguntam como conseguiram fazer alguma coisa sem o código-fonte no passado.

Quando o senhor dirige uma empresa, se seu software tiver um bug, seus clientes não se importam se a culpa é sua, do Linus ou de algum desenvolvedor de Rails aleatório. Eles se importam que seu software tenha um bug. O software de todos se torna meu software porque todos os bugs deles são meus bugs. Quando algo dá errado, o senhor precisa procurar o que está quebrado e consertar. O senhor deve corrigi-lo no ponto certo da pilha para minimizar os riscos, os custos de manutenção e o tempo de resposta. Às vezes, uma solução rápida é a melhor opção. Outras vezes, o senhor precisará recompilar o compilador. Muitas vezes, o senhor pode pedir a outra pessoa para corrigi-lo no upstream, mas com a mesma frequência, precisará corrigi-lo você mesmo.

• As lojas de software fechadas têm duas opções: implorar por generosidade ou contornar a situação.
• As lojas de código aberto com desenvolvedores mais fracos tendem a agir da mesma forma que as lojas de software fechadas.
• As lojas mais antigas tendem a desenvolver lentamente os músculos necessários para manter suas próprias bifurcações, correções e outros aspectos.

Os verdadeiros hackers chegaram a um acordo com um fato simples: se for executado em minha máquina, o software é meu. Sou responsável por ele. Devo entendê-lo. A criação a partir do código-fonte é a regra e não a exceção. Preciso controlar meu ambiente e minhas dependências.

Ninguém lê o código de outras pessoas por diversão. Que diabo, Eu nem gosto de ler meu próprio código. A ideia de que o senhor se acomodaria em uma cadeira de couro, com seu paletó de fumante e uma taça de conhaque para uma bela noite de leitura do código de outra pessoa é absurda.

Mas precisamos acessar o código-fonte. Nós devemos ler o código de outras pessoas porque temos que entendê-lo para fazer as coisas. Portanto, não tenha medo de leia a fonte, Luke – e siga-o onde quer que ele o leve, por mais assustador que seja o código.