software development

Do We Need to Test UI Changes During Code Review?

Pandiyan MuruganLeave a comment

Code reviews are a crucial part of the development process. They help catch bugs early. They maintain code quality and guarantee consistency. But when it comes to UI changes, one question that comes up every time –

“Should I test every UI change during code review?”

Let’s break it down.

The Real Deal

When reviewing code, your job isn’t to become a full-time QA. You’re not expected to click through every screen or test every browser. But that doesn’t mean you just review the code and approve without even running it.

Here’s a simple rule I follow:

Do a smoke test. Leave deep testing to the person who wrote the code.

Responsibilities – Who Does What?

Code Author (the one raising the PR):

  • Clear information of what has been changed.
  • Links to relevant to related requirements document if any.
  • Tests all use cases — positive, negative, edge cases.
  • Ensures responsiveness and accessibility.
  • Runs the app in different screen sizes (desktop, mobile, etc.).
  • Adds before/after screenshots or screen recording in the PR.
  • Mentions what was tested and how.

Code Reviewer (the one reviews the PR):

  • Pull the branch and run a quick smoke test.
    • Does the UI render?
    • Does it break anything obvious?
    • Are core interactions working? (clicks, inputs, nav)
  • Review the code:
    • Is the styling clean?
    • Any hardcoded values?
    • Are components reusable and scoped?
    • Does it break any layout in high level?

You’re the second line of defense, not the QA team.

When to Dig Deeper?

You don’t always need to click every flow, but in these cases, it’s worth going beyond a smoke test:

  • It’s a high-impact UI change.
  • There’s a risky refactor.
  • The code seems too simple for the change it claims to solve.
  • You’re curious or feel something’s off.

TL;DR

  • Do a smoke test during code review.
  • Let the code author do full testing.
  • Make sure they show what’s changed with screenshots or a demo.
  • Your goal: catch obvious issues, review clean code, ensure UI logic is solid.

Let your review be lightweight, focused, and valuable. Not every change needs a deep dive — just enough to ensure you’re not shipping broken UI.

When and Why You Should Refactor a Customer-Facing Application

Pandiyan MuruganLeave a comment

Refactoring is the process of improving the internal structure of your code without changing its external behavior. It’s essential for maintaining a healthy codebase, especially for customer-facing applications. Here’s when you should consider refactoring:

1. Performance Issues Impacting User Experience

  • If the app is slow, timing out, or consuming excessive resources, refactor to optimize the code.
  • Focus on improving database queries, algorithms, and caching techniques to boost speed.

2. Frequent Bugs or Crashes

  • Constant bug fixes indicate poor code quality.
  • Refactor to stabilize the application, making it less error-prone and easier to maintain.

3. Difficulty Adding New Features

  • When new features become hard to implement due to complex code, refactoring is necessary.
  • Simplify and decouple the code to make future development faster and smoother.

4. Code Duplication

  • Duplicate code makes maintenance a nightmare.
  • Apply the DRY principle (Don’t Repeat Yourself) during refactoring to remove redundancy and improve efficiency.

5. Outdated Libraries or Legacy Code

  • Relying on old libraries can result in security risks and compatibility issues.
  • Refactor to modernize the application with up-to-date tools and technologies.

6. Poor Code Readability

  • If the code is hard to understand, especially for new developers, refactoring can help.
  • Clean up the structure, improve naming conventions, and simplify logic to enhance collaboration.

7. Security Vulnerabilities

  • Outdated code can lead to serious security risks, especially in customer-facing apps.
  • Refactor vulnerable areas to ensure data protection and compliance with security standards.

8. Low Testability

  • Highly coupled components can make writing tests difficult.
  • Refactor the code to improve modularity, enabling better test coverage and a more reliable app.

9. Evolved Business Logic

  • When business requirements change, your code may no longer align.
  • Refactor to reflect updated business logic and support new workflows or customer needs.

10. Accumulated Technical Debt

  • Technical debt makes future updates more complex and risky.
  • Refactor regularly to “pay off” this debt, improving long-term maintainability and performance.

Conclusion: Refactor Proactively

Refactoring prevents performance issues, improves stability, and reduces technical debt. By addressing these common problems early, you’ll create a more maintainable and scalable product that continues to provide value to your customers.