Universidade Federal Rural de Pernambuco

Departamento de Estatística e Informática

Bacharelado em Sistemas de Informação

DEVTIPS PROJECT

Daniel Bonasser Carnib Coelho

Recife

Outubro de 2020
Resumo
Um grande problema hoje em dia, é a enorme distância existente entre
programadores iniciantes e os mais experientes, a DevTips será uma plataforma
onde permitirá que programadores menos experientes em uma stack (ferramenta
de programação) possam receber dicas sobre alguma parte específica de um
projeto, sobre a linguagem que ele está desenvolvendo, sobre alguma biblioteca,
e outras coisas, com um programador mais experiente de forma individual, com
o objetivo de tornar mais rápida e específica a busca por dúvidas ou dicas de
projetos com pessoas experientes da área.

1. Introdução
1.1 Apresentação e Motivação
O trabalho está inserido no contexto de desenvolvimento full-stack
que consiste na separação da parte visual da aplicação (também
conhecida como front-end) da parte de servidor onde ficará o banco de
dados da aplicação (também conhecida como back-end). Com a
motivação de poder proporcionar aos desenvolvedores mais experientes,
uma forma voluntária de dar dicas e espalhar conhecimento de
Dedicatória.
desenvolvimento específico de uma stack que ele trabalha, oferecendo
esse conhecimento por um valor, que ele próprio decidirá.

1.2 Objetivos
O problema observado é o fato de desenvolvedores que estão iniciando na
área da programação, muitas vezes não têm contato com pessoas mais
experientes da mesma área, como consequência, ficam na dúvida na hora de
realizar um projeto, essas dúvidas vão desde o próprio funcionamento da
linguagem que ele optou, até dúvidas relacionadas a arquitetura de projeto.
Como resposta atualmente a esse tipo de problema, existem diversos fóruns que
qualquer pessoa pode colocar sua dúvida e, alguém aleatório poderá responder.
A proposta da DevTips para solução deste problema é proporcionar ao
desenvolvedor menos experiente um contato direto com programador mais
experiente, por um tempo combinado entre eles dois e por um valor que o
desenvolvedor mais experiente decidirá. O nome da plataforma foi pensado
justamente para combinar com a proposta. “DevTips” é a junção da abreviação
da palavra em inglês “Developer” que significa “desenvolvedor”, por isso
“Dev”, e a palavra “Tips” que, do inglês quer dizer “dicas”. Desta forma temos
por objetivo viabilizar de forma mais rápida e específica a solução de dúvidas
dos desenvolvedores menos experientes, ajudando assim a comunidade de
iniciantes.

1.3 Organização do trabalho

Estamos dividindo a parte do front-end com a do back-end. Pretendemos fazer a

implementação do front-end em ReactJs e o servidor back-end com um banco
de dados em NodeJs, ou seja, será um modelo de comunicação usando API
REST. Para fazer a comunicação entre as duas partes, utilizaremos a biblioteca
Axios.

2. Trabalhos Relacionados
Existem hoje no mercado duas principais plataformas que fariam frente a
proposta da DevTips, sendo elas a Stack Overflow e a Experts Exchange.

O Stack Overflow oferece como limitação o fato de o desenvolvedor não

poder entrar em contato direto com alguém do mercado, na verdade ele mais se
caracteriza como um fórum, onde podemos colocar uma dúvida que temos e
qualquer pessoa pode se disponibilizar para responder. A proposta da DevTips é
justamente conectar o desenvolvedor que está com dúvida diretamente e de
forma individual com alguém mais experiente e poder conversar com ele de
forma particular sobre a dúvida.

O Experts Exchange tem a proposta bem parecida com a da DevTips, e

acreditamos que esse seria o verdadeiro concorrente. Apesar da proposta ser
semelhante, uma lacuna que podemos identificar na Experts Exchange é o fato
de que desenvolvedores podem se registrar como experts, porém podem optar
para não serem contactados de forma direta, podendo dessa forma dificultar
quem está querendo buscar por respostas. A proposta da DevTips é justamente
fazer com que todos os desenvolvedores que optaram por dar as dicas, possam
ser conectados diretamente, para isso o desenvolvedor no processo do registro
na plataforma, deverá informar os horários e dias da semana que ele estará
disponível para poder ser contactado.

3. Referencial Teórico
Como dito anteriormente na seção 1.3, o trabalho utilizará o conceito de
SPA (Single Page Application), dessa forma é separado toda a parte visual da
aplicação (front-end) da parte onde ficará o banco de dados (back-end), essa
separação traz mais flexibilidade na parte interativa da aplicação.

3.1 Parte Visual da aplicação

Na parte visual da aplicação, escolhemos o ReactJS como ferramenta de

