Um Programador Mais Eficiente

Um desenvolvedor, também conhecido popularmente como programador ou ainda, engenheiro de software, ou para o mais hipster, coder. É o responsável por organizar códigos e linguagens de programação dentro da tecnologia da informação. Em todos anos que não seja bisexto comemoramos o Dia do Programador no dia 13 setembro e nos anos bisextos no dia 12 setembro, isso porque a data é celebrada no 256º dia do ano.

Gostaria de elencar algumas dicas que podem ajudar qualquer desenvolvedor a aumentar sua eficiência na entrega de código, vou fazê-la por ordem de grandeza na minha opinião:

1. KISS, não é banda de rock, é um acrônimo para “Keep it simple, stupid”, que em bom português fica “Mantenha isto simples, estúpido” , pode parecer um pouco agressivo, entretanto é muito válido, porque você iria criar complicado, se é você mesmo amanhã que irá ter que dar manutenção! Pegou?

2. Comente com riqueza e qualidades todos códigos, seja um facilitador da vida das próximas gerações de desenvolvedores, que quando tiverem contato com esses códigos eles lhe farão agradecimentos em memória.

3. Nunca, jamais, em tempo algum, despreze testes únicos, esses são de total responsabilidade de um desenvolvedor e são eles que vão garantir sua paz no futuro, acredite.

4. TDD, acredite, parece difícil, complicado, trabalhoso demais, mas, uma vez que você se apropria, todos os seus problemas acabam antes mesmo da codificação.

5. Aproprie-se da solução primeiro, antes de sair escrevendo código, um parêntese, o TDD te força a saber antes de fazer.

6. Coma SOLID com farinha no café da manhã, no almoço e no jantar, até que este conceito faça parte de você, isso irá garantir uma excelência na sua entrega.

7. Quando for utilizar algo externo, adquirida domínio do conhecimento de sua utilização, isso irá economizar longas horas tentando, além de mostrar o caminho para melhor aplicação.

8. Utilize o google, “Stack Overflow”, programação em par, você não é uma ilha e pode conseguir ajuda em muitos lugares, entrentanto, aprenda com essas oportunidades.

9. 99% dos problemas de tecnologia tem solução, muitas vezes não enxergamos na hora é porque estamos demais envolvidos por ele, aprenda a praticar pausas estratégicas para dar um tempo para o cérebro absorver, processar e encontrar possíveis soluções. 

10. Pode parecer piegas, mas é a realidade, escrever código no fundo é uma arte, a arte de organizar os comandos para que se executem com harmonia resultando numa linda sinfonia, ou seja, tenha paixão por cada nota.

Nesta data tão especial temos muito que comemorar, pois agora existem outros cargos e  funções no cenário de tecnologia, como arquiteto de soluções, designers de interface, gerente de projetos, cientista de dados, DBAs, engenheiro de redes, entre outros que compartilham conosco o título de “Menino(a) do Computador”.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Aprendendo com Coding Dojo

Todo aquele que precisa executar uma prática que exige conhecimento de movimentos específicos para alcançar resultados esperados, tem que ter um espaço seguro e confiável para treinar e aplicar cada movimento, seja novo ou conhecido e além de ter um ou mais mestres para orientar e também avaliar a performance da aplicação do aprendizado. Tá, mas o que isso tem há ver com tecnologia? Tudo meu pequeno padawan, os desenvolvedores também precisam ter um espaço seguro e confiável para treinar e melhorar suas habilidades, esse local é Coding Dojo.

A palavra Condig é o termo em inglês para “programando” ou “gerando código”, já a palavra Dojo, (pronuncia-se Dojô) é uma palavra de origem japonesa e significa “local de treinamento”. Logo, o Coding Dojo nada mais é que do um “local de treinamento de código”.

Esse espaço tem como suas principais características ser um ambiente colaborativo, que estimula o aprendizado de forma divertida e principalmente sem nenhum tipo de competitividade entre os participantes. Existem três modalidades:

Randori

