Executando verificação de segurança...
1

[LIVRO] The Pragmatic Programmer - Prefácio e Capítulo 1

Ei pessoal, tudo certo? Recentemente fiz a leitura do livro "The Pragmatic Programmer: from journeyman to master” (Andrew Hunt e David Thomas) ou em português “O Programador Pragmático: de Aprendiz a Mestre”, e depois de ter terminado o livro pensei em publicar minhas anotações do livro aqui no TabNews para compartilhar o conhecimento de forma mútua.

Vi que já tiveram vários posts aqui no TabNews que envolvesse o nome do livro, inclusive um post sobre o vídeo do Mano Deyvin sobre o livro, mas não encontrei nenhum sobre o conteúdo do livro. Então, para quem tiver interesse, vou procurar explorar aqui alguns conceitos que eu absorvi do livro.

Vale ressaltar que eu li a 1a Edição de 1999 em inglês. São minhas anotações pessoais, com tradução de termos e ideias próprias, logo poderão ter informações que na tradução em português oficial estejam diferentes. A ideia não é ser, necessariamente, um resumo/resenha do livro, mas de pontuar algumas ideias que eu entendi serem interessantes a compartilhar.

Confesso que deveria ter lido esse livro há um tempo, mas o erro também faz parte do processo de aprendizagem e experiência, então fico feliz por tê-lo lido agora. Por mais que eu procure aqui compartilhar o conhecimento, a leitura individual do livro é imprescindível.

PS.: Conforme eu fui fazendo o post eu percebi que ia ficar muito grande, então vou separar um post por capítulo (ou dois se não ficar muito grande). Ao todo são 8 capítulos.

Prefácio

A ideia do livro é te fazer se tornar um melhor programador. Não importa se você é um desenvolvedor sozinho, consultor ou membro de um grande time. A ideia de “pragmático” vem do latim “hábil no negócio” que vem do grego “para fazer”. O livro é sobre fazer.

Programar é um trabalho difícil e é uma arte que necessita ser construída com diferentes tipos de recursos. Esse livro é para àqueles que desejam se tornarem programadores mais produtivos.

Programadores pragmáticos normalmente compartilham algumas dessas características:

  • Early adopters
  • Questionador
  • Pensador crítico
  • Realístico
  • Apto para todo tipo de trabalho (famoso “pau para toda obra”)

Ser um programador pragmático envolve uma disciplina de engenharia, tendo cuidado com aquilo que é desenvolvido como se estivesse criando um produto manufaturado e envolve um processo contínuo de cuidado e melhoria do seu produto.

Capítulo 1 - A Pragmatic Philosophy (Uma Filosofia Pragmática)

Pense no problema dentro do contexto geral. Como fazer compromissos inteligentes e decisões informadas?

The Cat Ate My Source Code (O gato comeu meu código)

Tome responsabilidades pelas suas ações no curso da sua carreira. Não é errado admitir ignorância ou erro. Quando você aceita uma responsabilidade por algo, você deve esperar ser responsabilizado por isso. Ao cometer erros, admita-os e ofereça opções de resolução

  • Não terceirize culpas ou fique se justificando. Pode até ser que eles tenham alguma parcela, mas proveja soluções, não desculpas.
  • Ao falar sobre um problema. Se escute antes, pense primeiro. O que você está falando parece algo idiota/ruim? Você procurou fazer todas as opções possíveis?

Software Entropy (Entropia do Software)

A Entropia é definida como sendo o grau de desordem de um sistema. Dentro de um software, quando mais não vamos corrigindo detalhes e problemas que irão aparecendo, mais entrópico será o sistema.