desenvolvimento. O React é uma biblioteca JavaScript que faz de forma mais
organizada tudo o que o JavaScript normal faz, no sentido de manipular a
DOMM do HTML (Árvore de elementos do HTML). Ao utilizar a sintaxe de
uma linguagem chamada JSX (JavaScript XML), que é uma extensão da sintaxe
do JavaScript, o ReactJS permite que utilizemos a lógica dos códigos do
JavaScript dentro do HTML, essa simbiose permite que o desenvolvimento
fique mais organizado, fácil e rápido. Outra vantagem do ReactJS é o conceito
de “estado”, esse conceito permite que elementos se modifiquem na página sem
para isso ter que carregar novamente, esse conceito permite maior velocidade
para determinados tipos de implementação, além de consumir menos dados do
usuário.
No front-end foram utilizadas duas principais APIs, a primeira chamada
de ‘axios’ permite que se estabeleça o contato com o servidor, para isso é
necessário colocar a url do servidor que servirá de base para todas as
requisições feitas. Com a url que servirá de base já configurada, agora é
necessário que se estabeleçam as diversas rotas pelo o qual o servidor será
acessado, cada rota permitirá acessar uma funcionalidade diferente já
programada no servidor pelas classes dos controladores, para isso foi utilizado a
api ‘react-router-dom’, essa api possui algumas funções que permitem fazer a
criação dessas rotas.

3.2 Servidor da aplicação

Na Parte onde ficará o banco de dados da aplicação, optamos por utilizar
o NodeJS como ferramenta de desenvolvimento. O Node.js pode ser definido
como um ambiente de execução Javascript server-side. Isso significa que com o
Node.js é possível criar aplicações Javascript para rodar como uma aplicação
standalone em uma máquina, não dependendo de um browser para a execução.
Desta forma, criaremos uma API que irá rodar como um servidor
localmente na máquina e poderá ser acessado por requisições do protocolo de
comunicação HTTP (Hypertext Transfer Protocol). Dentro desse servidor
estará o banco de dados, onde serão guardados todos os dados dos usuários
registrados, a princípio será utilizado o Sqlite3, um banco que utiliza o SQL,
porém bem menor e menos seguro que o MySQL por exemplo.
As principais bibliotecas utilizadas para a construção desse servidor
foram as ‘express’ e a ‘knex’. O Express é um framework para aplicativo da
web do Node.js, mínimo e flexível que fornece um conjunto robusto de recursos
para aplicativos web e mobile, com ele é possível trabalhar com requisições e
respostas (request, response) de forma muito mais simples pois ele possui uma
miríade de métodos utilitários HTTP a seu dispor. O Knex.js é um query builder
(construtor de Query SQL) para Postgres, MSSQL, MySQL, MariaDB,
SQLite3, Oracle e Amazon Redshift, projetado para ser flexível e portátil, com
ele foi feita toda a modelagem do banco de dados, criação e relacionamento das
tabelas.

3.3 Criação de uma API

A necessidade da criação de uma API vem pelo fato de que é muito

provável que esse projeto venha a ter, no futuro, uma versão mobile. Dessa
forma, fica muito mais simples ter uma API cujo as funcionalidades serão
usadas tanto na versão web quanto na mobile.
Dentro do servidor criaremos um conjunto de rotinas e padrões de
programação (API) que permitirão o acesso a funcionalidades específicas do
banco de dados pela parte visual da aplicação como, adicionar pessoas ao
banco, ou listar os dados do banco, entre outras. As funcionalidades da API
estão dentro de uma pasta chamada de controllers onde nela haverão
inicialmente três controladores que ficarão responsáveis pelas funções da API e
poderão ser chamadas por meio do protocolo de requisições HTTP vindas do
front-end.

3.4 Conexão da parte visual com o servidor

Como a parte visual da aplicação está separada da API, a forma como
optamos conectar os dois é usando Requisições por meio do protocolo HTTP
(Hypertext Transfer Protocol) e seus métodos (GET, POST, DELETE, PUT, ...)
para podermos ter acesso ao banco de dados. Para isso utilizaremos a biblioteca
Axios, que facilita bastante o processo de fazer as requisições.
O processo funciona da seguinte forma: A parte visual irá fazer uma
requisição ao servidor como por exemplo, gravar alguma informação no banco
de dados, ou visualizar os dados dentro do banco. Quando essa requisição chega
ao servidor, ele analisa se está tudo correto com a requisição serão chamados os
controladores que irão executar as funções que foram solicitadas, devolvendo
uma resposta ao usuário que pode ser tanto positiva como negativa, dependendo
de como a requisição foi feita. Quando a resposta retorna dados para serem
processados pela parte visual, esses dados vem no formato JSON (JavaScript
Object Notation), que é basicamente uma formatação leve de troca de dados.
Para seres humanos, é fácil de ler e escrever. Para máquinas, é fácil de
interpretar e gerar.
Quando o JSON retorna para a parte visual, nela irá conter os códigos que
irão gerar a UI (User Interface) ou seja, processar, organizar e estilizar todos
esses dados para que fique agradável visualmente ao olhar do usuário.

