Reflexões sobre os “Princípios da Programação Orientada a Gambiarras”

A bíblia do P.O.G

É complicado… Agora são 03:46 da madrugada e enquanto assisto o empolgante GP da Austrália de F1 decidi falar um pouco sobre P.O.G, eu sei… É a total falta do que fazer, mas não resisti, então deixa eu falar um pouco sobre os “principios” do P.O.G, hoje tão presentes no mundo do desenvolvimento de software, ou da tecnologia de forma geral e que tem contaminado a mente de brilhantes homens do mundo tecnológico que preferem tomar o caminho aparentemente mais rápido, mas no final mais doloroso…

Como todo paradigma de programação, a P.O.G também possui todos aqueles diversos conceitos xaropes que nos fazem ver o mundo mais bonito dentro de softwares super bem feitos. Como qualquer teoria científica, o P.O.G tem sua definição técnica-filosófica:

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

Você achou que eu estava brincando quando falei que ia falar sério sobre esse assunto? Não estou brincando, e inclusive quero ver alguns conceitos rápidos com você, mas antes disso uma pergunta: Porque empresas de softwares e programadores autonomos usariam o P.O.G? A resposta pode ser:

  • 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 (Método MacGyver)
  • Governo soltando 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!”

Quando se faz necessário o uso do P.O.G (necessário?) é preciso respeitar algumas regrinhas básicas, que são os chamados “CONCEITOS NORTEADORES DA TEORIA DO P.O.G” e eis que vou “esquadrinhá-las” nesse momento:

CONCEITOS NORTEADORES DA TEORIA DO P.O.G

Enjambração

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++, e o compilador de C++ 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 900 mil 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.

Redireção

Uma das características que proporcionam grande ganho de produtividade. A redireção consiste em uma análise para verificar todos os envolvidos em um problema. Após esta análise, fazemos a redireção do problema aos envolvidos. Quanto maior o número de envolvidos, mais redireções do mesmo problema poderemos fazer.

“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 Windows não funciona direito. Após reinstalar o Windows, 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 complicar tudo.” Depois tente tudo de novo. Se nada der certo, aí sim podemos procurar um código na internet para tentar resolver o problema.

Você estava achando que esse negócio de P.O.G era brincadeira, mas existem até livros sobre esse tema e estudos científicos sobre sua eficiência… De onde você acha que eu tirei todas essas informações tão profundas sobre o tema? Eu me aprofundei nesse tema depois de ver uma palestra apresentada no 4° SOLISC (CONGRESSO CATARINENSE DE SOFTWARE LIVRE), onde o Paulino Michelazzo ministrou o tema: “P.O.G NUNCA MAIS”, mas deixe para ver essa palestra no final deste texto (coloquei os slides para vocês verem).

Voltemos aos conceitos do P.O.G, onde não existem apenas os conceitos, mas também os principios práticos:


Princípios da Programação Orientada a Gambiarras

  1. 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.
  2. 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 errado é você quem vai se dar mal mesmo (e como).
  3. Murphy ou Lei de Murphy ou Lady Murphy – Para lidar com Murphy e seu exército só com POG. Murphy é sagaz e ligeiro, esta só esperando você dar mole. Nada mais rápido do que uma gambiarrazinha pra acertar o que Murphy destrói.
  4. 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 coitado do programador seguinte.
  5. 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.
  6. Eficiência primeiro – Evite escrever em várias linhas o que pode ser feito em uma.
  7. 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.
  8. 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.
  9. A ocasião faz o ladrão – Em determinados momentos não conseguimos escapar dela.
  10. Capacidade de Abstração – Este conceito se baseia em focar-se no problema e desconsiderar conceitos e dados alheios 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.
  11. 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.
  12. 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.
  13. 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 ?
  14. Faca nos dentes – O famoso “Vai fazendo ai!”
  15. Se compilou é porque funciona – Deu certo? Deixa! Funcionou? Não mexa!
  16. Se ninguém reclamou é porque esta funcionando! – Se todos seguissem esse conselho teriam menos problemas
  17. Vai programando aí que eu vou ver o que o cliente quer – Comece logo a desenvolver o projeto, depois você vê o que o cliente precisa!
  18. Limpa o histórico e o cache e dá um [Control + F5] que funciona – Essa engana qualquer cliente de sistemas web, coitados…
  19. Travou? Tenta dar [Ctrl + Alt + Del]. Se não funcionar, desliga e liga de novo a máquina – Este é o principio de que a culpa sempre é do cliente, e não sua
  20. Hmmm.. que estranho… Não era para acontecer isso – Quando não se tem idéia da resposta, utilize esse recurso!
  21. É que 1GB de RAM é pouco! Tem que colocar mais memória!!! – Uma ótima saída para ganhar tempo
  22. Ontem tava funcionando! – Esse recurso é muito bom quando se fez tanta gambiarra que o código já não roda mais

Quanto absurdo embutido nesses “conceitos”, mas será que os Poger´s ficarão sempre impunes? Não há condenação para esta “raça” de programadores que cada vez mais se espalha no mundo? (inclusive em grande corporações que não quero citar o nome…), ainda bem que o próprio ciclo de vida do P.O.G já mostra qual o futuro desses programadores mestres na gambiarra:


Ciclo de vida de um projeto POG

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 se salva)
7. Os inocentes que não foram mandados embora, assumem a manutenção do Sistema.

