AgileZ

Se você programa em alguma linguagem de programação orientada a objeto, com certeza conhece os termos “Private”, “protected” e “public” e muito provavelmente sabe para que eles servem. Métodos ou membros públicos são aqueles que podem ser acessados por outras classes, os protegidos apenas pelos descendentes e os privados só possuem visibilidade local, ou seja, dentro da própria classe. Parece simples, porém, é muito comum encontrar programadores que parecem não seguir critério algum ao definir o nível de visibilidade dos membros de suas classes, ou então aplicam alguma metodologia aleatória para este fim. Propriedades que eram protegidas são publicadas durante o desenvolvimento de outras classes clientes, conforme a necessidade. Classes “amigáveis” (class friendly) são criadas para permitir acesso a funções protegidas. Práticas como essas acabam por criar uma arquitetura extremamente confusa, com componentes de difícil entendimento, difíceis de serem testados e expandidos. Qual seria então o melhor critério para evitar esse tipo de problema?

Leia mais…

Seguindo a tendência do artigo anterior (Sua equipe de desenvolvimento está no caminho certo?) vou falar um pouco sobre algumas questões que nem sempre são observadas pelos programadores, mas competem para a sua imagem como bom profissional.
É muito comum, principalmente entre programadores mais novos, o ideal do código perfeito. Muitas vezes o programador novato trabalha suas habilidades com a meta de se tornar um melhor codificador a cada dia. Essa fase é plenamente justificável, e faz parte do desenvolvimento do profissional, entretanto, conforme o programador for ganhando maturidade e experiência, é necessário que ele trabalhe outras habilidades não relacionadas à codificação, que podemos chamar de habilidades não técnicas.

Desenvolvi uma lista com algumas questões que devem ser observadas por todo programador. (lista baseada no artigo de Alberto Gutierrez ).

1. Seja disciplinado:
No nosso dia-a-dia nos deparamos com diversas interrupções e tarefas paralelas. Telefone tocando, email, mensagem instantânea, colega chamando e diversas outras. Ser disciplinado significa estabelecer uma metodologia para que essas interrupções prejudiquem o menos possível o seu desempenho e produtividade. Utilização de técnicas como a técnica do pomodoro, por exemplo, é uma excelente metodologia para manter o foco em uma tarefa por vez.

Leia mais…

Se você e sua equipe são adeptos do scrum ou outra metodologia ágil provavelmente devem conhecer ou utilizar testes unitários, mas não necessariamente o desenvolvimento orientado a testes (TDD). O teste unitário consiste basicamente em validar dados válidos e inválidos via entrada e saída, já o TDD utiliza teste unitário como parte de sua metodologia cujo principal objetivo não é testar as unidades (é um dos objetivos, mas não o único).

Em um cenário de desenvolvimento ágil, sem uso de TDD, o programador geralmente não conta com um modelo de classes em forma de diagramas – como outras metodologias pesadas. Por isso é comum a modelagem ser feita apenas mentalmente, em algum outro formato (rascunho em papel de pão?) ou até mesmo diretamente no código. As classes, operações e atributos vão surgindo conforme a necessidade, e são constantemente alterados e implementados até a conclusão da tarefa associada. Eventualmente, alguns testes de unidade são implementados baseando-se nas classes já prontas. Leia mais…

Programar muitas vezes é considerado como sinônimo de codificar, ou seja, escrever código para ser compilado. A importância de um bom algoritmo na qualidade final de um software é indiscutível e não pretendo levantar discussões a este respeito por aqui, mas colocar em pauta outro aspecto – que também é programação – porém nem sempre tem a atenção merecida: a interface gráfica, ou, mais precisamente, a interface de usuário (IU).

Assim como a parte que fica por debaixo dos panos (o código) a interface gráfica tem uma importância fundamental para o sucesso de seu sistema. Padrões de projeto (Design Patterns), Grasp, POO, POA e etc. São inúmeras as técnicas existentes para auxiliar a construção de excelentes softwares. Mas, quantos de vocês conhecem alguma para desenhos de interfaces gráficas? O que deve ter em mente o programador ou projetista de interface para construir uma boa IU?

Leia mais…

A programação orientada a objetos é, de longe, o paradigma mais utilizado em programação. Com várias décadas de existência, (apesar de muita gente não saber, a OO surgiu com as linguagens SIMULA I (1962-65) e Simula 67 (1967)) evoluiu bastante, porém, é muito comum encontrar projetos com problemas de arquitetura dos mais diversos tipos, entre eles, problemas de coesão, acoplamento desnecessários, generalizações inconsistentes e outras.

O intenção deste artigo é introduzir o conceito de GRASP (General Responsibility Assignment Software Patterns), que, conforme o nome já diz, tem o objetivo de tornar a distribuição de responsabilidade entre as classes uma tarefa mais criteriosa e eficiente, melhorando de forma significativa a qualidade de seu projeto e reduzindo os problemas de arquitetura mais comuns.

Leia mais…

Existe uma cultura entre os programadores na qual a máxima ‘use comentários sempre que puder e deixe seu código bem explicado’ é praticamente uma lei fundamental da programação. Pouca gente discute isso, afinal, nada como um código bem documentado para torná-lo legível, certo? Nem sempre. E é sobre esta questão que eu vou falar neste artigo. Quando devemos usar comentários? Até que ponto comentar é uma boa prática? Existem outros artifícios que podemos usar para substituir um comentário?

Para começar, vamos voltar um pouco pela história. Há muito tempo, os compiladores tinham uma limitação de memória, onde existia um limite de caracteres por arquivo compilável. Em consequência disso, os programadores eram obrigados a serem muito seletivos e econômicos ao codificar, usando o menor número de caracteres para nomes de operações, variáveis e etc. Imagine um complexo código de ordenação onde todas as variáveis tivessem apenas um caractere. A primeira variável seria a variável ‘a’, a segunda ‘b’, a terceira ‘c’. Qual seria sua reação, ao ‘tentar’ ler esse código? Um pouco confuso, provavelmente. Nessa hora qualquer um rezaria por encontrar um código bem comentado. Leia mais…

Um conceito simples, mas nem sempre bem entendido e aplicado. ‘Programar para uma interface e não para uma implementação’, você sabe o que isto significa?

Apesar deste conceito ser aplicável a projetos de software, é mais antigo que ele, e é utilizado bem antes do primeiro compilador ser desenvolvido. Um exemplo bem obvio do que é isto, pode ser encontrado na casa de qualquer pessoa: um interruptor de luz. ‘Como assim José?’.

Um interruptor de luz é um exemplo muito bom. Consiste em um botão, que liga e desliga a luz. Uma interface simples, que esconde os detalhes de implementação de quem vai utilizá-la. Para ligar a luz, basta apertar o botão, e para desligá-la, adivinhem? Aperte novamente. A implementação está bem encapsulada – o usuário não precisa entender nada de pólo positivo, neutro, 127v, amperagem ou resistência. Qual foi o pensamento do designer ao projetar um interruptor de luz? Com certeza foi algo parecido com: ‘qual o mínimo possível de informação o usuário do meu produto precisa para usá-lo?’.

Leia mais…