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.
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.
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.
é 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:
é 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.
é 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.
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
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.
"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.
"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.
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
disco, alocação de blocos; ๏ Gerenciamento de diretórios, procura pelo path; ๏ Gerenciamento de permissões; ๏ Agendamento de disco; ๏ Cache de leitura de blocos;
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;
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.
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)
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
eminetto
colopl
mihyon
satotakeshi
kazamori
miu_crescent
line_developers
kyonmm
kargo113
alvarosanchez
yummydum
moritamasami
cybozuinsideout
moore
robhawkes
jacobian
danielanewman
productmarketing
bkeepers
deanohume
shlominoach
rmw
bryan
shpigford
chriscoyier
