Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Reflexões sobre Design de Software

Reflexões sobre Design de Software

Nesta palestra falo sobre complexidade de software, como ela gera problemas para o desenvolvimento de software e dicas de como minimizá-la.

0227f6274b8a6cce078d7f8a91460c41?s=128

Elton Minetto

June 20, 2022
Tweet

More Decks by Elton Minetto

Other Decks in Technology

Transcript

  1. Reflexões sobre Design de Software

  2. Elton Minetto

  3. Elton Minetto ๏ Escrevo códigos, sou professor, palestrante, e escritor

  4. Elton Minetto ๏ Escrevo códigos, sou professor, palestrante, e escritor

    ๏ Escrevo no https://eltonminetto.dev e no twitter
  5. Elton Minetto ๏ Escrevo códigos, sou professor, palestrante, e escritor

    ๏ Escrevo no https://eltonminetto.dev e no twitter ๏ Principal Software Engineer @ PicPay
  6. Inspirações A Philosophy of Software Design por John Ousterhout

  7. Inspirações A Philosophy of Software Design | John Ousterhout |

    Talks at Google
  8. Complexidade

  9. “Complexidade é qualquer coisa relacionada à estrutura de um sistema

    de software que torna difícil entendê-lo e modificá-lo” -- John Ousterhout, tradução minha ;)
  10. A complexidade normalmente se manifesta em um projeto de software

    de três maneiras principais ordenadas em termos de gravidade crescente:
  11. A complexidade normalmente se manifesta em um projeto de software

    de três maneiras principais ordenadas em termos de gravidade crescente: ๏ Amplificação de mudança (Change amplification): Quando uma simples mudança requer a modificação do código em muitos lugares.
  12. A complexidade normalmente se manifesta em um projeto de software

    de três maneiras principais ordenadas em termos de gravidade crescente: ๏ Amplificação de mudança (Change amplification): Quando uma simples mudança requer a modificação do código em muitos lugares. ๏ Carga cognitiva (Cognitive load): Quando desenvolvedores precisam carregar muitas informações em suas cabeças para concluir uma tarefa. Isso aumenta as chances de que eles possam perder alguma coisa, levando a bugs.
  13. A complexidade normalmente se manifesta em um projeto de software

    de três maneiras principais ordenadas em termos de gravidade crescente: ๏ Amplificação de mudança (Change amplification): Quando uma simples mudança requer a modificação do código em muitos lugares. ๏ Carga cognitiva (Cognitive load): Quando desenvolvedores precisam carregar muitas informações em suas cabeças para concluir uma tarefa. Isso aumenta as chances de que eles possam perder alguma coisa, levando a bugs. ๏ Desconhecidos desconhecidos (Unknown unknowns): Quando não é óbvio quais informações ou mudanças são necessárias para realizar uma tarefa.
  14. Como os sistemas de software se tornam complicados? A complexidade

    é incremental. Geralmente não é uma coisa que torna um sistema complicado, mas um acúmulo de más decisões ao longo de um período de tempo. O autor dá duas razões principais pelas quais os projetos de software se tornam complexos:
  15. Como os sistemas de software se tornam complicados? A complexidade

    é incremental. Geralmente não é uma coisa que torna um sistema complicado, mas um acúmulo de más decisões ao longo de um período de tempo. O autor dá duas razões principais pelas quais os projetos de software se tornam complexos: ๏ Dependências — Uma dependência entre duas ou mais partes de um sistema só é desejável se a dependência for clara e óbvia. Quando não está claro qual código depende de outro, mesmo mudanças simples no sistema levarão muito tempo e existe um alto risco de bugs aparecerem em produção.
  16. Como os sistemas de software se tornam complicados? A complexidade

    é incremental. Geralmente não é uma coisa que torna um sistema complicado, mas um acúmulo de más decisões ao longo de um período de tempo. O autor dá duas razões principais pelas quais os projetos de software se tornam complexos: ๏ Dependências — Uma dependência entre duas ou mais partes de um sistema só é desejável se a dependência for clara e óbvia . Quando não está claro qual código depende de outro, mesmo mudanças simples no sistema levarão muito tempo e existe um alto risco de bugs aparecerem em produção. ๏ Obscuridade — Isso ocorre quando algumas informações importantes sobre o sistema não são óbvias . Por exemplo, quando não está claro em que ordem executar um conjunto de métodos para realizar uma operação. Se o código não for óbvio, o leitor deve gastar muito tempo e energia para tentar entendê-lo, e a probabilidade de mal-entendido é alta.
  17. Como minimizar a complexidade?

  18. None
  19. ๏ Cultivando um bom "mindset"

  20. ๏ Cultivando um bom "mindset" ๏ Escrevendo bons módulos

  21. Cultivando um bom "mindset"

  22. Programação tática

  23. Programação tática ๏ Colocar a feature ou correção em produção

    o mais rápido possivel
  24. Programação tática ๏ Colocar a feature ou correção em produção

    o mais rápido possivel ๏ Pegar atalhos, não escrever testes, não refatorar código para melhorar o design e dificilmente pensar em design
  25. Programação tática ๏ Colocar a feature ou correção em produção

    o mais rápido possivel ๏ Pegar atalhos, não escrever testes, não refatorar código para melhorar o design e dificilmente pensar em design ๏ Resultados: aumento da complexidade, péssimo design
  26. Programação estratégica

  27. Programação estratégica ๏ Código funcionando não é o suficiente

  28. Programação estratégica ๏ Código funcionando não é o su fi

    ciente ๏ Objetivo: produzir um bom design de software, minimizar a complexidade, evitar débitos técnicos.
  29. Programação estratégica ๏ Código funcionando não é o su fi

    ciente ๏ Objetivo: produzir um bom design de software, minimizar a complexidade, evitar débitos técnicos. ๏ Mais lento no curto prazo, mas ganha-se velocidade com o tempo, e evita grandes refatorações futuras.
  30. Quanto investir?

  31. Quanto investir? ๏ Faça continuamente pequenos investimentos

  32. Quanto investir? ๏ Faça continuamente pequenos investimentos ๏ Quando escrevendo

    novos códigos: faça o design com cuidado, invista em documentação.
  33. Quanto investir? ๏ Faça continuamente pequenos investimentos ๏ Quando escrevendo

    novos códigos: faça o design com cuidado, invista em documentação. ๏ Quando alterando código existente: tente sempre encontrar algo a melhorar.
  34. Escrevendo bons módulos

  35. Módulo?

  36. Módulo? ๏ De acordo com o livro, um módulo é

    "uma unidade de código relativamente independente com uma interface e uma implementação". Pode assumir muitas formas, como uma função, classe, pacote ou serviço.
  37. Módulo? ๏ De acordo com o livro, um módulo é

    "uma unidade de código relativamente independente com uma interface e uma implementação". Pode assumir muitas formas, como uma função, classe, pacote ou serviço. ๏ Interface é tudo que a pessoa precisa para interagir com o código. Não só a assinatura dos métodos, mas também seus efeitos colaterais. É o custo de complexidade que este código impõe ao resto do sistema, por isso deveria ser o menor possível.
  38. Como escrever bons módulos?

  39. Como escrever bons módulos? ๏ Forneça bons "defaults"

  40. Como escrever bons módulos? ๏ Forneça bons "defaults" ๏ Esconda

    informações que não são importantes
  41. Como escrever bons módulos? ๏ Forneça bons "defaults" ๏ Esconda

    informações que não são importantes ๏ Elimine erros desnecessários
  42. Como escrever bons módulos? ๏ Forneça bons "defaults" ๏ Esconda

    informações que não são importantes ๏ Elimine erros desnecessários ๏ Escreva boa documentação
  43. Como escrever bons módulos? ๏ Forneça bons "defaults" ๏ Esconda

    informações que não são importantes ๏ Elimine erros desnecessários ๏ Escreva boa documentação ๏ Escolha bons nomes
  44. Como escrever bons módulos? ๏ Forneça bons "defaults" ๏ Esconda

    informações que não são importantes ๏ Elimine erros desnecessários ๏ Escreva boa documentação ๏ Escolha bons nomes ๏ Dê preferência a módulos profundos ao invés de rasos
  45. Módulos profundos vs módulos rasos

  46. None
  47. None
  48. ๏ Módulos profundos são aqueles que fornecem interfaces simples para

    funcionalidades complexas,
  49. ๏ Módulos profundos são aqueles que fornecem interfaces simples para

    funcionalidades complexas, ๏ Módulos rasos são aqueles que possuem uma interface complicada sem esconder muita complexidade.
  50. Módulo raso FileInputStream fileStream = new FileInputStream(fileName); BufferedInputStream bufferedStream =

    new BufferedInputStream(fileStream); ObjectInputStream objectStream = new ObjectInputStream(bufferedStream);
  51. Módulo profundo Unix fi le I/O: int open(const char* path,

    int flags, mode_t permissions); int close(int fd); ssize_t read(int fd, void* buffer, size_t count); ssize_t write(int fd, const void* buffer, size_t count); off_t lseek(int fd, off_t offset, int referencePosition);
  52. Módulo profundo Escondido atrás desta interface temos:

  53. Módulo profundo Escondido atrás desta interface temos: ๏ Localização no

    disco, alocação de blocos;
  54. Módulo profundo Escondido atrás desta interface temos: ๏ Localização no

    disco, alocação de blocos; ๏ Gerenciamento de diretórios, procura pelo path;
  55. Módulo profundo Escondido atrás desta interface temos: ๏ Localização no

    disco, alocação de blocos; ๏ Gerenciamento de diretórios, procura pelo path; ๏ Gerenciamento de permissões;
  56. Módulo profundo Escondido atrás desta interface temos: ๏ Localização no

    disco, alocação de blocos; ๏ Gerenciamento de diretórios, procura pelo path; ๏ Gerenciamento de permissões; ๏ Agendamento de disco;
  57. Módulo profundo Escondido atrás desta interface temos: ๏ Localização no

    disco, alocação de blocos; ๏ Gerenciamento de diretórios, procura pelo path; ๏ Gerenciamento de permissões; ๏ Agendamento de disco; ๏ Cache de leitura de blocos;
  58. Módulo profundo Escondido atrás desta interface temos: ๏ Localização no

    disco, alocação de blocos; ๏ Gerenciamento de diretórios, procura pelo path; ๏ Gerenciamento de permissões; ๏ Agendamento de disco; ๏ Cache de leitura de blocos; ๏ Independência de dispositivos;
  59. Módulo profundo Escondido atrás desta interface temos: ๏ Localização no

    disco, alocação de blocos; ๏ Gerenciamento de diretórios, procura pelo path; ๏ Gerenciamento de permissões; ๏ Agendamento de disco; ๏ Cache de leitura de blocos; ๏ Independência de dispositivos; ๏ etc.
  60. Bônus

  61. Escreva, compartilhe e discuta com seus pares sobre design de

    software
  62. Referências

  63. Referências ๏ A Philosophy of Software Design

  64. Referências ๏ A Philosophy of Software Design ๏ A Philosophy

    of Software Design | John Ousterhout | Talks at Google
  65. Referências ๏ A Philosophy of Software Design ๏ A Philosophy

    of Software Design | John Ousterhout | Talks at Google ๏ Book Summary: A Philosophy of Software Design
  66. Referências ๏ A Philosophy of Software Design ๏ A Philosophy

    of Software Design | John Ousterhout | Talks at Google ๏ Book Summary: A Philosophy of Software Design ๏ A Philosophy of Software Design: My Take (and a Book Review)
  67. Referências ๏ A Philosophy of Software Design ๏ A Philosophy

    of Software Design | John Ousterhout | Talks at Google ๏ Book Summary: A Philosophy of Software Design ๏ A Philosophy of Software Design: My Take (and a Book Review) ๏ Book Review: “A Philosophy of Software Design” by John Ousterhout
  68. Perguntas https://eltonminetto.dev https://twitter.com/eminetto elton@minetto.dev