[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":85,"_72":86,"_35":87},"articles",{"_11":12,"_13":14,"_15":16,"_17":16,"_18":19,"_20":21,"_22":23,"_24":23,"_25":16,"_26":27},"content",[30],"pageable",{"_28":21,"_29":19},"totalElements",1,"totalPages","size",10,"number",0,"first",true,"last","numberOfElements","empty",false,"page_number","page_size",{"_31":32,"_33":34,"_35":36,"_37":38,"_11":39,"_40":-5,"_41":23,"_42":27,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":52,"_54":55,"_56":57,"_58":59,"_60":52,"_61":16,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71},"id",6,"title","Code Quality Metrics","slug","clean-code-part-5-metrics","excerpt","Framework for measuring code complexity, coupling, cohesion, and coverage using SonarQube and JaCoCo. Set quality gates and interpret trend data.","# Advanced Clean Code Patterns Part 5: Code Quality Metrics Framework\n\n\"You can't improve what you don't measure.\" Metrics transform subjective code quality discussions into objective data. This article covers the essential metrics for measuring complexity, coupling, cohesion, and coverage - along with practical guidance on setting targets and tracking trends.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| Metric Categories | Complexity, Coupling, Cohesion, Coverage |\n| Key Tools | SonarQube, JaCoCo, PIT, SpotBugs |\n| Primary Insight | Trends matter more than absolutes |\n| Setup Time | 2-4 hours for full pipeline |\n| Business Impact | 40% reduction in escaped defects |\n\n---\n\n## 🎯 What You'll Learn\n\nAfter reading this article, you will be able to:\n\n- **Calculate cyclomatic and cognitive complexity** and understand their thresholds\n- **Measure coupling** with afferent/efferent metrics\n- **Evaluate cohesion** using LCOM variants\n- **Set up coverage metrics** including mutation testing\n- **Configure SonarQube** quality gates for your team\n- **Interpret trends** and take action on degrading metrics\n\n---\n\n## 🔥 Production Story: The Quality Gate That Saved Black Friday\n\nAn e-commerce company had a tradition: disable all quality checks before major sales events because \"we need to ship fast.\"\n\nTwo days before Black Friday 2022, a developer pushed a change that passed unit tests but had cyclomatic complexity of 47 (threshold: 10). The code looked like this:\n\n```java\npublic void processOrder(Order order) {\n if (order.getType() == OrderType.STANDARD) {\n if (order.getTotal().compareTo(FREE_SHIPPING_THRESHOLD) > 0) {\n if (order.getShippingAddress().getCountry().equals(\"US\")) {\n // ... nested 5 levels deep\n }\n }\n } else if (order.getType() == OrderType.EXPRESS) {\n // ... similar nesting\n }\n // ... 300 more lines\n}\n```\n\nOn Black Friday, traffic spiked. A rare code path was triggered. The method threw NullPointerException. Orders failed. 23 minutes of downtime during peak traffic.\n\n**Cost:** $2.1M in lost sales, customer trust damaged.\n\n**The fix:** They implemented mandatory quality gates:\n- Complexity > 15: Block merge\n- Coverage < 80% for changed lines: Block merge\n- No new critical/blocker issues: Block merge\n\nNext year, same traffic spike, zero incidents. The quality gate caught 47 potentially problematic changes in the weeks leading up to Black Friday.\n\n---\n\n## 🧠 Mental Model: The Quality Metrics Dashboard\n\n```text\n┌─────────────────────────────────────────────────────────────────┐\n│ CODE QUALITY DASHBOARD │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ 📊 COMPLEXITY (How hard to understand?) │\n│ ┌──────────────────────────────────────────────────────────┐ │\n│ │ Cyclomatic Complexity [████████░░] 8/10 ✓ Good │ │\n│ │ Cognitive Complexity [██████░░░░] 12/15 ✓ OK │ │\n│ │ NPath Complexity [█████░░░░░] 200/500 ✓ Good │ │\n│ └──────────────────────────────────────────────────────────┘ │\n│ │\n│ 🔗 COUPLING (How connected to other modules?) │\n│ ┌──────────────────────────────────────────────────────────┐ │\n│ │ Afferent Coupling (Ca) 12 incoming dependencies │ │\n│ │ Efferent Coupling (Ce) 5 outgoing dependencies │ │\n│ │ Instability (I) 0.29 (stable) │ │\n│ └──────────────────────────────────────────────────────────┘ │\n│ │\n│ 🎯 COHESION (How focused is each class?) │\n│ ┌──────────────────────────────────────────────────────────┐ │\n│ │ LCOM4 [████████░░] 1.2 ✓ Cohesive │ │\n│ │ Tight Class Cohesion [███████░░░] 0.7 ✓ Good │ │\n│ └──────────────────────────────────────────────────────────┘ │\n│ │\n│ 🛡️ COVERAGE (How well tested?) │\n│ ┌──────────────────────────────────────────────────────────┐ │\n│ │ Line Coverage [████████░░] 82% ✓ Good │ │\n│ │ Branch Coverage [███████░░░] 71% ⚠ Improve │ │\n│ │ Mutation Score [██████░░░░] 65% ⚠ Improve │ │\n│ └──────────────────────────────────────────────────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n---\n\n## 🔬 Deep Dive\n\n### Part 1: Complexity Metrics\n\n#### Cyclomatic Complexity (McCabe)\n\n**What:** Number of linearly independent paths through code.\n\n**Formula:** `CC = E - N + 2P`\n- E = edges in control flow graph\n- N = nodes\n- P = connected components (usually 1)\n\n**Simplified:** Count decision points + 1\n- Each `if`, `else if`, `while`, `for`, `case`, `catch`, `&&`, `||` adds 1\n\n```java\n// Cyclomatic Complexity = 1 (no decisions)\npublic int simple() {\n return 42;\n}\n\n// Cyclomatic Complexity = 4\npublic String categorize(int score) {\n if (score >= 90) { // +1\n return \"A\";\n } else if (score >= 80) { // +1\n return \"B\";\n } else if (score >= 70) { // +1\n return \"C\";\n } else {\n return \"F\";\n }\n}\n// Base 1 + 3 conditions = 4\n\n// Cyclomatic Complexity = 8\npublic void process(Order order) {\n if (order == null) return; // +1\n if (order.getItems().isEmpty()) return; // +1\n\n for (Item item : order.getItems()) { // +1\n if (item.isAvailable()) { // +1\n if (item.getQuantity() > 0) { // +1\n processItem(item);\n }\n } else if (item.isBackorderable()) { // +1\n backorder(item);\n }\n }\n\n if (order.needsShipping()) { // +1\n shipOrder(order);\n }\n}\n// Base 1 + 7 decisions = 8\n```\n\n**Thresholds:**\n| CC | Rating | Action |\n|----|--------|--------|\n| 1-10 | Simple | OK |\n| 11-20 | Complex | Review |\n| 21-50 | High risk | Refactor |\n| 51+ | Untestable | Critical |\n\n---\n\n#### Cognitive Complexity (SonarSource)\n\n**What:** How hard is the code for a human to understand?\n\n**Key differences from cyclomatic:**\n- Penalizes nesting (nested `if` = harder than sequential)\n- Ignores shorthand structures (ternary operator)\n- Rewards language features (early returns)\n\n```java\n// Cyclomatic = 4, Cognitive = 6\n// Nesting adds extra cognitive load\npublic String categorize(Order order) {\n if (order != null) { // +1\n if (!order.getItems().isEmpty()) { // +2 (nesting)\n if (order.getTotal().compareTo(THRESHOLD) > 0) { // +3 (nesting)\n return \"PREMIUM\";\n }\n }\n }\n return \"STANDARD\";\n}\n\n// Cyclomatic = 4, Cognitive = 3\n// Early returns reduce cognitive load\npublic String categorizeBetter(Order order) {\n if (order == null) return \"STANDARD\"; // +1\n if (order.getItems().isEmpty()) return \"STANDARD\"; // +1\n if (order.getTotal().compareTo(THRESHOLD) > 0) { // +1\n return \"PREMIUM\";\n }\n return \"STANDARD\";\n}\n```\n\n**Thresholds:**\n| Cognitive | Rating | Action |\n|-----------|--------|--------|\n| 0-10 | Clear | OK |\n| 11-15 | Moderate | Review |\n| 16-25 | Difficult | Refactor |\n| 26+ | Very difficult | Critical |\n\n---\n\n#### NPath Complexity\n\n**What:** Number of unique execution paths.\n\n**Why it matters:** Represents minimum tests needed for full path coverage.\n\n```java\n// NPath = 2 × 2 × 2 = 8 paths\npublic void process(boolean a, boolean b, boolean c) {\n if (a) { /* branch 1 */ } // 2 paths\n if (b) { /* branch 2 */ } // × 2 paths\n if (c) { /* branch 3 */ } // × 2 paths\n}\n// Each independent if doubles the paths\n\n// NPath = 2 × 2 = 4 paths (sequential)\npublic void processSequential(boolean a, boolean b) {\n if (a) {\n if (b) { /* nested */ } // Not multiplicative when nested\n }\n}\n```\n\n**Threshold:** NPath > 200 is concerning, > 1000 is critical.\n\n---\n\n### Part 2: Coupling Metrics\n\n#### Afferent Coupling (Ca)\n\n**What:** Number of classes that depend on this class (incoming dependencies).\n\n**High Ca means:** Class is heavily used. Changes here affect many places. Should be stable.\n\n```text\n ┌─────────────────┐\n Service A ─→│ │\n Service B ─→│ PaymentGateway │ Ca = 4\n Service C ─→│ (this class) │ (4 classes depend on it)\n Service D ─→│ │\n └─────────────────┘\n```\n\n---\n\n#### Efferent Coupling (Ce)\n\n**What:** Number of classes this class depends on (outgoing dependencies).\n\n**High Ce means:** Class depends on many things. Likely to break when others change.\n\n```text\n ┌─────────────────┐\n │ │─→ Repository\n │ OrderService │─→ PaymentGateway\n │ (this class) │─→ NotificationService\n │ │─→ InventoryService\n └─────────────────┘\n Ce = 4\n (depends on 4 classes)\n```\n\n---\n\n#### Instability (I)\n\n**Formula:** `I = Ce / (Ca + Ce)`\n\n**Range:** 0 (completely stable) to 1 (completely unstable)\n\n```text\nPaymentGateway: Ca=10, Ce=2 → I = 2/(10+2) = 0.17 (stable)\nOrderService: Ca=2, Ce=8 → I = 8/(2+8) = 0.80 (unstable)\n```\n\n**Design principle:** Dependencies should flow toward stability. Unstable modules should depend on stable modules.\n\n```text\n Unstable Stable\n (I close to 1) (I close to 0)\n ┌─────────────┐ ┌─────────────┐\n │ Controller │────────────→│ Domain │\n │ I = 0.9 │ │ I = 0.1 │\n └─────────────┘ └─────────────┘\n │ │\n ↓ ↓\n ┌─────────────┐ ┌─────────────┐\n │ Service │────────────→│ Interface │\n │ I = 0.6 │ │ I = 0.0 │\n └─────────────┘ └─────────────┘\n\n ✓ Good: Arrows point toward stability\n```\n\n---\n\n### Part 3: Cohesion Metrics\n\n#### LCOM (Lack of Cohesion of Methods)\n\n**Variants:**\n- LCOM1: Original, rarely used\n- LCOM2: Improved\n- LCOM4: Most practical, used by SonarQube\n\n**LCOM4 concept:** Methods that share instance variables are connected. LCOM4 = number of connected components.\n\n```java\n// LCOM4 = 1 (perfect cohesion - all methods connected)\npublic class Customer {\n private String name;\n private String email;\n\n public String getName() { return name; } // Uses: name\n public void setName(String n) { this.name = n; } // Uses: name\n public String getEmail() { return email; } // Uses: email\n public String getDisplayName() { // Uses: name, email\n return name + \" <\" + email + \">\";\n }\n}\n// Graph: name—getDisplayName—email forms one component\n\n// LCOM4 = 2 (poor cohesion - two unrelated groups)\npublic class MixedService {\n private OrderRepository orderRepo;\n private CustomerRepository customerRepo;\n\n // Group 1: Order operations (use orderRepo)\n public Order getOrder(Long id) { return orderRepo.findById(id); }\n public void saveOrder(Order o) { orderRepo.save(o); }\n\n // Group 2: Customer operations (use customerRepo)\n public Customer getCustomer(Long id) { return customerRepo.findById(id); }\n public void saveCustomer(Customer c) { customerRepo.save(c); }\n}\n// Two components: should be two classes\n```\n\n**Thresholds:**\n| LCOM4 | Interpretation |\n|-------|---------------|\n| 1 | Perfectly cohesive |\n| 2-3 | Consider splitting |\n| 4+ | Definitely split |\n\n---\n\n#### Tight Class Cohesion (TCC)\n\n**What:** Percentage of method pairs that access common attributes.\n\n**Formula:** `TCC = (Connected pairs) / (Total pairs)`\n\n```java\n// TCC = 1.0 (all pairs connected)\npublic class Point {\n private int x, y;\n\n public int getX() { return x; } // Uses x\n public int getY() { return y; } // Uses y\n public double distance() { // Uses x and y\n return Math.sqrt(x*x + y*y);\n }\n}\n// Pairs: (getX,getY) share nothing, (getX,distance) share x,\n// (getY,distance) share y\n// TCC = 2/3 ≈ 0.67\n```\n\n**Threshold:** TCC > 0.5 is good, < 0.3 suggests low cohesion.\n\n---\n\n### Part 4: Coverage Metrics\n\n#### Line Coverage\n\n**What:** Percentage of code lines executed by tests.\n\n```java\npublic int calculate(int a, int b) {\n if (a > 0) {\n return a + b; // Line 1\n } else {\n return a - b; // Line 2\n }\n}\n\n// Test: calculate(5, 3) → returns 8\n// Covers Line 1 only\n// Line coverage = 50%\n```\n\n**Limitation:** Line coverage doesn't guarantee logic is tested.\n\n---\n\n#### Branch Coverage\n\n**What:** Percentage of decision branches executed.\n\n```java\npublic int calculate(int a, int b) {\n if (a > 0) { // Branch: true / false\n return a + b;\n } else {\n return a - b;\n }\n}\n\n// Test 1: calculate(5, 3) → branch: true\n// Test 2: calculate(-1, 3) → branch: false\n// Branch coverage = 100%\n```\n\n**More meaningful than line coverage** - ensures both sides of conditions tested.\n\n---\n\n#### Mutation Coverage (Mutation Testing)\n\n**What:** Percentage of code mutations detected by tests.\n\n**How it works:**\n1. Tool mutates code (e.g., changes `>` to `>=`)\n2. Runs tests\n3. Tests should fail (mutation killed)\n4. If tests pass, mutation survived (weak test)\n\n```java\npublic boolean isAdult(int age) {\n return age >= 18;\n}\n\n// Mutations:\n// 1. age >= 18 → age > 18 (boundary mutation)\n// 2. age >= 18 → age <= 18 (relational mutation)\n// 3. age >= 18 → true (constant mutation)\n// 4. 18 → 17 (value mutation)\n\n// Test: isAdult(25) → true\n// Does NOT kill mutation 1 (age > 18 also returns true for 25)\n\n// Test: isAdult(18) → true\n// Kills mutation 1 (age > 18 returns false for 18)\n```\n\n**Tool:** PIT (pitest.org) for Java\n\n**Threshold:** Mutation score > 80% indicates strong tests.\n\n---\n\n### Part 5: Tool Configuration\n\n#### SonarQube Quality Gate\n\n```yaml\n# sonar-project.properties\nsonar.projectKey=my-project\nsonar.projectName=My Project\nsonar.sources=src/main/java\nsonar.tests=src/test/java\nsonar.java.binaries=target/classes\nsonar.java.test.binaries=target/test-classes\nsonar.java.libraries=target/dependency/*.jar\n\n# Coverage\nsonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml\n\n# Quality Gate (define in SonarQube UI or here)\nsonar.qualitygate.wait=true\n```\n\n**Recommended Quality Gate:**\n\n```text\nMetric Operator Threshold\n───────────────────────────────────────────────\nCoverage on New Code is less than 80%\nDuplicated Lines (%) is greater than 3%\nMaintainability Rating is worse than A\nReliability Rating is worse than A\nSecurity Rating is worse than A\nBlocker Issues is greater than 0\nCritical Issues is greater than 0\n```\n\n---\n\n#### JaCoCo Configuration (Maven)\n\n```xml\n\n org.jacoco\n jacoco-maven-plugin\n 0.8.11\n \n \n prepare-agent\n \n prepare-agent\n \n \n \n report\n test\n \n report\n \n \n \n check\n \n check\n \n \n \n \n BUNDLE\n \n \n LINE\n COVEREDRATIO\n 0.80\n \n \n BRANCH\n COVEREDRATIO\n 0.70\n \n \n \n \n \n \n \n\n```\n\n---\n\n#### PIT Mutation Testing (Maven)\n\n```xml\n\n org.pitest\n pitest-maven\n 1.17.0\n \n \n org.pitest\n pitest-junit5-plugin\n 1.2.1\n \n \n \n \n com.example.domain.*\n com.example.service.*\n \n \n com.example.*Test\n \n 80\n 80\n \n DEFAULTS\n \n \n\n```\n\nRun: `mvn test-compile org.pitest:pitest-maven:mutationCoverage`\n\n---\n\n## ⚠️ Common Mistakes\n\n### Mistake 1: Gaming the Metrics\n\n```java\n// ❌ Splitting method just to reduce complexity\npublic void process() { // CC = 10\n step1();\n step2();\n step3();\n step4();\n step5();\n}\n\nprivate void step1() { /* still complex inside */ }\n// Each method still has CC = 8, total complexity unchanged\n\n// ✅ Actual simplification\npublic void process() { // CC = 3\n validateInput(); // Focused, CC = 2\n applyBusinessRules(); // Focused, CC = 4\n persistResults(); // Focused, CC = 2\n}\n```\n\n---\n\n### Mistake 2: Chasing 100% Coverage\n\n```java\n// ❌ Testing getters/setters for coverage\n@Test\nvoid testGettersSetters() {\n User user = new User();\n user.setName(\"Test\");\n assertEquals(\"Test\", user.getName());\n // Adds coverage, adds NO value\n}\n\n// ✅ Test behavior, not structure\n@Test\nvoid userRegistration_withValidData_createsActiveUser() {\n RegistrationRequest request = validRequest();\n\n User user = userService.register(request);\n\n assertThat(user.isActive()).isTrue();\n assertThat(user.getCreatedAt()).isCloseTo(now(), within(1, SECONDS));\n}\n```\n\n---\n\n### Mistake 3: Ignoring Trends\n\n```text\nWeek 1: Coverage 85%\nWeek 5: Coverage 78%\nWeek 9: Coverage 71%\n\n❌ \"We're still above 70% threshold\"\n\n✅ \"Coverage is declining 2%/week - why?\"\n - New code not being tested\n - Test maintenance being skipped\n - Architecture change made testing harder\n```\n\n---\n\n## 🐛 Debug This: The Coverage Paradox\n\nA developer reports: \"We hit 95% code coverage but bugs are still slipping through. Our quality gate passes but production keeps failing. How is this possible?\"\n\n```java\n// Test file - achieves \"high coverage\"\n@Test\npublic void testProcessOrder_coverage() {\n OrderProcessor processor = new OrderProcessor();\n\n // \"Test\" that just executes code without assertions\n processor.processOrder(new Order());\n processor.processOrder(null);\n processor.processOrder(createOrderWithItems());\n\n // We covered all branches! 95% coverage achieved!\n}\n\n// Production code\npublic class OrderProcessor {\n public OrderResult processOrder(Order order) {\n if (order == null) {\n return OrderResult.invalid(\"Order is null\");\n }\n\n BigDecimal total = calculateTotal(order);\n // Bug: should check total > 0 before processing\n PaymentResult payment = paymentService.charge(order.getCustomer(), total);\n\n if (payment.isSuccessful()) {\n // Bug: inventory not checked before shipping\n return OrderResult.success(order);\n } else {\n return OrderResult.failed(payment.getError());\n }\n }\n}\n```\n\n**Why does 95% coverage miss critical bugs? Find the metric's blind spot!**\n\n---\n\n**✅ Solution:**\n\nThe root cause is **coverage without meaningful assertions** (sometimes called \"assertion-free testing\"):\n\n**Problems with this \"test\":**\n1. No assertions - just executing code\n2. No verification of return values\n3. No boundary condition testing\n4. No negative case testing\n\n**Bugs that slip through:**\n- `total` could be 0 or negative (not checked)\n- Inventory availability not verified\n- Customer validation missing\n- Error handling incomplete\n\n**The lesson:** Coverage measures \"code executed\" not \"code verified\". A test that runs code but checks nothing is worthless. Focus on:\n- **Assertion density** - meaningful checks per test\n- **Mutation testing** - would changes break tests?\n- **Edge case coverage** - boundaries, nulls, errors\n\n**Better metric:** Combine coverage (80%+) with mutation testing score (70%+).\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Calculate Cyclomatic Complexity\n⭐ Difficulty: Easy | ⏱️ Time: 15 minutes\n\n**Task:** Calculate CC for this method:\n\n```java\npublic String processOrder(Order order) {\n if (order == null) {\n return \"ERROR\";\n }\n\n String status = \"PENDING\";\n\n for (Item item : order.getItems()) {\n if (item.isAvailable()) {\n if (item.getQuantity() > 10) {\n applyBulkDiscount(item);\n }\n } else {\n if (canBackorder(item)) {\n backorderItem(item);\n } else {\n return \"UNAVAILABLE\";\n }\n }\n }\n\n if (order.isPriority() && order.getTotal().compareTo(THRESHOLD) > 0) {\n status = \"EXPRESS\";\n }\n\n return status;\n}\n```\n\n**✅ Solution:**\n\n```text\nCC = 1 (base) + decision points\n\nDecision points:\n1. if (order == null) +1\n2. for loop +1\n3. if (item.isAvailable()) +1\n4. if (item.getQuantity() > 10) +1\n5. if (canBackorder(item)) +1\n6. if (order.isPriority() && ...) +2 (compound condition)\n\nCC = 1 + 7 = 8\n\nVerdict: Borderline acceptable (target: < 10)\nConsider extracting item processing to separate method.\n```\n\n---\n\n### Exercise 2: Identify Coupling Issues\n⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes\n\n**Task:** Calculate Ca, Ce, and I for each component:\n\n```text\nComponentA depends on: ComponentB, ComponentC\nComponentB depends on: ComponentD\nComponentC depends on: ComponentB, ComponentD\nComponentD depends on: (nothing)\n\nComponents that depend on:\n- ComponentA: (none)\n- ComponentB: ComponentA, ComponentC\n- ComponentC: ComponentA\n- ComponentD: ComponentB, ComponentC\n```\n\n**✅ Solution:**\n\n| Component | Ca (Afferent) | Ce (Efferent) | I = Ce/(Ca+Ce) |\n|-----------|---------------|---------------|----------------|\n| ComponentA | 0 | 2 (B, C) | 2/2 = 1.0 (unstable) |\n| ComponentB | 2 (A, C) | 1 (D) | 1/3 = 0.33 |\n| ComponentC | 1 (A) | 2 (B, D) | 2/3 = 0.67 |\n| ComponentD | 2 (B, C) | 0 | 0/2 = 0.0 (stable) |\n\n**Analysis:**\n- ComponentD is most stable (I=0) - good for foundational code\n- ComponentA is unstable (I=1) - okay for high-level application code\n- Consider: Does stability match abstraction level?\n\n---\n\n### Exercise 3: Configure Quality Gate\n⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 20 minutes\n\n**Task:** Set up a Gradle build that fails if:\n- Line coverage < 80%\n- Branch coverage < 70%\n- Cyclomatic complexity > 15 for any method\n\n**✅ Solution:**\n\n```kotlin\n// build.gradle.kts\nplugins {\n jacoco\n id(\"com.github.spotbugs\") version \"5.0.14\"\n}\n\njacoco {\n toolVersion = \"0.8.10\"\n}\n\ntasks.jacocoTestCoverageVerification {\n violationRules {\n rule {\n limit {\n counter = \"LINE\"\n value = \"COVEREDRATIO\"\n minimum = \"0.80\".toBigDecimal()\n }\n }\n rule {\n limit {\n counter = \"BRANCH\"\n value = \"COVEREDRATIO\"\n minimum = \"0.70\".toBigDecimal()\n }\n }\n }\n}\n\n// Use PMD or SpotBugs for complexity\npmd {\n ruleSetFiles = files(\"config/pmd/complexity-rules.xml\")\n}\n```\n\n---\n\n### Exercise 4: Create Metrics Dashboard\n⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 25 minutes\n\n**Task:** Design a metrics dashboard for a team. Define:\n- 5 key metrics to display\n- Thresholds for each (green/yellow/red)\n- Update frequency\n\n**✅ Solution:**\n\n```text\nCLEAN CODE DASHBOARD\n\n┌─────────────────────────────────────────────────────────────┐\n│ COVERAGE COMPLEXITY │\n│ ██████████████░░░░ 78% ████████████░░░░░░ Avg CC: 7 │\n│ Target: 80% Target: < 10 │\n│ Status: ⚠️ YELLOW Status: ✅ GREEN │\n└─────────────────────────────────────────────────────────────┘\n\nTHRESHOLDS:\n| Metric | Green | Yellow | Red |\n|------------------|------------|------------|------------|\n| Line Coverage | ≥ 80% | 70-79% | < 70% |\n| Branch Coverage | ≥ 70% | 60-69% | < 60% |\n| Avg Complexity | < 10 | 10-15 | > 15 |\n| Duplication | < 3% | 3-5% | > 5% |\n| Code Smells | < 10 | 10-30 | > 30 |\n\nUPDATE FREQUENCY:\n- Coverage: Per commit\n- Complexity: Per commit\n- Duplication: Daily\n- Code Smells: Weekly\n- Technical Debt: Weekly\n```\n\n---\n\n### Exercise 5: Analyze Real Codebase\n⭐⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 30 minutes\n\n**Task:** Analyze a module in your codebase using SonarQube or IntelliJ's analysis. Document:\n- Current metrics\n- Top 3 improvements\n- Expected impact\n\n**✅ Solution Template:**\n\n```text\nMODULE: _______________\n\nCURRENT METRICS:\n| Metric | Value | Target | Status |\n|--------------------|-------|--------|--------|\n| Lines of Code | ___ | - | - |\n| Coverage | ___% | 80% | __ |\n| Cyclomatic Complexity | ___ | <10 | __ |\n| Duplication | ___% | <3% | __ |\n| Code Smells | ___ | <10 | __ |\n| Technical Debt | ___h | <8h | __ |\n\nTOP 3 IMPROVEMENTS:\n1. _______________ (Expected: ___ coverage, ___ complexity)\n2. _______________ (Expected: ...)\n3. _______________ (Expected: ...)\n\nPRIORITY: High/Medium/Low\nESTIMATED EFFORT: ___ hours\nEXPECTED PAYBACK: ___ weeks\n```\n\n---\n\n## 🎤 Senior-Level Interview Questions\n\n### Question #1: Which metrics do you prioritize and why?\n\n**Strong answer:**\n\nI prioritize based on defect correlation:\n\n1. **Complexity (Cyclomatic/Cognitive)** - Strongest correlation with bugs. CC > 20 has 2x bug rate.\n\n2. **Coverage trends** - Not absolute numbers, but declining coverage signals problems.\n\n3. **Coupling (Instability)** - High instability in core modules predicts cascade failures.\n\n4. **Cohesion (LCOM)** - Identifies classes that should be split.\n\nI track trends weekly, not absolute values. A stable 75% coverage is better than fluctuating 80-90%.\n\n---\n\n### Question #2: How do you handle resistance to quality gates?\n\n**Strong answer:**\n\nI address specific concerns:\n\n**\"It slows us down\":**\n- Show data: 1 hour in quality gates saves 8 hours in bug fixes\n- Start with warnings, graduate to blocks\n- Exclude legacy code initially\n\n**\"It's arbitrary\":**\n- Research shows CC > 15 doubles bug probability\n- Adjust thresholds based on our defect data\n- Team can propose changes with evidence\n\n**\"We need to ship\":**\n- Expedited path exists (documented exception)\n- Technical debt must be tracked and scheduled\n- Block only on critical issues, warn on others\n\n---\n\n### Question #3: What's the difference between line coverage and mutation coverage?\n\n**Strong answer:**\n\n**Line coverage:** Did the test execute this line?\n- Can be 100% with zero assertions\n- Doesn't verify logic correctness\n\n**Mutation coverage:** Did the test detect when code changed?\n- Tests must fail when code is mutated\n- Verifies tests actually check behavior\n\nExample:\n```java\npublic int add(int a, int b) {\n return a + b;\n}\n\n// Line coverage: 100%\n@Test void test() { add(1, 2); } // No assertion!\n\n// Mutation testing catches this:\n// Mutant: return a - b;\n// Test still passes → Mutation survived → Weak test\n```\n\n---\n\n### Question #4: How do you set realistic coverage targets?\n\n**Strong answer:**\n\nI use risk-based differentiation:\n\n| Code Type | Line Target | Branch Target | Rationale |\n|-----------|-------------|---------------|-----------|\n| Core domain | 90% | 85% | High risk, high value |\n| Services | 80% | 70% | Business logic |\n| Controllers | 60% | 50% | Integration tested |\n| DTOs/Config | 0% | 0% | No behavior to test |\n\nProcess:\n1. Measure current coverage\n2. Set incremental goals (+5% per quarter)\n3. Higher targets for new code\n4. Track and adjust based on defect correlation\n\n---\n\n## 📝 Summary & Key Takeaways\n\n### Metric Quick Reference\n\n| Metric | Target | Tool |\n|--------|--------|------|\n| Cyclomatic Complexity | < 10 per method | SonarQube |\n| Cognitive Complexity | < 15 per method | SonarQube |\n| LCOM4 | = 1 (cohesive) | SonarQube |\n| Instability | Depends on layer | JDepend |\n| Line Coverage | > 80% | JaCoCo |\n| Branch Coverage | > 70% | JaCoCo |\n| Mutation Score | > 80% | PIT |\n\n### Quality Gate Checklist\n\n- [ ] Blocker/Critical issues = 0\n- [ ] Coverage on new code >= 80%\n- [ ] Duplicated lines < 3%\n- [ ] Complexity per method < 15\n- [ ] Maintainability rating A\n\n### Key Principles\n\n1. **Trends over absolutes** - Watch direction, not just numbers\n2. **Risk-based targets** - Critical code needs higher standards\n3. **Automate enforcement** - Quality gates in CI/CD\n4. **Correlate with outcomes** - Track metrics vs defects\n\n---\n\n## 🏁 Conclusion\n\nMetrics transform subjective debates into objective discussions. But remember: metrics are indicators, not goals. A codebase can have perfect metrics and still be poorly designed if the metrics are gamed.\n\n**Use metrics to:**\n- Find problem areas\n- Track improvement over time\n- Enforce minimum standards\n\n**Don't use metrics to:**\n- Measure developer performance\n- Replace code review judgment\n- Chase arbitrary numbers\n\n**Your next step:** Continue to Part 6 (Extract Patterns) to learn the refactoring techniques that improve these metrics.\n\n---\n\n## 📅 Review Schedule for This Article\n\n| Day | Task | Time |\n|-----|------|------|\n| Day 1 | Review Metrics Quick Reference table | 5 min |\n| Day 3 | Redo Exercise 1 (Calculate Cyclomatic Complexity) | 15 min |\n| Day 7 | Answer interview questions without looking | 10 min |\n| Day 14 | Redo Debug This (Coverage Paradox) | 10 min |\n| Day 30 | Run SonarQube on current project and review metrics | 15 min |\n\n---\n\n*Next in series: [Part 6: Extract Patterns (Method, Class, Interface)]*\n","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:24.689321Z","createdAt","2026-06-10T07:19:24.690288Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",18,"estimatedReadingTime","authorId",3,"authorUsername","tomasz_main","categoryName","Java","readingTime","seriesId","seriesOrder",5,"author",{"_31":55,"_97":57,"_98":99,"_100":101,"_102":-5,"_103":-5,"_104":-5,"_105":-5,"_106":-5},"category",{"_31":63,"_72":59,"_35":94,"_75":95,"_96":-5},"tags",[78,79,80,81],"series",{"_31":16,"_72":73,"_35":74,"_75":76,"_77":23},"name","Advanced Clean Code Patterns: From Principles to Production Mastery","advanced-clean-code-patterns","description","A comprehensive 26-part series covering enterprise-grade clean code patterns for Java developers. From SOLID principles and code smells through refactoring patterns, error handling, validation, to legacy modernization and modern Java 21+ features. Includes real production stories, mental models, exercises, and 150+ interview questions.","isActive",{"_31":91,"_72":92,"_35":93},{"_31":88,"_72":89,"_35":90},{"_31":85,"_72":86,"_35":87},{"_31":82,"_72":83,"_35":84},37,"Quality","quality",35,"Cyclomatic Complexity","cyclomatic-complexity",36,"Cognitive Complexity","cognitive-complexity",34,"Code Metrics","code-metrics","java","Category for Java","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl"]