Há muitos aspectos que contribuem para um software podre, a maioria deles incluem relações com aspectos psicológicos, culturais, trabalhistas e do projeto.

  • Em comparação com o ambiente de construção temos o exemplo da “janela quebrada”. Algo pequeno, mas que é sensível a uma construção, e que se não for reparado pode levar a uma cultura de abandono.
  • Consertar janelas quebradas, rasuras e outras infrações menores, reduzem significativamente problemas muito sérios
  • Faça ações para consertar um código mal-feito imediatamente, se não der tempo, planeje.
  • Apagando o fogo. Uma janela quebrada - um mal design de código, uma decisão errada de gestão, fazendo com que o time tenha que lidar com isso durante todo o projeto - é o necessário para fazê-lo entrar em ruínas.
  • Uma vez em um projeto com várias janelas quebradas, é bem possível termos a mentalidade de considerar todo o resto do código ruim e apenas seguir o fluxo.

Stone Soup and Boiled Frogs (Sopa de pedras e sapos cozidos)

Um resultado sinérgico é quando todos ganham. Seja um catalisador da mudança, quando você começa a liderar uma mudança e engajar as pessoas nela, um por um, eles começarão a perguntar o que deve ser feito e como colaborar.

  • Pessoas facilmente aderem a casos de sucesso
  • Cuidado para não se distrair muitas vezes, caso contrário, os projetos podem sair de mão por pequenas situações que não percebemos. Dia a dia podemos modificar o nosso código até que nada do original permaneça
  • É comum que o acumulo de pequenas coisas quebrem a moral e times
  • Se você colocar um sapo em uma panela com água quente, ele tentará fugir. Mas se você colocar em uma panela com água normal e for esquentando gradativamente, ele vai se acostumando até cozinhar.

Good-Enough Software (Software bom o suficiente)

Controle de qualidade é muito difícil: Tempo, tecnologia e temperamentos conspiram contra nós. Ainda assim é possível criar softwares bons o bastante para os desenvolvedores e para os clientes.

  • Bom o bastante não deve ser visto como sinônimo de código pobre ou mal feito
  • Devemos fazer da qualidade uma requisição. Devemos negociar a qualidade de um produto
  • Um bom software hoje é melhor que um software perfeito amanhã
  • Não podemos nos perder no grande quadro do desenvolvimento de software
  • Um software nunca será perfeito, mas deve ser minimamente adequado e funcional

Your Knowledge Portfolio (Portfólio do seu conhecimento)

Um investimento em conhecimento sempre paga o melhor interesse. Seu conhecimento se torna ultrapassado com novas tecnologias, linguagens e ambientes que são desenvolvidos. Com o valor do seu conhecimento caindo, o mesmo ocorre para a sua empresa ou cliente

  • Conheça seu portfólio
    1. Investimentos regulares: invista regularmente no seu conhecimento, faça pequenas conquistas diariamente
    2. Diversificação: quanto mais diversificado, mas valioso você é
    3. Gerencie os riscos: não coloque todos os seus conhecimentos em um cesto apenas
    4. Compre na baixa, venda na alta: Conheça uma tecnologia antes dela se tornar popular. Isso te dará uma vantagem em relação a colegas concorrentes
    5. Revise e rebalancie: Repense tudo o que você está fazendo em face das demandas do mercado
  • Aprenda uma nova linguagem a cada ano
  • Leia um livro técnico a cada trimestre
  • Leia livros não-técnicos também
  • Faça aulas
  • Participe de grupos locais
  • Experimente novos ambientes de desenvolvimento
  • Mantenha-se atualizado
  • Pensamento crítico: Não se deixe levar pelo hype. Critique e analise tudo o que você ouvir e ler. Nunca subestime o poder do comercialismo. Vão tentar vender qualquer coisa a você de todas as formas.

Communicate (Comunicação)

Ter as melhores ideias, o melhor código, ou a forma mais pragmática de pensar se torna inútil caso você não saiba se comunicar.

  • Saiba o que você quer dizer
  • Conheça a sua audiência
  • Escolha seu momento
  • Escolha um estilo
  • Faça isso parecer bom: se a sua ideia é boa, então a apresente da melhor forma possível
  • Envolva sua audiência
  • Seja um escutador
  • Volte para as pessoas
  • Tanto o que você diz, quanto forma como você diz importam
Carregando publicação patrocinada...