POG – Programação Orientada a Gambiarra

On 5 de agosto de 2010, in Curiosidades, Programação, by sergiolemos

Nesse Artigo iremos tratar de um dos mais abrangentes paradigmas modernos o POG

Introdução

Com o gigantesco aumento do número e porte das empresas do setor de TI, a demanda por novas tecnologias cresceu absurdamente. Como as técnicas de programação seqüencial, por botão, procedural e orientada por objetos não conseguem mais suprir a qualidade máxima esperada pelos softwares geradores de relatórios que necessitam de massiva quantidade de recursos como desempenho, performance e throughput, a Programação Orientada a Gambiarras foi desenvolvida.

Origem

Algoritmos probabilísticos possuem comportamene randômico, ou seja, para uma coisa que entra (ui!), qualquer coisa que sair como resultado está ok. A metodologia POG está diratemente ligada com o meio científico, pois tarefas muito complicadas encontradas neste meio não podem ser resolvidas com algoritmos determinísticos triviais e, portanto, os Algoritmos Probabilísticos entram em cena. O resultado disto é o amplo uso de técnicas que geram saídas randômicas e principalmente Gambi Design Patterns, vide Simulador Network Simulator.

Desta forma, resultados de artigos científicos levam em consideração apenas as saídas favoráveis. Se o algoritmo não está dando “aquele resultado ótimo”, rode até que aquela flagzinha ser ativada.

O primeiro POG que se tem notícia é datado de 1582 d.C. O nome deste POG hoje é chamado de Ano Bissexto, foi criado pelo Papa Gregório XIII, Este POG foi aplicado quando descoberto que a Terra leva 365,25 dias para dar uma volta no Sol, porém nosso calendário tem apenas 365 dias, o que leva a uma diferença de 6 horas por ano. Fonte: Arial

Ao invés de corrigir o “sistema” para que não houvesse essa diferença, a solução adotada pelo Papa foi: “A cada quatro anos, é só colocar mais um dia ali”. E então foi criado o primeiro POG de que se tem notícia. Por este motivo, em 1930 foi instituído o “Dia Internacional da POG” como o dia 29 de fevereiro.

Definição de POG

A Programação Orientada a Gambiarras (POG ou WOP – Workaround-oriented programming) é um paradigma de programação de sistemas de software que integra-se perfeitamente a qualquer grande Paradigma de Programação atual.

Por definição, Gambiarra é aquilo que é de difícil concepção, de inesperada execução para tornar fácil o uso de algo que sequer deveria existir.

A Programação Orientada a Gambiarras foi uma evolução natural do uso do Programa Bacalhau, também conhecido como ATND – “Artifício Técnico Não Documentado” ( na Química, também conhecido como MTEDM – “Manutenção Técnica com Elementos Disponíveis no Momento” e na Engenharia Civil como STCT – “Solução Técnica de Cunho Temporário”, nome pouco apropriado, uma vez que, todos sabemos, as soluções se tornam permanentes), dos anos 1960–1980, e vem de uma antiga expressão brasileira: “Para quem é, bacalhau basta” (época em que o peixe seco ainda era barato). Programadores e analistas mais preocupados em usar buzzwords costumam utilizar o termo workaround para impor respeito.

Para que um programador possa exercer a Programação Orientada a Gambiarras, são necessários alguns fatores específicos, facilmente encontrados em ambientes de desenvolvimento:
* Sistemas originalmente mal projetados
* Clientes chatos
* Usuários chatos
* Falta de vontade
* Falta de tempo
* Gente que pensa que é DBA (normalmente são pessoas chatas, gordas, feias, sem certificação nenhuma e que fizeram um curso de SQL Básico)
* Arquiteto de software achando que é o máximo (normalmente pessoas altas, loiras, chatas, arrogantes e metidos a sabe-tudo)
* Término do estoque de café/chá
* Aproximação do final da tarde
* Véspera de feriado/fim-de-semana
* Ter o Jackie Chan como chefe
* Ter o MacGyver como coordenador de projeto (ver Método MacGyver)
* Governo defecando regras ou MP’s que entram em vigor imediatamente sem dar tempo de atualizar sistemas.
* Requisitos dinâmicos e/ou instáveis
* Produto com implementação pré-determinada que se torna personalizado (leia-se mutante) para angariar “aquela grande licitação”
* Área comercial vendendo ou pré-vendendo produtos imaginários ou inacabados com “entrega garantida em 30 minutos ou seu dinheiro de volta!”

Reunidos, todos estes fatores transformam o programador em um gambiarrizador, espécie mais evoluída de programador, que possui curva de aprendizado e produtividade muito mais acentuadas. Os códigos dos gambiarrizadores podem ser chamados de CACA (Código Avançado Complexo e Adaptável) que possuem, dentre outras qualidades, reusabilidade e legibilidade em seu auge.