Esse é o formato mais “tradicional” por que todos participação, no início o mestre da sessão propõem um desafio a ser resolvido e todos os participantes deverão resolvê-lo utilizando uma única máquina, utilizando o sistema de rodízio de pares. Neste par existirá um piloto que irá operar a máquina e o copiloto que irá auxiliá-lo, a plateia neste momento só acompanha, a cada tempo de minutos pré-definidos previamente, o copiloto virá piloto e alguém da plateia se torna o co-piloto. Se utilizado o TDD a plateia somente poderá efetuar interrupções quando todos os testes estiverem verde. Importante, o mestre pode servir como um consultor da tecnologia e não dá solução do problema. Ao final todos devem entender a solução, pois durante toda a sessão o piloto e copiloto devem estar sempre narrando seus pensamentos.

Kata

Aqui o mestre assume a postura de palestrante, ele irá demonstrar o problema e já partir para aplicação da solução, que pode estar parte pré desenvolvida e ser complementa durante a sessão. Todos os participantes podem a qualquer momento efetuar interrupções para expor dúvidas. O resultado final é que todos ao final devem ser capazes de efetuar a implementação da solução. 

Kake

Muito parecido ao Randori, a principalmente diferença é que não existe um rodízio de pessoas, e sim de duplas, cada dupla trabalha em sua máquina e ao fim do turno as duplas trocam de máquinas e continuam o desenvolvimento da dupla anterior, esse ambiente exige mais conhecimento avançado da tecnologia ensinada.

Benefícios

A utilização do Coding Dojo em um ambiente corporativo aumenta o engajamento do time de desenvolvimento, estimula a aquisição de novos conhecimentos e principalmente desenvolve os valores dos profissionais participantes:

• Participação: Exemplifica a importância da participação de todos na resolução do problema, porque todos podem opinar.

• Cooperação: O problema tente a ter uma solução melhor e mais rápida com a colaboração entre todos, pois vários aspectos são levados em conta por conta da experiência pessoal de cada participante.

• Coragem: Estimula a coragem de enfrentar novos desafios, pois o ambiente sendo seguro até o mais tímidos ganham espaço e oportunidade para praticar a interlocução de suas ideias, sem o julgamento do dia a dia.

• Simplicidade: Como existem vários níveis de experiências entre os participantes, a simplicidade é importante ser mantida para que todos estejam avançado em conjunto, porque é vital que ao final todos estejam treinados para implementação a solução.

• Respeito: Esse valor é muito praticado, porque todos os participante devem respeitar a proposta de solução de um problema, porque todos acabamos aprendendo que existem várias formas de resolver um problema.

Sempre ao final do Coding Dojo é importantíssimo a execução de uma breve retrospectiva pelo responsável para verificar se os principais objetivos foram alcançados, porque além de ser ambiente de ensinamento seguro, é também altamente adaptável ao público, ou seja, caso os resultados não estejam sendo satisfatório, podemos adaptar o formato para facilitar a aplicação do conhecimento.

Onde Treinar?

Aqui na GFT praticamos a cada 15 dias em sessões online, elas são abertas para todos participarem, basta acessar o atalho abaixo, escolher o melhor dia e horário para você praticar conosco.

https://www.meetup.com/GFTBrasil

Oss

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Principios SOLID em Imagens

A maioria dos desenvolvedores utilizam a POO - Programação Orientada à Objeto e devem ter ouvido falar sobre SOLID, essa sigla é acrônimo para (iniciais do nome em inglês) para os principios para construção de software com qualidade e manutentabilidade. 

Para facilitar a compreensão desses conceitos, foi criado as imagens abaixo, afinal de contas nada melhor que desenhar para se fazer entender.

Princípio da responsabilidade única - (Single-responsibility principle)

Uma classe, microsserviços, componentes devem ser responsável por apenas uma atividade. Utilizando esse principio você poderá garantir que qualquer alteração que venha a acontecer no código irá impactar somente seus dependentes diretos. 

Princípio aberto-fechado (Open–closed principle)

As entidades de (classes, módulos, funções) devem estar abertas para extensão, entretanto  fechado para modificação. Utilizando esse principio podemos garantir que as alterações sendo realizadas através de extensão da entidade base nada será afetado no contexto dos códigos que utilizam a classe original. 

Princípio da substituição de Liskov (Liskov substitution principle)

O objetivo desse princípio é verificar que uma subclasse poderá ser substituída pela sua classe base sem erros. O principio é uma homenagem a Barbara Liskov, ela definiu que "se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa".

Princípio de segregação de Interface (Interface segregation principle)

Crie interfaces refinadas e específicas, porque elas são melhores que interfaces genéricas. Não devemos ser forçados a depender das interfaces que não iremos utilizar. Esse princípio lida com as desvantagens da implementação de grandes interfaces únicas.

