Um sistema operacional que se mantém vivo há quase 50 anos, se manteve firme e estável desde então, concorrendo com diversos sistemas operacionais. Iniciado em 1973, chegando ao mainstream do desktop em 2001 com o MacOS X; chegando aos smartphones em 2008, com o Android; e indicado por alguns especialistas como o futuro dos sistemas operacionais.

Com tantos atributos de sucesso, vale a pena estudar sua filosofia de desenvolvimento. O livro The Art of Unix Programming, de Eric S. Raymond (ESR), é um dos estudo mais completos sobre o assunto. Logo nos primeiros capítulos define 17 regras que resumem as bases da filosofia Unix.

Hoje vamos começar uma série de quatro posts diferentes aonde vamos abordar as bases da filosofia Unix, conforme ESR, em 17 regras.

1. Regra da Modularidade

Escreva módulos simples e conecte-os através de interfaces simples.

A maior parte do desenvolvimento do software é gasto com depuração. Por isso um grande monólito só aumenta o tempo gasto com depuração e manutenção, e por consequência aumenta o custo geral do software.

Ao desenvolver pequenos módulos com interfaces bem definidas e claras, a depuração fica mais simples pois os problemas estão sempre isolados e restritos a um módulo. Assim os problemas ficarão sempre isolados aos módulos que sofreram a alteração.

Não seguir essa regra implica em desenvolver grandes trechos de código de difícil depuração. Qualquer bug implica na necessidade de profundo conhecimento do código fonte, algo que poucos ou apenas um desenvolvedor no time será capaz de fazer.

2. Regra da Clareza

Clareza é melhor que inteligência.

Um código claro, bem comentado, estruturado, com orientações apropriadas para utilização e manutenção é muito mais importante que um código rápido ou compacto.

Código ofuscado, com muitas construções não ortodoxas, tabulação inapropriada, sempre dificultam a manutenção.

Normalmente código que não é claro é fruto de um programador muito inexperiente, ou de um programador que não deseja trabalhar em equipe, e por isso entende que outros desenvolvedores não deveriam ser capazes de interpretar seu código.

3. Regra da Composição

Projete programas para ser conectados com outros programas.

A tradição Unix sempre privilegiou o desenvolvimento de ferramentas que utilizam a entrada e saída padrão para se comunicar com outros programas, normalmente utilizando streams, arquivos ou pipes.

Quando as GUIs (Graphical User Interfaces – Interfaces Gráficas de Usuário) se popularizaram essa regra tornou-se cada vez mais complicada de ser implementada. Mas com a popularização de APIs e WebServices sua implementação tornou-se mais simples e efetiva.

Quando a regra da composição não é seguida em um projeto a integração entre seus módulos é sempre problemática. Quando um novo módulo precisa de informações que se encontra em outro módulo é necessário acessar as informações diretamente da fonte, ou até mesmo gerá-los novamente.

4. Regra da Separação

Separe regras do mecanismo; separe interface de engines.

Ao separar regras de mecanismo garantimos que o mecanismo pode ser facilmente mantido, e rapidamente adaptável a novas regras, tornando o software mais barato de manter e mais simples de adaptar às mudanças nas regras de negócio.

As arquiteturas 3-Tier são ótimos exemplos de separação, aonde são separadas camada de dados, de processamento e de exibição, conectando as três com interfaces simples e bem definidas.

Outro bom exemplo é desenvolver os mecanismos através de um conjunto de funções em C e utilizar uma linguagem script para implementar regras de negócio.

Ignorar a regra da separação gera grandes dificuldades no momento de alterar regras de negócio. Além disso alterações em módulos não relacionados, como por exemplo de exibição, podem gerar bugs em módulos de regras de negócio.

Tags: qualidade