Dicas para o desenvolvimento de um software – Parte 9

Dicas para o desenvolvimento de um software - Parte 9Olá, leitores! Nos artigos anteriores sobre dicas de desenvolvimento, foquei bastante em aspectos técnicos, visuais e comportamentais de um software. Neste artigo, vou abordar assuntos mais conceituais que fazem parte da minha paixão por TI: Engenharia e Arquitetura de Software. A partir do momento que tomei conhecimento e comecei a praticar os conceitos citados neste artigo, notei uma grande diferença na minha produtividade. Provavelmente estes conceitos não serão novidade para muitos, mas é interessante deixá-los registrados aqui no blog como parte dessa série de artigos.

 

Design Patterns
Os Design Patterns, ou Padrões de Projeto, como são conhecidos, são conceitos ou modelos orientados a objetos visando solucionar problemas no desenvolvimento de softwares. Estes padrões possuem finalidades particulares que podem ser aplicadas para controlar a estrutura, a criação e o comportamento das classes e dos objetos em uma aplicação. Dependendo da situação em que esses projetos forem aplicados, é possível notar uma redução considerável na complexidade do software em virtude da reutilização de código-fonte e de componentes.
Este ano, por exemplo, acompanhei a implementação dos padrões de projeto Strategy, Observer, Builder e Factory Method em um projeto na empresa em que trabalho e pude observar as vantagens que estes padrões trouxeram ao código-fonte, bem como a facilidade para compreender e documentar o software.
Apesar de existir 23 padrões de projeto, é praticamente inviável implementar todos eles em uma única solução, afinal, utilizar padrões de projeto sem um propósito é uma má prática. É preciso haver um motivo real para a implementação, ou seja, uma situação em que se pode comprovar de que o padrão de projeto será uma solução adequada para o problema. Caso contrário, a implementação pode aumentar a complexidade do código-fonte e afetar também o desempenho da aplicação.
Uma das dúvidas mais frequentes relacionadas a padrões de projeto é saber onde, quando e como utilizá-los. Em primeiro lugar, o engenheiro de software deve ter sólidos conhecimentos em Programação Orientada a Objetos e um bom nível de abstração, ou seja, a Orientação a Objetos é a base essencial para compreender os padrões de projeto. Em segundo lugar, é necessário conhecer o objetivo principal de cada padrão de projeto para que seja possível fazer um estudo da viabilidade buscando solucionar um problema no software. Porém, mesmo com esse conhecimento técnico, é comum alguns engenheiros não conseguirem identificar as situações ou os módulos que devem receber a implementação dos padrões. Portanto, em terceiro lugar, o profissional também deve ter um domínio satisfatório da regra de negócio do cliente. A consolidação de todas essas experiências é o que permite a seleção e a aplicação consciente dos padrões de projeto no desenvolvimento do software.

 

Padrão de arquitetura
Um bom software deve proporcionar flexibilidade e facilidade de manutenção. São inúmeros os casos de softwares que foram desenvolvidos sem uma estrutura bem definida e, após algum tempo, apresentaram complicações nas atividades de manutenção. Por conta disso, os padrões de arquitetura são modelos que surgiram para definir a estrutura do software visando não somente a facilidade da manutenção, mas também outros aspectos, como a modularização, desempenho, agilidade no build e a divisão de responsabilidades em camadas.
Só para efeito de conhecimento, já publiquei dois artigos aqui no blog sobre o MVC (Model-View-Controller), um dos padrões de arquitetura disponíveis no mercado no qual me identifiquei bastante. Além do MVC, há também outros padrões populares, como o MVP (Model-View-Presenter) e o MVVM (Model-View-View-Model). Apesar da diferença nas nomenclaturas, a ideia central desses três padrões de arquitetura é basicamente a mesma: separar a lógica e a apresentação dos dados em camadas (ou níveis) diferentes. Enquanto a camada Model representa a modelagem dos dados (classes, métodos, persistência), a camada View é responsável por exibir estes dados ao usuário. Por fim, a camada intermediária, diferente para cada padrão (Controller, Presenter ou View-Model), tem a função de gerenciar a comunicação entre a Model e a View.
Deixo aqui a minha recomendação: procurem estudar e conhecer melhor sobre estes padrões de arquitetura. Os conceitos são bastante interessantes e a implementação definitivamente traz bons resultados!

 

