Q A Sankhya Dev Talks Boas Praticas De Programacao Na Plataforma Sankhya

Fala comunidade!

No dia 21/06 realizamos mais um Sankhya Dev Talks, neste evento conversamos sobre boas práticas de programação na plataforma Sankhya. No webinário exploramos padrões e boas práticas amplamente difundidas no mercado, e também boas práticas que devem ser aplicadas no uso dos frameworks e APIs da Sankhya. Confira abaixo uma seleção de conteúdos apresentados no evento, e também respostas para as principais dúvidas:

Sobre o evento

Perguntas e Respostas:

  • Como fazer com que todo o time siga as boas práticas?

Tornar essas boas práticas conhecidas por todos, principalmente destacando o valor que cada boa prática tem no processo de evolução e sustentação do código. Aplicar essas boas práticas no dia a dia, principalmente na fase de revisão de código e planejamento do produto, onde as refatorações precisam ganhar tempo e importância dentro das prioridades dos times.

  • Para queries em SQL Server é necessário se preocupar em usar NOLOCK ?

O hint ‘nolock’ faz parte de um conjunto de hints que foram descontinuados no SQL Server já faz algum tempo, então é pouco provável que isso faça alguma diferença nas versões dos últimos 5 anos. O nolock especificamente foi aposentado por conta de que agora o SQL Server usa o conceito de ‘snapshot isolation’ e ‘read-committed’, que torna o lock de leitura desnecessário.

  • A melhor forma de tratar uma transação cancelada dentro de um loop é com throw new JapeSession.CanceledTransactionException()?

JapeSession.CanceledTransactionException só deve ser usada em casos onde se quer desfazer a transação (rollback) de forma silenciosa, dando ao sistema a condição de continuar normalmente. Um exemplo de uso é quando vamos cancelar uma NFe. Primeiro cancelamos a nota no sistema, caso dê tudo certo cancelamos a transação e chamamos o serviço de cancelamento da SEFAZ, dando certo a gente repete a transação, desta vez deixando comitar.

  • Quais são os principais desafios em termos de tecnologia que a Sankhya enfrenta hoje?

São vários os desafios, mas o maior de todos é migrarmos nossa stack tecnológica para uma estrutura que dê mais autonomia e agilidade para nossos times, além de modernizar nossas APIs e plataformas utilizadas. Dentre os projetos mais proeminentes posso citar a quebra do monolito, que visa separar nosso sistema em sistemas menores e independentes, junto com toda nossa esteira de CI/CD e também o projeto do novo Design System, que vai modernizar nossa UI/UX e simplificar o trabalho dos desenvolvedores e QAs em nossa interface com usuário.

  • A compilação já está sendo realizada com Java 7?

Temos diversas versões do Java rolando em nossa estrutura, mas o principal ainda é JAVA 6. Estamos neste momento migrando para o Java 11 e logo poderemos usar os recursos novos.

  • No JdbcCommand poderia haver um recurso para retornar um resultado tipado, já como uma lista com os objetos montados, similar ao TypedQuery do JPA?

Com certeza poderia, e isso simplificaria ainda mais a interface de programação. Lembrando que esse tipo de estratégia é muito bom para baixos volumes de dados, pois quando temos um resultado grande temos um consumo de memória alto, portanto temos que ter junto uma solução de iterator que entrega uma única instância por vez para ser processada.

  • O nome do parameter tem que começar com “br.com.sankhya”?

Não, isso foi só um exemplo. O nome do parâmetro deve expressar o que ele representa.

  • Você acha que todos os princípios do SOLID conseguem ser implantados em uma empresa sem que tenha um impacto na produtividade do desenvolvimento?

Como tudo na vida, a diferença entre o remédio e o veneno, às vezes, está apenas na dose. Temos que saber usar os princípios como direcionadores de boas práticas, porém sem dogmatismos ou extremismos. Vejamos abaixo algumas características e aplicações de cada princípio:

S) Princípio da responsabilidade única.

É um princípio muito importante e usei um exemplo na apresentação que fala exatamente sobre isso, quando tratei dos EJBs delegando a lógica de negócio para BusinessDelegators, onde as responsabilidades de cada componente ficam mais claras e separadas.

O) Princípio do conceito aberto/fechado

É fundamental em um bom design orientado a objetos, e penso que torna o código mais fácil de evoluir e manter, e com mais estabilidade. Sou adepto ao princípio “prefira composição à herança”, mas esse item em específico se aplica a outros pontos no objeto, inclusive em métodos tendo um único objetivo e se adaptando a callbacks por exemplo.

L) Princípio da substituição de Liskov

Esse é um princípio básico da orientação à objeto e se complementa com uma boa prática, que é a de programar por interfaces. Dentro da regra do polimorfismo da OO, boas interfaces trabalham sempre com o tipo base, independentemente do tipo em runtime.

I) Princípio da Segregação da Interface

É um bom princípio, porém com o advento de linguagens mais dinâmicas (fracamente tipadas) isso acabou sendo um problema menor. Um exemplo disso são os lambdas do Java, que substituem as interfaces em diversos casos, principalmente em casos de callback, por exemplo.

D) Princípio da inversão de dependência

Esse deve ser aplicado sempre, pois torna a evolução do código mais simples e a manutenção mais rápida, usando o conceito de polimorfismo e code-to-interfaces.

O que você achou do evento? Ficou com alguma dúvida?

Avalie o evento, respondendo ao nosso formulário.

Qual tema você gostaria que fosse abordado nos nossos talks?

Vote na enquete: Dê sua opinião: Temas Webinários Técnicos

Agradecemos a participação de todos e aguardamos vocês no próximo Sankhya Dev Talks

#SankhyaDeveloper