Figura 1. Exemplo modelo de requisições e respostas usando a API

4. Metodologia científica

4.1 Modelagem do banco de dados

A modelagem do banco foi pensada inicialmente para possuir cinco

tabelas onde, uma não haveria relacionamentos com nenhuma outra, que seria a
tabela de usuários e todas as outras quatro haveriam relacionamentos entre si. O
banco escolhido para desenvolver a aplicação foi o SQlite3, por ser um banco
pequeno e mais fácil de estabelecer conexão, devido ao curto tempo a escolha
dele foi a mais assertiva.

Figura 2. Diagrama Entidade relacionamento da plataforma DevTips

Também houve um planejamento dos controladores que irão fazer todas as
funções dentro do banco de dados. Três controladores em formato de classe
foram suficientes para fazer a aplicação rodar de acordo com o planejamento.
Dois dos controladores são completamente independentes sendo eles o
controlador dos usuários (UserController) e o controlador dos desenvolvedores
(DevController), o terceiro controlador, o controlador das stacks
(StacksController), é totalmente dependente da classe de DevController uma
vez que, não pode haver uma stack registrada sem antes ter um desenvolvedor
registrado, formando assim uma relação de composição.

Figura 3. Diagrama de classes da plataforma DevTips

4.2 Modelagem da Parte visual da aplicação

 Toda a parte visual da aplicação também teve um planejamento de como
o fluxo entre as páginas iriam funcionar, usando a plataforma Whimsical, foi
possível um melhor embasamento quanto ao que deveria ser desenvolvido.
Ajudou bastante também a guiar no desenvolvimento dos controladores do
banco de dados pois, conforme as funções ficavam prontas nos controladores,
foi possível ir adiante no desenvolvimento da parte visual, integrar as duas
partes e verificar o funcionamento de ambas juntas.

Figura 4. Fluxo das páginas da plataforma

5. Resultados
A plataforma foi planejada para ser feita em um curto espaço de tempo,
com base nisso podemos afirmar que todas as funcionalidades planejadas foram
implementadas com sucesso, assim como todo o planejamento do fluxo de telas,
estilizações e conexões de toda a parte visual com a API.
Quanto aos resultados para com os objetivos da plataforma, também
podemos dizer que foi alcançado, a plataforma visava juntar desenvolvedores
mais experientes com os iniciantes, a plataforma consegue fazer isso, mesmo
que de uma forma simples. Evidentemente muitas coisas poderiam ser
implementadas para deixar ela uma plataforma mais segura mas, dentro do
planejado, tudo foi devidamente entregue.

6. Conclusão
O problema a ser solucionado é a distância entre os desenvolvedores
iniciantes e experientes. Podemos concluir que a DevTips não é uma plataforma
que “reinventa a roda”, mas sim uma ideia que foi possível ser modelada
utilizando-se das tecnologias mais utilizadas do mercado, visando a resolução
desse problema o mais rápido possível.
Apesar de simples inicialmente, esse projeto pode vir a se tornar mais
complexo no futuro, porém desde já apresenta a solução para o problema, fazer
com que os desenvolvedores possam entrar em contato um com o outro de
forma direta, ao nosso ver, é uma grande forma de diminuir essa distância e
possibilitar um avanço mais rápido para aqueles que estão começando na área.

6.1 Trabalhos Futuros

Para esse projeto se torne viável de ser lançado na internet, alguns

trabalhos ainda precisam ser feitos. O primeiro seria a troca do SQlite3 para um
banco de dados maior e com mais segurança, como o MySQL por exemplo.
Além disso, seria interessante fazer uma remodelagem nas tabelas do banco de
dados, colocando em uma única tabela, usuários e desenvolvedores,
diferenciando-os por meio de uma chave ou campo específico. Outra coisa
essencial de ser feita é uma tratativa de erros mais eficaz, para alguns erros em
específico, o servidor em vez de retornar o erro de imediato, fica tentando
acessar indefinidamente o banco, então se faz necessário tratar esses erros de
servidor mais específicos. Fazer uma análise dos desenvolvedores que estão se
registrando também seria muito importante, pois dessa forma, iremos garantir a
qualidade dos desenvolvedores que estarão à disposição para dar dicas, um
sistema que pudesse fazer a avaliação deste desenvolvedor pelos próprios
usuários, também seria interessante para o manutenção da qualidade.

Referências Bibliográficas
Site do ExpressJS: https://expressjs.com/pt-br/
Site do KnexJS: http://knexjs.org/