Clean Code
Uma vez li a seguinte frase em um fórum de programação:
“Código ruim não é ruim, é apenas mal compreendido.”

Francamente, não concordo com essa frase. Se todos os programadores pensarem dessa forma, teremos tanto código ruim nos softwares que, em certo momento, será impossível compreendê-los. Analogicamente, é o mesmo que misturar um ingrediente vencido na receita de um bolo: o sabor não será o mesmo, além do risco de fazer mal à saúde. Que analogia sem sentido, não? Rsrs…
Para evitar o código ruim, existe um conceito conhecido como Clean Code. Em linhas gerais, como o próprio nome sugere, Clean Code significa “código limpo” e orienta a como escrever um código estruturado, organizado e compreensível.
O conceito de Clean Code envolve várias práticas que podem ser aplicadas por qualquer desenvolvedor para escrever um código melhor. Entre essas práticas, há recomendações sobre como definir nomes de funções, nomes de variáveis, responsabilidades de métodos (um método deve ter uma e somente uma responsabilidade), indentação de código, parâmetros e até mesmo orientações de como comentar (e também anotar) o código-fonte.
Clean Code - A Handbook of Agile Software CraftsmanshipHá um ótimo livro escrito por Robert C. Martin chamado Clean Code – A Handbook of Agile Software Craftsmanship que aborda todas essas práticas de forma bem detalhada e didática, inclusive com bastantes exemplos. Ainda não tive a oportunidade de lê-lo por completo, mas já consultei algumas páginas para estudar melhores formas de aprimorar alguns pontos do meu código e me identifiquei com o conteúdo. Na verdade, depois de conhecer este livro e ler vários artigos na internet sobre este assunto, pude perceber o quanto o comprometimento na escrita do código-fonte é importante para o desenvolvimento de software.
Isso nos leva a refletir sobre aquela famosa frase: “Você é responsável pelo seu código!”.

 

Interfaces
Se você tem conhecimento ou experiência com Programação Orientada a Objetos, provavelmente já ouviu falar ou trabalhou com Interfaces. Na verdade, essa palavra tem uma ambiguidade na área de TI e pode confundir o profissional que trabalha com programação. A palavra “Interface” pode ser usada para se referir ao visual de uma aplicação, um componente de hardware (por exemplo, interface de rede), como também um recurso na Orientação a Objetos, no qual é o objetivo deste tópico.
Interface é o nome que se dá a um recurso para trabalhar com abstrações. O objetivo das Interfaces é prover flexibilidade na estrutura de software de modo que resulte em um baixo acoplamento (dependência) entre classes. Ao invés de trabalhar com implementações concretas, as Interfaces podem ser utilizadas para representar as abstrações no projeto de software em nível de modelagem.
Neste artigo, vou abordar o conceito de Interfaces no sentido de padronização de métodos entre classes, mas gostaria de ressaltar que o contexto de Interfaces envolve mais do que isso, ok?

Pois bem, uma Interface nos permite determinar comportamentos em comum entre classes que a implementam. Por meio de sua utilização, é possível estabelecer um padrão na implementação de métodos como se houvesse um tipo de “contrato”. Em outras palavras, as classes que implementam uma determinada Interface deve obedecer todos os métodos assinados por ela, garantindo um nível adequado de padronização.

