[Reflexão] – A psicologia dos programadores

Um post para refletir acerca dos princípios que estão na “arte de programar”. Retirado do site JavaFree.

Resumo das partes essenciais encontradas no artigo “The Psychology of Programmers“.

  • Programadores geralmente têm mais atenção e maior capacidade de concentração que a maioria da população
  • Programadores são criativos por natureza, gostam de investigação, inovação e por isto não gostam de projetos de manutenção
  • Programadores geralmente deixam as organizações quando não há mais trabalho criativo a ser executado
  • Programadores preferem: liderança a gerenciamento, coisas melhores a melhores coisas, orientação a pessoas a orientação a coisas, …
  • … eficácia a eficiência, princípios a técnicas, orientação a direção a orientação a velocidade
  • Programação demanda precisão no pensamento. Isto faz com que programadores também apliquem esta precisão em questões sociais
  • Programadores não participam por participar. Eles continuam buscando algo lógico para adicionar, dizer ou perguntar
  • Programadores não gostam de fazer coisas rotineiras e/ou repetitivas em sua vida, por causa de sua atitude criativa e lógica
  • Programadores parecem ser introvertidos, mas isto não é totalmente verdadeiro …
  • … quando aplicável, é por eles estarem praticando maior atenção, maior concentração e maior lógica, até mesmo em aspectos sociais
  • Programadores apreciam e estão dispostos a aprender teorias psicológicas e filosóficas
  • Programadores são idealistas. Eles estão muito preocupados com seu ambiente de trabalho, com a estética geral de seu escritório, etc

Link: http://architects.dzone.com/articles/psychology-programmers

Apresentação sobre “Os seis chapéus do pensamento”

No 8º encontro do GURU-SP, no qual estive presente e hei de escrever um report, aprendi acerca do assunto “os seis chapéus do pensamento”, via Rafael Rosa. Fiquei empolgado com o assunto e além de fazer a aquisição do livro (coisa que o Rafael  não indicou, mas fiz mesmo assim…rs) montei uma apresentação para repassar o conteúdo pro pessoal da empresa onde trabalho (Voice Technology). Abaixo coloco o link da apresentação no slideshare:

Caros leitores: qualquer opinião ou dúvida fiquem a vontade para falar!

P.S. : Fiz a apresentação há 3 horas atrás e o pessoal gostou bastante do conteúdo! A idéia de fazer mais lightning talks na empresa, aparentemente, foi bem aceita e com bom público. Só queria deixar o agradecimento, novamente, ao Rafael Rosa pela “luz”!

Nomeie as coisas corretamente

Esse post é essencial e de grande valia em termos de reflexão de como o programador inexperiente, até os mais experientes, devem tomar cuidado e seguir a risca a escrita de código com coesão, em termos de lisura e entendimento de variáveis, métodos e clareza de informações.

O texto abaixo está na íntegra e foi redigido por Daniel Lopes, retirado do blog AreaCriações. Daniel Lopes ministra cursos de Ruby/Rails pela E-Genial; um companheiro de empresa está fazendo o curso “Ruby on Rails – do básico ao avançado” e está gostando, portanto é indicado para os interessados em aprender mais sobre essa nova linguagem/framework de desenvolvimento Web.

Boa Leitura a todos!

Pensar no nome dos seus métodos e classes é tão importante quanto fazer o código funcionar. E se a nomenclatura que você adotou não é boa, eu considero o código errado! Este é tipo de coisa que não é ensinada em faculdades, mas deveriam ser.

Hoje vivemos em um mundo de desenvolvimento orientado a objetos. Mas é o objetivo de OOP? Simular o mundo real através do código, não é atoa que a primeira linguagem OO se chama Simula.

Tenho dedicado boa parte do meu em treinamentos, sejam pela eGenial ou para equipes em empresas. No ano passado participei de treinamentos com mais de 100 pessoas e só no começo deste ano foram mais quase 100.

Treinar tanta gente é uma experiência fantástica pois em nenhum emprego eu poderia ver o fonte de tantas pessoas, conhecer tantos problemas diferentes e aprender com os erros dos outros e propor soluções antes mesmo que aconteçam comigo.