Estudos realizados neste segmento mostram que os programadores que evoluem para gambiarrizadores vivem melhor, saem as 18:00h, tem cabelos mais bonitos e esvoaçantes. Tudo pelo fato de que, em gambiarrizadores, eles entram em um estado alfa, onde tudo na vida funciona. Tudo que é impossível torna-se possível, de maneira totalmente obscura, mas possível.

Há correntes de programadores que discriminam a Programação Orientada a Gambiarras, alegando ser uma má técnica, que faz com que os sistemas fiquem lentos e ganhem bugs. Também ficou claro nas pesquisas que estes programadores só dizem isto por nunca terem evoluído para gambiarrizadores (e por isso nunca pegam mulher nenhuma). Com apenas uma evolução (ao contrário de ‘ como o Charmander, que necessitam de duas para atingir o ápice de seu desenvolvimento), 100% dos programadores admitem que a Programação Orientada a Gambiarras, definitivamente, é o melhor paradigma de todos.

Além disso, a Programação Orientada a Gambiarras, assim como outros paradigmas, deu origem a outros movimentos de pesquisa científica como Modelagem Orientada a Gambiarras (MOG ou WOM – Workaround-oriented modeling), Desenvolvimento de Sistemas Orientado a Gambiarras (DSOG ou WOSD – Workaround-oriented software development).

Conceitos de POG

A POG utiliza fortemente o conceito de enjambração. Enjambrar consiste em “adaptar” um novo item ao sistema. Por exemplo, você tem um software em C+=1, e o compilador de C=C+1 compila código C também. Baseado nisso, você pega aquele código que você escreveu em Pascal durante a faculdade, roda o p2c (famoso tradutor de Pascal para C) e encaixa no seu código.

Outro exemplo do conceito de enjambração, que ocorre fora do mundo do software, é quando estamos escrevendo um TCC ou outro trabalho do tipo. Podemos, por exemplo, utilizar o Fabuloso Gerador de Lero-Lero (software especializado em geração de Prosopopéias Flácidas Para Acalantar Bovinos, ou Conversa Mole Para Boi Dormir) para gerar um texto com 900mil frases. Logo após, é só escrevermos uma adaptação de meio parágrafo antes e depois do texto gerado para que este se encaixe com o trabalho atual.

Reflexão

O princípio da Reflexão parte do ponto de vista de que os reflexos são reflexões daquilo que se reflete ao refletir em nossa visão. Computacionalmente falando, é quando refletimos algo fazendo com que a nova imagem seja igual (um reflexo) da antiga. Para isso, utilizamos as teclas Ctrl+C para gerar a imagem, e Ctrl+V para depositá-la em outro lugar.

Antes de tentarmos utilizar recursos como a Enjambração, devemos ganhar em produtividade com a Reflexão. A Enjambração só é produtiva se a Reflexão não der certo.

Insistimento

Outro recurso da POG para ganharmos em produtividade é o Insistimento. Caso um programa possua um erro de compilação, devemos tentar compilá-lo novamente mais algumas vezes para nos certificarmos de que não foi “um bitzinho problemático” que deu problema na hora da compilação. Caso não funcione várias vezes, podemos tentar reiniciar a máquina. Se ainda não der certo, diga ao seu chefe que você suspeita que a máquina está com problemas de hardware e por isso não compila.

Se ele arrumar uma máquina nova ou consertar a atual, diga que deve ser pau do sistema operacional, pois todo mundo sabe que Linux não funciona direito. Após reinstalar o Linux, tente remover ou adicionar alguns comentários para ver se eles não estão “bugando” o compilador.

Após tudo isso, diga ao cliente que está procurando uma solução: “Sabe como é né, essas coisas com programação são assim, uma coisinha errada pode ferrar tudo.”

Depois tente tudo denovo. Se nada der certo, aí sim podemos procurar um código na internet para tentar resolver o problema

PPOG (Princípios da Programação Orientada a Gambiarras)

* Se funciona, então tá certo – Acoplado ou não, txt ou sql, mil funções ou 10, design patterns… Nada disso tem valor para o usuário, que só precisa de um software funcional. O termo “escalável” é falacioso.

* My Way – Programador esperto, se é esperto mesmo é adepto do My Way. Se você está com dúvidas, faça do seu jeito pois se der merda é você quem vai se foder (e como).

* Deixe o amanhã para amanhã – Muitos programadores atrasam projetos alegando que a demora de uma implementação para seguirem regras de design patterns ou comentários que ajudarão a outros entender melhor o código. Deixe o amanhã para o otário programador seguinte.