Já sei, ficou complicado, não é? Vamos para um exemplo teórico!
Suponha que criamos uma Interface e definimos duas assinaturas de métodos que serão utilizados no formulário de clientes: DescontarValor e ValidarDocumento. Vale ressaltar que na Interface não há implementação destes métodos, apenas a assinatura. Pois bem, em seguida, criamos as classes ClienteFisico e ClienteJuridico que implementam a Interface que acabamos de criar. Por convenção, essas duas classes devem obrigatoriamente implementar os métodos DescontarValor e ValidarDocumento, já que elas possuem um contrato com a Interface. Porém, como as classes são diferentes, a implementação destes métodos será diferente para cada uma delas. Para a pessoa física, o desconto do valor será de 2% e a validação do documento deverá ocorrer pelo CPF da pessoa. Por outro lado, para a pessoa jurídica, o desconto será de 4% e a validação irá verificar a veracidade do CNPJ da empresa. Mesmo que sejam finalidades diferentes, os nomes dos métodos são os mesmos e a implementação é obrigatória. Se futuramente for necessário incluir um novo método na Interface, como, por exemplo, VerificarCredito, este deverá ser codificado em cada classe que implementa a Interface. Bacana, não?

As vantagens de se utilizar Interfaces se resumem essencialmente na organização e nivelamento de classes, na reutilização de componentes do software e na facilidade de manutenção (em virtude da flexibilidade). O conceito de Interfaces é utilizado com bastante frequência na implementação de Design Patterns e de padrões de arquitetura, portanto, é muito importante conhecê-lo. Assim como disse em outro artigo, estes conceitos estão estritamente ligados um ao outro, o que facilita a compreensão e expande a linha de raciocínio para profissionais que trabalham com Orientação a Objetos.

 

Agradeço novamente pela visita, leitores!
Abraço!


Confira também as outras partes dessa série de artigos:

Dicas para o desenvolvimento de um software – Parte 1
Dicas para o desenvolvimento de um software – Parte 2
Dicas para o desenvolvimento de um software – Parte 3
Dicas para o desenvolvimento de um software – Parte 4
Dicas para o desenvolvimento de um software – Parte 5
Dicas para o desenvolvimento de um software – Parte 6
Dicas para o desenvolvimento de um software – Parte 7
Dicas para o desenvolvimento de um software – Parte 8
Dicas para o desenvolvimento de um software – Parte 9
Dicas para o desenvolvimento de um software – Parte 10
Dicas para o desenvolvimento de um software – Parte 11


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

9 comentários

  1. cara… curtir muito seu artigo.. me ajudou muito .. no momento eu programo em (c# .net)
    tenho somente 3 meses de programação … mas já estou em um projeto para uma pequena empresa de meu Pai … e seu artigo mim esclareceu muita coisa… Parabéns… boa sorte em sua caminhada

  2. Parabéns pela série de Posts muito esclarecedoras.
    Gostaria de tirar uma dúvida se possível, estou começando um projeto que rodará na WEB.
    Pensando que ele poderá ser Multi Filial que dica você daria neste caso, como ficaria o banco de dados? Um para cada cliente, ou um banco único? Como se trabalha com isso na WEB?

    Você teria algum artigo que fale sobre isso?
    Desde já obrigado pela atenção.

  3. Andre boa tarde.

    veja se pode me ajudar
    Suponhamos que eu teria que colocar status em dados do DBgrid. Explico.
    Tenho cadastrado NFs em um DBGrid. Essas notas ficam em cor branca. Quando eu entregasse elas a meu clientes e desse um duplo clique, ela representasse a cor de ENTREGA REALIZADA ou então uma coluna no GRID me aparecesse apenas o status de Entregue ou Pendente. Teria como?

    No aguardo,

    1. Olá, Cristiano. É possível desenvolver essa funcionalidade, sim. Você pode utilizar os eventos de desenho da DBGrid para criar esse efeito visual. Pra ficar mais fácil, vou entrar em contato você por e-mail, ok? Abraço!

  4. Ótimo post André, parabéns.
    Sou estudante de desenvolvimento web pelo curso adv aqui do rio de janeiro, http://www.cursoadv.com.br
    Acho ótimo contar com essas dicas, orientações, experiências de profissionais.
    Assim posso me inspirar para sempre melhorar.

    1. Olá, Diego! Tudo certo?

      Primeiramente, obrigado pela visita e pelo comentário no blog!
      Diego, não conheço muito bem a ADV, mas já fui informado de que os cursos realmente são bons.
      Espero que você continue motivado em continuar aprimorando o seu conhecimento!

      Abraço!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.