Edição das 15h13min de 3 de junho de 2016

Versão 1.0 - publicada em 03/06/2016

1. Apresentação

A Política de Padrões da MSTECH EDUCAÇÃO E TECNOLOGIA LTDA tem por finalidade estabelecer as melhores práticas adotadas como padrão de desenvolvimento de sistemas de aplicações e interfaces Web, com abrangência nas especialidades de "FRONT-END", "BACK-END", "DESIGNER DA INFORMAÇÃO", "DEVICES" e "TESTES". Este documento possui caráter oficial e tange como modelo de referência aplicável para toda a empresa.

Este material é fruto da construção dos colaboradores da empresa através das Equipes de Especialidades, conduzidos a partir do início de 2016, com o objetivo de definir as melhores práticas para cada uma das frentes.

Devido à natureza de constante evolução do mercado de TI, esse documento deve ser revisitado de forma contínua, inserindo novos padrões a cada definição consensual das equipes.

2. Definições

Abaixo apresentamos as definições realizadas para cada uma das frentes de trabalho. Este material deve ser considerado o guia oficial da empresa para novos desenvolvimentos

2.1 Padrões de desenvolvimento de Front-End

2.1.1 Ambientes de desenovlvimento(IDE) definidos

Deve ser adotado para o desenvolvimento de códigos de front-end como padrão de IDE (Integrated Development Environment):

• Visual Studio: para projetos que contém como parte da solução a plataforma .NET;
• JetBrains WebStorm: para os demais projetos/sistemas (caso não seja possível utilizá-lo);
• GitHub Atom: Alternativa leve para desenvolvimento, caso não haja disponibilidade do WebStorm.

Obs.: Tanto o Visual Studio quanto o JetBrains WebStorm são soluções pagas, com licenças adquiridas pela MSTECH. Antes de instalar, consulte o GTI para verificar a disponibilidade de licença.

2.1.2 Padrão de Bibliotecas

Para o desenvolvimento de códigos Javascript, ficou acordado que será utilizado ou o Javascript Nativo ou o "AngularJS", na versão 1.

Estão em análise e estudo para adoção futura o "AngularJS 2" e o "Vue.JS". Entretanto, estes não deverão ser utilizados ainda em sistemas destinados à clientes.

2.1.3 Padrão de comentários de códigos e APIs

Para comentários em front-end, será utilizada a estrutura definida no "JSDocs". Considerar os campos com comentários padronizáveis:

@description: descrição da sua função ou do método - (Obrigatório);

@author: nome do desenvolvedor e data de criação/alteração - (Obrigatório nas condições abaixo): - Quando for o criador, insere o campo no começo do documento; - Quando for alteração de uma função, insere na própria função.

@param: descrição do parâmetro (nome*, tipo*, descrição*) – (Se necessário); @callback: descrição do callback (tipo*) – (Se necessário); @return ou @returns (caso o retorno seja mais do que um) descrição do retorno: (nome, tipo*, descrição*) – (Se necessário).

Obs.: Em caso de refactor de um código que não está adequadamente comentado e é um trecho que precisa de informação para entendimento, adicionar comentário que responda às perguntas: "O quê/Para quê/Como?/Quando?"

2.1.4 Padrão de nomenclaturas

Nos códigos front-end, as nomenclaturas de variáveis e métodos devem ser descritos no idioma inglês. Para padronização, construiremos um Glossário com a indicação do melhor termo para cada entidade.

2.2 Padrões de desenvolvimento de Back-End

2.2.1 Testes de Unidade

Deve ser utilizado como padrão de testes unitários para desenvolvimento na plataforma .NET em aplicações MVC (Model-view-controller) os frameworks open-source “xUnit.net”, “Moq”, “FluentAssert” e “AutoFixture”.

Projetos baseados em Webform, dada a complexidade e a impossibilidade de avaliar de forma modular o código, não serão aplicados os testes unitários.

2.2.2 Testes de Integração

Deve ser utilizado como padrão de testes de integração para desenvolvimento na plataforma .NET em aplicações MVC (Model-view-controller) o framework open-source “SpecFlow”.

Projetos baseados em Webform, dada a complexidade e a impossibilidade de avaliar de forma modular o código, não serão aplicados os testes de integração.

2.2.3 Padrões de Arquitetura e organização de código

Na organização de códigos construídos em ASP.NET MVC, recomenda-se o uso do padrão de organização conhecido como "CQS"(Command Query Separation). Referência sobre esse padrão: Martin Fowler "Command Query Separation"

2.3 Padrões de Design da Informação

2.3.1 Portfólio de serviços da equipe de Design da Informação

O “cardápio” padrão dos serviços de “Design da Informação” encontra-se na página oficial Designers da informação MSTECH

2.4 Padrões de desenvolvimento de Devices (Mobile e Desktop)

2.4.1 Ambientes de desenovlvimento(IDE) definidos

Deve ser adotado como padrão de IDE (Integrated Development Environment):

• O IntelliJ IDEA para os projetos/sistemas desenvolvidos em Java;
• O Xcode para os projetos/sistemas desenvolvidos em iOS;
• O Android Studio para os projetos/sistemas desenvolvidos em Android.

Obs.: Configurar as IDEs para utilização do padrão Square de organização de código, com o Tab contendo 4 espaços.

2.4.2 Padrões de Arquitetura

• Desenvolvimento de aplicações Android: Deve ser utilizado como padrão de arquitetura Android o Clean Architecture. Referência;
• Desenvolvimento de aplicações iOS: Será utilizado como padrão de arquitetura o MVVM (Model-View-View-Model) conforme recomendado pela Apple;
• Desenvolvimento Desktop: Deve ser utilizado como padrão de arquitetura Desktop o MVP (Model-View-Presenter) e, como padrão de arquitetura em Camadas, N-Tier.

2.4.3 Testes Unitários

Para a construção e execução dos testes unitários, deve ser utilizado como padrão para desenvolvimento JavaScript e Android os frameworks open-source JUnit e Mockito e, especificamente para Android o Robolectric.

Para análise de cobertura de código, deve ser utilizado o Jacoco (Java Code Coverage).

2.4.4 Uso de analisadores de código

Devem ser adotados como padrão de analisadores de código na plataforma mobile:

• PMD;
• FindBugs;
• JSLint, considerando e resolvendo “warnings”;
• SonarLint para análise de código Android.

2.4.5 Padrões de framework

Deve ser adotado o Gradle como padrão para projetos/sistemas Desktop, permanecendo o Maven para projetos/sistemas Desktop legados.

2.4.6 Padrão de comentários de códigos e APIs

Deve ser adotado o JavaDoc como padrão de comentários para os projetos/sistemas e API's desenvolvidos em Java.

2.4.5 Padrões de instaladores

Adotar na construção de instaladores a política de rollback.