|
|
Linha 13: |
Linha 13: |
| 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 | | 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 ==
| + | [https://wikipedia.mstech.com.br/index.php/Padr%C3%B5es_Back-End Padrões de Back-End] |
| | | |
− | ===2.1.1 Ambientes de desenovlvimento(IDE) definidos ===
| + | [https://wikipedia.mstech.com.br/index.php/Padr%C3%B5es_Front-End#1._Ambientes_de_desenovlvimento.28IDE.29_definidos Padrões de Front-End] |
| | | |
− | Deve ser adotado para o desenvolvimento de códigos de front-end como padrão de IDE (Integrated Development Environment):
| + | [https://wikipedia.mstech.com.br/index.php/Padr%C3%B5es_Mobile Padrões Mobile e Desktop] |
| | | |
− | * '''Visual Studio:''' para projetos que contém como parte da solução a plataforma .NET;
| + | [https://wikipedia.mstech.com.br/index.php/Padr%C3%B5es_Designer_da_Informa%C3%A7%C3%A3o Padrões de Designer da Informação] |
− | * '''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.
| + | [https://wikipedia.mstech.com.br/index.php?title=Padr%C3%B5es_de_Testes&action=edit] |
− | | + | |
− | ===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 [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 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: [http://martinfowler.com/bliki/CommandQuerySeparation.html 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 [http://design.mstech.com.br/ Designers da informação MSTECH]
| + | |
− | | + | |
− | == Padrões de desenvolvimento de Devices (Mobile e Desktop) ==
| + | |
− | | + | |
− | ===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. Padrões de Arquitetura ===
| + | |
− | | + | |
− | * '''Desenvolvimento de aplicações Android:''' Deve ser utilizado como padrão de arquitetura '''Android''' o '''Clean Architecture'''. [https://github.com/android10/Android-CleanArchitecture 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'''.
| + | |
− | | + | |
− | ===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).
| + | |
− | | + | |
− | ===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.
| + | |
− | | + | |
− | ===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.
| + | |
− | | + | |
− | ===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.
| + | |
− | | + | |
− | ===7. Padrões de instaladores ===
| + | |
− | | + | |
− | Adotar na construção de instaladores a política de ''rollback''.
| + | |
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.
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