Princípio da inversão de dependência (Dependency inversion principle)

Chega um momento no desenvolvimento de software em que nosso aplicativo será amplamente composto por módulos. Quando isso acontece, precisamos esclarecer as coisas usando a injeção de dependência. De uma forma objetiva o princípio nos faz entender que sempre devemos depender de abstrações e não das implementações.

Todos os desenvolvedores devem seguir esses cinco princípios, porque eles irão garantir um código mais limpo, eficiente e mais fácil de ser testado.

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br

As imagens são traduções das orignais do artigo de Ugonna Thelma em https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898

Estágios de um Desenvolvedor

Todo programador tem a oportunidade de escolher em que estágio sua carreira vai estar, para isso existem alguns comportamentos que podem alavancar ou prejudicar.

BONS HÁBITOS

MAUS HÁBITOS

Aprenda sempre algo novo Todo conhecimento adquirido pode ajudá-lo num próximo problema e Nomear métodos e variáveis corretamente O nome da variável e do método deve descrever perfeitamente o que esse código faz . Formatar o código Recuo é mágico! Você pode revelar toda a estrutura do código e editá-lo com uma compreensão clara de como ela funcionará. Planeje seu código Portanto, em vez de resolver problemas e programar em paralelo, é muito mais fácil descobrir o procedimento primeiro e depois escrever uma solução. Faça controle de versão Haverá momentos em que você cometerá um grande erro de programação e desejará voltar para uma versão anterior de um código. Concentre-se em uma linguagem por vez Escolha um e mantenha-o até dominá-lo, depois passe para o próximo. Ponha lógica por meio de comentários Escrevendo os comentários com lógicas, além de facilitar a implementação do código também ajudará na manutentabilidade. Seja proativo Você precisa se concentrar nas coisas que estão sob sua influência e que você possa oferecer ajuda. Comece com o fim no inicio Programadores eficazes geralmente têm objetivos muito convincentes em mente sobre seu futuro. Ofereça Vantagem ao Próximo Quer você seja ou não o único desenvolvedor trabalhando em um projeto, você não deve deixar seu ego fazer com que você pense apenas em si mesmo. Pratique Sinergia Não há dúvida de que grandes projetos são desenvolvidos por muitas pessoas que trabalham em equipe, logo equipes são mais importante que indivíduos.

Agir como se você tivesse todas as respostas Ninguém precisa e nem sabe todas as respostas e tudo bem. Estar na defensiva sempre que alguém critica seu código Esteja aberto a ter uma conversa aberta e direta sobre o seu código e como ele pode ser aprimorado. Desistir antes de tentar para valer Muitos programadores chegam tão perto de uma solução, apenas para desistir logo antes de resolverem o problema. Culpar os outros O desenvolvedor mais valioso é aquele que assume a propriedade e a responsabilidade pelo código que escreve. Ignorar  opiniões de outros desenvolvedores Uma das melhores maneiras de aprender e crescer como desenvolvedor é parear conhecimento com outros desenvolvedores. Super engenharia de problemas simples Não crie soluções confusas para problemas fáceis. Usar uma ferramenta errada Pare de tomar decisões com base em "está na moda ", esteja aberto para usar diferentes tecnologias, idiomas e estruturas. Evitando mensagens de erro. Erros de código ocorrem com frequência e eles também geralmente incluem informações muito valiosas sobre o que deu errado, por que aconteceu e quais linhas de acionamento dos problemas. Recusando-se a aprender com os erros Isso é contraproducente, recusar-se a aprender com seus erros fará com que você os repita. Resolver algo difícil e não documentá-lo Depois de passar horas decifrando o código por conta própria, é seu dever documentar para ajudar a próxima pessoa que encontrar o problema. Não gastar energia em revisões de código A equipe de desenvolvimento está unida e é responsabilidade de todos os membros da equipe garantir que o código que todos os outros membros estejam contribuindo cumpra os altos padrões da equipe.

Essa são alguns hábitos que podem nós levar a um dos extremos dos dois estágios de programador, o ideal é que tenham sempre em mente que estar no centro dessa escala com certeza irá nos tornar um profissional altamente eficiente e eficaz.

Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil
//marcelogoberto.com.br

Dicas para melhorar o entendimento das SQL Querys