Mas uma coisa tem me assustado muito: NOMES. Pensar no nome dos seus métodos e classes é tão importante quanto fazer o código funcionar. E se a nomenclatura que você adotou não é boa, eu considero o código errado! Este é tipo de coisa que não é ensinada em faculdades, mas deveriam ser.

Hoje vivemos em um mundo de desenvolvimento orientado a objetos. Mas qual é o objetivo de OOP? Simular o mundo real através do código, não é atoa que a primeira linguagem OO se chama Simula.

Então, o primeiro fator que considero para desenvolver OO corretamente é como você deve nomear e simular o mundo real através do seu código.

Mas como nomear corretamente as coisas?

A funcionalidade do Rails que acho mais fantástica é a preocupação de manter a característica do Ruby de ser legível. Temos métodos como validates_presence_of ou has_and_belongs_to_many ao invés de apenas vpo ou has_blg. Esta preocupação fica mais clara ainda se pensarmos nas tabelas, models e controllers.

Tabelas no Rails praticamente só servem para persistir objetos (reparem: objetos no plural) por isso elas são nomeadas no plural (customers, transactions, teachers, etc) enquanto a classe, que criará uma instância por vez, é nomeada no singular (Customer, Transaction, Teacher).

Métodos são operações que o objeto pode realizar, logo devem ser ações como calculate, find, sum enquanto propriedades/atributos são características do objeto que consequentemente devem ser nomeadas como tal. Seus accessors devem ter nomes de propriedades como name, age, value e etc. Se existe uma variável que é um verbo/ação então simplesmente seu código está errado e não tem significado como um objeto.

Já sabemos como nomear tabelas, classes e como a prática do Rails é muito boa para manter o código legível. Mas o que são controllers?

Um controller é uma forma de expor ao mundo os seus objetos do sistema e ao pensar como organizar seu controllers você deve ter isto em mente (por isto o Rails é REST e não apenas para expor uma API qualquer). Suas actions do controller devem ser ações mesmo, ações que vão ser executadas em seus objetos para poder mostrá-los ao mundo.

Se você tem uma action chamada “calculos” o nome simplesmente está errado, isto não é uma ação. Se você pensar em um controller como expositor de seus models com views então o método “calculos” está até no local errado, ele deveria estar dentro do model de BankAccount por exemplo e o controller apenas obtém o valor retornado pela ação calculate de um objeto da classe BankAccount. Neste exemplo a preocupação com nomes nos ajuda a colocar os métodos nos locais corretos criando uma boa arquitetura.

Código deve ser legível mesmo quando o sistema se tornar legado.

Qualquer sistema se torna legado, mesmo ele sendo escrito em Rails 3.0beta hoje, daqui a uma semana ele é legado e você não se lembrará de boa parte do que foi escrito lá.

Um desenvolvedor é um escritor e seu código (principalmente em Ruby) são frases que dizem o que deve acontecer. Se você não nomear seus métodos, objetos e variáveis da forma correta mais cedo ou mais tarde nem mesmo você entenderá um código que escreveu (experiência própria) quanto mais outro desenvolvedor.

Outro fator que destrói a legibilidade são os resumos. Um helper como options_for_select que cria options para um select do html poderia ser resumido para opt_select ou has_many poderia ser h_many. Mas estes resumos são extremamente prejudiciais e tornam o fonte impossível de ler futuramente.

Então sempre escreva o fonte como um manual e pensando em outra pessoa que venha a le-lo ao invés de pensar em você mesmo. Isto evitará o problema acima e mesmo daqui a 1 ano você voltará no código e entenderá tudo na primeira leitura.

Por que escrever fonte em Português é péssimo?

Nos treinamentos percebo que muita gente tenta escrever código Ruby em Português. O grande problema disto é que você terá algo assim: Pessoa.find_all_by_nome. Se você pensar em seu código como um simulador do mundo real que apenas contem instruções de como as coisas devem acontecer está óbvio que o seu simulador está “manco”.

