Palestra sobre Clean Code ministrada na Benner em Outubro de 2018. Baseada no livro Clean Code do Uncle Bob (Robert Cecil Martin).
Código fonte em: https://github.com/paulohs/CleanCodeSample/
A palestra irá falar sobre arquitetura de software o do profissional responsável por ela, o arquiteto de software. Muito se discute sobre esse papel, quais as suas atribuições e o que ele realmente faz. O objetivo desta palestra é desmistificar alguns dos conceitos sobre essa questão, falar sobre a carreira do arquiteto de software, como se tornar um, como lidar com novas tecnologias e um guia rápido de estudos.
É notável a quantidade de aplicações em PHP que ainda utilizam nosso velho e conhecido modo Macarrônico de programar: dezenas de snippets e blocos de código que trabalham com regras de negócio, apresentação e tudo mais espalhados por N lugares na aplicação. A solução mais sustentável para esse tipo de situação seja provavelmente a adoção de um framework, mas existe uma resistência muito grande que é completamente justificável: voltamos àquelas perguntas relativas à “para que mexer num time que está ganhando?“. Vamos trabalhar um pouco essa idéia mostrando exemplos e confrontando situações reais.
Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014Gilmar PSL
O Projeto (Design) de APIs é algo que todo programador deveria saber, afinal de contas, inevitavelmente todos escrevem programas que se comunicam com outros programas, sejam seus próprios programas ou de terceiros. Muitas vezes, integrar seu código ao de uma API pode ser algo terrível e complicado ou uma experiência simples prazerosa. Mas o que faz uma API ser simples e fácil de usar? O que de fato é uma API e quando devemos criar uma? Como desenvolvemos uma API? Basta usar Padrões de Projeto, DDD, TDD, etc? Esperamos responder essas e outras questões sobre o projeto de API e apresentar exemplos relacionados a um projeto open source real, como o JRimum.
A palestra irá falar sobre arquitetura de software o do profissional responsável por ela, o arquiteto de software. Muito se discute sobre esse papel, quais as suas atribuições e o que ele realmente faz. O objetivo desta palestra é desmistificar alguns dos conceitos sobre essa questão, falar sobre a carreira do arquiteto de software, como se tornar um, como lidar com novas tecnologias e um guia rápido de estudos.
É notável a quantidade de aplicações em PHP que ainda utilizam nosso velho e conhecido modo Macarrônico de programar: dezenas de snippets e blocos de código que trabalham com regras de negócio, apresentação e tudo mais espalhados por N lugares na aplicação. A solução mais sustentável para esse tipo de situação seja provavelmente a adoção de um framework, mas existe uma resistência muito grande que é completamente justificável: voltamos àquelas perguntas relativas à “para que mexer num time que está ganhando?“. Vamos trabalhar um pouco essa idéia mostrando exemplos e confrontando situações reais.
Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014Gilmar PSL
O Projeto (Design) de APIs é algo que todo programador deveria saber, afinal de contas, inevitavelmente todos escrevem programas que se comunicam com outros programas, sejam seus próprios programas ou de terceiros. Muitas vezes, integrar seu código ao de uma API pode ser algo terrível e complicado ou uma experiência simples prazerosa. Mas o que faz uma API ser simples e fácil de usar? O que de fato é uma API e quando devemos criar uma? Como desenvolvemos uma API? Basta usar Padrões de Projeto, DDD, TDD, etc? Esperamos responder essas e outras questões sobre o projeto de API e apresentar exemplos relacionados a um projeto open source real, como o JRimum.
Apresentação sobre temas abordado no livro Clean Code de Robert C. Martim.
Os benefícios sobre manter seu código limpo. Quais prejuízos um código sujo pode trazer para sua empresa.
Como se expressar no seu código dispensando o uso de inúmeros comentários que poluem o código.
O Projeto (Design) de APIs é algo que todo programador deveria saber.
Afinal de contas, inevitavelmente todos escrevem programas que se comunicam com outros programas, sejam seus próprios programas ou de terceiros. Muitas vezes, integrar seu código ao de uma API pode ser algo terrível e complicado. Outras, uma experiência simples e prazerosa. Mas o que faz uma API ser simples e fácil de usar? O que de fato é uma API e quando devemos criar uma? Como desenvolvemos uma API? Basta usar Padrões de Projeto, DDD, TDD, etc?
Nesta palestra, esperamos responder essas e outras questões sobre o projeto de API e apresentar exemplos relacionados a um projeto open source real, como o JRimum.
Apresentação do Coderage Brasil 2018 sobre TDD com Código Legado com Delphi usando Spring.Testing e TestInsight.
Dicas de Refactory, como identificar Code Smell e Antipatterns e Hands on do refactory do exemplo GettingStarted do FireDAC.
"Apresentação atualizada, pois o SlideShare não permite re-upload."
Vídeo da primeira parte - Apresentação
https://youtu.be/ZWQO0bLB8gU
Apresentação do Coderage Brasil 2018 sobre TDD com Código Legado com Delphi usando Spring.Testing e TestInsight.
Dicas de Refactory, como identificar Code Smell e Antipatterns e Hands on do refactory do exemplo GettingStarted do FireDAC
Clean Code: Por um mundo com códigos melhores - The Developers Conference - P...Thiago Barradas
Palestra apresentado no TDC (The Developers Conference) de Porto Alegre de 2017, um evento que aborda diversas tecnologias. A palestra foi uma apresentação sobre código limpo, como melhorar e manter o padrão do seu código e com isso fazer do mundo um lugar melhor, com códigos melhores.
Clean Code: Por um mundo com códigos melhores - SETI 2017Thiago Barradas
Palestra apresentado no SETI - UFLA (Lavras MG) de 2017, um evento que aborda diversas tecnologias. A palestra foi uma apresentação sobre código limpo, como melhorar e manter o padrão do seu código e com isso fazer do mundo um lugar melhor, com códigos melhores.
Mesmo um código ruim pode funcionar. Mas se ele não for limpo, pode acabar com uma empresa de desenvolvimento. Perdem-se a cada ano horas incontáveis e recursos importantes devido a um código mal escrito. Mas não precisa ser assim.
O renomado especialista em software, Robert C. Martin, apresenta um paradigma revolucionário com Código limpo: Habilidades Práticas do Agile Software. Martin se reuniou com seus colegas do Mentor Object para destilar suas melhores e mais ágeis práticas de limpar códigos “dinamicamente”. Este webcast apresentará gradualmente os valores da habilidade de um profissional de softwares e lhe tornar um programador melhor – mas só se você praticar.
Arquitetura em camadas em python e quanto isso pode ajudarBetter Developer
Venha ver como conceitos de arquitetura de software e padrões de projeto também podem ser aplicados quando desenvolvemos em Python. Veremos exemplos práticos de como isso traz maturidade ao projeto e o quanto ajuda na manutenção e evolução do mesmo. Por fim será mostrado case de como isso é importante no desenvolvimento de soluções para área financeira na empresa Nexxera.
Apresentação sobre temas abordado no livro Clean Code de Robert C. Martim.
Os benefícios sobre manter seu código limpo. Quais prejuízos um código sujo pode trazer para sua empresa.
Como se expressar no seu código dispensando o uso de inúmeros comentários que poluem o código.
O Projeto (Design) de APIs é algo que todo programador deveria saber.
Afinal de contas, inevitavelmente todos escrevem programas que se comunicam com outros programas, sejam seus próprios programas ou de terceiros. Muitas vezes, integrar seu código ao de uma API pode ser algo terrível e complicado. Outras, uma experiência simples e prazerosa. Mas o que faz uma API ser simples e fácil de usar? O que de fato é uma API e quando devemos criar uma? Como desenvolvemos uma API? Basta usar Padrões de Projeto, DDD, TDD, etc?
Nesta palestra, esperamos responder essas e outras questões sobre o projeto de API e apresentar exemplos relacionados a um projeto open source real, como o JRimum.
Apresentação do Coderage Brasil 2018 sobre TDD com Código Legado com Delphi usando Spring.Testing e TestInsight.
Dicas de Refactory, como identificar Code Smell e Antipatterns e Hands on do refactory do exemplo GettingStarted do FireDAC.
"Apresentação atualizada, pois o SlideShare não permite re-upload."
Vídeo da primeira parte - Apresentação
https://youtu.be/ZWQO0bLB8gU
Apresentação do Coderage Brasil 2018 sobre TDD com Código Legado com Delphi usando Spring.Testing e TestInsight.
Dicas de Refactory, como identificar Code Smell e Antipatterns e Hands on do refactory do exemplo GettingStarted do FireDAC
Clean Code: Por um mundo com códigos melhores - The Developers Conference - P...Thiago Barradas
Palestra apresentado no TDC (The Developers Conference) de Porto Alegre de 2017, um evento que aborda diversas tecnologias. A palestra foi uma apresentação sobre código limpo, como melhorar e manter o padrão do seu código e com isso fazer do mundo um lugar melhor, com códigos melhores.
Clean Code: Por um mundo com códigos melhores - SETI 2017Thiago Barradas
Palestra apresentado no SETI - UFLA (Lavras MG) de 2017, um evento que aborda diversas tecnologias. A palestra foi uma apresentação sobre código limpo, como melhorar e manter o padrão do seu código e com isso fazer do mundo um lugar melhor, com códigos melhores.
Mesmo um código ruim pode funcionar. Mas se ele não for limpo, pode acabar com uma empresa de desenvolvimento. Perdem-se a cada ano horas incontáveis e recursos importantes devido a um código mal escrito. Mas não precisa ser assim.
O renomado especialista em software, Robert C. Martin, apresenta um paradigma revolucionário com Código limpo: Habilidades Práticas do Agile Software. Martin se reuniou com seus colegas do Mentor Object para destilar suas melhores e mais ágeis práticas de limpar códigos “dinamicamente”. Este webcast apresentará gradualmente os valores da habilidade de um profissional de softwares e lhe tornar um programador melhor – mas só se você praticar.
Arquitetura em camadas em python e quanto isso pode ajudarBetter Developer
Venha ver como conceitos de arquitetura de software e padrões de projeto também podem ser aplicados quando desenvolvemos em Python. Veremos exemplos práticos de como isso traz maturidade ao projeto e o quanto ajuda na manutenção e evolução do mesmo. Por fim será mostrado case de como isso é importante no desenvolvimento de soluções para área financeira na empresa Nexxera.
2. Paulo Henrique da Silva
• Benner Tecnologia
• Desenvolvedor há mais de 20 anos
• Graduação em Ciências da
computação
• Pós em Desenvolvimento de
aplicações Web
• Hobbies: Astronomia/Fotografia
28. • Nomes com propósito
• Escolher bons nomes leva tempo, mas economiza mais
• Cuide dos seus nomes
• Troque-os quando achar melhores
• Todos que lerem seu código ficarão agradecidos
• Nomes pronunciáveis
• Evite informações erradas
• Prefixos de tipo
• Classes devem ser substantivos (Cliente, Conta, Pagina). Evite palavras
como Manager, Data, Info (que também não deve ser verbo)
• Classes com mais construtores, devem utilizar factories.
33. • Funções!
• Devem ser pequenas!
• Deve fazer apenas uma coisa e fazê-la bem
• Respeite o nível de abstração
• Mínimo possível de parâmetros, máximo 3.
• Um parâmetro booleano, cheiro ruim.
• Se precisa passar muita coisa, pense em passar um objeto (não é trapaca)
• Evite efeitos colaterais.
• Funções devem alterar o estado dos objetos que elas pertencem, não o
estado de outros objetos
• Evite repetição: DRY. A duplicação é a raiz de todo mal!
34.
35. • Comentários no código
Não utilize!
Comentários são, no máximo, um mal necessário.
Exceto: Copyright, Docs de API, etc
36. • Formatação
• Ferramentas com o Visual Studio já forcam a formatação correta.
• Mas se você estiver utilizando uma ferramenta que não força, não quer
dizer que não é para formatar.
• Evite linhas muito longas
• Tenha regras de equipe.
• Utilize espaçamento vertical
37. • Objetos
• Saiba diferenciar estruturas de dados de objetos.
• Estruturas de dados são representadas por classes que
expõem os dados, sem funções significativas.
• Objetos são classes que escondem as informações internas e
expõem operações que operam em tais dados
• Evite classes que são objetos e estruturas de dados ao mesmo
tempo!
38. • Classes
• Devem ser pequenas!
• Devem ter uma única responsabilidade.
• Poucas variáveis de instância. Alta coesão: Os métodos da classe
devem manipular tentar manipular todas as variáveis da classe.
• Quando isso não acontece normalmente tem uma outra classe
querendo surgir.
• Adote o S.O.L.I.D.
39.
40. • Testes de unidade
• Código limpo deve estar coberto por testes!
• O teste também deve ser limpo, pois ele é a documentação do seu código.
• Manutenção de código, vai eventualmente exigir mudança nos testes.
• F.I.R.S.T.:
• Fast
• Idenpendent
• Repeatable
• Self-Validating
• Timely
41. • Tratamento de erro
• Evite códigos de erro
• Utilize exceções, elas deixam o código limpo e legível.
45. • Sistemas
• Injeção de dependência
• Desenvolvimento gradual – deve funcionar desde o início (evolução de
uma cidade)
• Cross-cutting concenrs
• Cache
• Persistência
• Logs
• Transação
• Segurança
• Regras de negócio
• Linguagens de domínio
• Otimização de decisões
46.
47.
48.
49. • Concorrência
• Cuidado com os mitos:
• Sempre melhora o desempenho
• Projeto não muda ao utilizar threads
• Não precisamos nos preocupar com concorrência em containers Web (IIS)
• Concorrência correta é complexa!
• Bugs de concorrência, não se repetem facilmente
• Se precisar utilizer, aqui vão algumas dicas:
• Responsabilidade única
• Limite o escopo dos dados
• Utilize cópia dos dados
• Threads independentes
• Conheça sua biblioteca.
• Seções críticas pequenas
58. Liskov
substitution
"objects in a program
should be replaceable
with instances of their
subtypes without
altering the correctness
of that program."
Há duas vertentes para ter habilidade profissional: Conhecimento e trabalho!
Não há como ser profissional sem as duas.
Programar com código limpo, não é diferente...
Alguns alegam que o fim do código está próximo; que logo todo código será gerado e não mais escrito; e não precisaram mais de programadores, pois as pessoas criarão programas a partir de especificações.
Bobagem. O código representa os detalhes dos requisitos. Não há como ignorar os detalhes. Eles precisam ser especificados. E especificar detalhadamente os requisitos de modo que uma máquina possa executá-los é programar e tal especificação é o código!
Na verdade só aumenta...
Como patrimônio, precisa de cuidados.
Pessoas já perderam seu emprego por conta de código ruim. Produtos já deixaram de existir por conta de código ruim. Empresas faliram por conta de código ruim.
As vezes por conta da pressão, do prazo, acabamos criando código ruim. Estamos cansados de trabalhar num problema. Deixamos para refatorar algo depois. Nosso gerente nos pressiona, as vezes temos medo de ser demitidos e deixamos as coisas pela metade.
O gerente quer um código bom. Ele vai cobrar o prazo, pois é o trabalho dele. Nós como programadores profissionais temos que proteger o código com a mesma paixão.
Se você fosse um médico, e seu cliente exigisse que você se apressasse, que parasse com a higienização das mãos pois demora demais. Você, como médico profissional, o que faria?
Nós programadores sempre temos um dilema: Sabemos que bagunça no código atrapalha. Mas por causa da pressão nos sentimos forçados a cometer essa bagunças.
Mas profissionais sérios sabe que a desorganização do código vai reduzir a velocidade do seu trabalho e você perderá o prazo. A única maneira de ir mais rápido, é manter o código organizado e legível.
Há brigas por linguagens em todo o lugar. Mas essa afirmação coloca a responsabilidade nas nossas costas. Não é a linguagem que faz os programas parecerem simples. É o programador!