Sem resumo de edição |
|||
| (8 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
| Linha 5: | Linha 5: | ||
===='''Status:''' Em progresso==== | ===='''Status:''' Em progresso==== | ||
===* [[Guia para Implementação - BIRD]]=== | ===* [[Media:Roteiro_Melhores_Praticas_Implementacao.pdf| Melhores práticas de Implementação - BIRD]]=== | ||
===* [[Media:Resumo_Guia_de_Implementacao.pdf| Resumo Guia para Implementação - BIRD]]=== | |||
==1. Visão Geral== | ==1. Visão Geral== | ||
| Linha 35: | Linha 37: | ||
Definir e aplicar as "Regras da Casa". Isso inclui a imposição do idioma Inglês para o código, a definição de convenções de nomenclatura (Snake case vs Camel case) e a configuração do ambiente de desenvolvimento (hooks de pre-commit). | Definir e aplicar as "Regras da Casa". Isso inclui a imposição do idioma Inglês para o código, a definição de convenções de nomenclatura (Snake case vs Camel case) e a configuração do ambiente de desenvolvimento (hooks de pre-commit). | ||
Ação: Manutenção do [[Guia para Implementação - BIRD]] e configuração dos pipelines de validação automática. | Ação: Manutenção do [[Media:Roteiro_Melhores_Praticas_Implementacao.pdf|Guia para Implementação - BIRD]] e configuração dos pipelines de validação automática. | ||
*'''3.2. Construção e Orientação (Tech Lead)''' | *'''3.2. Construção e Orientação (Tech Lead)''' | ||
| Linha 87: | Linha 89: | ||
<br> | <br> | ||
*'''The Pragmatic Programmer''' – Andrew Hunt & David Thomas. (Base para os | *'''The Pragmatic Programmer''' – Andrew Hunt & David Thomas. (Base para os princípios DRY e ETC) | ||
princípios DRY e ETC) | |||
<br> | <br> | ||
*'''Refactoring''' – Martin Fowler. (Técnicas para melhorar código legado sem alterar | *'''Refactoring''' – Martin Fowler. (Técnicas para melhorar código legado sem alterar comportamento) | ||
comportamento) | |||
<br> | <br> | ||
*'''PEP 8 – Style Guide for Python Code.''' Disponível em: https://peps.python. | *'''PEP 8 – Style Guide for Python Code.''' Disponível em: https://peps.python.org/pep-0008/ | ||
org/pep-0008/ | |||
<br> | <br> | ||
*'''Google Java Style Guide.''' Disponível em: https://google.github.io/styleguide/ | *'''Google Java Style Guide.''' Disponível em: https://google.github.io/styleguide/javaguide.html | ||
javaguide.html | |||
<br> | <br> | ||
*'''C# Coding Conventions (Microsoft).''' Disponível em: https://learn.microsoft. | *'''C# Coding Conventions (Microsoft).''' Disponível em: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions | ||
com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions | |||
<br> | <br> | ||
*'''OWASP Top 10 – Padrão global de conscientização sobre segurança de aplicações | *'''OWASP Top 10''' – Padrão global de conscientização sobre segurança de aplicações web. | ||
web. | |||
<br> | <br> | ||
| Linha 119: | Linha 114: | ||
<br> | <br> | ||
#[[Engenharia de Requisitos]] - Leonardo | |||
#[[Projeto de Software]] - Luis Henrique | #[[Projeto de Software]] - Luis Henrique | ||
#[[Modelagem de Software]] - Davi | #[[Modelagem de Software]] - Davi | ||
#[[Padrões de Trabalho]] - Carlos Ernani (Junin) | #[[Padrões de Trabalho]] - Carlos Ernani (Junin) | ||
Edição atual tal como às 17h26min de 22 de janeiro de 2026
Responsável: Gabriel de Freitas Villela
Última Atualização: 02/12/2025
Status: Em progresso
1. Visão Geral
A área de Implementação (Software Construction) é o motor da Fábrica de Software. É responsável por materializar as definições abstratas (requisitos e arquitetura) em um produto funcional, tangível e executável.
Diferente de uma abordagem artesanal, na nossa Fábrica o foco não é apenas "escrever código", mas sim estabelecer uma Engenharia de Construção. O objetivo é garantir que o software seja construído sobre alicerces sólidos de padronização, permitindo que qualquer desenvolvedor da equipe possa atuar em qualquer módulo com a mesma eficiência e qualidade (intercambiabilidade). O responsável atua como um Líder Técnico (Tech Lead), provendo ferramentas, roteiros e orientação para o time.
2. Fundamentos Teóricos
A prática de implementação nesta organização é fundamentada nas seguintes Áreas de Conhecimento (KAs) do SWEBOK v4 e práticas de indústria:
- Software Construction (Cap. 3): Foco na codificação, verificação unitária, integração e depuração.
- Engenharia de Qualidade (Clean Code): Aplicação rigorosa de princípios como SOLID, DRY (Don't Repeat Yourself) e KISS (Keep It Simple, Stupid) para garantir manutenibilidade.
- Automação de Processos: Uso de Ferramentas de Análise Estática (Linters, Formatters, Type Checkers) para garantir a consistência do código independentemente da linguagem (Python, C#, Java).
3. Principais Responsabilidades
A atuação vai além da digitação do código, focando na governança técnica da construção:
- 3.1. Governança e Padronização
Definir e aplicar as "Regras da Casa". Isso inclui a imposição do idioma Inglês para o código, a definição de convenções de nomenclatura (Snake case vs Camel case) e a configuração do ambiente de desenvolvimento (hooks de pre-commit).
Ação: Manutenção do Guia para Implementação - BIRD e configuração dos pipelines de validação automática.
- 3.2. Construção e Orientação (Tech Lead)
Atuar como facilitador técnico. O responsável pela implementação cria os esqueletos (scaffolding) das aplicações e resolve os problemas técnicos mais complexos, pavimentando o caminho para que os demais membros codifiquem as regras de negócio.
Ação: Codificação do core do sistema, Code Reviews (revisão de pares) e mentoria técnica para o time.
- 3.3. Preparação para Operação
Garantir que o código não apenas funcione na máquina do desenvolvedor, mas seja operável em produção.
Ação: Implementação de logs estruturados, tratamento adequado de exceções e não-exposição de credenciais (Segurança/Environment Variables).
4. Integração com o Time
Abaixo detalha-se como a área de Implementação interage com as outras áreas da Software House:
4.1. Com Projeto e Modelagem (Luis Henrique e Davi)
- Entrada: Diagramas UML e Definição Arquitetural.
- Ação: A implementação deve ser o espelho fiel da modelagem. Responsável pela implementação valida se a arquitetura proposta pelos responsáveis do Projeto e Modelagem de Software é viável tecnicamente dentro do prazo. Se o diagrama é a planta, a implementação é a construção do prédio.
4.2. Com Q&A e Garantia de Entrega (Giovana e João Gabriel)
- Saída: Código "buildável" e testável.
- Ação: A Implementação entrega para o Q&A um código que já passou por testes unitários básicos e análise estática. O código deve ser limpo o suficiente para que o Q&A foque em bugs de negócio, não em erros de sintaxe.
4.3. Com Segurança (Lucas)
- Parceria Contínua: Security by Design.
- Ação: Implementar as blindagens solicitadas pelo responsável pela Segurança do Software durante a escrita do código (ex: sanitização de inputs), em vez de deixar para corrigir vulnerabilidades apenas no final.
Referências e Leitura Recomendada
- SWEBOK v4: Capítulo 3 (Software Construction).
- Clean Code: A Handbook of Agile Software Craftsmanship - Robert C. Martin. Base para os princípios SOLID e Nomenclatura)
- The Pragmatic Programmer – Andrew Hunt & David Thomas. (Base para os princípios DRY e ETC)
- Refactoring – Martin Fowler. (Técnicas para melhorar código legado sem alterar comportamento)
- PEP 8 – Style Guide for Python Code. Disponível em: https://peps.python.org/pep-0008/
- Google Java Style Guide. Disponível em: https://google.github.io/styleguide/javaguide.html
- C# Coding Conventions (Microsoft). Disponível em: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions
- OWASP Top 10 – Padrão global de conscientização sobre segurança de aplicações web.
- Documentação Interna:
- Engenharia de Requisitos - Leonardo
- Projeto de Software - Luis Henrique
- Modelagem de Software - Davi
- Padrões de Trabalho - Carlos Ernani (Junin)