Não é incomum ver código de produção que quando compilado apresenta uma quantidade enorme de advertências geradas pelo compilador. Normalmente este é primeiro teste que executo quando estou avaliando a qualidade de um código: a quantidade de advertências que este gera ao ser compilado. Advertências deixadas para trás denotam duas coisas: negligência por parte do programador e baixa qualidade do código final.
As advertências existem para demonstrar que há pontos de problemas potenciais no seu código. Estes problemas não são suficientemente graves para impedir a geração do código executável, mas são problemas ainda assim. O fato do executável final ser gerado não significa que ele presta. As advertências são um aviso sobre a má qualidade do executável final.
O código precisa compilar sem nenhuma advertência. Ponto final. O programador que deixa advertências no código que escreve é negligente. Os problemas estão lá. E vão acontecer quando forem para a produção. O primeiro teste que precisa ser feito é a compilação do código. Código com advertências não pode, jamais, ir para a produção. Nunca!
Até hoje não entendo por que os programadores, principalmente os mais inexperientes, ignoram as advertências acreditando que seu código é livre de suspeitas. A advertência, em si, já é um indício de que algo não vai bem.
A palavra de ordem é objetividade. O grande desafio de qualquer programador é escrever código que seja objetivo, ou seja, a menor quantidade de código possível que resolva um problema proposto. Sem frescura, sem invenção de moda, sem a preocupação de demonstrar conhecimento. Curto e grosso. No entanto, não é sempre assim na área de computação. É comum encontrar engenharia de foguete onde deveria ter, no máximo, uma casinha de sapé.
Design Pattern à força
Há programadores que querem usar design patterns de qualquer maneira em seus códigos. É bonito, é elegante, mas em grande parte do tempo desnecessário. Você deve usar design patterns onde eles são necessários e não por que você os conhece. Infelizmente há programadores que forçam o uso de design patterns para a resolução de problemas de programação. O efeito colateral é código complexo, altos footprint e consumo de recursos.
O resultado é apenas um: código desnecessariamente complexo, de difícil manutenção e com problemas que não acabam mais. Não é incomum ver software coberto de defeitos sem fim que nunca são totalmente consertados.
Desenhe antes de programar!
Gaste todo o tempo do mundo desenhando e planejando o que você vai fazer antes de sair programando como um animal de carga que não olha para os lados. É possível fazer desenvolvimento e design incrementais, mas isso exige muita disciplina. Desenhe antes! Faça esquemas, use papel, lápis, caneta, faça disso uma arte. Não comece a programar a menos que você já tenha estruturado tudo o que você vai fazer antes.
A falta de desenho antes de iniciar a programação leva a código confuso, principalmente para programadores sem muita experiência. Código sem desenho é altamente acoplado, com falhas de encapsulamento e com problemas tais que chegam a ser gritantes. Desenhe antes, programe depois. E entenda que mesmo depois de haver desenhado o que você vai fazer, você precisará ajustar seu desenho durante a escrita do código. É um trabalho interativo.
Leia e pesquise
Pesquise sobre a linguagem e o ambiente que você vai utilizar antes de sair programando. Por que isso? Para evitar quer você saia escrevendo código que já existe. Não acredite e não seja pretensioso de achar que seu código é melhor do que o código de um SDK ou biblioteca. O seu código nunca foi testado pois você o está escrevendo agora. O código do SDK ou biblioteca já foi muito testado, consertado, alterado e evoluído. Programe com humildade.
Replicar em código o que já existe é comum de quem sai programando com viseira, sem olhar para os lados, preocupado apenas com o prazo final. Sim, o prazo de entrega é importante. Mas é importante, também, que o software chegue lá funcionando. Não adianta nada atingir um prazo final com um software cheio de problemas. Isso irá te ocupar desnecessariamente e consumirá os recursos do projeto a ponto de levá-lo ao prejuízo. Dependendo do tamanho do prejuízo seu emprego estará em xeque.
Os filmes e as músicas são caros, por isso baixo tudo de graça da internet.
Esta é a desculpa de quem fomenta a pirataria. O fato de não concordar com os preços e o anonimato proporcionado pela internet faz aparecer um Robin Hood às avessas que rouba dos ricos e distribui para si mesmo os frutos do roubo. As pessoas esquecem-se que podem fazer uso de um direito seu que, por fim, faz os preços baixarem: o seu poder enquanto consumidor.
A lei mais básica do mercado é chamada de “Lei da oferta e da procura”. Quando a oferta é maior que a procura, os preços são baixos. Quando a procura é maior que a oferta, os preços são altos. Não concorda com o preço do CD da sua banda favorita? Não compre! Espere baixar até um preço que você considere aceitável.
Por que não concordo com a pirataria? Por que as coisas levam tempo e dinheiro para serem feitas. O artista investe seu tempo e dinheiro para produzir trabalho de qualidade tal que possa ser vendido. O justo é remunerar este artista pelo trabalho que ele teve em nos entreter. Se o preço é muito alto ou se não concordo com o preço, procuro por outro entretenimento, que seja mais condizente com minha condição financeira. Isso funciona assim desde a pré-história.
O impulso consumista é o que leva as pessoas optar pela pirataria. A ansiedade e o desejo em ter algo é tamanho que as barreiras da moral são postas de lado e comete-se o crime acreditando-se que se está fazendo a coisa certa. Você gostaria de vender seu trabalho de graça? Certamente que o artista que fez o filme ou a música que você gosta não gostaria.
Ah, mas a indústria da mídia abusa e coloca preços altíssimos! Bem, quando você vai comprar verdura precisa pagar o preço que lhe pedem. Se você acha que está caro demais o que você faz? Reclama com o comerciante e não compra. Basta fazer isso: reclame com a indústria da mídia e não compre! Se você não comprar vale a lei da oferta e da procura. Fatalmente o preço vai cair.
O cenário é simples: você precisa compartilhar algum tipo de informação entre várias partes do seu código. A solução mirabolante: usar uma variável global. Afinal as variáveis globais estão acessíveis de todos os lugares e facilmente você introduz referências à ela em diversas partes do seu código.
Isso é uma péssima ideia. O uso de uma variável global denota péssimo design. Trata-se de um radical livre dentro do seu código que pode levá-lo a comportamentos erráticos, principalmente se a sua aplicação utilizar mais de uma linha simultânea de execução. A lista de problemas que podem ser causados por variáveis globais é tão grande que é melhor evitar o seu uso a todo custo.
Desenhe e redesenhe!
Ficou difícil compartilhar informações no seu código? Isso é sinal de que a modularização está ruim e precisa de um redesenho. Não tenha medo de mudar as coisas de lugar. É preferível redesenhar toda a sua estrutura de código do que deixar pontos de falha potenciais como uma variável global. Siga a Lei de Murphy: o que puder ser montado ao contrário, será montado ao contrário (este é o enunciado original).
Um bom desenho da estrutura do seu código poderá livrá-lo de várias dores-de-cabeça. A variável global é uma delas.
Por que a variável global é ruim?
O seu programa é, na verdade, uma máquina de estados. O estado do seu programa, como um todo, é dado pela soma dos estados de cada objeto individual que existe no seu programa. Apesar de usar o termo objeto, estou me referindo a qualquer coisa que possa mudar o comportamento do seu software, ou seja, variáveis e não, necessariamente, objetos como em Programação Orientada ao Objeto.
O estado do seu programa independe da linguagem de programação. E a manutenção deste estado depende de como os objetos em memória são tratados e controlados. Sempre é uma boa ideia manter todo o controle de estado centralizado. Assim você consegue controlar o ciclo de vida de cada objeto durante o processamento dos dados. Porém, as variáveis globais tem o controle do seu estado compartilhado por áreas do seu código que nem sempre são evidentes, dificultando a manutenção.
Isso quer dizer que não fica evidente no seu código qual módulo ou função altera o estado de uma variável global, tornando a manutenção uma caça de agulhas em palheiros. A situação fica ainda pior quando há várias threads utilizando um estado compartilhado globalmente, o que pode levar a mudanças assíncronas de estado completamente sem controle pois a execução das threads dependem da quantidade de time sharing que lhes foi reservada e que pode ser de tamanho completamente arbitrário.
Assim, o controle do estado de uma variável global torna-se distribuído no seu código sendo difícil mantê-lo ao longo do tempo. E é certeza que todos os piores defeitos do seu código ocorrerão nas rotinas que alteram o estado de uma variável global.
As aplicações de mensagens instantâneas hoje são lugar comum. O ICQ, pioneiro nesta classe de aplicações, não é mais popular. As aplicações mais populares são o MSN da Microsoft, Skype, recém comprado pela Microsoft e o gTalk. E nesse meio há os softwares integrados que permitem usar vários protocolos na mesma aplicação.
Sou usuário do Skype há bastante tempo e também há bastante tempo que a qualidade da aplicação vem decaindo. As chamadas peer to peer, a principal característica do software, caiu de qualidade com interrupções frequentes, baixa qualidade de recepção e travamentos diversos. O MSN nunca teve muita qualidade nas conversas peer to peer, sendo bom para o envio de mensagens instantâneas.
Ontem tive a oportunidade de usar o protocolo do gTalk através do iChat, um software integrado da Apple para o Mac. O resultado foi agradável: excelente qualidade do vídeo transmitido e recebido bem como excelente qualidade de áudio. Houveram algumas pequenas interrupções na conversa, mas nada que fosse suficientemente gritante como vem ocorrendo com o Skype.
De uma forma geral, a aplicação é simples e não permite, por exemplo, a conferência com várias pessoas, uma feature importante e que diferencia o Skype dos seus concorrentes.
