Boas Práticas
De LEDES
Tabela de conteúdo |
Discussões Periódicas
Discussões periódicas podem ocorrer 1 ou 2 vezes na semana e são reuniões na qual cada membro da equipe responde às seguintes perguntas:
- O que fiz desde a última discussão?
- O que estou planejando fazer até a próxima?
- Existe algo me impedindo de atingir minha meta?
Um momento bom para as discussões periódicas é depois do almoço. Durante a manhã pode ser complicado. Estas discussões de status não demoram e uma forma eficiente de fazer estas reuniões seria ficar em pé e em frente a um quadro negro. Como as pessoas tendem a ficar cansadas depois do almoço, ter uma viva reunião em pé nessa hora permite que a equipe mantenha a sua energia alta. Como todo mundo tem trabalhado durante o dia, suas mentes estão focadas no trabalho e não em questões pessoais.
- Todos os membros do projeto devem propor e criticar as soluções.
- Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto.
- Deve-se valorizar a produção e não simplesmente as "horas de trabalho".
- No desenvolvimento, deve-se valorizar o "como foi feito" e não simplesmente o "o que foi feito".
- O foco deve ser na criatividade. Os membros devem saber achar soluções e caminhar com as próprias pernas.
Convenção de Código
Esta seção especifica uma proposta de convenção de código para ser utilizada em todos os projetos do LEDES. A convenção de código é importante por uma série de motivos:
- 80% do custo de tempo de vida de um artefato de software está na manutenção.
- Dificilmente o autor do software será responsável pelo sua manutenção durante todo o tempo de vida.
- Convenções facilitam a leitura do código, permitindo a outros programadores e aos gestores entender novos códigos de forma rápida e completa.
- Se o projeto for vendido como um produto, você precisa garantir que seu código estaja limpo e conciso.
A Convenção de Código oficialmente adotada no LEDES normaliza que:
- Sempre se utilize nomes de variáveis, funções, classes e demais entidades em inglês.
- Sempre se utilize Camel Case (myVar) para variáveis locais.
- Sempre se utilize Pascal Case (MyClass) para nomes de classes.
- Sempre se utilize Upper Case (MY_VAR) para variáveis globais.
- Sempre se utilize Upper Case entre underlines (_MY_CONST_) para constantes.
- Sempre se utilize Orientação a Objetos.
- Se você não possui fluência em programação OO no PHP, devore este material antes de começar: Classes e Objetos (PHP 5)
- Se procure manter funções pertinentes dentro das classes (mesmo que sejam static).
- Sempre utilize final para constantes em Java.
- Sempre se quebre linha:
- Após ponto-e-virgula;
- Antes de um operador;
- Antes de abrir chaves (escopo).
- Sempre se feche artefatos de software na mesma coluna ou na mesma linha em que foram abertos.
- Sempre se use tabulação em vez de espaços para identar.
- Utilize-se linhas em branco:
- Entre funções e métodos;
- Entre classes;
- Entre expressões com variáveis distintas.
- Em todos os arquivos deve-se utilizar o padrão de cabeçalhos e comentários especificado pelo DoxyGen.
- Sempre se utilize Design Patterns.
- Jamais utilize-se Deprecated Elements.
Adaptado de Code Conventions for the Java Programming Language.
Também define-se o seguinte padrão para sistema e hierarquia de arquivos:
PHP
- No servidor de desenvolimento:
- Desabilite o parâmetro zend.ze1_compatibility_mode;
- Habilite o parâmetro safe_mode;
- Desabilite o parâmetro register_globals
- Não use funções deprecateds (como session_register);
Java: Web Application
Java: WebServer
Java: OffLine Application
Banco de Dados
A Convenção de Código oficialmente adotada no LEDES normaliza que:
- Sempre se utilize nomes de entidades em inglês.
- Sempre se utilize nomes em Lower Case, separados por underline.
- Sempre se utilize esquemas (não public) nos BDs.
- Sempre utilize nomes de tabelas e outras entidades no singular.
- Separe através do uso de schemas as entidades de acordo com o contexto no sistema.
