O uso de recursos em computação exige mais do que o simples conhecimento da plataforma. Também exige conhecimentos específicos como algoritmos e estruturas de dados. Os algoritmos são essenciais para minimizar o uso de processamento e as estruturas de dados são essenciais para descrever a informação de maneira mínima e racional.

Eu sempre bato nesta mesma tecla: algoritmos e estruturas de dados. Os estudantes de computação são levados a crer que é importante conhecer uma linguagem de programação em detrimento do conhecimento de algoritmos e estruturas de dados. Infelizmente, não poderiam estar mais enganados. Sem o bom conhecimento de algoritmos e estruturas de dados o resultado sempre é um programa excessivo: excesso de consumo de recursos, excesso de código desnecessário, etc.

Sou de opinião que a programação deve sempre orientar-se ao uso racional de recursos, ou seja, nunca partir da suposição que os recursos necessários estarão sempre disponíveis. Essa forma de pensar leva ao desenvolvimento de aplicações eficientes. Não basta apenas ser bonitinha: a aplicação precisa, também, ser rápida e responder prontamente ao usuário. Quanto mais uma aplicação demora, menor será a possibilidade de permanecer em uso. Afinal, o principal motivo das aplicações existirem são os usuários.

Com alguma frequência vejo alguns design patterns utilizados de maneira inadequada. Singletons são os mais usados de maneira incorreta. O façade, objeto deste artigo, também. Normalmente, o façade acaba tornando-se um tipo de classe “sacola” na qual tudo o que não se consegue modelar como objeto acaba indo parar.

Basta lembrar-se para o que o façade serve: para unificar uma API esparsa em um único ponto. Ou seja, a ideia do façade é servir como entry point em uma API complexa, criando  uma interface mais simples de ser utilizada. Isso é bem diferente de socar toda e qualquer funcionalidade que não se sabe bem onde deveria ficar.

O efeito negativo de transformar o façade em uma classe sacola é a criação de uma classe enorme, com métodos igualmente grandes e que é programada basicamente como se fosse um conjunto de funções e não um conjunto de métodos pela disjunção funcional que acaba existindo entre cada um dos métodos introduzidos.

Eu bato muito na tecla da manutenção pois é com ela que se gasta mais tempo nos ciclos de desenvolvimento de software.

Introduzir código pronto, de terceiros, introduz no seu sistema uma variável descontrolada que irá atingir em cheio a manutenção do seu código. O que as pessoas não conseguem entender é que usar uma biblioteca de código aberto aumenta o trabalho de manutenção do código. Por que? Por que o código introduzido no seu sistema agora faz parte do seu sistema. E como este código foi escrito por seres humanos é certo que contém defeitos. Quem vai consertá-los?

A postura correta é consertar os defeitos e publicar as correções para a comunidade que mantém o código. Afinal, você abraçou a causa depois que resolveu introduzir o código no seu projeto. Agora o filho é seu também. Assim, ao introduzir código aberto no seu sistema você também tornou-se um mantenedor deste mesmo código. O problema, que poucos enxergam, é o custo que isso gera para os projetos da empresa. Afinal, alguém terá de dedicar horas de trabalho para manter código aberto, gratuito, e cada hora de trabalho custa dinheiro à empresa. Seu salário vem no fim do mês, não é mesmo?

O uso indiscriminado de código aberto dentro de projetos nas empresas gera prejuízos não por que o código aberto é ruim, mas pela falta de planejamento na utilização deste código. Empresas como a IBM, por exemplo, financiam projetos de código aberto para poder usufruir dos mesmos. Há um planejamento e envolvimento empresarial consciente nestes projetos. Porém, um programador introduzir à revelia uma biblioteca de código aberto em um projeto irá gerar prejuízos para a empresa pois a falta de planejamento na utilização deste código custará horas de manutenção em código de terceiros.

]]> http://www.ronaldolima.eti.br/2012/02/14/vai-mesmo-usar-codigo-achado-no-google-no-seu-sistema/feed/ 0 http://www.ronaldolima.eti.br/2012/02/14/app-para-mobile-um-sistema-de-informacao/ http://www.ronaldolima.eti.br/2012/02/14/app-para-mobile-um-sistema-de-informacao/#comments Tue, 14 Feb 2012 10:05:36 +0000 ronaldo http://www.ronaldolima.eti.br/?p=955 Desenvolver aplicações, as famosas apps, para dispositivos móveis está na moda. Muita gente desenvolve aplicações para as plataformas móveis sem ter um mínimo de conhecimento de programação de computadores, como se isso fosse descartável. O resultado são aplicações lentas, pesadas e que consomem muito mais recursos do que deveriam.

