Existem motivos para não seguir as boas práticas de desenvolvimento de software?
Calma, não abandone a leitura do livro Clean Code ainda. Ainda não leu? Comece! Vai mudar sua vida profissional. Minha intenção com este texto não é causar confusão, e sim abrir um diálogo sobre “tradeoffs”. Minha opinião sobre boas práticas? Siga sempre que puder! Quando quero aprender uma linguagem ou ferramenta nova, minha primeira atitude é procurar no google algo como “rails best practices”, assim sei que vou começar meu aprendizado da melhor forma possível.
Existem diversas boas práticas no desenvolvimento de software, relacionadas aos mais diversos níveis, desde a facilitação da resolução de problemas pontuais a solução de arquiteturas complexas. A natureza da existência de uma boa prática é a utilização contínua da mesma por diversas pessoas, o que acaba por instaurar um “padrão”.
Porém mesmo como boas práticas que são, é preciso saber quando utilizá-las. Elas devem servir como um guia, sendo assimiladas profundamente e mudando seu jeito de programar. Eu ainda me lembro de como eu era logo que comecei a programar, com as minhas próprias idéias, sem ter muitas referências. Quando comecei a ter contato com coisas como Design Patterns, guias de estilo de código ou TDD comecei a perceber que existia um jeito muito melhor de fazer as coisas do que o meu e lentamente (beeem lentamente) fui adotando cada uma dessas “regras”. Como tenho alguma dificuldade em guardar nomes, muitos conceitos ou padrões eu não lembro exatamente como se chamam, mas com o tempo muitos já viraram parte do meu jeito de pensar, e as idéias começam a surgir “envelopadas” com o formato de um padrão específico.
Alguns conceitos são difíceis de entender o propósito a início, mas facilmente vemos os resultados de quem os adota, nesses casos pode faltar motivação ou capacidade de decidir se devo ou não utilizá-los. Nesses momentos uma boa tática é: “Fake it until you make it”.
Se você está iniciando em qualquer coisa que seja, você deve buscar primeiro o conhecimento e a experiência de pessoas referência que já passaram por onde você está passando e seguir seus princípios à risca, mesmo que ainda não consiga ver claramente como os benefícios acontecem. Quando eu comecei a aprender Angular, encontrei o Angular Style Guide do John Papa, que mostra diversas boas práticas para criação de aplicações com Angular, e simplesmente segui a risca o que estava ali. Passado esse período inicial, comecei a perceber que alguns princípios estavam entrando no meu caminho. A verdade é que mesmo que grande parte do que estava escrito ali fizesse sentido e fosse realmente de grande utilidade, alguns itens simplesmente não se encaixavam com o projeto em questão. Temos que levar em conta que cada projeto de software é único e portanto deve ter seus próprios padrões, logicamente baseados nas boas práticas já existentes no mercado de desenvolvimento de software.
Um exemplo de boas práticas está no “Object Calisthenics”. No livro “The ThoughWorks Anthology”, Jeff Bay criou algumas diretrizes para um exercício que nos capacita a criar softwares com qualidade. O objetivo não foi criar regras para serem seguidas a risca em todos os seus projetos, e sim que através da repetição de determinadas práticas, você se torne um programador melhor, e assim seja capaz de tomar suas próprias decisões, não se limitando as “regras” do Calisthenics. É importante deixar claro que eu gosto e acho altamente recomendável seguir as instruções cunhadas no livro sempre que possível, afinal o resultado normalmente é muito satisfatório. Se você está começando, minha dica é seguir a risca, tomar como regras (afinal faz parte do exercício) e quando entender o impacto, tomar suas próprias decisões sobre se vale ou não a pena implementar todos os conceitos.
Quando você se ver entre a lança e a espada precisando tomar uma decisão que pode afetar o seu projeto, primeiro avalie sua própria experiência. Você já adotou as boas práticas extensivamente o suficiente e com isso construiu experiência suficiente para saber quando ela não deve ser aplicada? Se sim, vá em frente, mas lembre-se que você é o único que tem capacidade de julgar sua própria experiência portanto acaba sendo o único responsável por qualquer decisão que tomar. Por mais perfeccionistas que sejamos, o software não é um fim, e sim um meio, uma ferramenta. Você pode fazer o software mais bonito e perfeito do mundo, se ele não atender os objetivos para o qual foi construído, com as restrições impostas, ele não vai fazer a diferença para a sociedade que todos queremos que ele faça.