Pessoa.find_all_by_nome não diz nada nem em Português e nem em Inglês. Logo é uma falha de arquitetura, e principalmente em Ruby, seu código acabou de perder a legibilidade da linguagem, que o Rails mantém e você acabou de destruir.

Como é impossível escrever tudo em Português então evite escrever qualquer coisa em Português. Desta forma você não terá um simulador “manco” que não descreve nada em linguagem nenhuma. Claro, termo técnico ou da regra de negócio como CPF, CNPJ e outros devem ser mantidos em Português ou na linguagem que for mas outras coisas como enturmação em uma rede social de alunos deveria ser representado como membership. Caso contrário você terá uma bizarrice como está:

class Estudante < ActiveRecord::Base
  has_and_belongs_to_many :enturmacoes
end

ao invés de

class Student < ActiveRecord::Base
  has_and_belongs_to_many :memberships
end

Evitando este tipo de arquitetura ruim: Estudante.first.enturmacoes.all(:conditions=>…). Ao ler esta frase (isto deveria ser uma frase) não existe nenhum significado em Português e nem em idioma algum, logo você tem um erro de nomenclatura e seu simulador do mundo real está manco, não representa a realidade e mais cedo ou mais tarde você estará dando manutenção em um sistema que apenas você entende.

Por favor não me venha dizer que é patriota e que o idioma do seu país é Português. Se você pensa assim deveria escrever class em japonês ao invés de Inglês já que o Ruby é uma linguagem Japonesa. Seu código é escrito para os outros e a única garantia que qualquer pessoa entenderá é escrevendo-o semanticamente correto e como a linguagem de programação já é em Inglês escreva-o em Inglês.

Também não existe problema algum se seu Inglês não é fluente. Tenha um dicionário a mão e tudo estará resolvido.

Conclusão

Não tenho vergonha em dizer que escrevi vários sistemas de 4 ou 5 anos atrás que por não ter seguido uma boa arquitetura o código é terrível e de difícil leitura. E pensando em arquitetura que me apaixonei por Ruby e consequentemente Rails, com eles é simples escrever um código que será fácil de ler mesmo daqui a 3 anos.

É sua obrigação fazer o código funcionar mas também é sua obrigação subdividir seus arquivos em pastas que fazem sentido, criar classes, templates e escrever código semanticamente correto, como um livro. Isto tudo é arquitetura do projeto e não apenas frescura, é preocupação com manutenção futura.

Esta regra o ajudará a identificar o que são método, o que são variáveis, objetos e onde colocar estas coisas.

Então pense 2 ou 3 vezes antes de escrever um método ou classe e não tenha vergonha em gastar mais horas do seu dia pensando em como organizar seus models e controllers do que escrevendo dezenas de linhas de código.

Por que alguns programadores não gostam de escrever testes automatizados?

Quebrar um paradigma de formação não é difícil, mas não é impossível.

Como tratamos de assuntos ligados as metodologias ágeis, vou abranger os testes automatizados e o que o mesmo poderá beneficiar o programador.

Os teste automatizados são uma maneira de garantir a qualidade de código, sendo assim, cliente e programadores ganham. O cliente vai ganhar um produto com qualidade melhor e o programador terá um aliado que são os testes automatizados para garantir que seu código tem qualidade.

Testes automatizados contribuem para princípios ágeis com software funcionando, adaptação a mudança, colaboração com o cliente e indivíduos em interações.

Problemas sem testes automatizados:

  • Muito tempo na depuração;
  • Erros encontrados tardiamente;
  • Difícil repetir testes;
  • Demorado;
  • Cansativo;
  • Executado poucas vezes.

Benefícios dos testes automatizados:

  • Segurança para mudanças de código e externa;
  • Aumento o tempo de vida útil do software;
  • Testes executados a qualquer momento;
  • Ajuda a encontrar erros;
  • Aumenta a velocidade de programação.

E como deve ser código do teste?

O código do teste merecem os mesmos cuidados que o código do sistema.

O código do teste sofre manutenção e também pode ter erros, portanto deve ser legível e simples.