As aplicações para dispositivos móveis são sistemas de informação. Não basta fazer uma interface bonita. É preciso ter um projeto sério de engenharia de software para que a aplicação torne-se um sucesso nas lojas on-line. Isso significa dizer que é essencial conhecer-se algoritmos, estruturas de dados, design patterns e outras matérias específicas de computação.

Canso de dizer e repito: um designer não tem a menor condição de implementar uma aplicação de sucesso apenas por fazer o design. O recheio, o código, precisa de modelos matemáticos de dados para suportarem a funcionalidade pretendida pela aplicação. Além do modelo, é preciso ter código que manipule o modelo matemático de maneira eficiente e eficaz.

Não quero desmerecer o trabalho do designer. Eu desenvolvo software e entendo o quanto o bom design é importante e essencial para a criação de uma aplicação. No entanto, da mesma forma que um programador normalmente não tem condições de fazer um bom design de UI, o designer não tem condições de fazer um código para a aplicação. É como pedir para um matemático pintar um quadro ou um pintor resolver uma equação.

Eu tenho visto bastante disso aqui na nossa terrinha: designers acreditando que podem escrever aplicações para dispositivos móveis. O resultado são aplicações belíssimas, mas cheias de defeitos, desde problemas básicos de navegação até problemas mais sérios como consumo de bateria, crashes inesperados e falhas graves de manutenção de dados. Por que isso? Pelo simples fato de que são aplicações desenvolvidas por quem sabe fazer UI mas não tem a mínima ideia de como modelar os dados, as relações entre eles e em como produzir informações através de processamento eficiente e eficaz.

O desenvolvimento de aplicações para dispositivos móveis é desafiador pois os recursos disponíveis são reduzidos e podem exaurir-se muito facilmente, ao contrário do que ocorre com os desktops ou servidores nos quais os recursos são abundantes. Os paradigmas são outros o que traz ao código final uma complexidade que não existe em máquinas com recursos.

O que é

O modificador register surgiu em uma época em que os otimizadores eram ainda primitivos. Ele era utilizado para informar ao compilador para colocar a variável dentro de um registrador do processador, visando agilizar cálculos e otimizar a performance. No entanto, o modificador só pode ser utilizado em tipos inteiros, ou seja, int, long, unsigned e char. O motivo para isso é simples: o registrador da CPU só funciona com números inteiros. Cálculos com números em ponto flutuante são função da ALU - arithmetics and logic unit, ou o co-processador matemático que hoje em dia já faz parte do processador em si.

A principal característica do modificador register é que não se pode obter o endereço de memória do objeto modificado. Por exemplo, o código abaixo gera um erro de compilação:

register int i;

int *k = &i;

Apesar de impedir a extração do endereço de memória da variável, usar o modificador register não garante que a variável será efetivamente colocada em um registrador da CPU. Em verdade, este modificador funciona como um hint para o otimizador, informando que a variável pode ser colocada em um registrador.

Por que é pouco usado

Como dito, o modificador  register é pouco usado pois as melhorias dos otimizadores fizeram-no perder o significado ao longo dos anos. Os otimizadores modernos analisam o código e colocam as variáveis inteiras, principalmente índices usados em loops no registrador da CPU automaticamente, sem a necessidade de hints no código.

O seu maior uso é em índices dentro de laços, onde requer-se que o incremento do conteúdo da variável ocorra da maneira mais rápida possível.

Por que usar

Eu vejo o modificador register com bons olhos. Ele é interessante para documentar no código que a variável declarada com ele não é passível de obtenção de endereço e, além disso, é uma variável que possivelmente é usada para indexar alguma estrutura de dados. Eu entendo que este modificador melhora a clareza do código, deixando mais óbvio o uso das variáveis. Apesar de não ser garantido que determinada variável será colocada no registrador da CPU, acredito que o seu uso em termos de documentação de código deixa mais clara a intenção de determinada declaração.

Sou de opinião que o código tem de ser bem legível a ponto de deixar claras as intenções de quem o escreveu. Isso faz com que a manutenção seja mais fácil e o código seja mais legível. É uma obrigação do programador deixar seu código legível visando a fácil manutenção futura, nem que seja para ele mesmo dar manutenção.

O fato é que o mal está à solta no mundo. Não falo no sentido religioso, mas no sentido prático. Que há pessoas más, não é novidade para ninguém. No entanto, cada vez mais a sociedade em que vivemos demonstra que a árvore da maldade está cada vez mais frondosa, enraizando-se mais profundamente e aumentando a quantidade de pessoas que comem do seu fruto.

O mal praticado contra os inocentes  ganha nova faceta, ou seja, é praticado dentro de casa, dentro da estrutura da família. Pais que abusam de seus filhos violentam a pureza e a inocência, tirando de seus filhos a leveza de ser criança e plantando a semente da destruição em suas almas.

