K.I.S.S - Mantenha as coisas Simples

Hoje vamos tratar do princípio K.I.S.S - 'Keep it simple, stupid'.

KISS, não é aquela banda de rock famosa, é um acrônimo para "Keep it simple, stupid" e, é um princípio de design observado pela Marinha dos EUA em 1960.

O princípio do KISS afirma que a maioria dos sistemas funciona melhor se forem mantidos simples e não complicados; portanto, a simplicidade deve ser uma meta fundamental no design e a complexidade desnecessária deve ser evitada.

Assim o princípio KISS valoriza a simplicidade do projeto e defende que toda a complexidade desnecessária seja descartada.

Esse princípio pode ser aplicado a qualquer cenário, incluindo muitas atividades de negócios, como planejamento, gerenciamento e desenvolvimento. Vamos considerar a abordagem focando o design e desenvolvimento de software.

Um problema comum entre engenheiros e desenvolvedores de software é que tendemos a complicar demais os problemas. Vivemos em um mundo complicado e estamos trabalhando em diferentes projetos em desenvolvimento, alguns são muito simples e outros são complexo. Assim, enquanto trabalhamos em projetos simples, muitas vezes optamos por seguir o caminho difícil que seguimos em projetos mais complicados.

'Tente manter o processo o mais simples possível'

Neste cenário, muitos programadores simplesmente ficam presos em uma certa linha de pensamento, que não é necessariamente a linha de pensamento correta. Em geral, cada tarefa de programação pode ser realizada de inúmeras maneiras.

Para buscar dados de um banco de dados, você pode escrever um procedimento armazenado e chamá-lo usando o ADO.NET ou o Entity Framework (supondo que você use o .NET); ou você pode escrever a consulta em sua base de código usando o ADO.NET; ou talvez você escreva uma consulta LINQ com o Entity Framework (ou LINQ to SQL, ou talvez ainda esteja preso aos conjuntos de dados digitados).

Agora, se formos contar as maneiras pelas quais você pode escrever sua consulta SQL ou LINQ, em breve chegará à conclusão de que existem centenas de maneiras de fazer algo tão simples quanto obter dados de um banco de dados.

Neste cenário é melhor avaliar e seguir o caminho mais simples ou seja o que usa o código mais claro, mais robusto e menor.

Todos nós experimentamos situações nas quais tínhamos trabalho a fazer no projeto e encontramos um código confuso. "Por que eles escreveram essas linhas e condições desnecessárias quando poderíamos fazer a mesma coisa em apenas 2-3 linhas?"

Basta dar uma olhada nos dois códigos mostrados abaixo. Ambos os métodos estão fazendo a mesma coisa, mas qual você usaria?

public String diaSemana(int dia) 
{  
    if ((dia < 1) || (dia > 7)) throw new InvalidOperationException("dia deve estar entre 1 e 7");  
    string[] dias = "Segunda","Terça","Quarta","Quinta","Sexta","Sabádo","Domingo"};  
    return dias[dia - 1];  
}

public String diaSemana(int dia) {  
    switch (dia) {  
        case 1:  
            return "Segunda";  
        case 2:  
            return "Terça";  
        case 3:  
            return "Quarta";  
        case 4:  
            return "Quinta";  
        case 5:  
            return "Sexta";  
        case 6:  
            return "Sábado";  
        case 7:  
            return "Domingo";  
        default:  
            throw new InvalidOperationException("dia deve estar entre 1 e 7");  
    }  
}

Dessa forma, sempre que possível, a complexidade deve ser evitada em um sistema - pois a simplicidade garante os maiores níveis de aceitação e interação do usuário. O objetivo de qualquer processo/projeto deve oferecer o resultado mais simples possível.

Falar é fácil, mas mostre-me como ???

Segue algumas diretrizes básicas:

- Mantenha seus métodos pequenos, cada método nunca deve ter mais de 50 a 100 linhas.

- Cada método deve resolver apenas um pequeno problema, não muitos casos de uso. Se você tiver muitas condições no método, divida-as em métodos menores. Não só será mais fácil ler e manter, como também encontrar bugs muito mais rapidamente.

- Não use lógica complexa se isso puder ser feito com simplicidade. Porque criar todo um sistema de Login se já houver um pronto que pode ser usado ou adaptado ?

- Não tenha medo de jogar fora o código. Ao refatorar o código, sempre remova o código indesejado.

- Resolva o problema e codifique-o. Antes de tudo, dedique tempo para entender o problema e como ele pode ser resolvido. Somente depois desse salto parta para resolvê-lo. Divida suas tarefas em subtarefas e resolva uma por uma, mantendo-as simples.

- Às vezes, usamos recursos sofisticados da tecnologia apenas para usá-los; não devemos usá-los até que seja necessário.

- Conheça as melhores práticas! Veja alguns bons livros sobre o assunto:

01 - Clean Code by Robert Martins

02 – Design Patterns: Elements of Reusable Object-Oriented Software by Eric Gamma

03 – Patterns of Enterprise Application Architecture by Martin Fowler

04 – Enterprise Integration Patterns by Gregor Hohpe

05 – The Mythical Man-Month by Frederick Brooks

06 – Code Complete by Steve McConnell

07 – Git for Teams by Emma Hogbin Westby

08 – Refactoring: Improving the Design of Existing Code by Martin Fowler

09 – The Art of Unit Testing by Roy Osherove

10 – Soft Skills: The Software Developer’s Life Manual by John Sonmez

- Certifique-se de pesquisar no Google por soluções antes de inventá-las. Porque reinventar a roda ??? Você não pode saber tudo, mas pode pesquisar tudo no Google e encontrar uma solução que mais se aproxima do seu objetivo.

- Não confie em tudo que lê na web. Até na MSDN existem alguns artigos que mostram más práticas! Continue usando seu bom senso.

- Pratique, pratique, pratique! A prática leva ao aperfeiçoamento.

- Depois leia o código - leia muito. Descubra o que funciona e o que não funciona e entenda o porquê.

Agora, Simples não significa "rápido, desleixado e sujo."

Na verdade, muitas vezes simplificar implica em muito trabalho que inclui várias iterações e muita discussão.

A recompensa é um software que é mais fácil de manter e menos suscetível a erros.

E estamos conversados...

"O temor do Senhor é fonte de vida, para desviar dos laços da morte."
Provérbios 14:26,27

Referências:

José Carlos Macoratti