Extreme Go Horse ou Go Horse Process são metodologias de desenvolvimento de software fictícias, criadas pelos profissionais da área para satirizar a triste realidade encontrada no dia a dia das empresas desenvolvedoras de software.
Já falamos aqui no DT sobre Scrum e XP, que são metodologias de desenvolvimento verdadeiras e que requerem uma certa doutrina para serem implantadas nas empresas, porém, como na prática a teoria é outra, muitas empresas ainda não seguem nenhuma metodologia, fazendo o desenvolvimento e correções de seus software nesta sequência: Altera, Executa, Compila! Então, baseado no dia a dia destas empresas, surgiu a ideia de criar métodos de desenvolvimento satirizando os oficiais.
Seguem os primeiros 10 mandamentos da 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.
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).
Em uma rápida pesquisa na internet, você encontrará em diversos sites os demais mandamentos, além de conteúdos diversos sobre o assunto.
Últimos 5 artigos de Fernando Fonte