pt-br.md

1. Pensou, não é XGH.

Com XGH você não pensa, você 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;
• A forma XGH, é exatamente igual à errada, contudo mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software (veja 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 os 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 banco por um script maluco).

8. Esteja preparado para pular fora quando o barco começar a afundar. Ou coloque a culpa em alguém.

Para quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, maior a probabilidade. O dia que a casa cair, é melhor o seu currículo estar cadastrado na APInfo, ou ter alguém para 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 (veja 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 (veja 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 (veja Axioma 10).

13. XGH é absoluto.

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! (veja Axioma 1)

14. XGH é atemporal.

Scrum, XP? tudo isso é modinha. O XGH não se prende às modinhas do momento. 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 (veja Axioma 1).

16. Não tente remar contra a maré.

Caso os seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Para 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 (veja Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (veja Axioma 8). Não tente gerir o XGH, ele é autossuficiente (veja 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 (veja Axioma 10), e o seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19. Se funciona, não rela.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (veja 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 para quê? 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 pensar que as chances do projeto fracassar ao utilizar 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 para você foi um sucesso!

22. O problema só é seu quando seu nome está nas docs 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.

23. Mais é mais.

Com o XGH você prospera na duplicação de código. A qualidade do código não tem sentido e não há tempo para revisões de código ou refatoração. O tempo é essencial, então copie e cole, rapidamente!

---

Original source: gohorseprocess.com.br/extreme-go-horse-xgh