Em Setembro de 2016 tive a chance de participar do DevOpsDays Oslo. Durante a conferência vi uma palestra muito engraçada e esclarecedora sobre “Como acabar com o DevOps” e fiquei inspirado em criar um post sobre como acabar com a Qualidade de Software.

A ideia aqui é apresentar cinco passos para sabotar um projeto de software.

Passo 1 – Não se importe com padrões de projeto e código limpo

Tenha certeza que você criou um código que apenas funciona, ele não precisa ser legível. Mesmo sabendo que desenvolvedores gastam 10 vezes mais tempo lendo código do que escrevendo, você não tem que se preocupar com isso. Se possível, crie o máximo possível de spaghetti code. Também não use nenhum tipo de padrão (em algumas partes do código escreva código de uma maneira e em outras partes escreva códigos que deveriam ser similares de maneira totalmente diferente) e recuse ferramentas para verificação de sintaxe de código. Programadores de verdade não precisam de ferramentas de verificação de sintaxe de código, elas bloqueiam a criatividade.

Passo 2 – Não teste a aplicação, e se fizer, teste apenas manualmente

Como um desenvolvedor de software você deve saber que está fazendo a coisa certa, então, não existe necessidade de testar. Mas se decidir testar, garanta não usar nenhum tipo de automação, pois isso consumirá seu tempo, e daí, além de ter que manter o código da aplicação você terá que manter o código dos testes também. Portanto, evite isso sempre!

Passo 3 – Não refatore

Você não precisa se preocupar em fazer seu código melhor se ele já está funcionando. Como se diz: “em time que está ganhando não se mexe”. Você também não precisa fazer o seu código legível para os outros que irão mantê-lo no futuro, afinal de contas, muito melhor é usar esse tempo desenvolvendo uma nova funcionalidade, aumentando ainda mais a complexidade da aplicação.

Mas se você decidir refatorar, garanta que não irá executar nenhum tipo de teste de regressão (e o mesmo para desenvolvimento de novas funcionalidade ou correção de bugs). No máximo, teste somente se o que você mudou ainda funciona. Só isso. Você realmente não precisa se preocupar se quebrou alguma coisa, você é um bom desenvolvedor e sabe exatamente o que está fazendo. Não se importe com efeitos colaterais.

Passo 4 – Não use integração contínua

Já que você não depende de testes automatizados, é fácil evitar o uso de integração contínua, pois você não tem basicamente nada para rodar. Na verdade, você tem que achar uma maneira de fazer o feedback loop o mais difícil e lento possível, pois assim ninguém saberá que as suas mudanças foram a causa raiz das funcionalidades que quebraram. Além disso, certifique-se de não tomar quaisquer medidas preventivas. Seja sempre reativo.

Passo 5 – Nunca escute o feedback dos usuários

Não escute os problemas e necessidades dos usuários, foque apenas no que você pensa que é importante, em outras palavras, foque nos itens mencionados antes. Você é o especialista e sabe exatamente o que precisa ser desenvolvido, e como isso será legal. Então, por que ouvir os usuários? No final eles nunca sabem o que querem.

Se você seguir os 5 passos acima, eu garanto que você acabará com a qualidade de software de seu projeto!

Esse post foi publicado originalmente no Medium em Inglês. Veja o post original aqui.

=D