Tipos de testes

O tipo de teste que o programador geralmente faz na metodologia ágil são os testes de unidade, que possuem as seguintes características:

  • Encontra muitos erros;
  • Tipo focando na funcionalidade(caixa-branca).

O demais testes são:

  • Aceitação;
  • Interface  do usuário;
  • Mutação;
  • Desempenho;
  • Estresse;
  • Segurança;
  • Integração.

Os demais testes o programador pode até fazer, mas necessita-se de um analista de teste, pessoal de infraestrutura ou arquiteto, conforme o teste e experiência requerida. Também existem diversos softwares (frameworks) para os demais testes, sendo um exemplo o JUnit e outros para testes de unidade.

Colegas programadores, com os testes automatizados você somente tem a ganhar na execução do seu trabalho e na formação profissional. Tendo uma visão focada nos negócios, além de tecnologias.

Qualquer funcionalidade que não possui testes automatizados simplesmente não existe.

Kent Beck

Uma breve introdução sobre Lean

P.S. : “Pinçado” do Cantinho do Agile 🙂

Os Melhores Podcasts de Tecnologia para Desenvolvedores

Post excelente escrito pelo André Faria Gomes. Muito bom mesmo! Podcasts sem dúvida são um dos meios mais indicados para adquirir conhecimento em tecnologia, ainda mais quando você está antenado no que Martin Fowler, Kent Beck, Rod Johnson entre outros estão falando. Retirado do andrefaria.com.

Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.

iPod FM radio remote por dan taylor
iPod FM radio remote por dan taylor

De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.

Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.

Desenvolvimento Ágil

por pcalcado
por pcalcado

Podcast da ImproveIt

por Vinícius Teles
http://improveit.com.br/podcast
Português

AgilCast

Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português

Agile Toolkit Podcast
http://agiletoolkit.libsyn.com
Inglês

ThoughtWorks Podcast

http://www.thoughtworks.com/what-we-say/podcasts.html
Inglês

Open Source

FLOSS Weekly

por Leo Laport, Jono Bacon e Randal Schwartz
Inglês

Java

HorecaExpo - Java por bramloquet
HorecaExpo – Java por bramloquet

JavaPosse

Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com

Java Technology Insider

Inglês
http://www.javaworld.com/podcasts/jtech

Grails Podcast

Por Glen Smith e Sven Haiges
http://grailspodcast.com

Ruby

Ruby on Rails por Andrew*
Ruby on Rails por Andrew*

Rails Envy

Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com

Rails Podcast

por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/

Rubiverse Podcast

Por Mike Moore
Ingles
http://rubiverse.com

JavaScript

jQuery Podcast

Português
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

Gadgets

GeekBrief TV

por Cali Lewis
Inglês
http://www.geekbrief.tv

Software

Desk por Guillermo Esteves
Desk por Guillermo Esteves

Pragmatic Podcasts

por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts

Software Engineering Radio

por Software Engineering Radio
http://www.se-radio.net
Inglês

Elegant Code

por Elegant Code Community
http://elegantcode.com
Inglês

Google Developer Podcast

http://code.google.com/p/google-developer-podcast/downloads/list
Inglês

Hearding Code

http://herdingcode.com
Inglês

Tecnologia

IT Conversations

http://itc.conversationsnetwork.org
Inglês

net@Night

por Amber MacArthur e Leo Laport
http://www.twit.tv/natn

Twit – This Week in Tech

por  Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit

MacBreak Weekly

por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw

This Week in Google

por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig

SitePoint Podcast

inglês
http://www.sitepoint.com/podcast

Empreendedorismo e Negócios

37 Signals Podcast

por 37 Signals
Inglês
http://37signals.com/podcast

Max Gehringer (CBN)

por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

Mundo Corporativo (CBN)

por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

The Startup Success Podcast

http://startuppodcast.wordpress.com
Inglês

TED Talks

por TED Talks
Inglês
http://www.ted.com

Tudo sobre o Google em 2 minutos

Retirado do blog Mundo Tecno. Muito bom! E ao estilo Google: simples, direto e impressionante!