Consultas em SQL são basicamente códigos no final, logo é importantíssimo termos a preocupação de oferecer um código claro e objetivo para aumentar a manutenibilidade dele por outros desenvolvedores. Comandos mal formatados e/ou com escritas confusas podem aumentar mais erros e uma falta geral de motivação para revisar seu trabalho. Para quem simplesmente escreve a consulta pode fazer sentido e até funcionar, porém é fundamental que o código esteja num melhor formato possível para aumentar sua qualidade, vamos a alguma regras que podem ajudar.

Seja consistente e corente com a formatação

SELECT primeiroNome, count(*) from
Usuários WHERE ultimo_nome = 'silva' Group by primeiroNome

Vamos analisar alguns pontos:

• Veja que algumas partes estão em maiúsculas e outras não, procure manter um padrão único, por exemplo todas as palavras reservadas.
• É confuso identificar o que é coluna ou o que é comando
• A coluna do SELECT está em "camelCase", a usada no WHERE está "snake_case" e o nome da tabela em "PascalCase", crie um padrão geral, se começou errado, conserte.
• A utilização de caracter especial em definição de nomes, como na tabela Usuários

Veja um exemplo como deveria ser:

SELECT primeiro_nome, COUNT(*) from
usuarios WHERE ultimo_nome = 'silva' GROUP BY by primeiro_nome 

Use e Abuse da Identação 

SELECT g.id, COUNT(u.id) FROM usuarios u JOIN gruopos g on u.grupo_chave
= g.chave WHERE u.nome = 'Marcelo' AND  u.sobrenome
= 'Silva'  GROUP BY g.chave ORDER BY COUNT(u.chave) desc 

Para uma consulta pequena pode não fazer diferença para leitura quando tudo está sem um padrão de separação, agora imagine aquelas longas procedures com todos os comandos encavalados, não é mesmo?

Veja se o resultado fica melhor para o entendimento: 

SELECT 
	  g.id
	, COUNT(u.id) 
FROM usuarios u 
	JOIN gruopos g on u.grupo_chave = g.chave 
WHERE 
	    u.nome = 'Marcelo' 
	AND u.sobrenome = 'Silva'
GROUP BY 
	g.chave 
ORDER BY 
	COUNT(u.chave) desc

Dica: A utilização da virgula (,)antes de cada campo no SELECT, ou das conjunções AND / OR no WHERE, GROUP BY, ORDER BY facilita a identificação visual onde se inicia ou termina o grupo de campo, além de fornecer uma forma agíl de comentar um campo 

Se você utilizar 2 ou 4 espaços não surti efeito considerável, o importante é só manter o padrão em toda a codificação, a simplesmente utilização dessa formatação farão seu colegas adorarem ver suas consultas quase como obras de arte. 😃

Utilize sempre "Aliases" 

SELECT
    u.chave
    , u.nome
    , t.chave
    , t.nome
    , (SELECT COUNT(*) FROM titulos where nome = t.nome)
FROM usuarios u
    JOIN titulos t on u.titulo_chave = t.chave 

O resultado dessa consulta será: 

chave	nome	chave	nome	count
1	Marcelo Goberto	4	Arquiteto	6

Novamente num cenário minimalista é possível identificar o que é cada conteúdo, agora imagine isso num longo resultado com várias colunas, por isso é fundamental que você nomeie cada coluna para que possa facilitar o entendimento.

Veja como fica o resultado da mesma consulta acima com ajustes 

SELECT
   u.chave AS usuario_chave   
   , u.nome AS usuario_nome
   , t.chave AS titulo_chave
   , t.nome AS titulo_nome
   , (SELECT COUNT(*) FROM titulos where nome = t.nome) AS qtde_titulos
FROM usuarios u
   JOIN titulos t on u.titulo_chave = t.chave

O resultado dessa consulta será 

usuario_chave	usuario_nome	titulo_chave	titulo_nome	qtde_titulos
1	Marcelo Goberto	4	Arquiteto	6

Utilize números nas clausulas GROUP BY e ORDER BY 

Neste caso essa é uma preferência pessoal que acredito que auxilia muito no organização de uma consulta, veja um exemplo com essa aplicação 

SELECT
   nome
    , sobrenome
    , COUNT(*) AS total
FROM usuarios
GROUP BY 1, 2
ORDER BY 3 desc 

Algumas vantagens na adoção desse formato são:

• Economia de linhas: a utilização de muitas colunas em GROUP ou ORDER não aumentará sua consulta, pois todos estarão enfileiradas
• Manutenção: Se desejar trocar o agrupamento ou a ordenação, basta trocar as colunas de lugar dentro da clausula SELECT

Esses foram alguns pontos que sempre considero na hora de escrever uma consulta, não existe um melhor padrão ou formato único para SQL, mas com certeza existe o desafio que procurar fazer um ótimo trabalho que possa ter sua manutenção facilitada para os próximos e quem sabe para nós mesmo, porque se todos tivermos um consenso que garantir sempre um excelente padrão de código, todos se sairão ganhando.

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Coisas que Desenvolvedores deveriam Aprender

Segurança em Primeiro Lugar

Qualquer aplicativo com certeza deverá ter segurança implementada, nunca deixe o desenho da segurança para "depois". Quando não efetuamos o mapeamento correto da estrutura de segurança no inicio do projeto, com certeza ela aumentará o tempo de desenvolvimento, com certeza será necessário reescrever código, adaptar conceitos para resolver as questões de segurança não mapeadas.

Cada Aplicativo é Diferente

Pode parecer redundante falar que cada aplicação é diferente de outra, porém muitas vezes acreditamos que todo aplicativo deve seguir um conjunto padrão de regras. Para cada aplicação é importante verificar o que realmente é preciso para que ela atinja o objetivo, e as vezes são necessários "exceções" para que se tenha o melhor caminho, não existe literamente, o certo e errado, e sim o que é melhor para que aplicação obtenha o melhor resultado no final.

Microsserviços não são Obrigatórios

É cativante falar que trabalhamos com microsserviços em nosso dia a dia, surfando na onda da alta tecnologia, transformando todos os nossos monólitos em microsserviços. Um exemplo clássico de quando não é recomendado utilizar, é quando o principal objetivo do projeto é cortar custos, a utilização de microsserviços com certeza não irá ajudá-lo a alcança esse resultado, pois lhe obrigará a criar mais instâncias do que realmente necessitaria. A utilização de microsserviços devem ser levadas em consideração analisando o contexto como um todo e não simplesmente a adoção da tecnologia por si só.

Padronize seu Ambiente de Desenvolvimento

Essa com certeza é uma das maiores dores de cabeças para um equipe durante um desenvolvimento, quando temos vários desenvolvedores que não estejam com os seus ambientes equalizados. Incidem inconsistências que levam a grande perda de tempo para solucioná-las, é importantíssimo coordenar as atualizações de versões, ferramentas, addons, enfim tudo que se relaciona com o projeto para sejam iguais, com isso fazemos com que todos estejam na mesma "página".

Use Pacotes quando Necessários

Ter pacotes para as aplicações se torno algo muito popular e principalmente fácil e rápido de executar. Entretanto cada pacote que é instalado, acoplado ou referenciado em seu projeto irá criar uma nova dependência, isso com certeza irá acarretar primeiramente o acréscimo na maioria das vezes de código de terceiros, além pequenas caixas pretas em seu projeto. Outro fator é que os pacotes sempre acabam importando mais referências, logo um simples, formatador de campo, pode se tornar uma extensão cadeia de bibliotecas que precisaram ser entregues e estarem disponíveis. É importantíssimo termos a analise do que realmente deve fazer parte do projeto, uma regra simples que pode ajudá-lo na decisão de importar ou fazer é, se puder escrevê-la em cerca de 10 a 15 minutos, e então o faço.

Não Abstraia o Universo

A abstração é uma outra grande armadilha que é fácil de cair. É muito comum pensarmos "talvez eu possa reutilizá-lo depois" e acabarmos por abstrair para que esteja "pronto" para ser reutilizado. O conceito de reutilização é amplamente mencionado como uma boa prática para ganharmos velocidade e qualidade no projeto, porém gastasse muito mais tempo para criar lógica de abstração, do que simplesmente escrever um método. Outra regra que pode ajudá-lo é, escreva a função, se no próximo passo, você escrever outra função semelhante, você poderá voltar e abstraí-la.

Você não é um Google

