add open close principle

Author: Surjit Kumar Sahoo

docs/1.architecture/1.separation-of-concerns.md

@@ -29,6 +29,6 @@ button
 
 You get the idea!
 
-### Additional Learning
+## Additional Learning
 
 - [Clean Code - lecture series by Robert C Martin aka Uncle Bob](https://www.youtube.com/playlist?list=PLdTodMosi-BxYqebBBI6JOQitcdUzF4YJ)

docs/1.architecture/2.single-responsibility-principle.md

@@ -92,6 +92,6 @@ render(FeedbackPopUp);
 Split the code into small pieces as much as possible, so that each piece becomes independent. Your feature should be simply a configuration file that configures all the pieces of code to work together as per the requirement. If the requirements change, you change the configurations. Not the underlying pieces of code.
 :::
 
-### Additional Learning
+## Additional Learning
 
 - [Clean Code - lecture series by Robert C Martin aka Uncle Bob](https://www.youtube.com/playlist?list=PLdTodMosi-BxYqebBBI6JOQitcdUzF4YJ)

docs/1.architecture/3.how-to-write-a-component.md

@@ -65,7 +65,7 @@ Both are React components, but conceptually they are different.
 
 - Components can be thought of as the building blocks for features.
 - Components are generic, their data structures, required props are not business requirement specific. Components should be re-usable in any given scenarios, to create any new business features without ever needing to change the components.
-- Components should be closed for modification, no matter the requirement, components should never need to change.
+- Components should be closed for modification, no matter the requirement, components should never need to change. [Read more about Open Close Principle](./4.open-close-principle-and-the-role-of-agile.md)
 - Components have robust unit tests to ensure they work as expect in all the possible scenarios.
 - You might think modal needs a gradient background header and submit/cancel/close buttons and you can configure them through props. No!, cause then it becomes a feature. Gradient background should be a separate component, buttons should be separate components and so on. Modal should just be a modal, that's it!
 - Components should be small and focused, doing one thing only. Example: button, dropdown, modal, accordion, table, card etc.
@@ -89,6 +89,6 @@ Both are React components, but conceptually they are different.
 After building a feature, refactor it by splitting out the UI and logic code into the smallest reusable pieces. Organize similar components and functions into folders as categories. And if there are several related functions, group them as class methods in a class.
 :::
 
-### Additional Learning
+## Additional Learning
 
 - [Clean Code - lecture series by Robert C Martin aka Uncle Bob](https://www.youtube.com/playlist?list=PLdTodMosi-BxYqebBBI6JOQitcdUzF4YJ)

docs/1.architecture/4.open-close-principle-and-the-role-of-agile.md

@@ -0,0 +1,24 @@
+---
+sidebar_position: 3
+---
+
+# Open Close Principle and the Role of Agile
+
+- Open-Close principle stands for "Open for extension and Closed for Modification".
+
+  - Once written, a piece of code should not be modified again (unless it's a bugFix of course) - closed for modification.
+  - In Object Oriented Programming inherit from the base class to create a new extended class with additional features.
+  - In react if we create a modal, buttons, cards, etc components, we should never need to change those components. If we need our modal look like card, we use card inside the modal, we put as many buttons where ever we need inside the modal as per the requirements.
+  - If a particular configuration / arrangements of components get's re-used multiple places, we can define it as another high level component. Such as a popup with specific spacing and styling guidelines for a particular app can be created using a base Modal component. Thus the Popup component becomes the extended component of Modal, keeping the Modal component unchanged.
+  - All the components, utilities, helpers should follow this principle.
+
+- Agile means the ability to move quickly and easily. It doesn't necessarily means to move faster, but rather jump from one feature to another or one requirement to another without much friction.
+  - From the start, on the very first implementation our code might not be perfect, that does not require any changes at all. (Closed for Modification). We need to improve the code in iterations. Sprints are for iterations.
+  - Work should be split into smaller stories and tasks. Sprints should be short, spanning 1 week or 2 weeks.
+  - Within a sprint we should be able to implement something small, or a small part of a requirement and ready to deploy. The feature might not be complete, that's OK, but it must be ready to deploy. Even the chronology of implementation should not matter, and everything should be cleanly decoupled. If we implement logout feature first, then in the next sprint login feature is planned, by the end of current sprint we should be able to deploy the logout feature.
+  - And in next sprint when we start to work on the login feature, we realize that the logout code needs some changes! That's a sign, ideally the code should never require any modification to make it work with different implementations of login. So we should take a follow up task first to refactor the logout code. If the sprints are small, we must have implemented small things, which we can refactor in no-time.
+  - The purpose of Agile is to let us know **fast** how bad our code is! The fact that our code written in previous sprint requires changing tells us that our code didn't follow open-close principle correctly! The faster we identify it, the better. Because once a heavy technical debt is accumulated, It'll get very difficult to fix!
+
+## Additional Learning
+
+- [Learn more about "Open Close" principle from the "Clean Code - lecture series" by Robert C Martin aka Uncle Bob](https://www.youtube.com/playlist?list=PLdTodMosi-BxYqebBBI6JOQitcdUzF4YJ)