Como Ser Um Programador Melhor Na Visão De Um Desenvolvedor Android
(3214) (1)
CategoriasAndroid, Design, Protótipo
AutorVinícius Thiengo
Vídeo aulas186
Tempo15 horas
ExercíciosSim
CertificadoSim
CategoriaEngenharia de Software
Autor(es)Vaughn Vernon
EditoraAlta Books
Edição1ª
Ano2024
Páginas160
Tudo bem?
Acredito ser viável começar com o seguinte "levantamento": com que coragem e disposição um autor resolve intitular seu livro como "Como ser um programador melhor".
Conheço alguns desenvolvedores que, devido ao título, certamente diriam que o autor é militante no Twitter.
"Vê se isso é nome que se dá a um livro. É muita prepotência!"
Teorias e achismos à parte… acredite: o livro "Como ser um programador melhor", de Pete Goodliffe, é um excelente livro para qualquer desenvolvedor que não esteja iniciando em programação.
Ao final do artigo eu explico melhor sobre "(…) desenvolvedor que não esteja iniciando".
Voltando ao "excelente livro"…
acabei destacando isto logo no início principalmente porque Goodliffe é mais um daqueles autores de livros de desenvolvimento que ainda hoje é desenvolvedor profissional.
A publicação de livros é, aparentemente, um hobby para ele.
E vale lembrar que em uma de minhas resenhas eu informei que o título foco deste artigo era uma espécie de "irmão mais velho" do must read As Leis Fundamentais Do Projeto De Software.
E sim, "Como ser um programador melhor" é, o que podemos dizer: a versão mais completa (com 383 páginas) do livro de Max Kanat.
E se você achou o título "Como ser um programador melhor" um pouco soberbo.
Então fique sabendo que até mesmo sobre a postura de um desenvolvedor na cadeira o autor fala sobre no livro.
Ele não somente fala sobre, como tem um capítulo inteiro dedicado a este assunto. Mais precisamente o capítulo 30, Postura dos programadores.
Apesar do livro ser excelente…
é importante te alertar que o conteúdo é totalmente baseado nas aventuras e décadas de experiência do autor no mundo do desenvolvimento de software.
E quando digo "(…) aventuras e décadas de experiência do autor", em resumo eu também estou dizendo: nem eu e provavelmente nem você vai concordar com 100% do que estiver nas páginas do livro.
(Aliás, existe algum livro onde concordamos 100% com ele?)
Dito isso, tem um assunto em específico que Goodliffe defende que eu particularmente sou contra.
O autor "segura uma bandeira" comum no mundo do desenvolvimento: que os desenvolvedores têm que conhecer várias linguagens de programação.
Ele dá uma série de argumentos para defender esse ponto de vista dele. Onde o principal argumento se resume em:
Desta forma os desenvolvedores terão mais artifícios em mãos para resolver problemas de programação.
Eu vou totalmente pela mão oposta.
Acho sim prudente um profissional de desenvolvimento conhecer um máximo de duas ou três linguagens de programação comuns no mercado, na indústria de criação de software.
Mas desse conjunto de duas ou três linguagens, ao menos uma delas eu vejo ainda como mais prudente o desenvolvedor dominar, conhecer as APIs nativas e as principais APIs da comunidade.
Agora um destaque: o mais importante do que falei acima é o trecho "(…) linguagens de programação comuns no mercado".
Isso pois é inviável ter uma "pobre" pool de linguagens. Duas ou três linguagens como informei anteriormente…
e nesse portfólio de linguagens de seu conhecimento você ter opções que:
- Ou estão apenas iniciando no mercado (são apostas);
- Ou já se provaram serem falhas. Ou seja, já estão a anos na indústria e simplesmente não ganham um forte engajamento na comunidade de desenvolvedores.
Com o domínio de duas linguagens bem aceitas em mercado, acredite:
Somente sobre Engenharia de Software há uma vida de habilidades a serem aprendidas que podem seguramente ser aplicadas nas duas linguagens de sua escolha e em qualquer projeto que faz uso dos principais paradigmas em mercado.
E para mim, seguindo o roteiro que eu descrevi a pouco, as chances são de que você com frequência será mais criativo e objetivo (para não falar melhor) nas soluções de algoritmos do que um developer com uma pool de, por exemplo, 7 linguagens.
Mas enfim. Isso acaba sendo apenas a minha opinião frente à opinião do autor.
Sendo assim, você está convidado(a) a defender sua opinião nos comentários abaixo.
Sobre este assunto, "Quantas linguagens de programação um desenvolvedor deve conhecer", eu paro por aqui.
Pois o que eu quero mesmo é falar mais sobre o livro "Como ser um programador melhor".
Estou mesmo é animado por ter novamente em mãos mais um daqueles títulos que eu seguramente recomendo que você reserve um tempo em sua agenda para ler de capa a capa.
Calma. Eu falei "em mãos", mas eu já finalizei toda a leitura. Não consigo fazer resenha de conteúdo que eu não tenha consumido por completo.
Minha parcela de contribuição neste artigo, ao menos para a comunidade Android, é deixar claro que o título foco desta resenha deveria sim ser um dos clássicos da área de desenvolvimento.
Clássicos como os títulos "Código Limpo" e "O Programador Pragmático".
Mesmo sabendo que, novamente de maneira explícita em um livro para programadores, o autor se compromete, agora com um toque mais denso, informar sobre a importância de:
- Codificar limpo, de maneira que outros desenvolvedores consigam seguramente entender todo o projeto sem ter que utilizar uma documentação ao lado;
- Testes. Estes dão "certificado de qualidade" e vida de longo prazo a qualquer aplicativo;
- Investir em fase de projeto. Que vem antes da codificação e faz toda a diferença na qualidade do software que será entregue;
- Saber trabalhar em time. É sempre nós e nunca eu ou ele(a);
- Uso de software de controle de versões. Isso deve ser obrigatório em qualquer projeto.
Sim, parece mais do mesmo.
Mas a abordagem é mais completa e o livro como um todo tem ainda mais conteúdos que ou são pouco abordados, ou nunca abordados em outros títulos de desenvolvimento.
E sim, estamos falando de um livro de 2014… que ainda é atual em cada um dos recursos apresentados. Recursos totalmente independentes de linguagens e paradigmas de programação.
Aliás, dos pontos que listei anteriormente, um deles o autor com frequência volta a falar no livro.
Saber trabalhar em time!
E hoje, eu sendo parte de um projeto de desenvolvimento, com dezenas de desenvolvedores e eu ainda em fase de treinamento até poder acessar toda a base de código Android.
Com este cenário em meu atual ambiente profissional… eu seguramente lhe afirmo que as empresas (e estou falando de uma em São Francisco - EUA) não estão preocupadas em encontrar gênios.
O Scrum e outras metodologias e frameworks ágeis de desenvolvimento de projeto, conseguiram mostrar ao mercado que é possível e inteligente investir em times com conhecimento técnico aceitável, mas que trabalham como um único organismo…
do que investir em "gênios" que, mesmo que ocasionalmente, estão mesmo preocupados em mostrar que são melhores coders do que os outros. Cometendo a heresia de, por exemplo, seguir os padrões pessoais de desenvolvimento.
Em meu caso, mesmo eu tendo que codificar na primeira fase do recrutamento. Quando já aceito e dentro do projeto, em fase de treinamento, a preocupação é quase que total com as minhas habilidades de trabalho em time.
De saber respeitar os escopos das tarefas atribuídas a mim e de conseguir ajudar outros quando necessário.
Em nenhum momento, ao menos na fase de treinamento, fui solicitado a aprender algo complexo sobre codificação Android.
Obviamente que estou preparado caso isso aconteça em algum ponto do desenvolvimento.
Mas eu confesso que fiquei surpreso em como as habilidades de trabalho em time são consideravelmente mais valorizadas do que habilidades técnicas individuais.
Isso tudo pode ser somente uma coincidência na minha rota profissional. Mas acredite, você não está tão distante de ouvir, em fase de seleção de projeto, a célebre frase:
Nós não contratamos programadores, contratamos pessoas.
E não chore.
Pois ao menos até o momento em que eu escrevo este artigo, isso aparentemente é uma das poucas verdades imutáveis no mercado de desenvolvedores de aplicativos. Você ainda vai ouvir essa emblemática frase.
Agora próximo ao final…
eu ainda quero informar que o livro tem muitos exercícios. Nenhum deles é complexo, nem mesmo perto disso.
Mas são exercícios que se você já tem experiência em trabalho com times de desenvolvimento, então não haverá a mínima dificuldade em respondê-los.
De qualquer forma, mesmo tendo experiência somente como desenvolvedor solo, ainda assim é bem possível responder a todas as questões.
E como dica: responda a todas as perguntas. Vale a pena.
O livro, devido às 383 páginas, pode parecer ser denso. Mas não é.
Os capítulos são curtos e, acredite em mim, não tem ao menos uma linha de código. Nem mesmo uma atribuição de valor a alguma simples variável.
Ainda assim o livro é um baita título, ao menos para qualquer desenvolvedor Android que já tem experiência em codificação.
Thiengo, o livro então não é para iniciantes, certo?
Eu particularmente não o recomendo para iniciantes.
Os conteúdos são primariamente para desenvolvedores que já têm ao menos um pequeno projeto como portfólio. Pode ser um simples aplicativo estático, de consumo de dados locais, mas que seja um app já disponível, por exemplo, na Google Play Store.
Abaixo deste nível de experiência, o leitor vai no mínimo achar a leitura boring.
Bom, eu não quero me alongar ainda mais e acabar por construir um outro livro falando sobre um livro.
Sendo assim, aguardo nos comentários ou em e-mail (se você estiver inscrito na lista do Blog) as suas dicas e dúvidas sobre este ou outros livros para desenvolvedores de software.
É isso.
E não se esqueça de se inscrever na lista de e-mails do Blog 📩 (que é gratuita) e assim receber também os conteúdos exclusivos que eu libero somente por lá.
Abraço.
Comentários Facebook