Cada vez mais me convenço que estamos assistindo ao declínio da sociedade moderna que está colapsando por sobre sua estrutura, demonstrando que vivemos o tempo da queda do mundo conforme o conhecemos. As relações entre as pessoas começam a transformar o indivíduo em coisas desprovidas de pensamento ou emoção, fato que é comprovado pelos abusos e violência que vemos inocentes sofrerem.

Crianças são forçadas a abandonar sua inocência e pureza pois tornam-se infectadas pelo vírus do mal, muitas vezes inoculado pelas pessoas que deveriam cuidar do seu crescimento sadio. Isso aumenta a insanidade destes tempos pois o ser humano perde seu valor, é desrespeitado e torna-se apenas um pedaço de carne em cima de duas pernas.

Eu enxergo nesse fenômeno do aumento da maldade um fato que é a diminuição da esperança. As pessoas têm menos esperanças, menos motivos para sorrirem. Alimentam-se de coisas sem valor deste mundo sendo que deveriam valorizar a vida que os cerca. Isso os condena à uma existência vazia, sem sentido e os tornam seres famintos, sempre com fome de algo que possa preencher suas almas. O resultado é que alimentam-se das coisas erradas, coisas que não preenchem seu vazio interior.

Ao contrário, o vazio aumenta, bem como a fome. Por fim, tornam-se famintos que sentem as dores da fome mas que nunca serão capazes de satisfazerem-se. Estão condenados.

As expressões lambda são ótimas para a criação de pequenas rotinas que precisam ser implementadas in place. A principal vantagem de utilizá-las é permitir que pequenos trechos de código, de escopo bem definido, sejam organizados em blocos de código bem destacados. O Objective C, por exemplo, faz uso corriqueiro das expressões lambda para a implementação de uma série de métodos em diversos objetos.

Como todo recurso poderoso de uma linguagem de programação, é preciso ter consciência em usar uma expressão lambda. Esse negócio existe para facilitar a escrita de pequenos trechos de código e não para que você escreva uma encíclica papal contando a História do Mundo desde a Criação.

A expressão lambda é útil, também, para criar uma hierarquia de funções, coisa que é suportada na linguagem Pascal, por exemplo. Em Pascal é possível declarar-se uma função ou procedimento dentro de uma função ou procedimento e assim sucessivamente. Em algumas circunstâncias é muito interessante limitar o escopo de uma determinada funcionalidade do seu código, criando hierarquias de definições.

O Objective C ainda permite que as funções lambda sejam atribuídas a variáveis, algo como um ponteiro para funções mas com estrutura totalmente variável. Isso dá à linguagem uma flexibilidade enorme para a criação de algoritmos adaptativos e polimórficos, dando ao programador uma tremenda ferramenta para criar rotinas simples e poderosas.

Reserve um horário do dia

Reserve um horário para estudar. Que seja meia-hora. Que seja no seu trabalho. O seu patrão vai agradecer depois, pois você está, na verdade, tornando-se um profissional melhor. Tire o telefone do gancho, saia do seu e-mail e dos messengers. E estude profundamente, de preferência ouvindo alguma música agitada. Música relaxante vai te fazer dormir. Prefira rock.

Estude o que pode usar imediatamente

Seja seletivo ao estudar. Procure estudar algum assunto que tenha a ver com o que está fazendo atualmente. Estude o assunto que possa melhorar o seu trabalho, tornando-o mais fácil para você. A equação aqui é bem simples: trabalho mais fácil, lucro mais alto. Você lucra por fazer o mesmo trabalho mais rápido e terá tempo mais livre para fazer as coisas realmente relevantes na sua empresa.

Varie linguagens de programação

Se você for programador, procure estudar outras linguagens de programação. O objetivo não é tornar-se um mestre Jedi de todas as linguagens, mas aprender paradigmas diferentes que podem ser aplicados na sua linguagem atual. Por exemplo, o estudo de TCL pode lhe ajudar a ter uma visão melhor de listas de dados e essa visão pode ajudá-lo a desenvolver rotinas mais eficientes em linguagens como C ou C++.

]]> http://www.ronaldolima.eti.br/2012/02/02/mantenha-o-estudo-em-dia/feed/ 0 http://www.ronaldolima.eti.br/2012/01/28/vai-mesmo-deixar-o-codigo-com-advertencias/ http://www.ronaldolima.eti.br/2012/01/28/vai-mesmo-deixar-o-codigo-com-advertencias/#comments Sat, 28 Jan 2012 09:19:31 +0000 ronaldo http://www.ronaldolima.eti.br/?p=925 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.

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.