O Programador Pragmático – parte 6

Aqui estou no terceiro capítulo do livro, mais empolgado que nunca, e vendo que ainda tenho muito que aprender. As vezes a leitura me faz parar pra refletir um pouco no meu dia a dia, exemplo disso são as anotações que eu estou mantendo em um txt para poder comparar as estimativas com o tempo que realmente eu gastei nas tarefas.

Outro exemplo é que eu acabei o segundo capítulo é já coloquei outros livros na lista de compras, dessa vez livros de regex, Shell Script, Python e outros.

Mais uma coisa, eu decidi que não vou mais ficar escrevendo resumos de cada capítulo, de agora em diante eu simplesmente vou lendo e fazendo minhas anotações, então poderá ter capítulos divididos em vários posts e mais de um capítulo em um post.

Então até agora ficou assim:

O Programador Pragmático – Resenha do prefácio

O Programador Pragmático – Capítulo 1

O Programador Pragmático – Capítulo 2 – primeira parte 1

O Programador Pragmático – Capítulo 2 – segunda parte 2

E de agora em diante será: O Programador Pragmático parte 6, parte 7… E assim por diante.

Agora continuando com o resumo…

Logo no inicio o livro fala sobre saber utilizar e bem as ferramentas que temos em mão, assim podemos ampliar nossa capacidade. Só que ao mesmo tempo não devemos ser totalmente dependentes delas, principalmente as do tipo “next, next e finish”.

Texto Simples

Na hora de escrever algo, prefira escrever textos simples e que sejam legíveis por pessoas e máquinas, como por exemplo o XML. Qual a vantagem disso? Textos simples não dependem de nenhuma implementação, qualquer linguagem de programação pode ler e escrever e assim que você bate o olho consegue entender. Veja esse texto:

nome=gabriel

nome:gabriel

Esses dois exemplos são textos que podem ser facilmente lidos por um programa ou pessoa, agora imagina se isso estivesse e hexadecimal ou binário.

O Problema com a IDE

Muitos de nós nos acostumamos com as facilidades de arrastar, copiar e colar que temos com as ferramentas de desenvolvimento, já que está tudo ali, é só ir no menu e selecionar uma opção que tudo é executado como mágica. Isso é ótimo e nos proporciona produtividade, como por exemplo as Refatorações do Eclipse, mas, não devemos ser totalmente dependentes da IDE.

Como diz no livro a grande jogada do IDE é “o que você vê é o que você tem”, mas por outro lado “o que você vê é tudo que você tem”.

Com uma IDE ficamos limitados as suas ferramentas ou se dermos sorte podemos adicionar algum plugin, já com a utilização de comandos em Shell temos todas as combinações possíveis.

Se você ainda não está convencido do poder da utilização do Shell, compre o livro que os altores dão vários exemplos de tarefas por linha de comando (uma página inteira).

Mais uma coisa… Sabe aquela tarefa que deve ser executada todo santo dia? Não seria melhor criar um script pra isso?

Se você também é adepto a sistemas Linux ótimo, você tem uma excelente ferramenta pra criar seus scripts, caso contrário procure ferramentas para utilização de comandos Unix no Windows, pois eles são mais poderosos.

Conhecendo o Editor

Como artesão temos como ferramentas os editores de texto, e assim como o pintor utiliza pincel para colocar no quadro a sua criatividade devemos utilizar os editores de texto. O ideia é que os atalhos sejam automáticos e que você não tenha que parar pra pensar quando for utilizar o seu editor, por isso o ideal é ter um único editor de texto. Assim podemos programar sem tira as mãos do teclado, e isso é muito mais rápido que pegar o mouse e ir no menu.

Também não podemos exagerar e utilizar o bloco de notas do Windows, já que ele não possui nenhuma característica que facilite nosso trabalho. No meu caso eu utilizo o NotePad++ com alguns plugins no Windows, e no Ubuntu o Gedit com plugins, e os dois sistemas também estão com o Eclipse.

Depois dessa leitura eu procurei no Google alguns atalhos paro Eclipse e achei esses links:

http://www.n0sl33p.org/dev/eclipse_keys.html

http://eclipse-tools.sourceforge.net/EclipseEmacsKeybindings_3_1.pdf

Controle de Versão

Esse assunto já deve ser entendo pela maioria, e se você não conhece é só da uma procurada no google por Subversion, Mercurial, Bazaar e Git e etc… Sobre o Git há um screencast muito bom feito pelo Akita que é bem barato.

Quem deu commit nessa classe com Bug?

A resposta é simples: Não importa quem, é problema SEU.

Essa é a primeira postura que devemos tomar, ao invés de procurar culpados encontre a solução!

Antes de começar a procurar o erro você deve ser desarmar, e evitar ficar se esquivando, depois a regra é: Não entre em pânico.

E como é da filosofia pragmática, saiba que não adiante resolver o problema de forma isolada, procure “agente transmissor” do problema.

A primeira dica que fica é que devemos obter o máximo de informações possíveis, e para isso talvez seja necessário entrevistar o usuário.

E para encontrar o bug podemos utilizar as ferramentas que já vem na IDE, onde você pode ir acompanhando os valores das variáveis. Esse trabalho também pode ser feito com papel e caneta.

Outra técnica para encontrar a causa do problema é explicar para outra pessoa, muitas vezes a outra pessoal não vai dizer nada, mas o simples ato de explicar fará você ter outra visão da situação.

Essa técnica eu já tinha aprendido a um tempo atrás, só que quando me ensinaram foi para que eu fixasse melhor as coisas que estudo, então eu sempre tento explicar para alguém as coisas novas que vou aprendendo.

Por enquanto é isso, pois já são 2:30 da madrugada e eu tenho que trabalhar (hoje!).

Gabriel Rubens

Deixe uma resposta