Sugestão de Livro: Head First Design Patterns

Você não está sozinho! Em algum lugar do mundo, alguém reparou a dificuldade das pessoas em entender design patterns e decidiu facilitar a nossa vida. Essa(s) pessoa(s) resolveram escrever um livro sobre design patterns, e é dele que vou falar.

Estava eu em um avião, e iria encarar umas horas de viagem a alguns meses atrás. Felizmente ao meu lado estava @Tiago__Farias, e na sua mochila estava um livro chamado Head First Design Patterns. Conversamos um pouco e falamos sobre alguns livros, e foi quando ele me emprestou o livro para que desse uma lida no vôo. Como tinha interesse em conhecer design patterns, comecei a ler right away o livro naquele momento.

O primeiro capítulo desse livro é o mais genial de todos (ainda mais se você não conhecer a série Head First, pois será uma surpresa, como foi para mim). Você começa a ler o livro e ele vai falando de forma muito didática (ensinando para os burros, do jeitinho que eu gosto :P) a mágica de orientação a objeto desde o início, falando sobre princípios de design, utilização de interfaces, etc e BANG! Quando você se dá por conta ele já ensinou um design pattern e você nem sentiu! Isso anima a você continuar a ler e aprender o restante dos design patterns. Obviamente o livro pode servir como um livro de referência, mas os capítulos iniciais são leitura obrigatória ao meu ver.

Não precisa nem falar que depois dessa viagem que eu conheci o livro (que foi emprestado) eu comprei na hora o meu exemplar na amazon!

Para quem não conhece e se interessou aqui tem o capítulo 3 para download que descreve e explica brilhantemente o padrão Decorator.  Boa degustação!

O que é Software Craftsmanship?

Por meio de um twitter de @lucabastos, terminei vendo uma apresentação de @sandromancuso & @activelylazy sobre essa nova onda rolando a algum tempo já, e terminei conhecendo por acaso esse movimento chamado de Software Craftsmanship.

Confesso que não conhecia ainda esse movimento mas pela apresentação que vi no slideshare me pareceu bastante interessante e já simpatizei de cara (inclusive depois de estudar um pouco o movimento eu assinei o manifesto, e no momento que assinei existia 213 brasileiros que já haviam assinado) .

Se formos traduzir literalmente Software Crafsmanship significa algo em como “Software Artesanal” e o movimento gira em torno de sermos melhores artesões.

Apesar do manifesto do Software Craftsmanship só ter sido criado em 2009, suas raízes vem desde 1999, com a publicação do conhecido livro Pragmatic Programmer, que trata sobre como ser um programador melhor, em diversos sentidos da palavra.

Uma definição de software craftsmanship é a seguinte:

It’s a lifestyle where developers choose to be responsible for their own careers and for improving their craft, constantly learning new tools and techniques. Software Craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development.

Figuras renomadas, como Robert C. Martin (ou Uncle Bob) que inclusive participou da criação do manisfesto ágil , apoiam o movimento. O próprio Uncle Bob escreveu:

The original torch of the Agile message has changed hands, and is now being carried by the Software Craftsmanship movement.

Segundo ele mesmo colocou, o movimento do software craftsmanship seria uma “extensão” do manifesto ágil, obviamente sem anular os pontos que foram citados no manifesto ágil. Dessa forma, vamos analisar o “manifesto do software artesanal”, que tem os seguintes valores:

Not only working software, but also well-crafted software;
Not only responding to change, but also steadily adding value;
Not only individuals and interactions, but also a community of professionals;
Not only customer collaboration, but also productive partnerships.

Muito legal esse manifesto, e como podemos perceber o ponto central por trás desses valores é sermos melhores programadores, e consequentemente nossos artesanatos serão bem melhores do que são hoje em dia. Além disso, é preciso parcerias onde possamos nos desenvolver, formando uma comunidade de artesãos de software capacitados.

@sandromancuso & @activelylazy em sua apresentação falaram das características do papel de artesão de software. Listei algumas aqui:

  • Nós controlamos nossas carreiras;
  • Artesão de software não é uma profissão comum daquelas que dá 18:00 e vamos pra casa;
  • Intolerância a código ruim;
  • Somos profissionais e somos pragmáticos;
  • Nós estamos continuamente aprendendo e interessados em aprender;
  • Nós nos importamos e somos orgulhosos do nosso trabalho :)

