A teoria e prática caminham juntas

Frequentemente ouço alguém pedir: "devo aprender primeiro a tecnologia X ou Y?" ou, "o que é melhor eu conhecer, Java ou C# ?". Normalmente minha resposta vai ser: não importa qual você aprenda, desde que aprenda primeiro os conceitos por trás delas.

A importância da teoria

As formas de ensino as quais estamos acostumados normalmente separam a teoria da prática, nunca mostrando como aplicar toda a teoria no mundo real. A teoria e prática são separadas de tal modo que somos levados a crer que uma não tem relação com a outra.

Certamente você já ouvir frases do tipo "Isso é coisa de acadêmico", "No mundo real uma coisa dessas não se aplica" ou então "Eu sou uma pessoa pragmática não ligo pra essas teorias".

Essas frases são exemplos claros de como a teoria e prática são vistas como duas coisas distintas. Uma pessoa se diz pragmática e se afasta de qualquer teoria. A verdade é que a teoria está pros traz de tudo que fazemos, querendo ou não, ela é o fundamento.

O foco excessivo na tecnologia

Uma tendência que vemos atualmente é um foco excessivo na tecnologia em si e não nas motivações por traz dela. Todos querem estudar a nova ferramenta da moda.  As soluções são baseadas apenas em ferramentas.

O que adianta conhecer o framework de desenvolvimento web XYZ se a pessoa não sabe os conceitos básicos de desenvolvimento web? Ou aprender o lindo e maravilhoso framework de persistência recém lançado, sem saber quais seus objetivos e razões de existir.

Esse foco excessivo leva as pessoas a serem especialistas em uma determinada ferramenta, sendo incapazes de utilizar outras ferramentas de mesmo propósito ou até mesmo de fazer qualquer julgamento a respeito delas.

A teoria faz parte da prática

Sempre que preciso utilizar uma ferramenta procuro entender os problemas que motivaram o desenvolvimento dela e a forma que ela visa resolver esses problemas. Com isso em mente, fica fácil comparar diversas ferramentas e adotar outra se necessário.

Um exemplo prático é o desenvolvimento Web. Comecei a desenvolver sistemas web utilizando ASP.Net, e como todos devem saber, o conceito de WebForms adotado pelo ASP.Net tenta abstrair a complexidade da web e simular o desenvolvimento desktop. Nunca gostei muito dessa idéia de abstrair a web, por isso acabava estudando o funcionamento por traz daquela abstração. É importante saber como mostrar os dados em um Grid ou como utilizar um Repeater com dados aninhados, mas tem coisas muito mais importantes que isso.

Com o conhecimento de desenvolvimento web em geral que adquiri, e não apenas o conhecimento da abstração criada pelo ASP.Net, fui capaz de utilizar outros frameworks sem problemas. É só uma questão de traduzir a teoria para os comandos do novo framework.

Orientação a objetos na teoria e na prática

A orientação a objetos não é nova, porém somente na última década ela passou a ser amplamente utilizada.

Em qualquer projeto desenvolvido hoje, se alguém cogitar utilizar o desenvolvimento estruturado, certamente será motivo de piadas. Afinal, programação orientada a objetos (POO) é um paradigma muito superior a programação estruturada. Há apenas um problema: grande parte dos projetos que atualmente são desenvolvidos utilizando POO não utilizam os conceitos de POO, são apenas programas estruturados utilizando classes.

POO não se resume a conhecer o que é classe, objeto, método e herança. Há muitos outros princípios que se aplicados ajudam no bom desenvolvimento. Os princípios mais difundidos são os que conhecemos pelo acrônimo SOLID. São eles:

• SRP - Single Responsibility Principle;
• OCP - Open Closed Principle;
• LSP - Liskov Substitution Principle;
• ISP - Interface Segregation Principle;
• DIP - Dependency Inversion Principle.

Apenas com estes princípios é que podemos realmente alcançar todo o potencial da POO e não apenas desenvolver programas estruturados utilizando classes. Em futuros posts devo falar mais sobre eles.
Mais uma vez, é um questão de mudar o foco da tecnologia para a teoria.

Em resumo

Para ter sucesso no desenvolvimento de software devemos tirar um pouco o foco da tecnologia e aprender os conceitos por traz dela. É uma pena que a cada dia as instituições de ensino estão focando menos nessa teoria e mesmo quando o fazem, é de forma distante da realidade, ficando difícil fazer uma ligação entre teoria e prática.

Valores nulos em chave única no SQL Server

O Microsoft SQL Server tem uma característica que eu não gosto nem um pouco: em uma chave única dois valores nulos são considerados iguais.

Imagine uma tabela com os campos abaixo, tendo uma chave única com o campo CPF.

ID	Nome	CPF
1	João	123.456.789-00
2	Pedro	NULL
3	Bino	NULL

