eXtreme Go Horse Programming
Autor: CodeLife | Publicado: 2011-09-10T16:51:00-03:00




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.



Fonte: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/