Como Developer e com o passar dos anos, irás concordar comigo que temos de encarar todos os tipos de cenários: desde os projectos mais fáceis aos mais complexos e as soluções que os clientes pedem. Mas porquê cair na ratoeira de construi-las de uma forma mais complexa daquela que realmente interessa??!

KISS – Keep iSimple, Stupid

O termo KISS (sigla em inglês para “Keep it Simple, Stupid”, ou alternativamente “Kids In Satan’s Service”), que em português (cof cof), não interessa muito, é preferível explicar o que realmente quer dizer com isto.

Vamos falar da história. É um princípio que foi cunhado por um engenheiro norte-americano, Kelly Johnson, durante a década de 60. A expressão surgiu quando, tentava demonstrar à sua equipa que o projeto de um avião de guerra deveria ser tão simples, que pudesse ser reparado por um mecânico qualquer no campo de guerra. A partir daí, o termo foi adaptado e utilizado em diversas áreas, especialmente no desenvolvimento de softwares e outros projetos mais complexos, para que o sistema fosse concebido de forma simples a fim de beneficiar tanto programadores quanto usuários.

O princípio KISS pressupõe que o escopo deve ser definido de forma simples, para que a sua execução e o produto final sejam bem-sucedidos. No KISS, projetos inteligentes pressupõem simplicidade com o objetivo de evitar excessos e problemas de funcionamento.

Apesar de conter a palavra “estúpido”, o princípio não remete que os projetos sejam desenvolvidas para usuários, ou por programadores alinhados ao termo em questão. No KISS, projetos inteligentes pressupõem simplicidade com o objetivo de evitar excessos e problemas de funcionamento.

 

YAGNI – You Ain’t Gonna Need It
Muitas vezes começamos a programar um sistema e damos por nós a criar funções só para caso de virem a ser necessárias, como se se tratasse de uma ansiedade em adicionar/pimpar o nosso “bebezinho”. Errado!

Está é a filosofia do “não vais precisar dele”. Muitas vezes coloquei funções que no momento não eram necessárias no sistema, então o que começou a acontecer? Pessoas a ligar e a perguntar: “Para que serve isto?“. Além do trabalho a mais de atender as pessoas e retirar ou desabilitar a funcionalidade, isso pode trazer processamento a mais sem necessidade. Já ouvi muitas pessoas dizerem: “O que realmente é importante?”, dica:

“Se é barato fazer agora e barato depois, deixe para depois. Se é barato agora, mas ficará caríssimo depois, faça agora.”

DRY – Don’t Repeat Yourself.

Pessoalmente este é um dos princípios mais importante. Se estás a repetir demasiado código, então estás a fazer alguma coisa errada! Don’t Repeat Yourself. Não te repitas. Supõe que o esforço para se corrigir um bug, para um programador normal, é X. Para um programador que faz copy & paste o mesmo código em vários sítios, o esforço é X vezes a quantidade de cópias do mesmo trecho.

“Define um método, propriedade uma só vez e reaproveita-o!”

Este exercício, para nós developers, é quase como um treino/desafio do dia-a-dia. Mantém a lógica apurada, e cada vez se torna mais fácil e rapidamente se domina uma linguagem ou biblioteca nova, da mesma forma que os matemáticos precisam de exercitar o músculo do cérebro através de exercícios para que estejam fresquinhos.

/body>