No SQL Server, ao contrário de outros bancos como o PostgreSQL, esses dados não seriam válidos. Ao tentar inserir o terceiro registro seria gerado um erro de chave duplicada.

Para contornar esse problema existe um truque denominado Nullbuster. Descobri essa técnica por acaso ao ler um post do Karl Seguin. Pesquisando na internet descobri que os créditos são dados ao Steve Kass, porém não encontrei nenhum link onde pudesse confirmar isso.

O truque é bastante simples, veja o SQL abaixo:

CREATE TABLE dupNulls (
  pk int identity(1,1) primary key,
  X  int NULL,
  nullbuster as (case when X is null then pk else 0 end),
  CONSTRAINT dupNulls_uqX UNIQUE (X,nullbuster)
)

Repare que foi criado um campo adicional denominado “nullbuster” onde o valor será igual a PK se o valor for NULO ou 0 se o valor estiver preenchido. A chave única então é composta dos dois campos.

A tabela exibida acima ficaria com os valores:

ID	Nome	CPF	Nullbuster
1	João	123.456.789-00	0
2	Pedro	NULL	2
3	Bino	NULL	3

Um truque bastante simples que resolve alguns problemas.

Influências de Domain-Driven Design

Nos últimos anos a prática de Domain-Driven Design vêm ganhando popularidade. Mesmo não sendo amplamente aplicada, muitas de suas abordagens influenciam o desenvolvimento de softwares como um todo.

Para quem não está familiarizado com o tema, DDD é uma abordagem para desenvolvimento de software. Esse termo for criado por Eric Evans no livro Domain-driven design: tackling complexity in the heart of software.

De uma maneira super resumida, DDD visa eliminar as diferenças entre negócio e software, o software deve espelhar exatamente o domínio sendo tratado. Para tanto, são adotadas diversas práticas no desenvolvimento, como por exemplo: colaboração mais próxima do especialista no negócio, uso de uma linguagem única pelos desenvolvedores e especialistas, e deixar os conceitos envolvidos na aplicação explícitos.

Como o próprio Eric Evans deixa claro, DDD não é uma abordagem a ser adotada no desenvolvimento de qualquer software, ela deve ser adotada apenas em sistemas complexos.

Mesmo não adotando a abordagem como um todo, podemos tirar proveito de diversas práticas no desenvolvimento de qualquer software.

Deixando os conceitos explícitos

Uma das práticas de DDD é deixar os conceitos explícitos. Ou seja, deixar clara a intenção deles. Isso deve ser feito tanto no nível de código como na própria interface.

Um exemplo que me deparei recentemente onde os conceitos não estão muito claros é no Blogger. Ao editar uma postagem vemos uma tela semelhante a figura abaixo:

A questão nessa tela são os botões “Publicar postagem” e “Salvar”. As ações deles não ficam muito claras ao usuário. Enquanto criamos uma postagem eles tem as funções de:

• Publicar postagem – tira a mensagem dos rascunhos e publica oficialmente a mensagem;
• Salvar – simplesmente atualiza os dados da postagem;

Se a mensagem já foi publicada, as funções são:

• Publicar postagem – simplesmente atualiza os dados da postagem;
• Salvar – move para os rascunhos a mensagem já publicada;

Ficaria muito mais claro para o usuário se as funções de Publicar, Mover para rascunhos e Salvar fossem distintas. Na minha opinião, ficaria muito mais claro com as seguintes opções:

• Salvar – simplesmente atualiza os dados. Não move para rascunhos e não publica, atualiza os dados independente do estado da postagem;
• Publicar postagem – aparece apenas se a postagem ainda não foi publicada;
• Mover para rascunhos – cancela a publicação e coloca novamente a mensagem nos rascunhos.

É uma alteração simples e que envolve basicamente renomear os botões. Pode ser que eu seja chato, mas acho que dessa forma fica muito mais claro para o usuário qual o efeito de cada comando.

Utilizando técnicas de DDD no dia-a-dia

Como já mencionei antes, DDD não é uma abordagem a ser adotada em todo e qualquer software, porém podemos tirar lições dela e adotar algumas partes no desenvolvimento do dia-a-dia. Sempre que possível podemos deixar os conceitos mais explícitos e usar nomenclaturas padronizadas. Ou seja, deixar claro tanto para o desenvolvedor como para o usuário o efeito de cada ação e sua relação com o negócio.

Plugin do Visual Studio - RockScroll

Para quem trabalha com o Visual Studio 2005 ou 2008, um plugin muito útil é o RockScroll. Ele destaca o código fonte na barra de rolagem. Veja a imagem abaixo pra entender melhor:

Esse plugin tem alguns recursos interessantes:

• Exibe o código fonte na barra de rolagem, destacando os comentários em verde;
• Com um duplo-clique em qualquer texto ele deixa o texto destacado em todos os locais onde aparece, no arquivo e na barra de rolagem. Bom para ver onde uma variável ou método são utilizados;
• Destaca os breakpoints;

