Paired Topics in Q1 Format
1. Centralised Version Control Systems (CVCS) vs. Distributed Version Control Systems (DVCS)
Centralised VCS:
A CVCS uses a single central server to store all versions of a project. Developers check out files from this server, make changes locally, and commit changes back to the central repository.
It ensures a single source of truth but relies heavily on network connectivity.
Useful for enforcing strict access control and centralized backups.
Weakness: If the central server fails, collaboration halts entirely.
Weakness: If the central server fails, collaboration halts entirely.
Distributed VCS:
In DVCS (e.g., Git), every developer has a full local copy of the repository, including its history.
Commits are made locally and later synced with remote repositories.
Offers resilience (no single point of failure) and supports offline work.
Strength: Enables branching/merging workflows and asynchronous collaboration.
Strength: Enables branching/merging workflows and asynchronous collaboration.
Connection:
Both aim to manage code revisions but differ in fault tolerance and flexibility. CVCS simplifies administration but sacrifices redundancy, while DVCS prioritizes flexibility and redundancy at the cost of increased local storage. Both are foundational for team collaboration but suit different project scales (CVCS for tightly controlled environments, DVCS for distributed teams).
2. git commit vs. git push
git commit:
Saves changes to the local repository by creating a snapshot of the staging area.
Requires a meaningful message to document changes (e.g., “Fix login bug”).
Allows incremental progress tracking without affecting others.
Key Use: Creating version checkpoints before sharing changes.
git push:
Uploads local commits to a remote repository (e.g., GitHub), making them accessible to others.
Essential for collaborative workflows but must be done cautiously to avoid conflicts.
Key Use: Syncing team progress and deploying code updates.
Connection:commit and push operate at different stages: local vs. remote. Commits act as private checkpoints, while pushes share finalized changes. Overusing push after every commit can clutter the remote history; instead, commits should be logically grouped before pushing to maintain clarity.
3. Unit Testing vs. Integration Testing
Unit Testing:
Tests individual components (e.g., a single function or class) in isolation using mocks/stubs.
Focuses on correctness of small code units. Frameworks like JUnit automate these tests.
Importance: Catches bugs early and supports Test-Driven Development (TDD).
Integration Testing:
Verifies interactions between multiple components (e.g., APIs and databases).
Ensures combined parts work as expected. Tools like MockMVC simulate system interactions.
Importance: Detects interface mismatches and data flow issues.
Integration Testing:
Verifies interactions between multiple components (e.g., APIs and databases).
Ensures combined parts work as expected. Tools like MockMVC simulate system interactions.
Importance: Detects interface mismatches and data flow issues.
Connection:
Both are part of the testing pyramid. Unit tests validate isolated logic, while integration tests ensure components communicate correctly. Together, they reduce defects but target different scopes: unit tests for code accuracy, integration tests for system harmony.
4. Aggregation vs. Composition (UML Relationships)
Aggregation:
A “has-a” relationship where one class (whole) contains another (part), but the part can exist independently.
Represented in UML with a hollow diamond. Example: A University has Departments, but departments can exist without the university.
Composition:
A stricter “owns-a” relationship: the part cannot exist without the whole.
Shown with a filled diamond. Example: A Car owns an Engine; deleting the car destroys the engine.
Connection:
Both denote part-whole relationships but differ in lifecycle dependency. Aggregation allows independence, while composition enforces ownership. Both improve modular design but are applied based on component lifespans.
5. Singleton Pattern vs. Factory Pattern
Singleton Pattern:
A creational pattern ensuring only one instance of a class exists.
Achieved via private constructors and static instance methods.
Use Case: Managing shared resources (e.g., database connections).
Factory Pattern:
Creates objects without specifying their concrete classes, delegating instantiation to subclasses.
Provides flexibility in object creation (e.g., ButtonFactory generating OS-specific buttons).
Factory Pattern:
Creates objects without specifying their concrete classes, delegating instantiation to subclasses.
Provides flexibility in object creation (e.g., ButtonFactory generating OS-specific buttons).
Connection:
Both abstract object creation. Singleton restricts instance count, while Factory standardizes creation logic. Factories can encapsulate Singleton instances to centralize resource management.
6. Refactoring vs. Technical Debt
Refactoring:
Restructuring existing code to improve readability, performance, or maintainability without altering functionality.
Includes techniques like Extract Method or Replace Magic Numbers.
Refactoring:
Restructuring existing code to improve readability, performance, or maintainability without altering functionality.
Includes techniques like Extract Method or Replace Magic Numbers.
Technical Debt:
Accumulated shortcuts or suboptimal code that slows future development.
Arises from deadlines, lack of testing, or poor design.
Connection:
Refactoring directly addresses technical debt by “repaying” shortcuts. Ignoring refactoring increases debt, making future changes harder. Proactive refactoring balances debt and delivery speed.
7. Waterfall Model vs. SCRUM
Waterfall Model:
A linear SDLC phase (requirements → design → implementation → testing → maintenance).
Rigid with minimal iteration; suited for stable, well-defined projects.
SCRUM:
Agile framework using iterative sprints (2-4 weeks) to deliver incremental value.
Roles include Product Owner, Scrum Master, and Developers.
Connection:
Both manage software delivery but oppose in flexibility. Waterfall suits fixed-scope projects, while SCRUM embraces changing requirements. SCRUM reduces risk via frequent feedback, contrasting Waterfall’s late-stage testing.
Connection:
Both manage software delivery but oppose in flexibility. Waterfall suits fixed-scope projects, while SCRUM embraces changing requirements. SCRUM reduces risk via frequent feedback, contrasting Waterfall’s late-stage testing.
8. Cyclomatic Complexity vs. Test Coverage
Cyclomatic Complexity:
Measures code complexity based on control flow paths. Formula: Edges – Nodes + 2.
High complexity indicates harder-to-maintain code.
Test Coverage:
Quantifies code exercised by tests (e.g., statement, branch coverage).
Ensures thorough testing but does not guarantee correctness.
Test Coverage:
Quantifies code exercised by tests (e.g., statement, branch coverage).
Ensures thorough testing but does not guarantee correctness.
Connection:
High cyclomatic complexity demands higher test coverage to mitigate risks. Coverage metrics guide testing efforts, while complexity highlights code needing refactoring. Both prioritize quality but focus on different aspects (structure vs. validation).
9. TDD (Test-Driven Development) vs. Clean Code
TDD:
Development approach where tests are written before code (Red-Green-Refactor cycle).
Ensures code meets requirements and supports regression testing.
Clean Code:
Code that is readable, maintainable, and follows standards (e.g., meaningful names, minimal comments).
Connection:
TDD inherently promotes clean code by enforcing modular, testable design. Clean code reduces “code smells” like long methods, which TDD discourages. Both aim for maintainability but approach it differently: TDD via tests, clean code via readability.
10. Continuous Integration (CI) vs. Continuous Deployment (CD)
CI:
Automatically merges and tests code changes in a shared repository multiple times a day.
Tools like Jenkins catch integration issues early.
CI:
Automatically merges and tests code changes in a shared repository multiple times a day.
Tools like Jenkins catch integration issues early.
CD:
Automatically deploys validated code to production after CI.
Reduces manual steps and accelerates delivery.
Connection:
CI ensures code stability before CD deploys it. CI focuses on integration, while CD focuses on delivery. Together, they enable rapid, reliable releases but require robust automation.