Muitas vezes iniciamos nossos projetos imaginando o envolvimento de todas tecnologias de ponta para o escalonamento e alta disponibilidade de nossa aplicação. Sabemos que a escala do projeto é determinante para definir nossa plataforma operacional, logo quanto mais imaginamos nosso projeto "gigante" maior será a plataforma. Ou seja, estamos fazendo isso porque a aplicação precisa estar num padrão de escala "Google" ou porque queremos adicionar essa tecnologia em nosso currículo? Procure se ater ao que realmente a aplicação precisa atender para o público e não o que é moda no mercado.

Não crie uma "filosofia" baseado em Estranhos

Seja você um desenvolvedor iniciante ou não, é importante que você decida sobre quais regras se aplicam ao seu aplicativo e ao seu estilo de desenvolvimento. Estude, pesquise, absorva novos conhecimentos na Internet, mas não crie uma forma de pensar em algo dos outros, faça seus testes, implementações, erre, aprenda, erre de novo, aprenda mais...

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br 

Princípios do SOLID que todo Desenvolvedor deve Conhecer

Há muitos anos os desenvolvedores utilizam a POO - Programação Orientada à Objeto (em inglês, OOP - Object Oriented Design) só que esse padrão por si só não evita programas confusos ou insustentáveis. Pensando em facilitar a criação de códigos, Robert C. Martin definiu cinco diretrizes que definem boas práticas para criação de códigos legíveis e de fácil manutenção, esses princípios foram chamados de SOLID, essa sigla é acrônimo (iniciais do nome em inglês): 

Princípio da responsabilidade única - (Single-responsibility principle)

Uma classe, microsserviços, componentes devem ser responsável por apenas uma atividade. Utilizando esse principio você poderá garantir que qualquer alteração que venha a acontecer no código irá impactar somente seus dependentes diretos. 

Princípio aberto-fechado (Open–closed principle)

As entidades de (classes, módulos, funções) devem estar abertas para extensão, entretanto  fechado para modificação. Utilizando esse principio podemos garantir que as alterações sendo realizadas através de extensão da entidade base nada será afetado no contexto dos códigos que utilizam a classe original. 

Princípio da substituição de Liskov (Liskov substitution principle)

O objetivo desse princípio é verificar que uma subclasse poderá ser substituída pela sua classe base sem erros. O principio é uma homenagem a Barbara Liskov, ela definiu que "se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa".

Princípio de segregação de Interface (Interface segregation principle)

Crie interfaces refinadas e específicas, porque elas são melhores que interfaces genéricas. Não devemos ser forçados a depender das interfaces que não iremos utilizar. Esse princípio lida com as desvantagens da implementação de grandes interfaces únicas.

Princípio da inversão de dependência (Dependency inversion principle)

Chega um momento no desenvolvimento de software em que nosso aplicativo será amplamente composto por módulos. Quando isso acontece, precisamos esclarecer as coisas usando a injeção de dependência. De uma forma objetiva o princípio nos faz entender que sempre devemos depender de abstrações e não das implementações.

Alguns problemas que com certeza surgiram por não adotar esses princípios, serão: repetição de código; código sem estrutura padronizada; fragilidade para manutenção; dificuldade na execução de testes e com certeza baixo reaproveitamento..

Abordamos os cinco princípios que todo desenvolvedor deve seguir. Pode ser assustador no começo, estar em conformidade com todos esses princípios, porém a máxima é verdade, com prática veem a aderência, e como consequência terá um enorme impacto na manutenção de nossos aplicativos.

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Usando Análise de Código no Visual Studio 2019 para Melhorar a Qualidade do Código

O Visual Studio oferece um recurso que executa análise de código estático para ajudar os desenvolvedores a identificar potenciais melhoras de design, globalização, interoperabilidade, desempenho, segurança, entre outras categorias de problemas que podem ser evitadas. A análise de código pode ser executada manualmente ou há qualquer momento dentro do projeto no Visual Studio. Uma outra vantagem é utilizada no processo de entrega continua (CD) , ela pode ser configurada para ser executada automaticamente no Azure DevOps.

Por que usar a análise de código estático?

A principal razão é que todos códigos será verificado antes da execução, ou sejam, análise estática verifica TODOS os códigos. Podem ser encontradas vulnerabilidades em códigos  que não estejam sendo executados, ou que não sejam de nosso conhecimento quando existem soluções monolíticas.

O segundo benefício é que você pode definir as regras específicas para o projeto e elas serão seguidas sem nenhuma intervenção manual. Se alguém esquecer de seguir essas regras, elas serão destacadas pelo analisador de código estático. Outro benefício é que podem ser identificados falhas no início do ciclo de desenvolvimento, o que significa menos custo para corrigi-los.

