Diferenças
Aqui você vê as diferenças entre duas revisões dessa página.
| Ambos lados da revisão anterior Revisão anterior Próxima revisão | Revisão anterior | ||
| pres:gerti:documento_de_arquitetura_de_software [14/07/2022 14:36] – [4.1. Qualidade Interna] bholiveira | pres:gerti:documento_de_arquitetura_de_software [14/07/2022 19:48] (atual) – bholiveira | ||
|---|---|---|---|
| Linha 1: | Linha 1: | ||
| - | ====== | + | ====== |
| ====== .1. Propósito ====== | ====== .1. Propósito ====== | ||
| Linha 171: | Linha 171: | ||
| A qualidade interna do produto de software será determinada quando a estrutura lógica do código, quanto a organização dos métodos e variáveis, quando a capacidade de apreensibilidade do código lido, nomenclatura de métodos e variáveis e quanto ao tamanho das estruturas (quantidade de linhas de código por método e classe). | A qualidade interna do produto de software será determinada quando a estrutura lógica do código, quanto a organização dos métodos e variáveis, quando a capacidade de apreensibilidade do código lido, nomenclatura de métodos e variáveis e quanto ao tamanho das estruturas (quantidade de linhas de código por método e classe). | ||
| - | Para estabelecer um padrão de qualidade interna dos produtos de software aderentes à arquitetura de software que trata esse documento, foi definido os seguintes padrões de código: | + | Para estabelecer um padrão de qualidade interna dos produtos de software aderentes à arquitetura de software que trata esse documento, foi definido os seguintes padrões de código: |
| + | |||
| ● Estilo de código - o padrão de estilo de código utilizado nos projetos será o padrão determinado pela Microsoft, com alterações definidas pelas estruturas de Style Cop adotadas pela equipe de desenvolvimento da GER-TI. Todo arquivo de classe de projeto deve ter o cabeçalho contendo a propriedade intelectual do TCE-GO, como apresentado na imagem abaixo. | ● Estilo de código - o padrão de estilo de código utilizado nos projetos será o padrão determinado pela Microsoft, com alterações definidas pelas estruturas de Style Cop adotadas pela equipe de desenvolvimento da GER-TI. Todo arquivo de classe de projeto deve ter o cabeçalho contendo a propriedade intelectual do TCE-GO, como apresentado na imagem abaixo. | ||
| Linha 183: | Linha 184: | ||
| internas, protegidas e por último as provadas, sendo os construtores de classe organizados em primeira posição. | internas, protegidas e por último as provadas, sendo os construtores de classe organizados em primeira posição. | ||
| ○ Métodos - os métodos serão organizados inicialmente por métodos públicos iniciados pelos tipo estáticos, seguidos de métodos internos, protegidos e posteriormente por métodos privados. Seguindo o manual de boas práticas de construção de código, Clean Code, os métodos das classes devem ser estruturados de acordo com a dependência entre si, isto é, os métodos utilizado por um método deve ser alocado logo abaixo desse método, de modo que o código seja auto explicativo, | ○ Métodos - os métodos serão organizados inicialmente por métodos públicos iniciados pelos tipo estáticos, seguidos de métodos internos, protegidos e posteriormente por métodos privados. Seguindo o manual de boas práticas de construção de código, Clean Code, os métodos das classes devem ser estruturados de acordo com a dependência entre si, isto é, os métodos utilizado por um método deve ser alocado logo abaixo desse método, de modo que o código seja auto explicativo, | ||
| + | |||
| ● Comentário de Bloco - o comentário de bloco será permitido para os métodos de interfaces e classes de forma obrigatória para os métodos públicos e facultativo para os métodos privados. Para os métodos de classes que utilizam a especificação por interfaces, o comentário do método pode ser único pela interface, ficando facultativo replicar o comentário no método da(s) classe(s) concreta(s), | ● Comentário de Bloco - o comentário de bloco será permitido para os métodos de interfaces e classes de forma obrigatória para os métodos públicos e facultativo para os métodos privados. Para os métodos de classes que utilizam a especificação por interfaces, o comentário do método pode ser único pela interface, ficando facultativo replicar o comentário no método da(s) classe(s) concreta(s), | ||
| + | |||
| ● Comentário de Linha - o comentário de linha de código não poderá ser extenso, devendo se limitar, de forma intuitiva, a explicação do uso da estrutura comentada e seu propósito. | ● Comentário de Linha - o comentário de linha de código não poderá ser extenso, devendo se limitar, de forma intuitiva, a explicação do uso da estrutura comentada e seu propósito. | ||
| + | |||
| ● Nomenclatura de Variáveis e Métodos - não existe limitação quanto ao tamanho do nome para variáveis e métodos. O nome desses estruturas deve sempre ser intuitivo de modo a facilitar o entendimento do propósito e para que serve a estrutura, dessa forma o nome das mesmas serem auto explicativas. O nome dessas estruturas que utilize mais de uma palavra, para as variáveis deve iniciar com letra minuscula e para métodos com letra maiúscula, e para ambas as palavra subsequentes a primeira deve sempre iniciar com letra maiúscula. As palavras que compõem o nome dessas estruturas deve conter ao menos duas letras, para não ferir o padrão de iniciar maiúsculo da segunda palavras em diante. O nome de métodos deve iniciar sempre com verbo, de forma a indicar a ação executada pela estrutura, como “Obtenha”, | ● Nomenclatura de Variáveis e Métodos - não existe limitação quanto ao tamanho do nome para variáveis e métodos. O nome desses estruturas deve sempre ser intuitivo de modo a facilitar o entendimento do propósito e para que serve a estrutura, dessa forma o nome das mesmas serem auto explicativas. O nome dessas estruturas que utilize mais de uma palavra, para as variáveis deve iniciar com letra minuscula e para métodos com letra maiúscula, e para ambas as palavra subsequentes a primeira deve sempre iniciar com letra maiúscula. As palavras que compõem o nome dessas estruturas deve conter ao menos duas letras, para não ferir o padrão de iniciar maiúsculo da segunda palavras em diante. O nome de métodos deve iniciar sempre com verbo, de forma a indicar a ação executada pela estrutura, como “Obtenha”, | ||
| + | |||
| ● Nomenclatura de Classes - toda classe preferencialmente deve ser um TAD, de modo a representa objetos do mundo real. Porem, há possibilidade ser necessário criar classes úteis funcionais para determinada operações típicas, como classes de extensão, classes de verificação de tipos conhecidos, como validação de CPF e CNPJ, entre outras. Para isso essas classes utilitárias, | ● Nomenclatura de Classes - toda classe preferencialmente deve ser um TAD, de modo a representa objetos do mundo real. Porem, há possibilidade ser necessário criar classes úteis funcionais para determinada operações típicas, como classes de extensão, classes de verificação de tipos conhecidos, como validação de CPF e CNPJ, entre outras. Para isso essas classes utilitárias, | ||
| + | |||
| ● Tamanho da estrutura - as classes não tem tamanho máximo fixado, porem, classes acima de 2 mil linhas de código devem ser refatoradas para | ● Tamanho da estrutura - as classes não tem tamanho máximo fixado, porem, classes acima de 2 mil linhas de código devem ser refatoradas para | ||
| classes de controle específico, | classes de controle específico, | ||