Este é o nosso primeiro FAQ (Perguntas e Respostas) sobre Engenharia de Software.
Mensalmente os membros da nossa lista VIP poderão enviar Perguntas que eu mesmo responderei, sobre quaisquer assuntos no campo da Engenharia de Software.
A seguir, as perguntas dos leitores, com as respectivas respostas.
Leitor: Caio de Araujo
“Usamos google muito mais que 20x rsrs algumas dúvidas, muito frequentes, e que já foram motivos de muita discussão por aqui.
- Banco de Dados antes do Software ou os dois devem crescer juntos?
- Qual parão de nomenclatura para as tabelas e colunas do BD? Um padrão utilizado aqui que eu sou totalmente contra é colocar os nomes das tabelas em português e prefixo nas colunas. Por exemplo cliente_principal(clipri_id integer primary key, clipri_nome varchar(100));
- Variáveis do software em inglês? Em português?
- Tabela x Enum. Eu particularmente não gosto de Enums, porém os desenvolvedores aqui amam Enum rsrs
São coisas que parecem bobas, mas já geraram muitas discussões.”
/* Abaixo meus comentários. */
Banco de Dados antes do Software ou os dois devem crescer juntos?
Salvo raríssimas exceções, um software nasce, evolui e é descontinuado. Isso é o que chamamos de ciclo de vida de produto.
Durante a evolução do software é natural seu modelo de dados sofrer ajustes ao longo do tempo.
E sabemos ainda, que o ideal é que dentro das possibilidades, todo software comece com o menor escopo possível, considerando o que é prioritário para o negócio (aquilo que gera mais valor), e a partir de feedback constante, vá crescendo alinhado com o negócio (isso é o conceito de MVP).
Outra verdade absoluta é que no início de qualquer software é praticamente impossível perceber todo o seu escopo, mas é possível diminuir os problemas gerados por esta incerteza (isso é o conceito de Cone da Incerteza).
Mas um produto inicial sempre é gerado. Neste caso, é compulsório um modelo de dados que dê condições estruturais da primeira versão do software ser liberada.
Mas não tem como “fechar” o modelo de dados na primeira versão, e a primeira versão do modelo deve ser projetada para dar condições ao software de crescer, com o mínimo de impacto em sua estrutura pre-existente.
Resposta: banco de dados “antes”, mas “durante” também, pois o modelo sempre deve acompanhar a evolução do escopo do software, e para lançar a primeira versão do software, é necessário um modelo de dados “estável”.
Qual padrão de nomenclatura para as tabelas e colunas do BD? Utilizar prefixos em colunas da tabelas?
Porque se dá “nome” a tabelas e colunas em um banco de dados?
Primeiro, obviamente, para se localizar objetos no banco e o software conseguir lidar com o armazenamento das informações.
Segundo, para dar condições desta localização ser a mais eficiente e eficaz possível, viabilizando agilidade no trabalho dos profissionais que “manuseiam” estes objetos de banco (leia-se qualidade e produtividade).
Muito se fala de utilizar nomenclatura de tabelas em Inglês.
Mas qual o real objetivo disso?
Alguns defendem que é a “linguagem universal” da programação, pois as linguagens de programação possuem sintaxe neste idioma, os fabricantes das linguagens utilizam esta idioma etc.
Mas e se o software a ser produzido não for um produto mantido por equipes que utilizam este idioma?
Se for, sem dúvida é melhor uma linguagem comum.
Mas se for uma equipe “100% Brasil”, e não houver perspetiva plausível de inserir profissionais “gringos” no projeto, não será melhor utilizar a língua nativa, ou seja, o “Pt-Br”?
Nossa área sempre sofre com problemas de comunicação, e neste contexto, o objetivo da nomenclatura de objetos em banco de dados, ou objetos da arquitetura e estrutura do software é facilitar ao máximo o entendimento por parte dos profissionais técnicos, e assim, gerar ganhos de produtividade e qualidade.
Então, na minha opinião, o idioma deve atender ao que citei anteriormente, pelas razões apresentadas, e o uso de prefixo no nome das tabelas eu acho pertinente, pois num banco de dados sempre temos objetos de tipos diferentes (table, function, trigger, index etc.).
O uso do prefixo facilita muito para diferenciar, com rapidez e precisão, qual o tipo do objeto que está sendo manipulado.
Mas tem que se tomar cuidado com os prefixos, pois o simples é o luxo. TBLCLIENTE é muito bom, eu acho.
Em relação aos campos, nem sempre dá para usar uma linguagem sem prefixos, sufixos e mnemônicos.
Isso se dá, principalmente, pelo fato de termos exponencialmente mais campos que tabelas em bancos de dados, e com muitos campos, o nome tem que ser mais curto, mas ao mesmo tempo tem que reduzir as possibilidades de ambiguidade (nomes muito semelhantes em uma mesma tabela, que gere confusão na hora de saber “qual é qual”).
Entretanto…
… eu não sou a favor do uso de mnemônicos, prefixos, sufixos e underlines em campos de tabela.
Uma boa modelagem, onde tempos apenas os campos realmente necessários, com os relacionamentos corretos, nos dá condições de utilizar “linguagem natural” no nome dos campos, e torna a evolução do modelo algo mais produtivo.
Para que se ter “NMCLI001” se podemos ter “NomeCliente”? Para que ter “VALTAXCONV” se podemos ter ValorTaxaConveniencia?
/* eu já trabalhei em empresas que para “acertar” no nome dos campos, ter aprovação do Administrador de Dados, ir para o DBA implementar, e então receber o retorno, demorava-se dias. Muito por causa da necessidade de se consultar uma tabela de mnemônicos, buscar no modelo ambiguidades, preencher tal planilha, abrir chamado etc. E na média, sempre davam bomba na primeira versão do chamado… */
Resposta: em relação ao idioma empregado na nomenclatura dos campos, minha opinião segue a mesma linha do que aplica-se às tabelas.
Variáveis do software em inglês? Em português?
Aplicam-se os mesmos argumentos citados para o caso das tabelas do banco de dados. Reforçando ainda que, neste caso não cabe prefixo.
Uma variável do tipo string – strNomeCliente – não precisa de “str”, o compilador geralmente nos ajuda em ambientes de linguagens fortemente tipadas, por exemplo. strNmCli então, sem comentários (aqui podemos entender melhor sobre isso).
Resposta: quanto ao idioma, depende. Quanto ao padrão aplicado, linguagem natural, sempre.
Tabela x Enum
Na minha opinião é muito mais “barato” em termos de processamento, complexidade do modelo de dados etc. utilizar Enum, e em campos da tabelas usá-los para equivalência, do que ter tabelas – por exemplo – de “código e descrição” para todos os Enumeradores.
Ainda tem um grande benefício, que qualquer alteração num Enumerador, gera impacto estrutural apenas na classe dele, não demandando alterar modelo de dados, método de acesso a dados etc.
Naturalmente, isso só é viável onde a arquitetura do software viabilize uma solução coesa e desacoplada.
Resposta: vou de Enum! 🙂
Leitor: Sabrina Silva
“Olá,faço sistemas de informação e sou péssima em programação.. A área que mais me chamou atenção foi engenharia de software , queria saber se posso seguir essa área sem saber programar?”
/* Abaixo meus comentários. */
Saber ou Gostar de Programação?
Na realidade, “dentro” da Engenharia de Software também se inclui desenvolvimento (ou programação, ou construção).
Mas muitos profissionais que estão se formando na área, ou que já se formaram também, não gostam de programar. Normal, sem problemas.
Afirmar ser “péssimo” em programação eu acho que é algo que pode ser repensado. Para quem está estudando, acho precipitado tal conclusão.
Quando estamos começando em qualquer área de conhecimento é natural encontrarmos dificuldades. Quanto menos sabemos, mais dificuldade enxergamos.
À medida que vamos ampliando nosso conhecimento sobre algo, o que era difícil deixa de ser, passando a ser algo do dia a dia. Mas isso não significa que mesmo se tornando menos difícil, será algo prazeroso.
Sem programar é possível seguir na Engenharia de Software.
Muitos profissionais tornam-se Analistas de Requisitos, outros Analistas de Testes, alguns Projetistas etc. Mas a visão do modelo de código fonte, ou seja, do último nível de abstração antes do software executável materializar, faz muita diferença na performance do profissional de Software.
Se souber programar, com alguma maturidade nisso, qualquer artefato produzido tende a ter maior qualidade.
DevOps?
Importante reforçar que esse nível de especialização que citei tende a deixar de existir no longo prazo, pois as empresas estão começando a cobrar profissionais “tudo em um”.
Alguns tem chamado este perfil de “Desenvolvedor Full Stack”, mas eu chamaria de “Analista de Sistemas Completo”, algo próximo do conceito de DepOps.
Resposta: Sim, é possível avançar na Engenharia de Software sem programar, mas ter boas noções de programação e banco de dados, por exemplo, é um grande diferencial para um Analista de Sistemas que lide mais com Requisitos, UML, Testes etc.
Leitor: Leandro Almeida
“Atualmente sou analista judiciário no TJ-Pará, na área de desenvolvimento. Não tenho exatamente uma dúvida, mas um cenário com possíveis soluções, e gostaria de saber se você tem alguma experiência anterior nisso para compartilhar.
Estou numa missão aqui no trabalho: migrar uma aplicação legada escrita em Delphi em 2001 pelo TJ-SC, que estamos usando aqui desde 2008! Ou seja, põe aí 16 anos de software, e cheio de remendo rsrs. A aplicação controla depósitos judiciais com regras da poupança, remunerando os depósitos e saques com juros e correções pro-rata die, é um sistema de tamanho pequeno a médio, porém com boa complexidade e sensibilidade dos dados, visto que trata-se de dinheiro.
Bom, tenho lido a respeito da reescrita de aplicações legadas, além de estar estudando e ter feito um curso online de DDD. Minha dúvida basicamente é saber se você tem alguma abordagem ou estratégia para que o projeto de reescrita tenha êxito. Como exemplo, li alguns blogs e artigos abaixo:
https://www.martinfowler.com/bliki/StranglerApplication.html
http://cdn.pols.co.uk/papers/agile-approach-to-legacy-systems.pdfAs abordagens são interessantes e oferecem menos riscos, mas ainda tenho dúvida.
Uma das minhas inquietações é a respeito da base de dados. Penso em alguns cenários possíveis:
1- Reescrever a aplicação projetando nova modelagem ER, porém traria um esforço e risco muito grande ao projeto, visto que teria de haver migração de dados através de scripts (e talvez não tenhamos pessoas suficientes para isso);
2- Reescrever a aplicação usando a mesma base de dados, modificando ou adicionando recursos que forem necessários (novas tabelas ou colunas), porém tendo de refletir no código legado (quando necessário) durante convivência de ambas aplicações;Em ambos os casos eu tentaria adotar modelagem orientada ao domínio (DDD) com TDD para garantir a qualidade e funcionamento das regras de negócio.
Estou propenso a seguir pelo cenário 2, porém não sei se tem alguma pegadinha aí. O que você acha? Alguma situação parecida que você já passou antes?”
/* Abaixo meus comentários. */
Eu já tive três experiências muito semelhantes a esta, uma inclusive ainda faz parte do meu dia a dia. Abaixo as três:
- ERP de Varejo feito em VB6 e MSSQL, 15 anos de existência, por onde uma operação bilionária se sustentava.
- Software de empréstimo bancário feito em Power Builder com MSSQL e Oracle, 18 anos de existência, por onde bilhões são movimentados por dia em vários bancos brasileiros.
- Sistema de Processamento de Informações para um Informador, feito em Delphi 2.0, 20 anos de existência, por onde milhares de diários são lidos por dia e transformados em milhares de publicações enviadas ha milhares de advogados diariamente.
/* Abaixo meus comentários. */
Reengenharia de uma única vez
Contextos como estes são muito, muito complexos.
Uma coisa que aprendi com estes projetos é que, se optar por fazer reengenharia (refazer o software em 100%), não faça de uma única vez (fazer de uma só vez = terminar apenas quanto tudo estiver [re]construído), pois quando o software novo estiver pronto, estará “velho”.
Não tem como o escopo do novo sistema acompanhar a evolução do negócio (enquanto o novo software estiver sendo construído), senão fica “cachorro correndo atrás do próprio rabo”.
Cultura e Equipe
Em projetos desta natureza o conhecimento do legado é fundamental.
E tal conhecimento é de tudo: modelo de dados, gambiarras, negócio, tecnologia etc.
Porém, os que serão responsáveis por evoluir a solução (seja para uma arquitetura desacoplada, seja para um novo sistema) não podem ficar com a cabeça no legado, pois assim o novo vai carregar todos os “vícios” do antigo.
Equilibrar isso demanda um esforço hercúleo.
E ainda: pela necessidade de “imersão” em projetos deste tipo, profissionais devem estar dedicados full time no projeto, e deve-se evitar o turn-over nesta equipe, a todo custo.
Banco de Dados
Se for feito trabalho de reengenharia, tenha um novo modelo de dados.
Modelo de dados de sistemas “antigos”, feitos “à base de remendos” e em tecnologias antigas geralmente não correspondem à realidade do negócio, e ainda, costumam quebrar grande parte das boas práticas de modelagem.
Mesmo modelos antigos porém “mais arrumados” devem ser revistos, pois na produção de software tudo evolui.
Uma prática recomendada há 20 anos pode não ser a melhor prática hoje, idem para tecnologia, padrões etc.
Por outro lado, é fundamental se tomar cuidado com “padrões e práticas” milagrosas, pois software com qualidade deve ser simples, em todos os aspectos.
Manter o “velho” ou fazer um “novo” – Refatorar, Desacoplar ou Reescrever?
Esta decisão, antes de mais nada, depende do objetivo estratégico da empresa.
E além disso, estar amarrada às restrições do projeto e do negócio
Há dinheiro suficiente? Há tempo suficiente? Quais os maiores riscos envolvidos? Há previsão do legado ser descontinuado por futura fusão, aquisição, compra de software pronto etc.?.
Refatorar o legado eu acho inviável na maioria dos casos em que eu já vi.
Sistemas feitos ha tanto tempo foram feitos sem pensar em escalabilidade, distribuição, paralelismo, testes unitários etc.
São sistemas muito acoplados, com muita lógica repetida, e código geralmente “orientado ao programador”, e não “orientado ao negócio”.
(Havendo a possibilidade) Melhor fazer o transplante do coração do que tentar remendá-lo se ele já passou por várias cirurgias, tumores etc.
Uma alternativa seria desacoplar aos poucos para ir evoluindo um novo software.
Por exemplo, se a tecnologia permitir parte do que tiver de lógica poderia ser “embutido” em serviços Rest (encapsula o pedaço da lógica em DLLs e cria-se serviços para consumir estas DLLs), e tais serviços serem consumidos em front-end novo, já diminuindo a dependência entre os componentes.
Coisas deste tipo isolaria o modelo de dados, isolaria o kernel do sistema, e viabilizaria não perder os aspectos mais críticos da inteligência do software, num primeiro momento.
Inclusive, este tipo de recurso é adotado em algumas empresas para aproveitar lógica de sistemas web muito acoplados em aplicativos mobile.
Mas essa opção é altamente custosa, pois o legado ainda evolui, e quando começa a funcionar, desliga o senso de urgência do sistema novo. Isso dá “fôlego novo” ao legado.
Reescrever eu acho que é melhor opção, se houver recursos para isso.
Mas, como citei no início, não dá para ser um projeto de 10 anos, que nunca acaba. É um projeto que tem que ser Iterativo e Incremental e com Sprints bem fixados, com um time único e coeso, com metas bem definidas e acompanhamento gerencial full time.
Um dos grandes desafios da reescrita é a coexistência do legado e do novo sistema – tanto em termos de operação de negócios como em termos de integração dos dois sistemas.
Mas tendo o cuidado necessário é possível sim passar por isso sem grandes traumas.
Para base de dados pode-se usar o conceito de alfândegas, para lógicas de negócio embutidas pode-se encapsular lógica do sistema legado em componentes e usar temporariamente no sistema novo etc.
Resposta: tome todo cuidado do mundo, defina um plano, e foque nele, sem desistir. Mas é um plano sem volta, devido às circunstâncias. Tecnicamente, sou a favor da reengenharia, mas desde que seja uma solução projetada para escalabilidade, do contrário em alguns anos o problema atual se repetirá. Entretanto, pela complexidade e extensão do assunto, não é possível esgotar tudo aqui, ficando apenas uma simples opinião.
Leitor: Lucas Arruda
” Existem muitos padrões de projeto e sempre me deparo com dúvidas no momento de iniciar um projeto. Inclusive na minha empresa acabo recebendo projetos pela metade que não tem arquitetura ou forma definida, foi tudo feito às pressas. Geralmente esses projetos não estão funcionando corretamente e me passam pra “dar um jeito”. Costumo ter vontade de refazer por ter muita coisa errada, mas a gerente nunca aceita isso. Então faço uma super refatoração e tento colocar “ordem na casa”. A minha dúvida pode parecer estranha (mas é o que acontece comigo), mas o que pode me ajudar a escolher um padrão pra um projeto que está bagunçado?”
/* Abaixo meus comentários. */
O método cartesiano, base de muito do que fazemos em produção de software, nos recomenda sempre quebrar um problema em partes menores até que sejam “indivisíveis”, e então, analisar pedaço a pedaço, buscando a melhor solução, sempre considerando a visão do todo.
Imagine que você está num quarto totalmente bagunçado, e precisa arrumá-lo.
Uma das coisas que precisa fazer é: entender todo o quarto, e descobrir “onde guardar cada tipo de item”. Depois, separar em “grupos” estes itens e guarda-los nos locais anteriormente definidos.
Meias na gaveta de meias, tênis na gaveta de tênis, camisas no cabide e por aí vai.
Se você sempre refatorar – refatorar sempre é boa prática, me refiro a ter a refatoração como a única opção para dar ordem nas coisas – talvez isso deixe o sistema organizado um tempo, mas depois tudo fique “zuado” novamente.
O ideal é você ter na sua empresa um “guia de padrões”, para que todo projeto siga uma mesma arquitetura ao ser iniciado.
Neste “modelo arquitetural” você definiria qual o padrão a ser aplicado, em termos de padrões de projeto, camadas, código limpo etc.
Para projetos que chegam bagunçados, e precisam ser organizados, é complexo afirmar qual e melhor solução.
Mas se for possível, eu tentaria desacoplar ao máximo (usando por exemplo fachadas e *factories [Simple, Factory e Abstract Factory] sempre o mais simples se possível).
Desacoplando, as meias podem até estarem “sujas”, mas ao menos estarão nas “gavetas corretas”.
Resposta: depende dos recursos disponíveis (tempo, dinheiro etc.). No pior caso, desacoplar o máximo, pois assim a “bagunça tende a ficar organizada”. Mas o ideal é começar certo, definindo práticas e padrões compulsórios a todos os projetos.
Finalizando
Agradecimentos sinceros aos leitores que enviaram suas perguntas! 🙂
Lembrando que não é possível esgotar muitas das questões aqui, pela amplitude destas. E que, ainda, trata-se da minha opinião, que pode ser revista à medida que vou me tornando menos ignorante.
Em breve o próximo FAQ, e faça parte da nossa lista VIP para enviar suas perguntas que estamos à disposição!
Grande abraço!