Nós criamos esta pequena especificação para ajudá-lo a criar aplicativos incríveis e consistentes. As diretrizes e requisitos descritos abaixo fazem parte do nosso processo de desenvolvimento. Certifique-se de que não só leia, mas também a compreenda.
Observação: Sócrates e nós estamos cientes de que ninguém sabe tudo, então não se preocupe se não terminar toda a aplicação, faça o seu melhor, nos envie e divirta-se ;-).
Sócrates diz: Sábio é aquele que conhece os limites da própria ignorância.
Todos as aplicações devem incluir um README descrevendo a estrutura, a implementação geral e o processo de compilação, se necessário. Existe um exemplo de readme como ponto de partida.
Certifique-se de seguir estas diretrizes:
- Siga algum estilo de código, de preferência o oficial da própria linguagem/framework.
- Escreva código em inglês.
- Use algum gerenciador de pacotes para dependências de terceiros, se necessário.
- Organize o código de acordo com as melhores práticas da linguagem/framework e padrões de projeto.
- Cobertura de testes (unitários, integrados):
- Entrega com no mínimo 80% de cobertura dos testes;
- Menos que 20% de duplicação de código;
- Nenhum defeito, vulnerabilidade, débito técnico ou fator de complexidade de código alta;
- Mantenha o código simples (Princípio KISS).
- Preze pela extensibilidade e manutenibilidade do código.
- Exigimos que as aplicações funcionem em plataformas com arquitetura x86 e sistemas operacionais, tais como: Microsoft Windows, macOS e Linux.
Crie uma aplicação (cliente e servidor) de cadastro de veículos. O servidor deve expor uma API que a aplicação cliente irá acessar para compor o CRUD de uma entidade Veículo.
- Marca, texto, não nulo, 40 caracteres;
- Modelo, texto, não nulo, 50 caracteres,
- Cor, texto, não nulo, 30 caracteres;
- Ano, inteiro positivo, não nulo;
- Preço, decimal positivo, não nulo;
- Descrição, texto;
- É novo?, boleano, não nulo;
- Data de cadastro, data e hora, não nulo;
- Data de atualização, data e hora, nulo.
- Utilize a tecnologia de sua escolha (sempre seguindo as diretrizes de boas práticas).
- Caso você não tenha domínio do
clienteou doservidor, faça apenas um deles. Se necessário, utilize algum tipo de simulação (mock) para o funcionamento da aplicação. - Faça a cópia do repositório (fork), desenvolva e submeta uma solicitação de mudança (pull request) contra o ramo mestre padrão (master).
- Squash seus compromissos (commits).
- Escreva uma descrição convincente de sua solicitação de mudança (pull request) de acordo com o guia How to Write a Git Commit Message.
- git - the simple guide
- How to Write a Git Commit Message
- Markdown Cheat Sheet
- A curated list of awesome READMEs
- README.md template for your open-source project
- Learn REST: A RESTful Tutorial
- Best Practices for Designing a Pragmatic RESTful API
- Roy Fielding on Versioning, Hypermedia, and REST
- 10 Best Practices for Better RESTful API
- Best RPC Programming Practices
- Best practices for service interface design in SOA