PPOG (Princípios da Programação Orientada a Gambiarras)
Fonte: http://desciclo.pedia.ws/wiki/Pog#A_Origem_do_POG
* 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).
* Murphy ou Lei de Murphy ou Lady Murphy – Para lidar com Murphy e seu exército só com POG. Murphy é sagaz e ligeiro, tá só esperando você dar mole. Nada mais rápido do que uma gambiarrazinha pra acertar o que Murphy destrói.
* 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!”
Bem, eu vou falar e não me matem por isso… Sempre tive cuidado em simplificar o código, mas algumas vezes depois de algum tempo olhamos naquele aplicativo feito à 5/6 meses e vemos que a qualidade de código nunca é superior à que usamos no projecto de ontem (isto é verdade em muitos programadores de sucesso)…. pelo simples facto que a pratica leva à perfeição e a evolução é de tal maneira que nem as linguagens de programação escapam. Sinceramente algumas vezes penso que as pessoas programam menos bem, não porque querem, mas sim porque não sabem mais, e nesses casos apenas a observação e aprendizagem vai trazer resultados…
É claro que há excepções, eu regularmente recebo/vejo animações flash/as3 feitas por uma empresa (bem grande) para inserir em alguns projectos, e tomo sempre atenção ao código deles, e vejo as suas perfeições mas muitas vezes também imperfeições, porque acredito que o dia-a-dia numa empresa de animação grafica/publicidade/programação 3d web não é facil e que em alguns projectos eles simplesmente querem é o trabalho pronto no menor curto espaço de tempo, bem como os clientes e nem querem saber de eventlistners para saberem se existem erros ou não… (às vezes por terem a certeza que não dá erros…mais uma lei de murphUI, funciona graficamente? logo não dá erros e não precisa de handlers).
Mas existem muitos mais promenores que podem fazer a diferença, gosto muito de me reger pela ideia que um aplicativo caminha para o sucesso quando esgotamos e tratamos todas as possibilidade de erro do mesmo.
Bom… sorry pelo testamento!
Abraços!
@Mario Santo – excelente comentário, meu amigo! Atualmente, minha codificação fica obsoleta de um projeto para o outro, pois eu aprendo sob demanda, afinal, preciso ganhar a vida e não posso passar meses em cima de teoria.
Gostei do trocadilho “MurphUI” =)
Ehhehe
Assim como eu tb as vezes parto pra uma gambiarrazinha.
Afinal ninguem é perfeito.
Aqui acontece do cliente pagar pra empresa (150 doletas hora) para um servico, mas quer o servico pronto em dois dias.
Mas como o q eles sempre querem, nao da pra fazer em apenas dois dias, partimos pra umas gambiarras da vida.
Mas afinal, isso faz parte e a gente vai aprendendo.
Aprendendo a fazer API, codigos reaproveitaveis q possamos ocupar pra outros trabalhos.
Abs