* Comentários são para amadores – Um desenvolvedor deve ser treinado para ser fluente na linguagem de programação usada sem precisar de comentários, independente da consequente ruína de sua vida social. Isso também é conhecido como sétimo sentido.

* Eficiência primeiro – Evite escrever em várias linhas o que pode ser feito em uma.

* Fé em Deus – A informática é levianamente definida como ciência exata, quando esta é na verdade uma ciência holística. Vários casos reais de divina Providência foram testemunhados em ambientes fiéis aos princípios ruins, assim o mal foi exorcizado, e a paz instalou-se graças a fé dos gambiarrizadores. Vale dizer que: há mais mistérios entre o teclado e o monitor do que julga a sua vã filosofia.

* 1337 h4x0r5 dud3 lol – Quanto mais ilegível, mais respeitado o código é. Consequentemente menos alterado ele é, e mais estável o sistema fica, garantindo a empregabilidade do gambiarrizador.

* A ocasião faz o ladrão – Em determinados momentos não conseguimos escapar dela.

* Capacidade de Abstração – Este conceito se baseia em focar-se no problema e desconsiderar conceitos e dados deios para atingir o objetivo, ou seja, o Programador deve abstrair tudo que lhe faça perder tempo como regras de negócio desnecessárias ou tratamentos de erros.

* Conclusão Hipotética Universal Técnica Explicativa (aka. C.H.U.T.E) – Quando nenhum dos outros conceitos se aplica, utiliza-se este até funcionar ou desistir.

* Criatividade acima de tudo – Uma pessoa criativa não é aquela que consegue chegar a diversos lugares, mas sim, aquela que chega no mesmo lugar por diversas maneiras. Portanto, o POGer não é nada mais do que um programador criativo, que faz a mesma coisa que outros, adotando técnicas não convencionais.

* Simplicidade acima de tudo – Se o programa funciona sem o Tratamento de Exceções e a verificação de campos preenchidos pelo usuário porque complicá-lo ?

* Faca nos dentes – O famoso “Vai fazendo ai!”

Incremental Patching Debug (InPaDe)

Uma situação bastante corriqueira no dia-a-dia de um desenvolvedor POG é a de a versão atual parar de funcionar, inexplicavelmente, após um build. Nestes casos, geralmente causados por intervenções de espíritos malignos no código ou olho gordo de colegas invejosos, podem ser resolvidos facilmente por IPG.

Basicamente, o desenvolvedor POG precisa apenas encontrar o zip da última versão que funcionou, mesmo que alguns bugs corrigidos voltem ou algum trabalho se perca. Nem sempre é rápido, mas quase sempre é possível. Lembre-se, um bom programador POG controla versões com arquivos zip, sempre mais práticos do que aquele monte de comandos chatos e difíceis de decorar do CVS.

Uma vez encontrada a versão, vai-se inserindo aos poucos as modificações da versão atual na versão antiga, compilando e testando, até que ela passe a funcionar novamente. Ferramentas de comparação podem ser usadas neste processo, mas nem sempre são necessárias: substituição simples de arquivos funciona perfeitamente bem.

Controle de Versionamento

O POGer, por definição, evita o uso soluções padrão e no controle de versão isto não é diferente. Porque utilizar CVS, SVN e Git enquanto você pode utilizar o bom e velho .zip ? Ferramentas mais sofísticadas que Winzip, ou Winrar são para iniciantes. POGer bom tira conflito na hora do merge só no olho.

A técnica para se manter a ordem dos arquivos é a seguinte. Cria-se o arquivo backup.zip com todo o código fonte do projeto. Durante o tempo de vida do projeto, independente de qual seja este tempo de vida, 2 ou 3 backups são suficientes. Para isto, crie os arquivos backup1.zip e backup_ultimo.zip. Se as coisas ficarem (um pouco) fora de controle crie arquivos backup_ultimo_ultimo.zip e, se necessário vá incrementando com a palavra “ultimo” a cada novo backup. Se as coisas ficarem realmente feias o próximo arquivo deve se chamar backup_ultimo_ultimo_agora_eh_verdade.zip. Não se esqueça de sempre aumentar o nome do arquivo a cada novo backup. Isto facilita encontrar a última versão.

Algoritmos probabilísticos

Meu programa não tem bugs, apenas desenvolve funcionalidades aleatórias

Algoritmos probabilísticos possuem comportamene randômico, ou seja, para uma coisa que entra (ui!), qualquer coisa que sair como resultado está ok. A metodologia POG está diratemente ligada com o meio científico, pois tarefas muito complicadas encontradas neste meio não podem ser resolvidas com algoritmos determinísticos triviais e, portanto, os Algoritmos Probabilísticos entram em cena. O resultado disto é o amplo uso de técnicas que geram saídas randômicas e principalmente Gambi Design Patterns, vide Simulador Network Simulator.

Desta forma, resultados de artigos científicos levam em consideração apenas as saídas favoráveis. Se o algoritmo não está dando “aquele resultado ótimo”, rode até que aquela flagzinha ser ativada.

Modelagem Orientada a Gambiarras (MOG)

Ao contrário de outras abordagens para modelagem existentes, que são geralmente complexas, contêm inúmeros diagramas que não representam nada (diagramas de classe, de estados, de seqüência, etc), a MOG é muito mais simples e eficiente. Todo sistema a ser desenvolvido possui um único diagrama, muito mais simples e eficiente do que os outros existentes. Esse diagrama representa 100% corretamente qualquer sistema e seu comportamento, evitando que a especificação fique desatualizada durante o processo de desenvolvimento.

Tipos de Erros POG

Acesso danado: ocorre quando você não tem permissão no local, muito comum no Linux, pois o Windows nem conhece a palavra “permissão”.

* Resolução do problema: Dê permissão total à todos.

Estouro de Time-out: ocorre quando o desenvolvedor que não possui habilidades no uso de POGs cria aplicações que são lentas e, desta forma, “estoura” o tempo estipulado para o processamento:

* Resolução do Problema: Aumente o tempo de Time-out para que este tenda ao infinito.

Documentação de projetos POG

Apesar do comprovado sucesso das metodologias POG, certos gerentes de projeto ainda recorrem a práticas desnecessárias e onerantes, como documentação de projeto. Entra em cena a esperteza de certos programadores e analistas POG.

Documento de Requisitos – Após as primeiras reuniões com o cliente, o vendedor usa os requisitos como entrada para um programa gerador de lero-lero. Assim nasce o documento de requisitos. Ele converte a linguagem coloquial do cliente para uma terminologia que ninguém entende. O cliente assina sem entender, os gerentes passam para os analistas sem ler, e esses fazem o MOG do sistema baseados no lero-lero.

Por fim, o cliente pede 150 funcionalidades a mais, os gerentes aceitam e não cobram, o prazo estoura e a culpa é do desenvolvedor.

UML – Forma que os analistas POG acharam de usar os desenhos de escola dos filhos para representar um sistema (vide Use Cases).

Documentação Orientada à Politicagem – A documentação tá lá pros analistas tirarem os seus da reta e colocarem a culpa no programador quando o projeto falhar. Ou então, caso tenha sucesso, levarem todo o crédito.

Prazos de um projeto POG

A grande vantagem da metodologia POG é entregar produtos com qualidade acima da média, mas também em prazos curtos. Existem vários tipos de prazo, cada um com seus prós e contras.

Prazo Jack Bauer
Gerente de TI: “São 150 funcionalidades no sistema. Você tem 24hs…”

Prazo Suicida
Gerente de TI: “O sistema precisa estar pronto agora!” Então, o programador POG, tendo assistido Constantine, corta os pulsos. O tempo para, e ele implementa o sistema. Lógico, que, como suicida, ele tem que implementar através de ssh direto do inferno. Deus, vendo o auto-sacríficio do cara, sente pena e manda ele de volta. O sistema fica pronto em alguns segundos.

Prazo Sanfona
Programador:”Devo gastar 24 horas para esse projeto”
Lider Técnico:”O Programador faz isso em 2 horas”
Prazo dado pelo Gerente de Projetos: “40 horas sendo uma previsão inicial”
Tempo realmente gasto: 160 horas

Prazo Capitão Nascimento
Gerente de TI: “Quanto tempo você precisa 0101?”
Programador:”Oito horas.”
Gerente de TI: “Oito horas?!? 0101 o Senhor é um fanfarrão! O Senhor tem oito segundos!”
Programador:”Mas, senhor..!
Gerente de TI: “Mas senhor é o caralho, o senhor tá com nojinho?”
Programador:”Não senhor..”
Gerente de TI: “Então senta o dedo nesse teclado e começa a programar!”

Ciclo de vida de um projeto POG

O ciclo de vida dos projetos POG se resumem às fases:
1. Entusiasmo
2. Desilusão
3. Pânico
4. Busca dos culpados
5. Punição dos inocentes
6. Honra e glória aos não participantes (no final quem não tem nada a ver com o projeto é que salva)
7. Os inocentes que não foram mandados embora, assumem a manutenção do Sistema.

Fonte: http://www.programei.org/index.php/08/09/2009/pog-programacao-orientada-a-gambiarra/

 

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

*

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">