Bem, para quem queria escrever pouco sobre essa teoria ridícula eu acabei escrevendo até demais… Como eu disse, para o pessoal que gosta do PHP deixo os slides de uma palestra bem interessante sobre como não ser um POGer nessa linguagem tão injustamente condenada exatamente pelo uso das teorias acima, liberte-se e seja um programador de verdade!

Você pode gostar...

8 Resultados

  1. Rodrigo disse:

    Puxa REVOLTADO, agora entendi melhor sua colocação e concordo com você! Todos os programadores do mundo já copiaram alguma coisa de alguém com certeza! E seu professor estava certo em não ficar reinventando a roda sem já existe solução disponível!

    Meu foco neste post não o Crtl+C/Ctrl+v, e sim a filosofia da gambiarra, da coisa mal feita que bem provavelmente vai custar o emprego do próprio poger, ou do programador que assumir uma bucha dessas…

    O que mais existe hoje são métodos eficazes de análise, programação e documentação, então porque fazer um serviço ruim? Não há justificativa!

  2. REVOLTADO disse:

    BEM, NA VERDADE O QUE EU QUERO DIZER E O SEGUINTE. NINGUEM CRIA NADA DO ZERO, E NINGUEM JA NASCEU SABENDO. MINHA CRITICA E A SEGUINTE ATIRE A PRIMEIRA PEDRA QUEM NUNCA USOU UM SCRIPT DE TERCEIROS. CASO CONTRARIO NAO EXISTIRIAM APIS, FRAMEWORKS, J-QUERY, CLASSES E TANTAS OUTRAS FUNCOES. A DIFERENCA PROFISSIONAL SE DA NA BUSCA CONSTANTE POR CONHECIMENTO, LIVROS FORUNS ETC. JA PAGUEI UMA CADEIRA DE INFORMATICA E A COISA QUE O PROFESSOR MAIS FALAVA ERA A QUESTAO DE REIVENTAR A RODA. TUDO BEM QUE VC DESCORDE, MAS PENSE NISTO.

  3. REVOLTADO. disse:

    ACHO ESSE TEXTO MUITO IDIOTA. TODOS TEM QUE TER OPORUNIDADE, FICO FELIZ PORQUE VOCE TEVE. MAS O MUNDO ESTE CHEIO DE GENTE COM MUITO CURSO QUE NAO SABE FAZER NADA.

  4. Rodrigo disse:

    Muito obrigado Alex, Rafael, Marco (ótima contribuição sobre conceitos POG´s) e João Paulo! O que eu posso aqui complementar sobre o assunto é que os conceitos POG´s me parecem que faz parte de uma cultura que não luta pela qualidade total, e sim apenas pelo resultado dentro do prazo estabelecido (prazo este quase sempre fora da realidade, e resultado este que é muitas vezes só aparente).

    Além da falta de qualificação, melhores salários, analistas mais competentes, empresas de TI mais comprometidas com a qualidade e melhores faculdades, a cultura é a grande culpada, a famosa solução do “jeitinho” para tudo! Fiquem espertos!!!

  5. João Paulo Paiva disse:

    Muito legal esse material seu sobre POG, eu vivo escutando o pessoal falar dessas falhas na má programação de softwares. É a primeira vez que ouço o termo, vou logo disseminar seu blog para os meus colegas da faculdade, talvez alguns não conheçam, parabéns pelo blob.

  6. Marco disse:

    “Warning NÃO é erro!” Dizer Popular POGer.
    Gostei mto da sua explanação sobre P.O.G.,
    eu que não sou especificamente área de computação/TI mas
    preciso mto de programação para o desenvolvimento de autonomos,portanto vc já deve imaginar como os meus códigos são mantidos por “adaptações pertinentes”, como não tenho muitos recursos de programação uma ramificação da POG surguiu… e percebi dentre os meus colegas que essa mutação do POG era comum a todos nós, dai um novo filo nasce o W.B.H (Workaround Based Hardware) vulgo Hardware Basea em POG, apartir de um código que atende minimamente aos requisitos exigidos, atendendo quase que de forma utópica, desenvolve-se um hardware que suprirá as deficiencias do seu software de comando, porém este W.B.H. tabem não é elaborado da forma mais “esperada”. Contando com recursos singulares escolhidos de forma bastente parametrizada pelo seu desenvolvedor.
    Entre nós estabelecemos a seguinte comvenção:
    1 – só é gambiarra se realmente não funcionar; se funcionar e for replicado já se torna solução parametrisada produzida em série;
    2 – Apartir do momento em que se obteve sucesso na adaptação, esta plenamente apto a notificar o fabricante e redigir um AppNote (Applications Notes) para que sua “Inovação” seja difundida.
    3 – se o projeto original não é seu vc esta desenvolvendo uma sólução extremamente expecifica para o seu estudo de caso.

    Sem mais delongas o POG vai mto mais alem do que nós podemos conceber Rodrigo!

  7. Rafael disse:

    Não sou a favor de forma alguma ao POG, mas também acho que todas esses padrões, design patterns, etc e tal muitas só servem pra tornar o projeto mais caro, e mais demorado

    Muitas vezes o simples também funciona!

  8. Alex disse:

    Eu to aqui morrendo de rir principalmente dos conceitos de “enjambração”, “insistimento” e “redireção”, muito fera!

    Não sou da área de TI mas vejo que muitos desses conceitos são usados em outras áreas, é tosco demais

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *