É obrigatória a leitura e aplicação de todos os padrões de projeto e de comportamento da equipe de desenvolvimento da VR System.

For noobs

Você é um noob, ainda está em Rookgaard antes de sair para suas Quests precisa de falar com o The Oracle. Tenha certeza de ao falar com ele sua backpack já deve possuir esses itens.

• Você terá um mentor durante seu inicio, obedeça tudo que ele lhe disser e utilize-o para tirar suas dúvidas. Os passos abaixo deixe pra fazer no final do dia.

Obs: "obedeça tudo que ele lhe disser", inclusive buscar um cafezinho, buscar água, etc...

• Crie uma conta no Skype - com avatar
• Ativar confirmação de leitura no seu Skype
• Crie uma conta no Github - com avatar
• Crie um avatar no Gravatar para seu e-mail a ser utilizado nas contas da VR System.
• Envie ao Gerente do Desenvolvimento, através dessa sua conta do Skype, seu e-mail a ser utilizado para criar sua conta no Back Office.
• Instale o VS
• Ativar visualização de linhas no seu VS
• Instale o SQL
• Instale o DevEx
• Instale o Git: coloque na configuração do Git do VS o mesmo e-mail e conta de usuário que criou no step2.
• Clone o projeto
• Temos um grupo de desenvolvimento se não estiver nele ainda, solicite para adicionarmos seu contato.
• Leia diversas vezes esses Padrões abaixo. Isso é importante para que você consiga desenvolver seu trabalho dentro do nossos padrões.
• Configure seu git para considerar camelcase nos arquivos. Esse repositório tem um app para corrigir arquivos criados com upper case.
  1. Dentro da pasta do projeto, vá na pasta .git
  2. Localize o arquivo config (está oculto, precisa ativar para ver arquivos ocultos)
  3. Troque o ignorecase para false.
• Comprar um bolo para o seu setor até a primeira semana.

Padrões do projeto

Tatue essas informações no seu braço para não esquecer.

• A tela de Marca pode ser utilizada de modelo, está completamente reõatorada e use-a para fazer novas telas.

- MarcaUI
- MarcaView
- MarcaUISearch (para telas de search)

• Classes ou Métodos devem seguir o seguinte padrão: Verbo, preposição ou conjunção devem estar me inglês e o resto em português. Comece o nome com o verbo e sempre em minúscula. Por Exemplo: Digamos que queira criar uma classe para criar um produto com um imposto.

public static void createProdutoAndImposto()

• Se for concatenar string não utilize o "+" priorize o uso do $ assim:

string value = $"Cliente: {nome_cliente_variavel}";

• Ao usar o EF colocar as TDelegate da LambdaExpression como "i" veja exemplo:

db.Get(i => i.Codigo)

• Quando estiver verificando algo por uma condition expression, quando fazemos um if na mesma linha utilize () para fazer o condition, dede que ele não seja um isEmpty, isZero ou algo do tipo que esteja sozinho, se tiver mais de uma condição, mesmo usando Extensions aí use o () para o if. Evite quebrar em duas linhas a verificação, porém, as vezes é necessário quando tem dois blocos distintos de verificação, ex: (a && b || c && d) && e && f. Veja que temo os blocos de 'a' a 'd' e depois outro bloco de verificação, ai nesses casos pode separar os dois.

nome = codigo.isZero() ? "x" : "y"; // certo
nome = (codigo.isZero()) ? "x" : "y"; // errado
nome = codigo is null ? "x" : "y"; // errado
nome = (codigo is null) ? "x" : "y"; // certo
nome = codigo.isZero() && codigo is null ? "x" : "y"; // errado
nome = (codigo.isZero() && codigo is null) ? "x" : "y"; // certo
nome = codigo.isZero() && codigo.isNotZero() ? "x" : "y"; // errado
nome = (codigo.isZero() && codigo.isNotZero()) ? "x" : "y"; // certo

• Usar sempre tipos primarios

Int16 usar short
String usar string
Int32 usar int

• Quando for atribuir um valor a um componente do DevExpress não utilize o campo .Text e sim o campo .EditValue

\\ IDIOT WAY
txtQtd.Text
\\ SMART WAY
txtQtd.EditValue

• Quando for atribuir um decimal num editValue não coloque 0 pois ele irá entender como Integer coloque 0m, veja abaixo:

\\ IDIOT WAY
txtQtd.EditValue = 0;
\\ SMART WAY
txtQtd.EditValue = 0m;

• Quando for recuperar um valor de um componente do DevExpress não utilize o campo .Text ou DisplayText e sim a extensão especifica.

\\ IDIOT WAY
txtQtd.Text
txtQtd.DisplayText
\\ SMART WAY
txtQtd.getStringValue()
txtQtd.getDecimalValue()

• Em checkbox do DevExpress utilize o .Value para não precisar de fazer casting.

chkFracionado.IsChecked.Value

• Se for montar uma query coloque os comando do SQL em maiúsculo e o nome dos campos coloque exatamente como na tabela

SELECT Ide FROM Unidades WHERE Ide IS NOT NULL

• As classes de Entity devem obrigatoriamente ter a seguinte marcação:

[Serializable]

• Se for uma variável vamos iniciar sempre minúsculo, se for uma propriedade vamos começar com maiúsculo e respeitando o CamelCase em ambos os casos. Utilize o nome do objeto respeitando o camelCase. Procure manter o mesmo padrão de nomes isso facilita na hora do Watch no debug.

Movimento movimento = new Movimento();
MovimentoProduto movimentoProduto = new MovimentoProduto();

• Em situações como as telas de Search por serem uma variável que armazena um objeto para ser acessado por outra tela, devemos colocar Selected no final e devem começar como minúscula. Seu Set deve ser privado (na maioria das vezes).

public Marca marcaSelected { get; private set; }

• Quando for criar uma propriedade Foreign Key coloque-a para acessar o objeto.

\\ IDIOT WAY
public Guid Unidade__Ide { get; set; }
public Unidades Unidades { get; set; }

\\ SMART WAY
public Unidades Unidade { get; set; }
public Guid Unidade__Ide
{
   get => Unidade.Ide;
   set => Unidade.Ide = value;
}

• Se for usar parametro opcional ele deve ser declarado na chamada do método.

\\ Dado o metodo calcular
public void calcular(verificar = false)
{

}

\\ IDIOT WAY
movimento.calcular(true);

\\ SMART WAY
movimento.calcular(verificar: true);

• Evite usar os campos Foreign Key criado para o linq, digamos que estamos tentando acessar o campo Ide da Unidade de venda

Produto.Unidade.Ide = Guid.Empty
# não use o campo exclusivo do linq, isso abaixo está errado
Produto.Unidade__Ide = Guid.Empty

• Utilize o RowDoubleClick como evento nas grids. Muitas vezes vai achar chamadas para o MouseDoubleClick então se encontrar esse código já corrige para esse método do RowDoubleClick

<dxg:TableView Name="tableView1" RowDoubleClick="tableView1_RowDoubleClick">

• Utilizaremos a notação CamelCase nos métodos e atributos das classes, não utilize mais _ e sempre coloque a primeira maiúscula e as demais minúsculas, mesmo quando o nome não sugerir isso, por exemplo ao criar um campo chamado Código CFOP, veja que o CFOP é tudo maiúsculo, mas ao criar você fará algo como abaixo. Com exceção dos campo que pertencem a outra tabela por exemplo Movimento__Ide isso vai nos indicar que é o campo Ide da tabela Movimento, aí nesses casos permite-se o uso do _ que por sinal deve ser duplo nesses casos.

public string CodigoCfop;

• As vezes acontece de na classe de DR você não utilizar alguns métodos, nesse caso obrigatoriamente implemente uma exceção de não implementado. Veja abaixo:

public override RelVendasPorRecebimentoDiario fillJoin(SqlDataReader dr) => throw new NotImplementedException();

• Se o método cabe em uma linha simplifique-o utilizando =>

public bool isValid() => true;

public int getQtde
{
   get => Qtde;
   set => Qtde = value;
}

• Nunca compare um combobox pelo SelectedIndex

• Nunca compare um valor de combo com um inteiro ou string, use sempre um enum.

• Enum:

  1. CamelCase.
  2. Nome do Enum no singular.
  3. Ter por default o valor de None = 0 e se precisar description o None será: "".
  4. Os demais valores devem começar sempre a partir do 1.
  5. Usar sufixo de Enumator no nome.
  6. Tanto o Enum quanto os seus valores devem estar no singular.
  7. Description não são obrigatórios, use-os se precisar de valores string para o enum.
  8. No caso das Flags elas devem estar no plural e os valores no singular.
  9. O Enum deve ficar na pasta de Enumerators dentro da Entity, colocar em subpastas respeitando a hierarquia da tela. Na hora de nomear os Enums procure evitar de colocar nomes muito genéricos, imagina um enum de Tipo dos produtos, não user Tipo e sim TipoProdutoEnumerator no nome do enum.
  10. Se o enum for genérico e não tiver relação apenas com o E-Trade mas for algo bem mais abrangente aí deve ir para classe Útil, Exemplo: dias da semana, dias do mês, resposta para sim e não, permissões.

• Padrão para criação de constantes. Sempre que precisarmos exibir mensagens para o usuário, será necessário criar uma constante e incluí-la na classe correspondente do projeto ConstantManager. Devemos usar CamelCase.

    public static class ProdutoExceptionConstant
    {
        public const string ProdutoNaoEncontrado = "Não foi possível identificar o produto selecionado.";
    }

