Clean Code. Escrevendo código para seres humanos. Rodrigo

Transcrição

1 Clean Code Escrevendo código para seres humanos Rodrigo

2 Rodrigo

3

4 Mas afinal O que é código limpo?

5 Ward Cunningham co-criador da XP Elegância e eficiência, fazer uma coisa bem feita! Bjarne Stroustrup criador do C++ Fácil para outro desenvolvedor entender e melhorar! Legibilidade, código como leitura de um livro! Dave Thomas co-autor do The Pragmatic Programmer Grady Booch co-criador do UML Escrito por alguém que se importa! Cada rotina faz exatamente o que você espera que ela faça! Michael Feathers escritor e coach

6 Qualquer um consegue escrever código que um computador entende. Bons programadores escrevem código que humanos entendem. (Martin Fowler)

7 Por que é importante escrever bom código? Modelo mental (o problema) Modelo semântico (a solução!) Modelo sintático (o código)

8 Três meses depois

9 Meu código lindo!

10 Quem é o culpado?

11

12 Deixe uma única janela quebrada e

13 Regra do escoteiro "Deixe o campo mais limpo que quando você chegou."

14 Agenda Nomes Funções Comentários Formatação Classes Testes Automatizados

15 Nomes

16 Revelar intenção calcular(int d, int t) calcularvalordeatraso(int dias, int taxa)

17 Evitar desinformação List pagamentoslist = new ArrayList(); Algum tempo depois. Set pagamentoslist = new HashSet();

18 Fazer distinções significativas copy(a, b); copy(source, destination);

19 Evitar redundância Double variablevalorpagar; Double valorpagar; create table PessoasTable( ) create table Pessoas( )

20 Usar nomes: Pronunciáveis: Date genymdhms; Date generationtimestamp;

21 Usar nomes: Procuráveis: String a; int x; //números mágicos total = 7; MAX_FILES_PER_STUDENT = 7;

22 Evitar encoding Notação húngara nvalor; snome; acondicoes; Member prefixes m_valor; _valor;

23 Usar um termo por conceito getpessoas(); fetchpessoas(); retrievepessoas();

24 Classes e métodos Classes devem ser substantivos Pessoa Conta Pagamento Métodos devem ser verbos totalizar() excluir()

25 Parece simples, mas não deixe isso te enganar (Erico Rocha)

26 Funções

27 Regras do Clube das Funções: 1 - Devem ser pequenas! 2 - Devem ser menores!

28 Funções Fazer uma única coisa! DRY - Don't Repeat Yourself SRP - Single Responsibility Principle Número de linhas? Número de indentações?

29 Exemplos de funções pequenas Um nível de abstração por função!

30 Ler o código de cima para baixo Estruturar em níveis Código como uma narrativa Cada função é seguida pelas outras no próximo nível

31 Código como narrativa

32 Parâmetros O ideal é zero! Um é bom! Dois é tolerável! Três? Evitar! Parâmetros do tipo boolean: maybe not Output Parameter: just don't

33 Efeitos colaterais boolean login(string user, String password) { User user = UserRepository.findByName(user); if (user!= null && user.checkpassword(password)) { Session.initialize(); return true; } return false; }

34 Command Query Separation Função deve FAZER algo ou RETORNAR algo Use exceções ao invés de códigos de retorno Não retornar null Não passar null

35 Refinamento Primeira versão da função apenas faz o código funcionar Refinamentos para extrair métodos privados separando responsabilidades, renomear variáveis e métodos Por fim, temos funções curtas, bem nomeadas, organizadas e estruturadas

36 Comentários

37

38 Quando comentários são ruins? Quando são redundantes Quando estão desatualizados Quando são desnecessários, gerando sujeira e ruído no código

39

40 Quando compensam código ruim" // verifica se o funcionário tem direito // a todos benefícios if(employee.flags && HOURLY_FLAG) && (employee.age > 65) if(employee.iseligibleforfullbenefits())

41 Melhor refatorar // módulo da lista global depende // do subsistema do qual fazemos parte? if(module.getdependsystems().contains(subsysmod.getsubsystem())){} List dependees = module.getdependsystem(); String oursubsystem = subsysmod.getsubsystem(); if(dependees.contains(oursubsystem)){}

42 Quando comentários são benéficos Intenção ao invés de explicação Alerta sobre consequências TODO Destacar a importância de algo

43 Lembrem-se! Autor e data ficam no controle de versão Documentação somente em APIs públicas Código comentado é código morto!

44

45 Formatação

46 The Open Closed Principle - Uncle Bob 12 May 2014 Craftsmanship In 1988 Bertrand Meyer defined one of the most important principles of software engineering. The Open Closed Principle (OCP). In his book Object Oriented Software Construction[1] he said: A satisfactory modular decomposition technique must satisfy one more requirement: It should yield modules that are both open and closed. A module will be said to be open if it is available for extension. For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs. A module will be said to be closed if is available for use by other modules. This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding). In the case of a programming language module, a closed module is one that may be compiled and stored in a library, for others to use. In the case of a design or specification module, closing a module simply means having it approved by management, adding it to the project's official repository of accepted software items (often called the project baseline), and publishing its interface for the benefit of other module designers. This definition is obviously dated. Nowadays many languages don't require that modules be compiled. And getting module specifications approved by management smacks of a waterfall mentality. Still, the essence of a great principle still shines through those old words. To wit: You should be able to extend the behavior of a system without having to modify that system.

47

48 Metáfora do jornal Lido verticalmente Manchete no topo Sinopse Detalhes

49 Ordenação vertical (de cima para baixo) Espaçamento vertical (parágrafos) Continuidade vertical (associação íntima) Distância vertical (não separar conceitos)

50 Formatação

51 Padrões internos Padrões da equipe Recursos da IDE Respeito!

52 Classes

53 SOLID Single Responsibility Principle (SRP) Open Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP)

54 Classes Devem ser pequenas! Responsabilidade única

55 Acoplamento "É o grau em que um módulo depende de outro módulo de programação.

56 Coesão "É a medida da força relativa de um módulo"

57 Regras do Clube das Classes: 1. Devem ter baixo acoplamento 2. Devem ter alta coesão

58 Te s te s

59 Três leis 1. Não se deve escrever testes de produção até ter um teste falhando; 2. Não se deve escrever mais que o suficiente para falhar o teste 3. Não se deve escrever mais código de produção que o suficiente para o teste passar

60 Manter os códigos dos testes limpos (padrão construir-operar-verificar) Minimizar o numero de asserts por teste (não necessariamente apenas um) Testar um único conceito por teste

61 Formas de medir a qualidade Testes automatizados Peer review Avaliadores estáticos de código FindBugs, CheckStyle, PMD CodeClimate, RubyCritic

62

63 Reconhecer bom código de mau código não significa que você saiba fazer bom código. (Uncle Bob)

64 Leituras complementares

65 Fontes e referências

66

67

68