DEV Community

Cover image for 🔍 The Potential of Perspective-Driven Code Reviews - Gaining New Insights
kirodotdev profile image snickerjp
snickerjp for kirodotdev

Posted on

🔍 The Potential of Perspective-Driven Code Reviews - Gaining New Insights

#kiro #ai #codereview

Introduction

The Importance of Perspective in Code Reviews

Code reviews are a crucial process that serves as the cornerstone of quality assurance, but the content and priorities of feedback can vary significantly depending on the reviewer's perspective. This report analyzes reviews from two different perspectives - operational and architectural - by AI "kiro" using actual Terraform code reviews as a case study, and examines the new insights gained by changing perspectives.

Two-Perspective Reviews by kiro

In this report, we requested AI "kiro" to conduct reviews from the following two perspectives:

  • 🔧 Operational Perspective: Emphasizing safety, maintainability, and practicality in team development for daily operations
  • 🏗️ Architectural Perspective: Emphasizing code design elegance, scalability, and architectural soundness

While these perspectives are not necessarily opposing, they differ in priorities and focus points. By requesting the same AI to review from different perspectives, we can objectively analyze how perspective differences affect feedback content.

🔧 Operational Perspective Review by kiro

Review Overview

The operational perspective review was analyzed using the following four evaluation criteria:

Item Rating Details
Security 🔴 Needs Improvement Hardcoded sensitive information
State Management 🔴 Needs Improvement Using local state
Code Quality 🟡 Good Some room for improvement
Operability 🟡 Good CI/CD not implemented

Major Issues Identified

1. State File Management (Most Critical)

  • ❌ Problem: Managing state files locally
  • ⚡ Risk: Conflicts in team development, loss risk, no backup
  • ✅ Solution: Implement S3 backend + DynamoDB locking 
