Software engineering is not only about writing code. It also includes requirements, design, testing, deployment, maintenance, and collaboration.
SDLC
The software development lifecycle usually includes:
- Planning
- Requirement analysis
- Design
- Development
- Testing
- Deployment
- Maintenance
Common models include waterfall, iterative development, agile, and DevOps.
DevOps
DevOps emphasizes collaboration between development and operations. The goal is faster and more reliable delivery.
Core concepts:
- CI: Continuous Integration
- CD: Continuous Delivery/Deployment
- IaC: Infrastructure as Code
- Monitoring and logging
- Automated testing
OOP
Object-oriented programming centers on encapsulation, inheritance, and polymorphism.
Encapsulation hides implementation details. Inheritance reuses and extends behavior. Polymorphism allows the same interface to have different implementations.
SOLID
SOLID principles:
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
The goal is lower coupling and better maintainability.
Design Patterns
Common patterns:
- Singleton
- Factory
- Factory Method
- Adapter
- State
- Strategy
Design patterns are not for decoration. They solve recurring structural problems.
Deeper Notes
When reviewing this topic, do not memorize names only. Focus on SDLC, DevOps, OOP, SOLID, design patterns, and collaborative engineering quality. If this stays at the definition level, it becomes hard to explain in interviews or apply in projects. A stronger way to study it is to place it in a concrete scenario: who calls it, where the input comes from, what happens on failure, and whether data or state can be processed twice.
- Software engineering connects requirements, design, implementation, testing, release, and maintenance into a sustainable loop.
- Principles and patterns are useful only when they reduce complexity; abstraction for its own sake is harmful.
- A strong engineering note should answer why this design exists, what alternatives were considered, and how failure is handled.
In a real project, use it as a decision framework: identify inputs, constraints, failure modes, and observability before choosing a specific tool or pattern. If a solution looks simple, keep asking whether it still works when scale grows, permissions change, recovery matters, and more people collaborate on it.
Practical Checklist
- Identify where this concept sits in the system: development-time constraint, runtime behavior, infrastructure capability, or collaboration workflow.
- Write one minimal working example and one failure example; only knowing the happy path is usually not enough.
- Record common misuses: edge cases, permission assumptions, performance assumptions, sync/async differences, or environment differences.
- Connect the concept to a project experience so that an interview answer can be grounded in real tradeoffs.
- End with one sentence about tradeoff: what it gives up and what it buys.
Self-Check Questions
- What core problem does this topic solve?
- What alternatives exist, and what are their costs?
- Where are the most likely edge cases?
- How would code, tests, or monitoring prove that it is reliable?
Applied Scenario
A good scenario is a team project. Requirements are broken into deliverable tasks, code is merged through branches and pull requests, tests protect important behavior, releases have checklists, and production issues can be diagnosed with logs and monitoring. SOLID and design patterns are not decorative; they are useful when they reduce the cost of change. Every abstraction should explain what duplication or complexity it removes.
Common Pitfalls:
- Using patterns for their own sake and adding unnecessary abstraction.
- Refactoring shared logic without tests.
- Missing the feedback loop between requirements, implementation, and release.