• InputModel e ViewModel: vamos procurar priorizar a criação de InputModel e ViewModel em situações que precisam de mais desempenho. Onde terá que retornar grandes quantidades de dados para o usuário ou pegar uma quantidade grande de informações. Abaixo defino o padrão para isso:
  1. O InputModel e ViewModel devem estar na Class Library Entity e dentro da Pasta Models, que terá uma pasta para Input e outra para View, depois outra para tela/contexto que está mexendo terminando em Models.
  2. Os arquivos devem terminar em InputModel ou ViewModel, por exemplo: imagina que está fazendo uma ViewModel para pesquisa de produto pode usar PesquisaProdutoViewModel.cs
  3. Procure ao nomear o arquivo, usar o motivo da função que aquela ViewModel ou InputView está executando.
  4. InputModel são exclusivos para receber informações do usuário para salvarmos ou processarmos no nosso sistema.
  5. ViewModel são exclusivos para exibir informações do nosso sistema para o usuário.
  6. Cuidado para não confundir os dois com um Wrapper. Um Wrapper ele é usado para receber dois objetos, um ViewModel e InputModel não tem objetos referenciados nele.

• Extensions obrigatórias

  Fomos desenvolvendo diversas extensões para facilitar nossa vida, é obrigatória o uso dessas extensões, procure acompanhar as mudanças da pasta Extensions no projeto Util e ver as novidades que foram criadas.

  Quase sempre quando sai uma nova extension eu pelo menos publico no grupo de desenv da VR. Cabe a você orientar seus amigos também por lá.

obj.Codigo.isZero() // verifica se um int é zero
obj.Codigo.isNotZero()

obj.Nome.isEmpty() // verifica se um string é empty ou vazio
obj.Nome.isNotEmpty()

obj.Ide.isEmpty() // verifica se um guid é empty
obj.Ide.isNotEmpty()

obj.Status.isApagado(); // propriedade "Status" de uma entidade é apagado (-1)
obj.Status.isNotApagado(); //propriedade "Status" de uma entidade é diferente de apagado (-1)

obj.Valor.isGreaterThanEqualToZero() // verifica se valor decimal é maior ou igual a zero
obj.Valor.isLessThanEqualToZero()
obj.Valor.isLessThanZero()
obj.Valor.isGreaterThanZero()

• CID para tabelas que não possuem Ide
  • Utilize o nome da tabela em lowercase
  • Caso tenha um _ (underscore), ignore-o
  • Todas as palavras subsequentes permanecerão em minúsculo. Exemplos:

Classes // errado
classes // correto

AdministradoraCartao // errado
administradoracartao // correto

Movimento_Produto // errado
movimentoproduto // correto

• Regras do pull request

  Ao enviar o pull request se vc for noob, quase certo que ele será rejeitado. Até aí tudo bem, mas pode ocorrer de você corrigir e ainda sim sua correção estar errada, então voltamos mais uma vez o pull request para você, nesse caso use a cabeça e pare de tentar mandar na novamente o pull request sem antes confirmar se o que você fez está correto.

  Parte do principio que se você erro a coisa 1, depois 2 tem grandes chances de errar novamente na terceira vez.

  Siga esse script:

  1. mandou o pull request
  2. foi recusado
  3. mandou as correções
  4. voltou novamente recusado
  5. nao mande novamente o pull request até falar com quem reprovou para conferir, antes de enviar, se está tudo certo!
  6. Evite ping pong, ficar indo e vindo com a tarefa do QA e Deploy
  7. É muito trabalhoso para quem confere o pull-request, além de ter que ficar repetindo os mesmo erros várias vezes a pessoa que confere tem que varrer todo o código novamente, então se você confere antes de enviar evita esses desgastes desnecessários.

Links complementares importantes

• Utilização dos controllers padrão

• Padrões obrigatório na construção de reports

• Regras para utilização do ThemedWindow

• Tudo sobre Git e banco de dados

• Tudo sobre relatórios e ParameterObject.

• Algumas ferramentas úteis para o dia-a-dia como Scripts para para SQL, trocar arqID e mais.

• Chupa cabra gerador de classe DAL

• Resolver conflito no merge do UpdateAutomatic

• Nesse artigo tem algumas boas praticas, algumas delas adotamos.

• Procedimentos para o pessoal do teste

• Checklist para verificação de pull request

Ambientes de desenvolvimento

• Configurações de Visual Studio obrigatórias.

• Argumentos para inicialização dos Exes

• Como configurar o ambiente de teste do CCM no dev

• Configurar o Sintegra para acessar via debug com o usuário 1

• Como configurar emulador balança Urano

• Como criar post ou artigo na base de conhecimento - aula com o Rasta

• Configurando debug dos pacotes nuget no vs code

• Configuração de certificado digital no Debug do WebAPI.

• Configurar o GourmetDroid e Android na troca de versão para vídeos

Aulas importantes

• Explicando como criar um campo na tela do começo ao fim

• Como funciona a fundo nossa camada de dados

• Atualizar o data model após criação de campo

• Combinado explicado para desenvolvedores

• Componentes customizados - Implementação

• Usando padrão template