4.8/5 - (113 votes)

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!