Me perdoem o off, mas eu não pude resistir de mandar isto para a lista! Trata-se de um metodo de programação chamado eXtreme Go Horse ou XGH.
eXtreme Go Horse (XGH) *1- Pensou, não é XGH.* XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida. *2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.* XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14). *3- Quanto mais XGH você faz, mais precisará fazer.* Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito. *4- XGH é totalmente reativo.* Os erros só existem quando aparecem. *5- XGH vale tudo, só não vale dar o toba.* Resolveu o problema? Compilou? Commit e era isso. *6- Commit sempre antes de update.* Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam. *7- XGH não tem prazo.* Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco). *8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.* Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa. *9- Seja autêntico, XGH não respeita padrões.* Escreva o código como você bem entender, se resolver o problema, commit e era isso. *10- Não existe refactoring, apenas rework.* Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8). *11- XGH é totalmente anárquico.* A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4). *12- Se iluda sempre com promessas de melhorias.* Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10). *13- XGH é absoluto, não se prende à coisas relativas.* Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça! *14- XGH é atemporal.* Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade. *15- XGH nem sempre é POG.* Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1). *16- Não tente remar contra a maré.* Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH. *17- O XGH não é perigoso até surgir um pouco de ordem*. Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos. *18- O XGH é seu brother, mas é vingativo.* Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo. *19- Se tiver funcionando, não rela a mão.* Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível. *20- Teste é para os fracos.* Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente. *21- Acostume-se ao sentimento de fracasso iminente.* O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso! *22- O problema só é seu quando seu nome está no Doc da classe.* Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8. ------ "E lembre-se: O Google <http://www.google.com.br/> é seu melhor amigo!" Mike Maciel Consultor | Desenvolvedor | Programador Cel: (65) 8405-0370 | Email: [email protected] http://www.mike.etc.br/ | http://desenvolvaweb.net/ Chat Skype: mikemaciel MSN: [email protected] icq: 238019088 Contacte-me: [image: Twitter] <http://twitter.com/mikemaciel>[image: Facebook] <http://www.facebook.com/profile.php?id=100000073438376>[image: Orkut] <http://www.orkut.com.br/Main#Profile?uid=11315338764427961029>[image: del.icio.us] <http://del.icio.us/mikemaciel>[image: Blog RSS]<http://mike.etc.br>[image: Linkedin] <http://br.linkedin.com/pub/mike-maciel/21/597/39> Mike & Etc - O Blog do Mike: Deus é brasileiro!<http://www.mike.etc.br/humor/deus-e-brasileiro/>
_______________________________________________ Lista mailing list [email protected] http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