Como esse plugin foi desenvolvido para uso interno na Microsoft, eles liberaram sem nenhum suporte ou garantia. Ou seja, pode não funcionar na sua máquina. Eu pessoalmente nunca tive problemas, o único problema que conheço é que em arquivos que utilizam “region” a posição da barra de rolagem não fica correta.

Para fazer o download visite o blog do Scott Hanselman(excelente blog) ou diretamente nesse link.

O programador fita adesiva

Recentemente Joel Spolsky publicou um artigo falando a respeito do “programador fita adesiva”. Esse artigo gerou muita discussão pela internet. Algumas pessoas apoiando e muitas totalmente contra.

Nesse artigo Joel apresenta um tipo de programador, o “duct tape programmer”, que só se preocupa em terminar o produto. Esse programador não inventa moda, não enche o código de frescuras ou fica limpando o código para ficar melhor. Ele simplesmente fará da forma mais simples possível, e se necessário utilizará uma fita adesiva só pra deixar as diversas partes juntas.

Jeffrey Pallermo, assim como muitos outros na internet, publicou uma resposta ao artigo. Concordo com a resposta dele, e compartilho da mesma opinião. Recomendo a leitura dessa resposta.

Objetivo correto, atitude errada

Primeiramete tenho que concordar plenamente com o objetivo, que é simplesmente liberar o produto. Nós desenvolvedores estamos muito ligados ao software em si e nem sempre temos uma visão clara do negócio e das necessidades do cliente.

Deixar de liberar uma funcionalidade apenas porquê o código está ruim não é aceitável. Em alguns casos a necessidade do cliente nos obrigada a fazer o sistema funcionar, de um jeito ou de outro, mesmo que utilizando técnicas “não recomendáveis”. Ou seja, é o velho conhecido: “dá um jeito de liberar isso, seja como for”.

Entretando, esse caso deve ser a excessão e não a regra. Não podemos construir um sistema inteiro dessa forma. O padrão deve ser construir um sistema com qualidade e, se por algum motivo precisamos utilizar técnicas obscuras para liberar logo a funcionalidade, OK, desde que seja uma solução temporária e logo seja substituída pela solução correta.

A fita adesiva serve muito bem para tampar um burraco, mas não adianta querer montar uma estrutura inteira com ela que não dará certo. Mesmo esse burraco tampado precisa ser logo consertado.

Qualidade não é opcional

Softwares em geral não são bem vistos, encontrar erros se tornou normal. Anormal é um software com qualidade. Devemos mudar isso, e logo!!

Qualidade não deve ser algo a mais, deve ser o padrão. Um produto com qualidade não é mérito, é obrigação. Devemos investir em processos e práticas que possibilitem aumento na qualidade e produtividade.

Com melhores práticas quem sabe podemos evitar o uso de fita adesiva e mudar um pouco a forma como os softwares são vistos atualmente.

Teoria das janelas partidas

Uma teoria bastante interessante é a Teoria das Janelas partidas.  Ela diz:

"Considere-se um edifício com algumas janelas quebradas. Se as janelas não são reparadas, a tendência é para que vândalos partam mais janelas. Eventualmente, poderão entrar no edifício, e se este estiver desocupado, tornam-se "ocupas" ou incendeiam o edifício.  

Ou considere-se um passeio. Algum lixo acumula-se. Depois, mais lixo acumula. Eventualmente, as pessoas começam a deixar sacos de lixo.”

Basicamente, enquanto as janelas estão intactas, as chances de um vidro ser quebrado são pequenas. Assim que um janela é quebrada e permanece assim, logo mais e mais janelas são quebradas.

Enquanto que o prédio está intacto, significa que tem alguém cuidando dele. Assim que uma janela é quebrada e ninguém conserta, significa que não tem ninguém ligando pra ele. Se ninguém liga, por quê não quebrar mais uma janela?

Agora imagine essa situação no desenvolvimento de software (o site Coding Horror tem um artigo falando justamente disso, recomendo a leitura). No desenvolvimento de software ocorre exatamente a mesma coisa. Não, não estou dizendo que temos desenvolvedores vândalos, o que quero dizer é que, assim que um problema é negligenciado, logo o sistema todo estará ruim.

Um desenvolvedor olha para um determinado código ruim e pensa “isso está ruim, mas o sistema já é ruim mesmo. um problema a mais não faz diferença”. Tenho certeza que você já presenciou isso.
Como prevenir isso? Da mesma forma demonstrada na Teoria das Janelas Partidas. Não deixar os problemas se acumularem. A cada problema encontrado, resolvê-lo imediatamente. Ou seja, mostrar que tem gente que dá valor ao código, que cuida dele.

É uma teoria muito simples e fácil de ser aplicada. Evita que em pouco tempo tenhamos um código muito ruim. Na próxima vez que você ver um problema e deixar de corrigí-lo, lembre-se dela.