Conhecimentos Básicos para Iniciantes em Programação – Cursos de Programação -Olá pessoal, Fabio Akita Neste terceiro episódio da série “Começando aos 40” vamos finalmente começar a falar sobre o currículo básico pra quem quer se tornar um desenvolvedor Web.
Conhecimentos Básicos para Iniciantes em Programação
Cursos de Programação – Veja que não existe somente Web, você pode escolher desenvolvimento mobile para
fazer apps para smartphones ou mesmo algo mais tradicional como aplicativos nativos Desktop
Todo mundo que tá iniciando tem que começar do zero, um pouco de HTML, um pouco de CSS,
um pouco de Javascript. Quem está fazendo algum curso de tecnólogo começa com um pouco
de Java, talvez um pouco de C# ou PHP.
Mas praticamente todos esses cursos falham em
mostrar TUDO que você realmente vai precisar pra montar uma carreira. Claro, como eu já
disse antes, sabendo um pouco do básico, você já começa a ser capaz de começar a trabalhar.
E a importância de trabalhar numa empresa com uma equipe é porque justamente você ainda não vai
ser capaz de fazer um projeto do começo ao fim sozinho, simplesmente porque em 1 ou 2 anos
é impossível saber tudo que se precisa.
E o que exatamente é esse TUDO que se precisa?
Eu disse que essa série vai ser bem longa. No episódio de HOJE vamos começar com os
conhecimentos mais básicos que você vai precisar. Vamos lá.
(…)
Um ou dois anos atrás eu esbarrei num repositório
no GitHub chamado Developer Roadmap, ele tem sido atualizado uma vez por ano e a versão 2019 está
lá. O autor por acaso é de uma empresa de cursos chamada Hackr.io que eu nunca parei pra ver então
não sei dizer se os cursos são bons ou não.
Esse roadmap é um mindmap, que é uma representação
gráfica de idéias em conceitos, na prática é um monte de caixinhas ligadas num gráfico. O que
eu achei interessante é que ele lista caixinhas obrigatórias pra cada carreira e caixinhas
opcionais mas desejáveis e, no geral, eu concordo com as divisões e prioridades que ele colocou,
então é uma boa referência pra vocês.
E note que eu disse que ele atualiza todo
ano. Nos últimos 2 anos não mudou tanto, mas se ele tivesse começado 5 ou 10 anos
atrás, vocês iriam ver que a carreira mudou bastante nesse período. Lembra no episódio
anterior que eu falo sobre o tempo? Pois é, considere que esse roadmap pode mudar muito ainda
daqui 2 anos ou mais. Se você for aprender TUDO que está nesse roadmap, se estudar e treinar com
afinco, vai precisar de uns 3 a 5 anos, no mínimo.
E eu diria que esse roadmap é básico, tem muito
mais além disso ainda. Mas não se assuste, você não precisa saber tudo de uma vez só, mas tenha
na cabeça que nossa carreira vai exigir que você esteja estudando constantemente. Não existe fazer
um curso de 6 meses e achar que já sai tudo.
Este roadmap se divide em QUATRO partes. Primeiro,
e o tema deste episódio, são conhecimentos gerais que todo mundo precisa saber. Daí ele separa
em carreira de desenvolvedor Front-end que se preocupa mais com a parte visual que as pessoas
normalmente vêem, o HTML e CSS final, Javascript e tudo que envolve usabilidade. Então você
tem Back-end que é a carreira mais complexa em termos de coisas pra aprender e se preocupa com o
software que roda por trás, as regras de negócio, as integrações, os bancos de dados. Finalmente uma
carreira nova que chamamos erroneamente de Devops, vou explicar porque em outro episódio. E como eu
disse antes, essas não são as únicas carreiras, só as primeiras TRES dentro do mundo de Web.
A idéia é você usar esse Roadmap como um checklist.
Cada caixinha amarela é um corpo de
conhecimentos grande. Você vai encontrar cursos inteiros pra cada caixinha. Mas lembre-se do
que eu já falei no meu episódio sobre Faculdade: você não deve tentar aprender 100% de cada
assunto de uma só vez. Aprenda no máximo 20%.
Os primeiros 20% que vai te permitir
resolver 80% dos problemas. Vou dar um exemplo. Na primeira parte, de conhecimentos
gerais, a primeira caixinha é GIT.
GIT é um versionador de arquivos. Essa ferramenta
foi desenvolvida inicialmente pelo criador do kernel do Linux, o famoso Linus Torvalds e o
atual mantenedor é Junio Hamano. Pense assim: como centenas de desenvolvedores podem editar
os mesmos códigos num projeto como o Linux e não virar uma bagunça colossal? É por
causa de ferramentas como o GIT.
Nos anos 90 e começo dos 2000 haviam várias,
como CVS que era uma grande porcaria mas era o que tinha, substituído pelo Subversion ou SVN que
era menos porcaria e eu usei muito e inclusive fiz um patch pra ferramenta TortoiseSVN pra ele
funcionar em Windows em projetos com Visual Studio que não suportava diretórios que começa
com ponto. Haviam ferramentas comerciais bem porcaria como Rational Clearcase ou a droga do
Microsoft SourceSafe.
Eram todos versionadores centralizados, e daí nos anos 2000 começamos a ir
para versionadores distribuídos como BitKeeper, Perforce, Darcs, Bazaar que era
usado pela Canonical, Mercurial.
Eu comecei a evangelizar Git no Brasil por volta
de 2007 como você pode ver em meus blog posts mais antigos linkados na descrição abaixo. E
nós da comunidade Ruby on Rails ajudamos muito o GitHub – que é feito em Ruby on Rails – a
crescer rapidamente.
Por causa disso GIT se tornou o padrão embora em ambientes comerciais
alguns ainda fiquem presos a ferramentas como o Microsoft Team Services. Mas esquece, 99%
do mundo de desenvolvimento usa GIT pelo simples fato que a maior parte dos melhores software
open source do mundo estarem lá no GITHUB.
O GIT em si possui centenas de comandos e
permutações. Você usa GIT pra baixar código dos repositórios preservando um histórico
de “commits” que são trechos de alteração de código.
Você pode navegar pra trás no tempo num
sistema desses e recuperar o estado do código como ele era ontem ou semana passada ou ano passado.
E cada modificação que você faz você empacota nesses “commits” e empurra (ou dá push) pra um
repositório elegido como central que todos usam, embora GIT em si não precise de um servidor
central. O fluxo de trabalho com GIT que a maioria dos desenvolvedores Web usam é derivado do que
nós da comunidade Rails desenvolvemos junto com o GitHub, o mecanismo que chamamos de Pull Requests
e Forks. A comunidade do Kernel do Linux usa um fluxo de trabalho diferente por exemplo.
Agora, os tais 20% que eu falei antes?
Você precisa saber talvez uma dúzia só de comandos
como “git init” pra iniciar um repositório, “git add” pra acumular as modificações que fez agora,
“git commit” pra empacotar essas modificações, “git push” pra enviar as modificações pra outro
repositório de origem, “git pull” pra puxar as últimas modificações desse repositório.
Se você dominar esses comandos já consegue participar de um projeto. Só que isso é o
ultra básico, porque existem vários coisas importantes que você vai precisar aprender como
o que são branches e como trocar de branches, como fazer cherrypicking, como reescrever commits,
as diferenças entre rebasing e merge, o que é stage, pra que serve squash de commits, pra que
serve bisect, pra que serve reflog, diferenças entre reset e clean, e assim por diante.
Mas você pode ir aprendendo um comando de cada vez.
O Git é praticamente um sistema de arquivos
avançado, sua estrutura de dados é baseado num DAG que é um Direct Acyclic Graph e se você entender
como ele funciona internamente você pode usar o GIT pra fazer coisas avançadas. Por exemplo, você
poderia criar um produto que é um mini-clone do Dropbox usando GIT. Você pode integrar o
GIT com sistemas de deployment, ou seja, que toda vez que você dá push no repositório ele
toma uma ação como atualizar o servidor ou rodar os testes do repositório num sistema de Continuous
Integration. As opções são infinitas.
Mas atenha-se em aprender os primeiros 20%, a
primeira uma dúzia de comandos. Não se preocupe, se você for curioso, você vai aprender tudo do
GIT eventualmente.
Mas se tentar aprender TUDO de uma só vez, você vai ficar meses estudando a
teoria e não vai entender tudo. Gaste uma semana em tutoriais iniciais do GIT. O próprio GitHub tem
o site Github Guides que vai te dar o básico. E obviamente treine em dezenas de arquivos na sua
própria máquina. Erre dezenas de vezes pra ver o comportamento de cada comando, teste os limites
de cada comando. Mas de onde vamos arranjar esses arquivos e projetos pra você treinar?
O Roadmap está correto em colocar GIT em primeiro lugar porque uma das coisas que
você logo no começo PRECISA fazer é fuçar MUITO o GitHub. Agora, entenda uma GRANDE
verdade de qualquer curso ou tutorial:
TODOS os passos que eles mostram SEMPRE funcionam,
porque a demonstração foi preparada pra funcionar. Começa com algum exercício do tipo, “vamos fazer
um aplicativo de lista de tarefas” daí ele vai te dando passo a passo tudo na ordem certa pra
no final você ter um pequeno aplicativo. Mas os passos só funcionam dentro de um ambiente
muito controlado, quase de laboratório, se divergir um pouquinho vai dar errado e
você não vai saber o que tem que fazer.
Pra quem só está iniciando, claro que é importante
ver as coisas sendo construídas de forma ordenada. Só entenda que isso é irreal. Todo tutorial
e curso não tem absolutamente nada a ver com a vida real. Na vida real você quase sempre
vai participar de um projeto que já existe, ou começar com outras pessoas, e vai baixar código
que já existe e ter que participar do código dos outros. E esse código não vai estar perfeito,
aliás, normalmente vai estar MUITO longe de perfeito, as coisas vão quebrar, as instruções
não vão funcionar, e você vai ficar em dúvida se é o código do projeto que tá quebrado ou você
que não tá entendendo alguma coisa trivial.
Muito do processo de programação é tentativa
e erro. Um dos grandes defeitos de cursos e tutoriais é que eles mostram só o passo a passo
perfeito. Tutoriais não ensinam a lidar com erros e isso é um enorme problema. Eu mesmo cansei
de receber mensagens de pessoas que falam
“Akita, tava seguindo esse tutorial e deu
um erro, você sabe como resolve?”
Daí eu falo “me manda a mensagem de erro que
tá aparecendo aí”. Daí eu pego essa mensagem, jogo no Google, e mando o primeiro link
que aparece e pergunto “e aí, era isso?”, aí a pessoa responde “puuuuuta Akita você
é [ __ ] mesmo, resolveu!” …. Aí eu fico …
“filho da mãe, eu virei proxy do Google”!!
Sério, se você é iniciante, assuma que 99% de todos os erros que você encontrar, você
certamente não é o primeiro. Muita gente já passou pelo mesmo erro que você tá passando e
eles já foram documentados nas Issues do GitHub, ou em sites como Stackoverflow, Stackexchange,
fóruns como Reddit. Antigamente, nos anos 80 e começo dos 90, a gente simplesmente não tinha onde
procurar online, porque nem tinha internet!! Então quando tinha um erro, a gente precisava aprender
a descobrir tudo sozinho. Por isso o povo dependia de empresas como Microsoft, BEA, IBM ou outros que
costumavam ter uma comunidade interna somente pra quem pagava a assinatura e você tinha acesso a
bancos de conhecimento que vinham em CDs como o MSDN. Mas hoje em dia, o Google vai te responder
90% das coisas que você vai precisar.
Isso tudo dito, em vez de ficar só fazendo passo a
passo de vários tutoriais, vá no GitHub e procure alguma coisa como “clone instagram javascript”,
vai aparecer vários. Alguns muito parecidos, alguns uma porcaria. Não importa. E agora
que você já aprendeu o básico de Git, clone o projeto na sua máquina e tente rodar.
Você vai sofrer um bocado da primeira vez e vai cair na segunda caixinha amarela do
Roadmap que diz “Basic Terminal Usage”.
Essa caixinha junto com outras como “SSH” vai te dar MUITO trabalho. Entenda outra verdade:
quando você for subir seu primeiro
projeto de verdade para o público, ele não vai estar na sua máquina, vai estar
num servidor. Seja você um programador front-end ou back-end você PRECISA o quanto antes
aprender mais sobre sistemas operacionais.
A maioria de vocês provavelmente está usando
Windows. E não tem nenhum problema. Eu uso Windows também. Porém você obrigatoriamente deve
aprender sobre distribuições baseadas em Linux. Você pode fazer isso do jeito difícil ou do jeito
ultra difícil. O jeito difícil, se sua máquina aguentar é baixar e usar o programa Virtualbox
ou versões pagas como VMWare ou Parallels.
Hoje em dia se tornou muito comum rodar Linux
em máquinas virtuais. Todo novo CPU suporta o que chamamos de instruções VT-X no caso da
Intel ou AMD-V no caso da AMD que são funções da CPU para fornecer o máximo de performance de
acesso ao hardware quanto possível em ambientes virtualizados. Significa que você consegue rodar
uma distribuição de Linux como Ubuntu, Fedora ou Arch inteira dentro de um Virtualbox.
A maioria das pessoas nunca instala seu próprio sistema operacional, nem configura nada.
Simplesmente compra a máquina e usa do jeito que veio. Isso é horrível. Um programador escreve
software. Software é código que diz à máquina o que fazer. A máquina é controlada por um
sistema operacional.
Se você não conhece o sistema operacional, sua programação sempre
vai ter muito achismo e chutes. Você acaba se tornando supersticioso e em vez de resolver
os problemas procura alguma mandinga.
É impossível aprender tudo só em poucos dias ou
semanas, por isso o melhor caminho pra começar é de cara tirar a rodinha da bicicleta e começar
a apanhar. Não comece com uma distribuição fácil como Mint ou Ubuntu. Comece instalando um sistema
operacional manualmente do zero e pra isso não há nada melhor do que uma distribuição Linux
como o Arch Linux, que me lembra um pouco minha época de Slackware 1.0 no meio dos anos 90.
Se você ainda não sabe disso, Linux é o nome do kernel, o binário responsável por iniciar a
máquina, configurar os dispositivos e oferecer serviços pros aplicativos podem falar com a
máquina. Existem dezenas de distribuições que usam o kernel Linux. O que varia em cada uma é a
seleção de aplicativos, formas de configuração, gerenciamento de pacotes e ecossistema. Na dúvida
você vai acabar escolhendo algo como Ubuntu, Mint, Elementary, Fedora, CentOS,
openSUSE, Manjaro, dentre outros.
Um Ubuntu ou mesmo Fedora são muito simples,
eles já fazem tudo pra você e no final é como se tivesse instalado um Windows ou
MacOS, você vai só apertando “próximo”, “próximo” e no final não aprendeu nada porque os
instaladores estão bons o suficiente pra fazer quase tudo sozinhos. Mas o Arch Linux não, ele
vai exigir que você realmente preste atenção, estude e vá configurando cada componente sozinho.
A cada passo você não vai saber o que precisa fazer e pra ajudar existe o site ArchWiki que
tem páginas inteiras detalhando cada pequeno componente do sistema em detalhes.
O Arch vai te forçar a ficar na linha de comando e digitar comandos que, mesmo que você
não entenda exatamente o que está fazendo, vai te dar a primeira sensação de que você está
colocando as mãos de verdade no computador. Vai ver dezenas de mensagens de erro e vai perder
horas em tentativa e erro a cada passo, e quando chegar ao final vai ter aquela satisfação de que
você fez alguma coisa funcionar sozinho.
Quando eu falo que as pessoas ficam supersticiosas
imagina quando alguma coisa não funciona, e o que é a primeira coisa que todo mundo pensa?
Ahh reboota a máquina que volta a funcionar. Nãaaao porque você vai rebootar? Primeiro tenta
entender se precisa rebootar. Normalmente é quando você muda alguma configuração que algum
serviço precisa, um daemon por exemplo.
Falando em daemons você vai precisar entender que
você sempre tem pelo menos 2 níveis de permissão no sistema, o acesso geral de administrador
ou root e o mais limitado, do seu usuário.
Um Spotify roda sob os privilégios do seu usuário e
não tem privilégios pra afetar coisas importantes do núcleo do sistema, como rebootar a máquina.
Mas existem serviços ou daemons – e nao DA-E-MONS daemons, que aliás, não tem nada a ver com diabo
mas com antigos demônios que performam tarefas em background -, que o sistema operacional
começa a iniciar depois do boot e rodam sob privilégios maiores pra poder controlar coisas
como sua rede, seu sistema de arquivos geral, tudo em background sem você perceber.
Um programa que você manualmente abriu como seu editor de textos você pode matar
a qualquer momento. Mas daemons, precisam de privilégios pra reiniciar, e aí
você começa a aprender sobre ferramentas como o “sudo” que você vai ver em vários tutoriais,
que permitem que seu usuário temporariamente tenha privilégios de administrador. No Windows
isso é aquela janela de confirmação que escurece sua tela toda pedindo uma confirmação e que
obviamente você nunca lê e só dá ok.
Mais do que isso, pra rodar linguagens como Javascript, Ruby, Python, PHP, Java,
você precisa saber quais versões instalar porque
códigos antigos podem precisar de versões mais antigas de cada linguagem. Se tentar rodar na
mais nova provavelmente vai falhar. Se você tem o Python mais novo instalado na sua máquina como a
versão 3, mas você entra numa empresa que precisa dar manutenção num projeto mais antigo que ainda
não foi atualizado, usando digamos Python 2.6, como você faz pra ter múltiplas versões rodando na
máquina ao mesmo tempo? Você vai ter que aprender que quando digita o comando “python” na linha
de comando ele vai olhar uma coisa chamada PATH, uma variável de ambiente, que diz em quais
diretórios procurar pelo executável. Se quiser ter múltiplas versões, basta instalar algum
gerenciador dessas variáveis VIRTUALENV ou o mais poderoso ASDF que vai gerenciar o PATH
e outras variáveis do ambiente pra você.
Mas pra isso você precisa ter essa noção que
cada linguagem é um conjunto de executáveis, coisas como interpretador, compilador, debugger,
bibliotecas. Onde eles ficam na sua máquina?
Como você, como programador, não sabe onde fica cada componente da linguagem que está usando?
Você PRECISA saber, então corre atrás disso.
Portanto, as duas coisas mais importantes que você PRECISA aprender e treinar logo de cara
é como gerenciar código usando ferramentas como GIT e serviços como GitHub e onde fica
cada ferramenta que você vai usar no sistema operacional. Você precisa aprender a ter controle
sobre sua própria máquina, porque a principal função de um programador é controlar as máquinas
para que façam exatamente o que você quer, e a forma de dar essas ordems é através de programas
gerados com o código que você escreve. Se você não consegue controlar seu sistema operacional e
sequer sabe onde estão suas ferramentas e porque elas funcionam, é a máquina que vai controlar
você e não o contrário.
Sem isso você sempre vai fazer algum código, muitas vezes vai chutar e se
realmente funciona você continua sem saber porque, e desse jeito nunca vai evoluir como programador.
Coloque isso na sua cabeça, a máquina serve a você e não o contrário. Domine suas ferramentas
e faça com que elas sirvam a você.
E como podem ver, hoje falamos somente das duas
primeiras caixinhas. Durante a série algumas serão mais curtas, algumas serão mais longas, mas o
assunto claramente é longo.
Aproveitem pra dar uma olhada no Developer Roadmap e já joguem dúvidas
nos comentários abaixo, talvez eu possa aproveitar algumas nos próximos episódios. Se curtiram o
vídeo deixem um joinha, compartilhem com seus amigos, assinem o canal e cliquem no sininho. A
gente se vê semana que vem, até mais!