Mudanças entre as edições de "Clean Code"

De Supel Wiki
Ir para: navegação, pesquisa
 
(2 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 1: Linha 1:
 
'''Consequência do código ruim'''</br>
 
'''Consequência do código ruim'''</br>
A organização têm uma série de percas com um software com código ruim .O código ruim traz uma série de consequências entre eles o prejuízos financeiros , na qual o software precisa de mais refatorações (manutenção), e o tempo da manutenção é maior . Com maior demanda de tempo no código  mais gastos para a organização onde os programadores neste momento poderiam trabalhar em novos projetos.
+
A organização tem uma série de prejuízos com um software de código ruim, entre eles: prejuízos financeiros, pois o software precisa de mais manutenção (refatoração) do que um código que está bem feito; prejuízo de tempo porque o desenvolvedor não entende o código e gasta muito tempo com a análise dele; prejuízo na implementação de soluções porque o código pode precisar de reforço antes de uma solução ser efetivada. Esses problemas tem como resultado, por exemplo, a impossibilidade de inicio de novo projeto, pois a equipe de desenvolvimento estará gastando muito tempo na manutenção do código ruim.
A produtividade dos programadores diminui necessitam identificar onde está ocorrendo o gargalo do código ou como é conhecido BUG , demandando maior tempo e esforços pois encontram grandes dificuldades em lê o código , e as soluções encontradas nem sempre vai resolver o problema se toda a estrutura não for refatorada.
 
Os programadores também sofrem com um código ruim . Ao lê um código ruim o programador se sente frustado, porquê não está trabalhando em um código que ele gostaria de trabalhar e pensa muitas vezes em refazer o projeto , do que refatorar o mesmo .  
 
  
'''Por quê entregamos código ruim'''</br></br>
+
Por esses motivos, e outros mais, um programador que encontra um código ruim sente-se frustrado, afinal, ele tenta trabalhar em um código que ele não entende, não gosta de trabalhar, não dá resultado e precisa de constante reforço. Ao ter esse sentimento o profissional tende a pensar que traria mais resultado iniciar novo código do zero do que refatorar constantemente código mal feito.<br>
 +
 
 +
 
 +
'''Por que entregamos código ruim'''</br></br>
 
O clean code nos traz alguns pontos:
 
O clean code nos traz alguns pontos:
 
* Entregas Apertadas : Quando se tem um tempo pequeno para entregas das tarefas , uma nova funcionalidade uma refatoração o que o programador está preocupado é em apenas entregar a funcionalidade , porque tem a necessidade de entregar logo , então ele faz apenas um código para funcionar sem se preocupar com a qualidade do código .
 
* Entregas Apertadas : Quando se tem um tempo pequeno para entregas das tarefas , uma nova funcionalidade uma refatoração o que o programador está preocupado é em apenas entregar a funcionalidade , porque tem a necessidade de entregar logo , então ele faz apenas um código para funcionar sem se preocupar com a qualidade do código .

Edição atual tal como às 16h57min de 27 de março de 2019

Consequência do código ruim
A organização tem uma série de prejuízos com um software de código ruim, entre eles: prejuízos financeiros, pois o software precisa de mais manutenção (refatoração) do que um código que está bem feito; prejuízo de tempo porque o desenvolvedor não entende o código e gasta muito tempo com a análise dele; prejuízo na implementação de soluções porque o código pode precisar de reforço antes de uma solução ser efetivada. Esses problemas tem como resultado, por exemplo, a impossibilidade de inicio de novo projeto, pois a equipe de desenvolvimento estará gastando muito tempo na manutenção do código ruim.

Por esses motivos, e outros mais, um programador que encontra um código ruim sente-se frustrado, afinal, ele tenta trabalhar em um código que ele não entende, não gosta de trabalhar, não dá resultado e precisa de constante reforço. Ao ter esse sentimento o profissional tende a pensar que traria mais resultado iniciar novo código do zero do que refatorar constantemente código mal feito.


Por que entregamos código ruim

O clean code nos traz alguns pontos:

  • Entregas Apertadas : Quando se tem um tempo pequeno para entregas das tarefas , uma nova funcionalidade uma refatoração o que o programador está preocupado é em apenas entregar a funcionalidade , porque tem a necessidade de entregar logo , então ele faz apenas um código para funcionar sem se preocupar com a qualidade do código .
  • Usuários com necessidades urgentes : É constante nas empresas um usuário vir com uma necessidade urgente , na qual deseja que seu problema seja resolvido em questão de minutos , o programador vai lá e coloca qualquer coisa no código só pra funcionar .
  • Mostrar Produtividade : É comum quando conseguimos um novo emprego , demonstrar serviço. Demonstrar que somos capazes de realizar as tarefas e queremos mostrar produtividade. Mais nem sempre a produtividade vem acompanhado da qualidade. A qualidade é tão importante quanto a quantidade.
  • Pressão do Chefe : Com o chefe cobrando resultados , cobrando entregas, muitas vezes os programadores ficam após o expediente para entregar logo o resultado , as vezes já estão cansados e querem se livrar de uma vez da tarefa , entregam o código de qualquer jeito. , pensando em rever depois , mais isso nunca acontece .

Benefícios:

  • Evita duplicação de código;
  • Possibilita maior clareza;
  • Identificar classes e métodos supérfluos;
  • Facilita a manutenção do código ;
  • Garante que todos os teste continuem funcionando.

Técnicas:
O clean code prega algumas técnicas em que ajudam a melhorar na qualidade do código são eles :

  • Nomes Significativos ;
  • Métodos Pequenos (Funções bem escritas);
  • Evite Comentários;
  • Classes.


Nomes Significativos: É você escrever uma função ou um método em que você consiga lê e em entender oque ele vai fazer , qual a sua finalidade através do seu nome .
Métodos Pequenos: Métodos pequenos e funções bem escritas são mais fácil de lê . Métodos muito extensos demandam maior tempo lendo e tentando rastrear oque cada parte do código faz . Evite Comentários: Comentários são mentirosos. Se uma função ou uma parte do código possui um comentário para justificar oque ele faz , o nome dele não está significativo . O desenvolvedor ao refatorar uma função que possui um comentário ele esta preocupado em apenas em refazer o código , para ele o comentário não é importante então ele não atualiza o mesmo . Classes : Quanto menor as suas classes serão mais fáceis de . Classes com apenas uma responsabilidade e com poucas propriedades ajudam na compreensão do que ela faz .