Vamos ver como ativar e configurar o analisador de código no Visual Studio 2019 para um projeto:

1. Abra a solução no Visual Studio 2019

2. Abra as propriedade do projeto e selecione a opção "Análise de Código"

3. Na parte de "Configurar Conjunto de Regras" você poderá definir e/ou configurar as regras que deseja que sejam validadas, para esse exercício vamos selecionar a opção "Todas as Regras da Microsoft"

4. Depois basta selecionar no menu "Compilação" a opção "Executar Análise de Código na Solução"

5. Como resultado da analise na "Lista de Erros" será exibidos todas as sugestões para melhorar o código

6. Clicando sobre um item, será exibido o ponto onde deve ser feita a interação para implementação da solução

7. Depois que implementar as melhorias, basta executar novamente a análise para atualizar a lista de recomendações.

Através da utilização de análise de código podemos garantir melhores códigos e principalmente ir aprender as melhores práticas através das recomendações, porque cada vez que efetuarmos uma implementação estaremos aprender uma boa prática, que com certeza será aplicada durante o processo de criação num próximo desenvolvimento.

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Hábitos Desnecessários para um Desenvolvedor

Todos sabemos que existem vários tipos de desenvolvedores, mas o que realmente determina a qualidade de código, não é necessariamente o conhecimento somente por si só, nesta métrica temos que levar em consideração sua a postura e seus hábitos no dia a dia. Alguns desses hábitos que são cultivados não ajudam e nem auxiliam no crescimento do ambiente corporativo, por isso que são desnecessário e devem ser evitados.

Meu código é o MELHOR!

Um dos maiores obstáculos de qualquer profissional, é simplesmente seu "Ego", quando este começa a tomar proporções, atrapalha o seu envolvimento com o time, porque acaba sempre ocupando um espaço entre você e os demais. Procure manter-se sempre humilde, principalmente em questão de ajudar aqueles que estão ao seu redor no dia a dia, oferecendo dicas construtivas, mentoria para uma melhor qualidade e evite ao máximo comparativos competitivos. Lembre-se, quando acreditamos que somos os melhores, fechamos as portas para novos conhecimentos.

Arrumo isso num piscar de olhos!

Muitas vezes é tentador resolver problemas da forma mais rápida possível, garantindo assim notoriedade. A forma mais comum para dar velocidade é a utilização de atalhos que são aplicados no curto prazo, contudo na grande maioria das vezes ocasiona um grande prejuízo no decorrer do tempo. É importante concedermos tempo para o completo entendimento e analise da melhor solução possível, um visão inicial e global pode oferecer uma solução mais trabalhosa, porém mais consistente e eficiente.

Eu lembro de tudo, não é necessário documentar!

Primeira verdade absoluta, é que ninguém é eterno, somente os documentos, veja o exemplo dos hieróglifos. Os desenvolvedores em sua maioria são dotados de excelente memória e raciocínio rápido, toda via todos somos falíveis, desde um simples deslize, como um afastamento por saúde. Devemos pensar que documentar deve ser um processo natural e cotidiano, porque qualquer documentação pode ajudar mais que nenhuma documentação.

Um desenvolvedor que evita documentar ou compartilhar seu conhecimento, não será transformado num membro insubstituível, ele com certeza será tratado como um passivo "forçoso" para empresa.

Não fui Eu!

Lembrando que todos somos falíveis, os desenvolvedores também se enquadram neste conjunto, logo devem praticar o habito de assumir as responsabilidades por falhas cometidas ao longo do processo de desenvolvimento. É muita mais fácil colocar a culpa, em documentos, membros da equipe, usuários que não utilizam corretamente o sistema, etc. Assumir erros oferece dois grandes bônus, primeiramente a oportunidade de aprender, porque toda falha é uma oportunidade de aprendizado, e o outro é sinalizar para todos o alto grau de envolvimento, criando uma reputação de comprometimento na empresa.

Esses são alguns dos hábitos que devem ser evitados, porém podemos resumi-los em uma única palavra, atitude.  Ter uma atitude boa e positiva, aliado com um pensamento positivo, refletirá no que você faz e o tornará um desenvolvedor mais produtivo.

Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil
https://marcelogoberto.blogspot.com/