Debating maintainability and design

Nível: C1

Objetivo

Debater maintainability e design em C1 com vocabulário de readability, cohesion, coupling, abstraction, naming, testability e extensibility. O foco é discutir trade-offs de design com a audiência sênior sem cair em preferências pessoais.

Explicação

Maintainability e design em C1 são debatidos com vocabulário técnico, não com preferências. Sete eixos:

1. Readability

Quão fácil é ler o código. C1 evita 'isso é feio' e usa 'isso é difícil de seguir porque X'. `This function is hard to follow because the conditional nesting is 5 levels deep.` Readability é objetivo, não gosto.

2. Cohesion

Quanto o código tem responsabilidade única. C1 cita: 'this class has 7 unrelated methods' ou 'this module mixes validation and persistence'. Cohesion alta é o ideal.

3. Coupling

Quanto o código depende de outros módulos. C1 cita: 'changing the user schema requires changing 5 modules' (alto coupling) ou 'changing the user schema only requires changing the user module' (baixo coupling).

4. Abstraction

O nível de indireção. C1 evita 'isso é overengineering' sem critério; usa 'this abstraction adds 3 layers without simplifying the call site'. Abstração sem ganho é ruído.

5. Naming

Os nomes carregam significado. C1 evita 'esse nome é ruim' e usa 'this name does not reveal intent; what does `process` actually do?' Nome sem intent é nome ruim.

6. Testability

Quão fácil é testar. C1 cita: 'this function depends on the current time, which makes it hard to test in isolation'. Testability é consequência do design, não feature adicionada depois.

7. Extensibility

Quão fácil é estender. C1 evita 'vamos adicionar mais um if' e usa 'this design forces every new case to modify the central function, which violates open-closed'. Extensibilidade é sobre a próxima mudança, não a atual.

Exemplos

Erros comuns

• Debater com preferência: 'isso é feio' é opinião; 'isso tem 5 níveis de aninhamento' é fato.
• Citar princípio sem explicar: 'SRP!' sem mostrar o que está misturado não convence.
• Pedir refactor sem alternativa: 'isso está errado' não ensina; 'SRP sugere separar X de Y' ensina.
• Misturar readability com performance: readability não é performance; são eixos diferentes.
• Citar 'overengineering' sem critério: abstração é overengineering quando não simplifica o call site.

Prática guiada

Reescreva cada crítica abaixo no padrão C1 de debate de design.

1. Readability: cite o critério objetivo (aninhamento, complexidade ciclomática).
2. Cohesion: cite o número de responsabilidades e o princípio (SRP).
3. Coupling: cite o número de módulos afetados.
4. Abstraction: cite o ganho vs custo; 'simplifica o call site?'.
5. Naming: pergunte 'o que isso realmente faz?' em vez de afirmar.
6. Testability: cite a dependência que complica o teste.
7. Extensibility: cite a próxima mudança e se o design a comporta.

Resumo

Debate de design C1 usa sete eixos: readability (critério objetivo), cohesion (SRP), coupling (módulos afetados), abstraction (ganho vs custo), naming (intent), testability (dependências), extensibility (próxima mudança). Cada eixo tem vocabulário e critério; sem eles, o debate vira preferência pessoal.

História: Debating maintainability and design

Nível: C1

História em inglês

Debating the user service refactor

On Thursday, I had to debate a refactor proposal for the user service in the design review. I opened with cohesion: this class has 7 unrelated methods; SRP suggests splitting by responsibility. I added coupling: changing the user schema requires changing 5 modules; this is high coupling. I questioned the abstraction: this abstraction adds 3 layers without simplifying the call site; KISS would suggest removing it. I closed with a recommendation: extract the validation into a helper, keep the abstraction, and split the class in two.

Tradução linha por linha

Notas de vocabulário

• this class has 7 unrelated methods; SRP suggests splitting = cohesion com princípio e número.
• changing the user schema requires changing 5 modules = coupling com número de módulos.
• this abstraction adds 3 layers without simplifying the call site = abstraction com critério de ganho.
• extract the validation into a helper, keep the abstraction, split the class = recomendação C1: ação específica por eixo.

Perguntas de compreensão

1. O que torna um debate de design C1 útil?
2. O que diferencia readability de performance?
3. Quando uma abstração é overengineering em C1?

Prática com a história

1. Reescreva 'isso é feio' como crítica de readability C1.
2. Reescreva 'isso é overengineering' como crítica de abstraction C1.
3. Reescreva 'isso está acoplado' como crítica de coupling C1.