Para sermos melhores artesãos, é sempre preciso:

Criatividade, Visão Crítica, Base teórica e Habilidades Práticas;

Além disso, é preciso estar ligado no que Software Craftmanship NÃO É:

  • NÃO É um certificado
  • NÃO É um curso
  • NÃO É um livro

Software Craftmanship é ATITUDE!

Somos maus programadores, aceite isso! Será mesmo?

Não sei quantos de vocês acompanharam alguns dos últimos posts que rolaram em alguns blogs famosos, mas Jared Richardson no Blog da Agile Zone publicou um post entitulado “You’re a Bad Programmer. Embrace It.” que foi bastante acessado e um tanto quanto polêmico.

Jared, em seu post, fala que somos péssimos desenvolvedores:

How many developers think they’re good programmers? We’re not. We’re all fairly bad at what we do. We can’t remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. And the languages we’ve spent years, in some cases decades, learning? We can’t even type the syntax properly, so we have compilers that check and correct it for us.

Até parece fazer sentido né? Só que não faz! Na verdade, é óbvio que existem bons e maus programadores (assim como qualquer outra profissão) e o fato de utilizarem utilizarem ferramentas não os torna maus programadores (talvez até o fato de utilizarem determinadas ferramentas para facilitar seu trabalho os torne BONS).

É como dizer que um mecânico é bom se ele apertar um parafuso de uma determinada peça com a mão, e não com uma chave de fenda.

Stephan, dono de outro blog famoso de TI, o Code Monkeyism, leu esse post do Jared e não gostou muito também :P Stephan então postou um resposta entitulada “Você é mesmo um mau programador?” e então ele critica diversos trechos do post original do Jared.

O post do Stephan (do Code Monkeyism) ficou muito legal e ele embasou cada ponto de crítica que fez ao nosso caro Jared. Não preciso nem dizer que concordei com o Stephan.

Até que dá pra entender que o intuito original do post de Jared era dizer que existem ferramentas que podem nos auxiliar a ser melhores programadores e a evitar alguns tipos de erros, o problema maior foi a fundamentação do problema que foi muito rasa.

O post de Stephan em resposta ao posto original do Jared termina da seguinte forma:

There are good and bad programmers. The good one are those who want to become better, are interested in their craft, the bad ones are those who do 9 to 5 jobs without any interest in their profession.

Existem bons e maus programadores. Os bons são os que querem se tornar ainda melhores, estão interessados no que produzem…

Um projeto pode ser ágil sem SCRUM ou KANBAN?

Hoje em dia muito se fala sobre Scrum, Kanban, e estes conceitos estão realmente na moda atualmente. Primeiramente gostaria de dizer que não tenho nada contra o Scrum ou o Kanban, muito pelo contrário, uso Scrum a algum tempo e percebo no dia-a-dia os benefícios de tais práticas.

E então chegamos na palavra que eu queria chegar: Prática. Tanto o Scrum quanto o  Kanban e também o XP (eXtreme Programming) são práticas comuns (formas de fazer, de conduzir) comuns no mundo ágil. Muitas pessoas param por aqui quando estão falando sobre desenvolvimento ágil, mas uma pergunta importante precisa ser respondida: O que faz uma metodologia/prática ser considerada ágil? Nesse momento então chegamos ao ponto crucial que são os princípios e valores que estão por trás do que se considera ágil. Todas as práticas que se consideram ágeis é porque valorizam os pontos levantados no manifesto ágil:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Sabendo agora que existem princípios por trás de determinadas práticas, podemos então responder a pergunta se um projeto pode ser ágil mesmo sem utilizar Scrum ou Kanban, e a resposta é ‘SIM’! Basta que estejamos ligados a esses princípios.

Sendo assim, o contrário também pode acontecer: Você pode “utilizar” Scrum, ter post-its na parede, dividir seu projeto em iterações (sprints), fazer Scrum Daily Meetings e ainda NÃO SER ÁGIL!

Então sabemos mais importante do que Scrum ou Kanban, são os principios e valores por trás dessas práticas. No próximo post vou tentar detalhar mais o manifesto ágil e explicar melhor esse texto que só tem 4 linhas mas é enorme.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 1.053 outros seguidores

%d blogueiros gostam disto: