Mudanças entre as edições de "Politica de Padronizacao de Codigo MSTECH"

De MSTECH wiki
Ir para: navegação, pesquisa
Linha 15: Linha 15:
 
== 2.1 Definições de Front-End ==
 
== 2.1 Definições de Front-End ==
  
===2.1.1 Ambientes definidos ===
+
===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):
 
Deve ser adotado para o desenvolvimento de códigos de front-end como padrão de IDE (Integrated Development Environment):
Linha 29: Linha 29:
 
Para o desenvolvimento de códigos Javascript, ficou acordado que será utilizado ou o Javascript Nativo ou o '''"AngularJS", na versão 1'''.
 
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.
+
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.2 Padrão de comentários de códigos e APIs ===
+
===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:
 
Para comentários em front-end, será utilizada a estrutura definida no "JSDocs". Considerar os campos com comentários padronizáveis:
Linha 47: Linha 47:
 
'''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?"'''
 
'''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.3 Padrão de nomenclaturas===
+
===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 [https://wikipedia.mstech.com.br/index.php?title=Gloss%C3%A1rio_de_termos_em_ingl%C3%AAs&action=edit Glossário] com a indicação do melhor termo para cada entidade.
 
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 [https://wikipedia.mstech.com.br/index.php?title=Gloss%C3%A1rio_de_termos_em_ingl%C3%AAs&action=edit Glossário] com a indicação do melhor termo para cada entidade.
 +
 +
== 2.2 Definições 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 unitários.
 +
 +
===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". Referência sobre esse padrão: [http://martinfowler.com/bliki/CommandQuerySeparation.html Martin Fowler "Command Query Separation"]

Edição das 14h22min 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 Definições 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 Definições 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 unitários.

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". Referência sobre esse padrão: Martin Fowler "Command Query Separation"