terraform {
  backend "s3" {
    bucket         = "your-terraform-state-bucket"
    key            = "alb-rules/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}
Enter fullscreen mode Exit fullscreen mode

2. Security Concerns

  • ❌ Problem: ARNs hardcoded in tfvars files
  • ⚡ Risk: Sensitive information leakage
  • ✅ Solution: Environment variables, Parameter Store utilization, .gitignore configuration

3. Stricter Version Management

  • ❌ Problem: Provider version range too broad (~> 5.0)
  • ✅ Solution: More specific version specification (~> 5.30.0)

4. Operational Improvement Proposals

  • 🏷️ Unified tag strategy (localize common tags)
  • ✔️ Add variable validation (IP format, priority range validation)
  • 🔄 Build CI/CD pipeline
  • 📊 Monitoring and alerting setup

Implementation Roadmap

The operational perspective presented a phased improvement plan:

  1. 📅 Phase 1 (1 week): Remote state file implementation
  2. 📅 Phase 2 (2 weeks): Security enhancement
  3. 📅 Phase 3 (1 month): CI/CD construction
  4. 📅 Phase 4 (3 months): Modularization and policy management

🏗️ Architectural Perspective Review by kiro

Review Overview

The architectural perspective focused on code design quality and future scalability.

Overall Rating: B+ → A (after improvements)

Evaluated Strengths

  1. ⚡ Dynamic Resource Generation: Excellent automatic splitting logic for ALB limitations (4 IPs/rule)
  2. 📋 Variable Separation: Externalization of configuration through terraform.tfvars
  3. 🏷️ Tag Standardization: Consistent tag strategy
  4. 🎯 Constraint Handling: Creative solutions for AWS limitations

Major Improvement Proposals

1. Modularization Recommendation (Priority: Low)

  • Migration from current flat structure to module-based structure
  • 🗂️ Environment-specific directory separation (production/staging)
  • ♻️ Creation of reusable modules

2. Dynamic Retrieval via Data Sources (Priority: Medium)

  • Dynamically retrieve hardcoded ARNs using Data Sources
  • More flexible and maintainable design 
# After improvement
data "aws_lb" "main" {
  name = var.load_balancer_name
}

data "aws_lb_listener" "https" {
  load_balancer_arn = data.aws_lb.main.arn
  port              = 443
}
Enter fullscreen mode Exit fullscreen mode

3. Enhanced Input Validation (Priority: High)

  • 🌐 CIDR format validation
  • 🔢 IP count validation
  • 💬 More detailed error messages 
variable "devinvm_ip_addresses" {
  description = "Devin VM IP addresses"
  type        = list(string)

  validation {
    condition = alltrue([
      for ip in var.devinvm_ip_addresses :
      can(cidrhost(ip, 0))
    ])
    error_message = "All IP addresses must be valid CIDR notation."
  }
}
Enter fullscreen mode Exit fullscreen mode

4. Output Improvements

  • 📝 Add detailed descriptions
  • 📊 Output rule summaries
  • 🗂️ More structured output format

Comparative Analysis

Common Ground: Issues Identified by Both Perspectives

The following items were identified by both kiro's operational and architectural perspectives and are items that should definitely be improved:

  1. ✔️ Adding Input Validation

    • 🔧 Operational perspective: Preventing operational mistakes
    • 🏗️ Architectural perspective: Improving code quality

  2. 📌 Stricter Version Management

    • 🔧 Operational perspective: Preventing unexpected behavior
    • 🏗️ Architectural perspective: Ensuring reproducibility

  3. State Management Improvement

    • 🔧 Operational perspective: Team development safety
    • 🏗️ Architectural perspective: Infrastructure reliability

  4. Security Enhancement

    • 🔧 Operational perspective: Protecting sensitive information
    • 🏗️ Architectural perspective: Design soundness

Differences: Priority Variations by Perspective

Readability Aspect

Perspective Priority Approach
🔧 Operational 🟡 Medium 🏷️ Tag unification, clear naming conventions
🏗️ Architectural 🔴 High 📦 Modularization, structured output

Analysis: Architectural perspective emphasizes structural code readability (modularization). Operational perspective emphasizes clarity in daily work (tags, naming).

Maintainability Aspect

Perspective Priority Approach
🔧 Operational 🔴 High 🔄 CI/CD, 📊 monitoring, 🔍 drift detection
🏗️ Architectural 🔴 High 📦 Modularization, 🔍 Data Source utilization

Analysis: Both prioritize maintainability, but operational perspective focuses on "operational processes" while architectural perspective focuses on "code design".

Performance Aspect

Perspective Priority Approach
🔧 Operational 🟢 Low No specific mention
🏗️ Architectural 🟢 Low No specific mention

Analysis: For this Terraform code, performance was not a major concern for either perspective.

Priority Differences

Operational Perspective Priorities 

🔴 Highest Priority (Immediate Response)
  ├─ State Management
  └─ Security

🟡 Medium Priority (Medium-term Improvement)
  ├─ CI/CD
  └─ Monitoring

🟢 Low Priority (Long-term Improvement)
  └─ Modularization
Enter fullscreen mode Exit fullscreen mode

Architectural Perspective Priorities 

🔴 Highest Priority
  └─ Input Validation

🟡 Medium Priority
  ├─ Data Source Implementation
  └─ State Management

🟢 Low Priority
  └─ Modularization
Enter fullscreen mode Exit fullscreen mode

Important Discovery:

  • 🔧 Operational perspective: "State Management" as highest priority → Focus on problems that could occur immediately
  • 🏗️ Architectural perspective: "Input Validation" as highest priority → Focus on code quality fundamentals

Both perspectives rated "Modularization" as low priority because the current code is simple and functions adequately.

Different Focus Points by Perspective

Kiro's operational and architectural perspectives focus on significantly different points even when looking at the same code.

Items Emphasized by Operational Perspective (Not mentioned by architectural perspective)

  • 🔄 CI/CD Pipeline Construction: Reducing human errors through automation
  • 📊 Monitoring & Alert Setup: Early problem detection and response
  • 🔍 Drift Detection: Detecting discrepancies between actual infrastructure and code
  • Phased Implementation Roadmap: Realistic improvement plan
  • Team Development Conflict Risks: Safety during multi-person work

These focus on "actual daily operational challenges".

Items Emphasized by Architectural Perspective (Not mentioned by operational perspective)

  • 📦 Detailed Module Structure Design: Ensuring reusability and scalability
  • 🗂️ Environment-specific Directory Separation: Logical structuring
  • 📤 Output Structuring and Detailing: Systematic information organization
  • 🔍 Specific Implementation of Dynamic Retrieval via Data Sources: Highly flexible design

These focus on "design considering future changes and extensions".

Important Insight: Both perspectives capture problems on different time scales. Operational perspective looks at "today and tomorrow", while architectural perspective looks at "months and years ahead".

Analysis

Value Brought by Perspective Diversity

From kiro's two-perspective comparison, we gained the following important insights:

  1. Complementary Perspectives: Operational and architectural perspectives don't oppose each other but complement each other. Operational perspective captures "current" problems, while architectural perspective captures "future" problems.

  2. Importance of Common Issues: Items commonly identified by both perspectives (input validation, version management, state management, security) are important matters that should definitely be addressed.

  3. Value of Priority Differences: The difference between operational perspective's "State Management priority" and architectural perspective's "Input Validation priority" should be judged based on project circumstances (team size, development phase, risk tolerance) rather than which is correct.

Balancing Operational and Architectural Perspectives

Recommended Approach

  1. Initial Stage: Prioritize operational perspective

    • State management, security, etc., ensure basic safety
    • Establish team development foundation

  2. Growth Stage: Incorporate architectural perspective

    • Code structuring, modularization
    • Scalability improvement

  3. Maturity Stage: Integration of both perspectives

    • Balance operational processes and code design
    • Continuous improvement cycle

Application to Development Teams

Perspective-driven reviews can provide the following benefits:

  • Junior Developer Growth: Learn practical skills from operational perspective reviews and design philosophy from architectural perspective reviews
  • Reviewer Burden Reduction: Clarifying perspectives makes review intentions clear and discussions constructive
  • Team Diversity Utilization: Members with different backgrounds can contribute from their respective perspectives

Importance of Code Simplicity

Through this analysis, we confirmed that "code simplicity" is valued by both perspectives:

  • Architectural perspective also values practical design over excessive abstraction
  • Operational perspective emphasizes clear, maintainable code over complex structures
  • Both perspectives rated the current implementation (ALB limitation handling) as "excellent" and "creative"

This is because code maintained by diverse members requires understandable and easily modifiable code.

Conclusion

New Insights from Changing Review Perspectives

From this report's analysis, the following values became clear:

  1. Comprehensive Quality Improvement: Problems overlooked by a single perspective can be complemented by multiple perspectives

  2. Priority Clarification: Common issues should definitely be addressed, while perspective-specific issues can be judged based on circumstances

  3. Learning Opportunity Creation: Reviews from different perspectives provide valuable opportunities to broaden developers' horizons

  4. Promoting Constructive Discussion: Clarifying perspectives makes "why that feedback is given" clear and deepens discussions

Recommendations for Future Review Culture

1. Perspective Clarification

Clearly marking perspectives (operational, architectural, security, etc.) in review comments makes intentions easier to understand.

2. Encouraging Diverse Perspectives

Foster a culture that actively seeks feedback from reviewers with different backgrounds within the team.

3. Accepting Gradual Improvement

Rather than seeking perfection, distinguish between operational perspective's "immediately necessary improvements" and architectural perspective's "future improvements", accepting gradual improvement.

4. Utilizing AI Reviews

As demonstrated in this report, using AI to efficiently obtain reviews from multiple perspectives can reduce human reviewer burden while improving quality.

Concrete Actions You Can Start Tomorrow

Perspective-driven reviews can be started today without special preparation.

🤖 Perspective-Specific Reviews Using Generative AI

The simplest method is to 🎯 specify perspectives when requesting reviews from generative AI:

Example 1: 🏗️ Architectural Perspective Review Request

"Please review this Terraform code from an 🏗️ architectural perspective.
Focus on design elegance, scalability, and future maintainability for feedback."
Enter fullscreen mode Exit fullscreen mode

Example 2: 🔧 Operational Perspective Review Request

"Please review this Terraform code from an 🔧 operational perspective.
Focus on daily operational safety, team development practicality, and troubleshooting ease for feedback."
Enter fullscreen mode Exit fullscreen mode

By simply 📝 splitting requests into two, you can gain insights from different perspectives. Please try it!

👥 Team Implementation

  1. 🏷️ Add Perspective Tags to Review Comments

    • Tags like [🔧 Operational Perspective] [🏗️ Architectural Perspective] clarify intentions

  2. 📝 Specify Expected Perspectives in Review Requests

    • "Please review focusing on 🔧 operational issues"
    • "Could you provide feedback from a 🏗️ design perspective?"

  3. 👥 Perspective Role Assignment

    • Operations staff review from 🔧 operational perspective, architects from 🏗️ design perspective
    • Obtaining both perspectives enables comprehensive quality improvement

🎉 Final Words

Perspective-driven reviews are not mere "✅ checking tasks" but 👥 venues for sharing team-wide knowledge and experience. By combining 🔧 operational and 🏗️ architectural perspectives with various other viewpoints, we can build more robust and maintainable codebases.

This initiative promotes 🌱 junior developer growth, shares 👨‍💼 senior developer insights, and ultimately contributes to 📈 overall project quality improvement. Accepting perspective diversity and building better software together through constructive discussion is the essential value of development teams.

📚 References

Please feel free to check out my first post:

Understanding the Differences: Kiro IDE, Kiro CLI, and Amazon Q Developer - DEV Community

Top comments (0)