diff --git a/.markdownlint.json b/.markdownlint.json index dc646ba..b5698ae 100644 --- a/.markdownlint.json +++ b/.markdownlint.json @@ -1,4 +1,7 @@ { "default": true, - "MD013": { "line_length": 150 } + "MD013": { "line_length": 150 }, + "MD024": false, + "MD033": false, + "MD041": false } diff --git a/advanced-tdd/01-advanced-tdd.md b/advanced-tdd/01-advanced-tdd.md index f82c658..98e6caa 100644 --- a/advanced-tdd/01-advanced-tdd.md +++ b/advanced-tdd/01-advanced-tdd.md @@ -5,12 +5,12 @@ subtitle: Advanced TDD # Pre-work -* Videos - * - * -* Exams - * - * +- Videos + - + - +- Exams + - + - # Chapters @@ -19,7 +19,7 @@ subtitle: Advanced TDD :::: column | Chapter | Time | -|----------------------------|----------| +| -------------------------- | -------- | | Welcome | 00:00:47 | | Core Collaps Supernova | 00:03:48 | | TDD Review: The Three Laws | 00:12:49 | @@ -29,12 +29,12 @@ subtitle: Advanced TDD :::: column -| Chapter | Time | -|----------------------------|----------| -| Incremental Algorithmics | 00:01:10 | -| Getting Stuck | 00:24:57 | -| Getting Unstuck | 00:36:02 | -| Conclusion | 00:49:24 | +| Chapter | Time | +| ------------------------ | -------- | +| Incremental Algorithmics | 00:01:10 | +| Getting Stuck | 00:24:57 | +| Getting Unstuck | 00:36:02 | +| Conclusion | 00:49:24 | :::: @@ -42,30 +42,30 @@ subtitle: Advanced TDD # Timetable -| Activity | Time | -|----------------------------|--------| -| Warmup | 5 min | -| Excercise 1 | 10 min | -| Wrap up | 5 min | +| Activity | Time | +| ----------- | ------ | +| Warmup | 5 min | +| Excercise 1 | 10 min | +| Wrap up | 5 min | # Warmup -* What ...? - * Type in the meeting chat +- What ...? + - Type in the meeting chat # Exercise 1 -* Prompt - * ... -* Time limit: ... +- Prompt + - ... +- Time limit: ... # Wrap up -* ... +- ... # What is next? -* Expect an e-mail with instructions for upcoming coding dojo +- Expect an e-mail with instructions for upcoming coding dojo # Final words diff --git a/advanced-tdd/03-clean-tests.md b/advanced-tdd/03-clean-tests.md index 7bb96dd..d983263 100644 --- a/advanced-tdd/03-clean-tests.md +++ b/advanced-tdd/03-clean-tests.md @@ -5,49 +5,49 @@ subtitle: Clean Tests # Pre-work -* Video: -* Exam: +- Video: +- Exam: # Chapters -| Chapter | Time | -|----------------------------|----------| -| Overview | 00:05:52 | -| History of the Earth | 00:08:31 | -| Anatomy of a Test | 00:20:50 | -| The Arrange | 00:29:50 | -| Setup Struggles | 00:40:56 | -| Test Hierarchy | 00:52:57 | -| Clean Composition | 01:06:04 | -| The Assertion | 01:10:30 | -| Conclusion | 01:20:58 | +| Chapter | Time | +| -------------------- | -------- | +| Overview | 00:05:52 | +| History of the Earth | 00:08:31 | +| Anatomy of a Test | 00:20:50 | +| The Arrange | 00:29:50 | +| Setup Struggles | 00:40:56 | +| Test Hierarchy | 00:52:57 | +| Clean Composition | 01:06:04 | +| The Assertion | 01:10:30 | +| Conclusion | 01:20:58 | # Timetable -| Activity | Time | -|----------------------------|--------| -| Warmup | 5 min | -| Excercise 1 | 10 min | -| Wrap up | 5 min | +| Activity | Time | +| ----------- | ------ | +| Warmup | 5 min | +| Excercise 1 | 10 min | +| Wrap up | 5 min | # Warmup -* What ...? - * Type in the meeting chat +- What ...? + - Type in the meeting chat # Exercise 1 -* Prompt - * ... -* Time limit: ... +- Prompt + - ... +- Time limit: ... # Wrap up -* ... +- ... # What is next? -* Expect an e-mail with instructions for upcoming coding dojo +- Expect an e-mail with instructions for upcoming coding dojo # Final words diff --git a/fundamentals/04-functions.md b/fundamentals/04-functions.md index 736b5b5..44719db 100644 --- a/fundamentals/04-functions.md +++ b/fundamentals/04-functions.md @@ -5,13 +5,13 @@ subtitle: Functions # Pre-work -* Video: -* Exam: +- Video: +- Exam: # Timetable | Activity | Time | -|------------|--------| +| ---------- | ------ | | Warmup | 5 min | | Exercise 1 | 20 min | | Exercise 2 | 20 min | @@ -20,49 +20,49 @@ subtitle: Functions # Warmup -* What are some "landmarks" you look for when you're reading code? - * Type in the meeting chat +- What are some "landmarks" you look for when you're reading code? + - Type in the meeting chat # Exercise 1 -* Prompt - * How to safely refactor code without breaking it? Discuss possible strategies. - * What to do if code is not covered by tests? -* Time limit: 10 minutes +- Prompt + - How to safely refactor code without breaking it? Discuss possible strategies. + - What to do if code is not covered by tests? +- Time limit: 10 minutes # Safe refactoring -* **Refactoring** is a process of - * restructuring existing code - * without changing its external behavior -* Safe refactoring - * Put the system under a test - * Run tests often - * Understand test coverage to avoid blind spots +- **Refactoring** is a process of + - restructuring existing code + - without changing its external behavior +- Safe refactoring + - Put the system under a test + - Run tests often + - Understand test coverage to avoid blind spots # Common approach to working with legacy code -* Create a "characterization test" that captures the current behavior -* Restructure the code to enable testing of a specific part of the code -* Write a test for wanted behavior that fails -* Implement the behavior to make the test pass +- Create a "characterization test" that captures the current behavior +- Restructure the code to enable testing of a specific part of the code +- Write a test for wanted behavior that fails +- Implement the behavior to make the test pass # Characterization test -* This test has many names - * "Characterization test" - * "Golden Master" - * "Snapshot test" -* Characterization test checks general behavior - * Uses fixed seed for program inputs - * Checks that the output is the same as the previous run +- This test has many names + - "Characterization test" + - "Golden Master" + - "Snapshot test" +- Characterization test checks general behavior + - Uses fixed seed for program inputs + - Checks that the output is the same as the previous run # Exercise 2 -* Prompt - * What code behavior do you find suspicious and why? - * What "code smells" do you find useful and why? -* Time limit: 10 minutes +- Prompt + - What code behavior do you find suspicious and why? + - What "code smells" do you find useful and why? +- Time limit: 10 minutes # Code smells [catalog](https://refactoring.guru/refactoring/smells) @@ -70,39 +70,39 @@ subtitle: Functions :::: column -* Bloaters - * Long method - * Long parameter list - * Data clumps - * Primitive obsession - * Long class -* Object-Orientation Abusers - * Switch statements - * Refused bequest - * Alternative classes with different interfaces - * Temporary field -* Change Preventers - * Divergent change - * Shotgun surgery - * Parallel inheritance hierarchies +- Bloaters + - Long method + - Long parameter list + - Data clumps + - Primitive obsession + - Long class +- Object-Orientation Abusers + - Switch statements + - Refused bequest + - Alternative classes with different interfaces + - Temporary field +- Change Preventers + - Divergent change + - Shotgun surgery + - Parallel inheritance hierarchies :::: :::: column -* Dispensables - * Lazy class - * Data class - * Comments - * Duplicate code - * Dead code - * Speculative generality -* Couplers - * Feature envy - * Inappropriate intimacy - * Incomplete library class - * Message chains - * Middle man +- Dispensables + - Lazy class + - Data class + - Comments + - Duplicate code + - Dead code + - Speculative generality +- Couplers + - Feature envy + - Inappropriate intimacy + - Incomplete library class + - Message chains + - Middle man :::: @@ -110,43 +110,43 @@ subtitle: Functions # "Feature envy" code smell -* Definition - * A method accesses the data of another object more than its own data -* Possible reason - * After fields move to a data class/structure -* Treatment - * Move operations on data to the class as well +- Definition + - A method accesses the data of another object more than its own data +- Possible reason + - After fields move to a data class/structure +- Treatment + - Move operations on data to the class as well # Exercise 3 -* Prompt - * How to define if a function is doing "one thing"? -* Time limit: 10 minutes +- Prompt + - How to define if a function is doing "one thing"? +- Time limit: 10 minutes # Where classes hide -* Classes hide in long functions with many local variables -* Functions that fill the screen are likely doing more than one thing -* Functions crossing levels of abstraction +- Classes hide in long functions with many local variables +- Functions that fill the screen are likely doing more than one thing +- Functions crossing levels of abstraction # "Extract class" refactoring -* Create characterizations test -- run often -* Extract function body to a new class's `invoke` method -* Extract local variables to fields -* Extract methods or new classes -* Repeat until you can't extract anymore +- Create characterizations test -- run often +- Extract function body to a new class's `invoke` method +- Extract local variables to fields +- Extract methods or new classes +- Repeat until you can't extract anymore # Wrap up -* Functions should be small -* Functions should do one thing -* Functions should have one level of abstraction -* Functions should have descriptive names +- Functions should be small +- Functions should do one thing +- Functions should have one level of abstraction +- Functions should have descriptive names # What is next? -* Expect an e-mail with instructions for upcoming coding dojo +- Expect an e-mail with instructions for upcoming coding dojo # Final words diff --git a/fundamentals/06-function-structure.md b/fundamentals/06-function-structure.md index 4aa34ca..36d9238 100644 --- a/fundamentals/06-function-structure.md +++ b/fundamentals/06-function-structure.md @@ -5,8 +5,8 @@ subtitle: Function Structure # Pre-work -* Video: -* Exam: +- Video: +- Exam: # Chapters @@ -14,28 +14,28 @@ subtitle: Function Structure :::: column -| Chapter | Time | -|----------------------------|----------| -| Overview | 00:00:55 | -| Fusion | 00:04:29 | -| Arguments | 00:09:09 | -| Three Arguments Max | 00:10:10 | -| No Boolean Arguments Ever | 00:12:19 | -| Innies not Outies | 00:14:00 | -| The Null Defense | 00:15:27 | -| The Stepdown Rule | 00:17:22 | -| Switches and Cases | 00:28:24 | -| Paradigms | 00:40:51 | -| Functional Programming | 00:41:31 | -| Side Effects | 00:43:28 | -| Command Query Separation | 00:47:28 | +| Chapter | Time | +| ------------------------- | -------- | +| Overview | 00:00:55 | +| Fusion | 00:04:29 | +| Arguments | 00:09:09 | +| Three Arguments Max | 00:10:10 | +| No Boolean Arguments Ever | 00:12:19 | +| Innies not Outies | 00:14:00 | +| The Null Defense | 00:15:27 | +| The Stepdown Rule | 00:17:22 | +| Switches and Cases | 00:28:24 | +| Paradigms | 00:40:51 | +| Functional Programming | 00:41:31 | +| Side Effects | 00:43:28 | +| Command Query Separation | 00:47:28 | :::: :::: column | Chapter | Time | -|----------------------------|----------| +| -------------------------- | -------- | | Tell, Don't Ask | 00:51:35 | | Structured Programming | 00:56:32 | | Early Returns | 01:00:13 | @@ -56,125 +56,125 @@ subtitle: Function Structure # Timetable -| Activity | Time | -|----------------------------|--------| -| Warmup | 5 min | -| Exercise 1 | 20 min | -| Exercise 2 | 20 min | -| Exercise 3 | 20 min | -| Wrap up | 5 min | +| Activity | Time | +| ---------- | ------ | +| Warmup | 5 min | +| Exercise 1 | 20 min | +| Exercise 2 | 20 min | +| Exercise 3 | 20 min | +| Wrap up | 5 min | # Warmup -* In your practice, what do you find the most useful technique to organize code - within a function or a class? - * Type in the meeting chat +- In your practice, what do you find the most useful technique to organize code + within a function or a class? + - Type in the meeting chat # Exercise 1 -* Prompt - * Collaborate to build the list of principles and techniques your learned +- Prompt + - Collaborate to build the list of principles and techniques your learned from the video episode. - * You must have at least 10 principles and techniques. -* Time limit: 10 minutes + - You must have at least 10 principles and techniques. +- Time limit: 10 minutes # Possible answer -* Function signature should be small - 3 or less arguments -* Avoid "output" arguments -* Avoid passing boolean values and null -* Limit the use of switch statements to top-level factory functions -* Limit the interdependencies by using the principle of the least knowledge -* "Pass a block" to solve the temporal coupling problem -* Use early returns to reduce the nesting level -* Avoid breaks/returns in a middle of a loop -* Prefer exceptions to error codes -* Separate commands and queries -* Tell, don't ask +- Function signature should be small - 3 or less arguments +- Avoid "output" arguments +- Avoid passing boolean values and null +- Limit the use of switch statements to top-level factory functions +- Limit the interdependencies by using the principle of the least knowledge +- "Pass a block" to solve the temporal coupling problem +- Use early returns to reduce the nesting level +- Avoid breaks/returns in a middle of a loop +- Prefer exceptions to error codes +- Separate commands and queries +- Tell, don't ask # Design patterns -* Definition - * A general reusable solution to a commonly occurring problem within a given +- Definition + - A general reusable solution to a commonly occurring problem within a given context in software design. - * A template for how to solve a problem that can be used in many different + - A template for how to solve a problem that can be used in many different situations. -* Examples - * [Null Object](https://en.wikipedia.org/wiki/Null_object_pattern) - * [Factory](https://en.wikipedia.org/wiki/Factory_method_pattern) -* Categories - * Creational - * Structural - * Behavioral - * Concurrency -* Catalog - * [Design Patterns](https://refactoring.guru/design-patterns) - * [Software design pattern](https://en.wikipedia.org/wiki/Software_design_pattern) +- Examples + - [Null Object](https://en.wikipedia.org/wiki/Null_object_pattern) + - [Factory](https://en.wikipedia.org/wiki/Factory_method_pattern) +- Categories + - Creational + - Structural + - Behavioral + - Concurrency +- Catalog + - [Design Patterns](https://refactoring.guru/design-patterns) + - [Software design pattern](https://en.wikipedia.org/wiki/Software_design_pattern) # Exercise 2 -* Prompt - * Introduce categories to split items from Exercise 1 into - * Make sure to create at least 3 categories - * Make sure to create an effective list! -* Time limit: 10 minutes +- Prompt + - Introduce categories to split items from Exercise 1 into + - Make sure to create at least three categories + - Make sure to create an effective list! +- Time limit: 10 minutes # Possible answer -* Simplify function signature - * Function signature should be small - 3 or less arguments - * Avoid "output" arguments - * Avoid passing boolean values and null -* Reduce coupling - * Limit the use of switch statements to top-level factory functions - * Limit the interdependencies by using the principle of the least knowledge - * "Pass a block" to solve the temporal coupling problem -* Clarify control flow - * Use early returns to reduce the nesting level - * Avoid breaks/returns in a middle of a loop - * Prefer exceptions to error codes -* Clarify state management - * Separate commands and queries - * Tell, don't ask +- Simplify function signature + - Function signature should be small -- three or less arguments + - Avoid "output" arguments + - Avoid passing boolean values and null +- Reduce coupling + - Limit the use of switch statements to top-level factory functions + - Limit the interdependencies by using the principle of the least knowledge + - "Pass a block" to solve the temporal coupling problem +- Clarify control flow + - Use early returns to reduce the nesting level + - Avoid breaks/returns in a middle of a loop + - Prefer exceptions to error codes +- Clarify state management + - Separate commands and queries + - Tell, don't ask # Exercise 3 -* Prompt - * Select top 3 principles and techniques from Exercise 1 by the highest ROI - * High return, low time effort cost - * Refer to your experience, if applies - * Explain and justify your choice -* Time limit: 10 minutes +- Prompt + - Select top 3 principles and techniques from Exercise 1 by the highest ROI + - High return, low time effort cost + - Refer to your experience, if applies + - Explain and justify your choice +- Time limit: 10 minutes # Possible answer 1. User early returns - * Low effort - * Clarifies the control flow + - Low effort + - Clarifies the control flow 2. "Pass a block" to solve the temporal coupling problem - * Medium effort - * Helps to avoid critical bugs in resource management + - Medium effort + - Helps to avoid critical bugs in resource management 3. Avoid "output" arguments - * Medium effort - * Make code more readable and less error-prone + - Medium effort + - Make code more readable and less error-prone # Summary -* Simplify function signature - * Function signature should be small - 3 or less arguments - * Avoid "output" arguments - * Avoid passing boolean values and null -* Reduce coupling - * Limit the use of switch statements to top-level factory functions - * Limit the interdependencies by using the principle of the least knowledge - * "Pass a block" to solve the temporal coupling problem -* Clarify control flow - * Use early returns to reduce the nesting level - * Avoid breaks/returns in a middle of a loop - * Prefer exceptions to error codes -* Clarify state management - * Separate commands and queries - * Tell, don't ask +- Simplify function signature + - Function signature should be small - 3 or less arguments + - Avoid "output" arguments + - Avoid passing boolean values and null +- Reduce coupling + - Limit the use of switch statements to top-level factory functions + - Limit the interdependencies by using the principle of the least knowledge + - "Pass a block" to solve the temporal coupling problem +- Clarify control flow + - Use early returns to reduce the nesting level + - Avoid breaks/returns in a middle of a loop + - Prefer exceptions to error codes +- Clarify state management + - Separate commands and queries + - Tell, don't ask # Wrap-up @@ -182,10 +182,9 @@ subtitle: Function Structure Next 7 days focus on using the techniques from this episode in your day-to-day work. - # What is next? -* Expect an e-mail with instructions for upcoming coding dojo +- Expect an e-mail with instructions for upcoming coding dojo # Final words diff --git a/fundamentals/08-form.md b/fundamentals/08-form.md index 0b271c9..33e0819 100644 --- a/fundamentals/08-form.md +++ b/fundamentals/08-form.md @@ -5,8 +5,8 @@ subtitle: Form # Pre-work -* Video: -* Exam: +- Video: +- Exam: # Chapters @@ -15,7 +15,7 @@ subtitle: Form :::: column | Chapter | Time | -|-------------------------|----------| +| ----------------------- | -------- | | Overview | 00:00:51 | | Sol's Pyre | 00:03:57 | | Comments | 00:11:12 | @@ -32,7 +32,7 @@ subtitle: Form :::: column | Chapter | Time | -|------------------------|----------| +| ---------------------- | -------- | | Formatting | 00:33:23 | | File Size | 00:34:23 | | Vertical Formatting | 00:37:35 | @@ -51,7 +51,7 @@ subtitle: Form # Timetable | Activity | Time | -|------------|--------| +| ---------- | ------ | | Warmup | 5 min | | Exercise 1 | 20 min | | Exercise 2 | 20 min | @@ -60,42 +60,42 @@ subtitle: Form # Warmup -* What are your formatting preferences? - (e.g. tabs vs spaces, 2 spaces vs 4 spaces, `snake_case` vs `camelCase`, etc.) - * Type in the meeting chat +- What are your formatting preferences? (e.g., tabs vs spaces, + 2 spaces vs 4 spaces, `snake_case` vs `camelCase`, etc.) + - Type in the meeting chat # Exercise 1 -* Prompt - * Compare classes and data structures -* Time limit: 10 minutes +- Prompt + - Compare classes and data structures +- Time limit: 10 minutes # Possible answer -* Classes - * Cohesive data and functions that operate on that data - * Private data, public functions - * Tell, don't ask - * Polymorphism - * Protects from new types, exposes to new methods -* Data Structures - * Cohesive data, simple functions like getters and setters - * Public data - * Ask, don't tell - * Switch statements - * Protects from new methods, exposes to new types +- Classes + - Cohesive data and functions that operate on that data + - Private data, public functions + - Tell, don't ask + - Polymorphism + - Protects from new types, exposes to new methods +- Data Structures + - Cohesive data, simple functions like getters and setters + - Public data + - Ask, don't tell + - Switch statements + - Protects from new methods, exposes to new types # Exercise 2 -* Code-review practice (part 1) -* Use the worksheet -* Go through scenarios 1-3 -* Suggest code improvements, and explain why - * Use the worksheet to record your suggestions - * Use active voice (e.g. "introduce parameter object" instead of "parameter - object should be introduced") -* Time limit: 15 minutes -* Scenarios adopted from [Eder Diaz blog](https://ederdiaz.dev/blog/clean-code-exercises-part-1/) +- Code-review practice (part 1) +- Use the worksheet +- Go through scenarios 1-3 +- Suggest code improvements, and explain why + - Use the worksheet to record your suggestions + - Use active voice (e.g., "introduce parameter object" instead of "parameter + object should be introduced") +- Time limit: 15 minutes +- Scenarios adopted from [Eder Diaz blog](https://ederdiaz.dev/blog/clean-code-exercises-part-1/) # Scenario 1 @@ -109,8 +109,8 @@ def can_buy_beer(age, money): # Scenario 1 solution -* Introduce constants to clarify the *magic numbers* -* Collapse if-statement when evaluating boolean expressions +- Introduce constants to clarify the _magic numbers_ +- Collapse if-statement when evaluating boolean expressions ```python LEGAL_DRINKING_AGE = 21 @@ -136,13 +136,13 @@ def should_show_image(item_index, article, show_all_images): Ternary operators note: -* C++: `condition ? a : b` -* Python: `a if condition else b` +- C++: `condition ? a : b` +- Python: `a if condition else b` # Scenario 2 solution -* Use explanatory variables to clarify sub-expressions -* Remove code duplication +- Use explanatory variables to clarify sub-expressions +- Remove code duplication ```python def should_show_image(item_index, article, show_all_images): @@ -169,8 +169,8 @@ def get_area(shape, width, height, radius): # Scenario 3 solution -* Introduce polymorphism to protect from new shapes -* Replace shape names with classes to make it less error-prone +- Introduce polymorphism to protect from new shapes +- Replace shape names with classes to make it less error-prone ```python import abc @@ -193,14 +193,14 @@ class Circle(Shape): # Exercise 3 -* Code-review practice (part 2) -* Use the worksheet -* Go through scenarios 4-6 -* Suggest code improvements, and explain why - * Use the worksheet to record your suggestions - * Use active voice (e.g. "introduce parameter object" instead of "parameter - object should be introduced") -* Time limit: 15 minutes +- Code-review practice (part 2) +- Use the worksheet +- Go through scenarios 4-6 +- Suggest code improvements, and explain why + - Use the worksheet to record your suggestions + - Use active voice (e.g. "introduce parameter object" instead of "parameter + object should be introduced") +- Time limit: 15 minutes # Scenario 4 @@ -224,8 +224,8 @@ def get_symbol(name): # Scenario 4 solution -* Introduce error handling -* Use PEP8 naming conventions +- Introduce error handling +- Use PEP8 naming conventions ```python class SymbolNotFoundError(Exception): @@ -264,8 +264,8 @@ def get_display_image(article, watermark=None): # Scenario 5 solution 1 -* Use early return to separate main logic from corner cases -* Use separate function for `watermark=None` argument +- Use early return to separate main logic from corner cases +- Use separate function for `watermark=None` argument ```python def has_image_and_display_image(article): @@ -286,7 +286,7 @@ def get_display_image(article): # Scenario 5 solution 2 -* Introduce a class +- Introduce a class ```python class Article: @@ -314,17 +314,17 @@ class Article: # The code checks if auth is enabled, if it's enforced, # and if user already registered (has email field). if ( - type(AUTH_ENABLED) == str and - AUTH_ENABLED == "true" and # enabled! - not skip_authentication and # enforced!! - user.email # already registered!!! + type(AUTH_ENABLED) == str + and AUTH_ENABLED == "true" # enabled! + and not skip_authentication # enforced!! + and user.email # already registered!!! ): print(f"Welcome back, {user.name}") ``` # Scenario 6 solution -* Replace comments with explanatory variables +- Replace comments with explanatory variables ```python is_auth_enabled = AUTH_ENABLED == "true" @@ -337,14 +337,14 @@ if is_auth_enforced and is_registered_user: # Summary -* Comments -* Formatting -* Classes vs data structures -* Abstraction boundaries +- Comments +- Formatting +- Classes vs data structures +- Abstraction boundaries # What is next? -* Expect an e-mail with instructions for upcoming coding dojo +- Expect an e-mail with instructions for upcoming coding dojo # Final words diff --git a/fundamentals/10-tdd.md b/fundamentals/10-tdd.md index d5e20bb..706caef 100644 --- a/fundamentals/10-tdd.md +++ b/fundamentals/10-tdd.md @@ -5,8 +5,8 @@ subtitle: TDD # Pre-work -* Video: -* Exam: +- Video: +- Exam: # Chapters @@ -15,7 +15,7 @@ subtitle: TDD :::: column | Chapter | Time | -|-----------------------|-------| +| --------------------- | ----- | | Overview | 00:53 | | Fear & Code Rot | 04:47 | | The Big Clean Up | 07:02 | @@ -29,7 +29,7 @@ subtitle: TDD :::: column | Chapter | Time | -|-------------------|-------| +| ----------------- | ----- | | Debugging Time | 37:45 | | Design documents | 41:24 | | Decoupling | 43:15 | @@ -44,7 +44,7 @@ subtitle: TDD # Timetable | Activity | Time | -|------------|--------| +| ---------- | ------ | | Warmup | 5 min | | Exercise 1 | 20 min | | Exercise 2 | 20 min | @@ -53,83 +53,83 @@ subtitle: TDD # Warmup -* What tools and frameworks do you use for testing? - * Type in the meeting chat +- What tools and frameworks do you use for testing? + - Type in the meeting chat # Exercise 1 -* Prompt - * What kind of changes to the code would you do if you had a comprehensive - set of unit tests? -* Time limit: 10 minutes +- Prompt + - What kind of changes to the code would you do if you had a comprehensive + set of unit tests? +- Time limit: 10 minutes # Possible answers -* Use better names according to their scope to communicate intent -* Extract explanatory variables to improve readability -* Extract methods and classes to reduce duplication -* Remove unused code to reduce complexity -* Format code to improve readability -* Optimize slow code to improve performance +- Use better names according to their scope to communicate intent +- Extract explanatory variables to improve readability +- Extract methods and classes to reduce duplication +- Remove unused code to reduce complexity +- Format code to improve readability +- Optimize slow code to improve performance # Exercise 2 -* Prompt - * List and categorize different kinds of software testing - * Which ones are compatible with TDD? -* Time limit: 10 minutes +- Prompt + - List and categorize different kinds of software testing + - Which ones are compatible with TDD? +- Time limit: 10 minutes # The testing pyramid -* Unit tests (bottom) - * Test smallest possible unit of code - * Focused on testing individual parts of the system - * Fast -* Integration tests (middle) - * Test how different parts of the system work together - * Focused on testing the interactions between different parts of the system - * Slower -* End-to-end tests (top) - * Test the system from the user's perspective - * Focused on testing the system as a whole - * Slowest +- Unit tests (bottom) + - Test smallest possible unit of code + - Focused on testing individual parts of the system + - Fast +- Integration tests (middle) + - Test how different parts of the system work together + - Focused on testing the interactions between different parts of the system + - Slower +- End-to-end tests (top) + - Test the system from the user's perspective + - Focused on testing the system as a whole + - Slowest # Exercise 3 -* Three Laws of TDD - * Write _NO_ production code except to pass a failing test - * Write only _enough_ of a test to demonstrate a failure - * Write only _enough_ production code to pass the test -* Prompt - * What objections do _you_ have to TDD? Discuss objections and see if you - can come to an agreement. -* Time limit: 10 minutes +- Three Laws of TDD + - Write _NO_ production code except to pass a failing test + - Write only _enough_ of a test to demonstrate a failure + - Write only _enough_ production code to pass the test +- Prompt + - What objections do _you_ have to TDD? Discuss objections and see if you + can come to an agreement. +- Time limit: 10 minutes # Discussion -* Groups to share their findings +- Groups to share their findings # Summary -* TDD is a technique to write code that is easy to change - * Eliminates fear of change - * Increases confidence in code - * Reduces debugging time - * Helps you create more decoupled code - * Prevents code rot -* TDD uses three laws - * Write _NO_ production code except to pass a failing test - * Write only _enough_ of a test to demonstrate a failure - * Write only _enough_ production code to pass the test +- TDD is a technique to write code that is easy to change + - Eliminates fear of change + - Increases confidence in code + - Reduces debugging time + - Helps you create more decoupled code + - Prevents code rot +- TDD uses three laws + - Write _NO_ production code except to pass a failing test + - Write only _enough_ of a test to demonstrate a failure + - Write only _enough_ production code to pass the test # What is next? -* Next session - * Continue the topic of Test Driven Development - * There will the next video to watch - TDD Part 2 - * 2/3 of the session will be coding dojo - * 1/3 of the session will be discussion -* Expect an e-mail with instructions for upcoming coding dojo +- Next session + - Continue the topic of Test Driven Development + - There will the next video to watch - TDD Part 2 + - 2/3 of the session will be coding dojo + - 1/3 of the session will be discussion +- Expect an e-mail with instructions for upcoming coding dojo # Final words diff --git a/fundamentals/12-polly.md b/fundamentals/12-polly.md index 4a1a589..956925a 100644 --- a/fundamentals/12-polly.md +++ b/fundamentals/12-polly.md @@ -5,7 +5,7 @@ subtitle: Polly want a message # Pre-work -* Video: +- Video: # Chapters @@ -14,7 +14,7 @@ subtitle: Polly want a message :::: column | Chapter | Time | -|-----------------------------|-------| +| --------------------------- | ----- | | Design stamina hypothesis | 03:50 | | Procedures vs. OO | 05:59 | | Churn vs. complexity | 07:49 | @@ -27,7 +27,7 @@ subtitle: Polly want a message :::: column | Chapter | Time | -|---------------------------------|-------| +| ------------------------------- | ----- | | Anthropomorphic polymorphic | 24:24 | | Resolution | 29:55 | | Isolate thing you want to vary | 32:13 | @@ -42,7 +42,7 @@ subtitle: Polly want a message # Timetable | Activity | Time | -|------------|--------| +| ---------- | ------ | | Warmup | 5 min | | Exercise 1 | 30 min | | Exercise 2 | 30 min | @@ -51,122 +51,124 @@ subtitle: Polly want a message # Warmup -* Do you have the "death star" anti-pattern examples from your code? - * Type in the meeting chat +- Do you have the "death star" anti-pattern examples from your code? + - Type in the meeting chat # Exercise 1 -* Prompt - 1. How object-oriented design principles can improve (or detract) the - success of a project or application? - 2. Are there any similarities or differences between OOP and TDD? -* Time limit: 10 minutes +- Prompt + 1. How object-oriented design principles can improve (or detract) the + success of a project or application? + 2. Are there any similarities or differences between OOP and TDD? +- Time limit: 10 minutes # Discussion -* Groups to share their findings +- Groups to share their findings # Possible answers -* Pros - * Modularity and reusability - * Can reduce time and effort required to develop and maintain the code - * Abstraction and encapsulation - * Hides the implementation details, making the code more readable - * Flexibility and adaptability - * Loose coupling and polymorphism makes it easier to change or update - individual objects without affecting the rest of the system - * Improved debugging and testing - * Makes it easier to isolate and debug individual objects - -* Cons - * If not properly applied, can lead to complex and hard-to-maintain code, - or overly complex class hierarchies ("Faux OO") - * Not always the best fit for every type of problem or project +- Pros + - Modularity and reusability + - Can reduce time and effort required to develop and maintain the code + - Abstraction and encapsulation + - Hides the implementation details, making the code more readable + - Flexibility and adaptability + - Loose coupling and polymorphism makes it easier to change or update + individual objects without affecting the rest of the system + - Improved debugging and testing + - Makes it easier to isolate and debug individual objects + +- Cons + - If not properly applied, can lead to complex and hard-to-maintain code, + or overly complex class hierarchies ("Faux OO") + - Not always the best fit for every type of problem or project # Exercise 2 -* Dependency injection - * Design pattern that involves passing objects as dependencies to an - object, rather than creating these dependencies within the object itself - -* Prompt - * Discuss the benefits and challenges of using dependency injection in - a project that involves multiple objects that depend on each other - * Consider the following questions: - 1. How does dependency injection help decouple the objects in the - project? - 2. What are the trade-offs of using dependency injection versus - creating dependencies within the objects themselves? - 3. How does dependency injection impact the maintainability and - scalability of the project? - 4. Can you think of a real-world example where dependency injection - would be useful? -* Time limit: 15 minutes +- Dependency injection + - Design pattern that involves passing objects as dependencies to an + object, rather than creating these dependencies within the object itself + +- Prompt + - Discuss the benefits and challenges of using dependency injection in + a project that involves multiple objects that depend on each other + - Consider the following questions: + 1. How does dependency injection help decouple the objects in the + project? + 2. What are the trade-offs of using dependency injection versus + creating dependencies within the objects themselves? + 3. How does dependency injection impact the maintainability and + scalability of the project? + 4. Can you think of a real-world example where dependency injection + would be useful? +- Time limit: 15 minutes # Discussion -* Groups to share their findings +- Groups to share their findings # Exercise 3 -* What is polymorphism - * The quality where different kinds of objects can respond to the same - message - * Objects can take on many forms and behave differently based on context +- What is polymorphism + - The quality where different kinds of objects can respond to the same + message + - Objects can take on many forms and behave differently based on context -* Prompt - 1. How does polymorphism make code more expressive and modular? - 2. What are the trade-offs of using polymorphism, and how to mitigate them? - 3. How can you test code with polymorphism, and what are the challenges? -* Time limit: 10 minutes +- Prompt + 1. How does polymorphism make code more expressive and modular? + 2. What are the trade-offs of using polymorphism, and how to mitigate them? + 3. How can you test code with polymorphism, and what are the challenges? +- Time limit: 10 minutes # Discussion -* Groups to share their findings +- Groups to share their findings # Possible answers -* How does polymorphism make code more expressive and modular? - * Creates a more dynamic code, as the same message can have different - effects on different objects - * Leads to more modular code, as different implementations of a message can - be separated into different classes; easier to reuse and maintain the code +- How does polymorphism make code more expressive and modular? + + - Creates a more dynamic code, as the same message can have different + effects on different objects + - Leads to more modular code, as different implementations of a message can + be separated into different classes; easier to reuse and maintain the code -* What are the trade-offs of using polymorphism, and how to mitigate them? - * Can make the code harder to understand and maintain since the same - message can have different effects on different objects - * Can lead to runtime errors if the message is sent to an object that - doesn't have an implementation of that message +- What are the trade-offs of using polymorphism, and how to mitigate them? -* How can you test code with polymorphism, and what are the challenges? - * Test the behavior of each implementation of a message - * Ensure that the code functions correctly when you send messages to objects - of different types + - Can make the code harder to understand and maintain since the same + message can have different effects on different objects + - Can lead to runtime errors if the message is sent to an object that + doesn't have an implementation of that message + +- How can you test code with polymorphism, and what are the challenges? + - Test the behavior of each implementation of a message + - Ensure that the code functions correctly when you send messages to objects + of different types # Summary -* OOP affords ... objects - * Anthropomorphic - * The attribution of human traits, emotions or intentions to non-human - entities - * Polymorphic - * The quality where different kinds of objects can respond to the same - message - * Loosely-coupled - * Objects strive for independence - * Role-playing - * Objects are more players of their roles than instances of their types - * Factory-created - * Factories hide the rules of picking the right player for a role - * Message-sending - * "I know what I want, you know how to do it" +- OOP affords ... objects + - Anthropomorphic + - The attribution of human traits, emotions or intentions to non-human + entities + - Polymorphic + - The quality where different kinds of objects can respond to the same + message + - Loosely-coupled + - Objects strive for independence + - Role-playing + - Objects are more players of their roles than instances of their types + - Factory-created + - Factories hide the rules of picking the right player for a role + - Message-sending + - "I know what I want, you know how to do it" # What is next? -* Next session - * We will do dojo of participants' choice -* Expect an e-mail with instructions for upcoming coding dojo +- Next session + - We will do dojo of participants' choice +- Expect an e-mail with instructions for upcoming coding dojo # Final words diff --git a/solid/01-foundations-worksheet.md b/solid/01-foundations-worksheet.md index 99fccf0..cd14ca0 100644 --- a/solid/01-foundations-worksheet.md +++ b/solid/01-foundations-worksheet.md @@ -1,13 +1,13 @@ # Exercise 1 -* Prompt - - Share your approach to software development with the group - - What are the similarities and differences between your approaches? -* Time limit: 15 minutes +- Prompt + - Share your approach to software development with the group + - What are the similarities and differences between your approaches? +- Time limit: 15 minutes # Exercise 2 -* Prompt - - Provide examples of your favorite design patterns and programming idioms - - How do you use them? -* Time limit: 15 minutes +- Prompt + - Provide examples of your favorite design patterns and programming idioms + - How do you use them? +- Time limit: 15 minutes diff --git a/solid/01-foundations.md b/solid/01-foundations.md index 73790b7..6805689 100644 --- a/solid/01-foundations.md +++ b/solid/01-foundations.md @@ -5,8 +5,8 @@ subtitle: Foundations of the SOLID Principles # Pre-work -* Video: -* Exam: +- Video: +- Exam: # Chapters @@ -15,7 +15,7 @@ subtitle: Foundations of the SOLID Principles :::: column | Chapter | Time | -|-------------------------------|-------| +| ----------------------------- | ----- | | Overview | 00:44 | | Special Relativity | 04:45 | | The Source Code is the Design | 11:14 | @@ -31,7 +31,7 @@ subtitle: Foundations of the SOLID Principles :::: column | Chapter | Time | -|-----------------------|-------| +| --------------------- | ----- | | Code Rot | 30:37 | | Version Two | 33:54 | | Version Three | 35:57 | @@ -49,7 +49,7 @@ subtitle: Foundations of the SOLID Principles # Timetable | Activity | Time | -|--------------------------------------|--------| +| ------------------------------------ | ------ | | Warmup | 5 min | | Exercise 1 | 15 min | | Three levels of software development | 15 min | @@ -60,116 +60,116 @@ subtitle: Foundations of the SOLID Principles # Warmup -* How do you manage dependencies in your code? - - Type in the meeting chat +- How do you manage dependencies in your code? + - Type in the meeting chat # Exercise 1 -* Prompt - - Share your approach to software development with the group - - What are the similarities and differences between your approaches? -* Time limit: 15 minutes +- Prompt + - Share your approach to software development with the group + - What are the similarities and differences between your approaches? +- Time limit: 15 minutes # Discussion -* Groups to share their findings +- Groups to share their findings # Three levels of software development -* Software Architecture -* Software Design -* Implementation Details +- Software Architecture +- Software Design +- Implementation Details ![The three levels of software development](img/sw-dev-levels.png) # Software Architecture -* Overall strategy of software approach -* Focuses on big decisions that are hard to change later -* Involves architectural patterns (e.g., client-server, microservices) -* Defines structure and interdependencies among key entities (modules, components) +- Overall strategy of software approach +- Focuses on big decisions that are hard to change later +- Involves architectural patterns (e.g., client-server, microservices) +- Defines structure and interdependencies among key entities (modules, components) # Software Design -* Tactics to make architecture strategy work -* Addresses interaction of software entities and dependencies -* Utilizes design patterns (e.g., Visitor, Strategy, Decorator) -* Helps break down complex systems into manageable pieces +- Tactics to make architecture strategy work +- Addresses interaction of software entities and dependencies +- Utilizes design patterns (e.g., Visitor, Strategy, Decorator) +- Helps break down complex systems into manageable pieces # Implementation Details -* Most concrete level of software development -* Focuses on actual implementation of solutions -* Addresses memory acquisition, exception safety, performance, etc. -* Includes implementation patterns and language idioms (best practices) +- Most concrete level of software development +- Focuses on actual implementation of solutions +- Addresses memory acquisition, exception safety, performance, etc. +- Includes implementation patterns and language idioms (best practices) # Idioms -* Can fall into Implementation Details or Software Design categories -* Address problems at implementation or design level -* Examples - - C++ idioms: - - RAII (Resource Acquisition Is Initialization) - - Copy-and-swap idiom - - Pimpl idiom - - Python idioms: - - List comprehensions - - Context managers (with statement) - - Decorators +- Can fall into Implementation Details or Software Design categories +- Address problems at implementation or design level +- Examples + - C++ idioms: + - RAII (Resource Acquisition Is Initialization) + - Copy-and-swap idiom + - Pimpl idiom + - Python idioms: + - List comprehensions + - Context managers (with statement) + - Decorators # Exercise 2 -* Prompt - - Provide examples of your favorite design patterns and programming idioms - - How do you use them? -* Time limit: 15 minutes +- Prompt + - Provide examples of your favorite design patterns and programming idioms + - How do you use them? +- Time limit: 15 minutes # Discussion -* Groups to share their findings +- Groups to share their findings # Software design goals -* Design for change -* Design for testability -* Design for extension +- Design for change +- Design for testability +- Design for extension # Design for change -* Embrace change as an inherent part of software development -* Avoid combining unrelated, orthogonal aspects to prevent coupling -* Avoid premature abstraction if you are not sure about the next change +- Embrace change as an inherent part of software development +- Avoid combining unrelated, orthogonal aspects to prevent coupling +- Avoid premature abstraction if you are not sure about the next change # Design for testability -* Understand tests are your protection layer against accidentally breaking things -* Separate concerns for the sake of testability -* Consider private member functions that need testing to be misplaced +- Understand tests are your protection layer against accidentally breaking things +- Separate concerns for the sake of testability +- Consider private member functions that need testing to be misplaced # Design for extension -* Favor design that makes it easy to extend code -* Design for code additions by all means of feature of your language - - base classes - - templates - - function overloading - - template specialization -* Avoid premature abstraction if you are not sure about the next addition +- Favor design that makes it easy to extend code +- Design for code additions by all means of feature of your language + - base classes + - templates + - function overloading + - template specialization +- Avoid premature abstraction if you are not sure about the next addition # Summary -* Treat software design as an essential part of writing software. -* Understand software design as the art of managing dependencies and abstractions. -* Consider the boundary between software design and software architecture as fluid. -* Design for easy change and make software more adaptable. -* Avoid unnecessary coupling and dependencies to make software more adaptable to - frequent changes. +- Treat software design as an essential part of writing software +- Understand software design as the art of managing dependencies and abstractions +- Consider the boundary between software design and software architecture as fluid +- Design for easy change and make software more adaptable +- Avoid unnecessary coupling and dependencies to make software more adaptable to + frequent changes # What is next? -* Next session - - Discussion session on the Single Responsibility Principle - - Watch episode 9 - The Single Responsibility Principle +- Next session + - Discussion session on the Single Responsibility Principle + - Watch episode 9 - The Single Responsibility Principle # Final words diff --git a/solid/02-srp.md b/solid/02-srp.md index 2fc44cf..46666a4 100644 --- a/solid/02-srp.md +++ b/solid/02-srp.md @@ -5,9 +5,8 @@ subtitle: The Single Responsibility Principle # Pre-work -* Video: -* Exam: - +- Video: +- Exam: # Chapters @@ -16,7 +15,7 @@ subtitle: The Single Responsibility Principle :::: column | Chapter | Time | -|----------------------------|----------| +| -------------------------- | -------- | | Overview | 00:01:01 | | General Relativity | 00:03:54 | | Responsibility | 00:10:05 | @@ -36,7 +35,7 @@ subtitle: The Single Responsibility Principle :::: column | Chapter | Time | -|------------------------|----------| +| ---------------------- | -------- | | Examples | 00:30:12 | | Conclusion | 00:39:58 | | Solutions | 00:41:15 | @@ -58,7 +57,7 @@ subtitle: The Single Responsibility Principle # Timetable | Activity | Time | -|------------------------|--------| +| ---------------------- | ------ | | Greetings, Warmup | 5 min | | Separation of concerns | 10 min | | Exercise 1 | 10 min | @@ -73,146 +72,149 @@ subtitle: The Single Responsibility Principle # Warmup -* What are the common challenges that you face when creating unit tests for your code? - * Type in the meeting chat +- What are the common challenges that you face when creating unit tests for your code? + - Type in the meeting chat \note{ - Dependency management: Unit tests require a clear understanding of the - dependencies of the code being tested. It can be challenging to manage these - dependencies and ensure that they are properly isolated for testing - purposes. - - Choosing the right test cases: It can be difficult to determine the right - test cases to use to ensure that the code is working as expected. This - requires a deep understanding of the code and its expected behavior. - - Keeping tests up to date: As code evolves over time, it can be challenging to - keep unit tests up to date with the latest changes. Developers need to - continually update their tests to ensure that they accurately reflect the - behavior of the code. - - Time constraints: Creating comprehensive unit tests can be time-consuming, - especially for complex code. Developers need to balance the need for thorough - testing with the time constraints of the project.) - - Integration testing: Unit tests are only one part of a comprehensive testing - strategy. Developers also need to perform integration testing to ensure that - all the components of the system are working together as expected. - Coordinating these different types of tests can be challenging. +Dependency management: Unit tests require a clear understanding of the +dependencies of the code being tested. It can be challenging to manage these +dependencies and ensure that they are properly isolated for testing +purposes. + +Choosing the right test cases: It can be difficult to determine the right +test cases to use to ensure that the code is working as expected. This +requires a deep understanding of the code and its expected behavior. + +Keeping tests up to date: As code evolves over time, it can be challenging to +keep unit tests up to date with the latest changes. Developers need to +continually update their tests to ensure that they accurately reflect the +behavior of the code. + +Time constraints: Creating comprehensive unit tests can be time-consuming, +especially for complex code. Developers need to balance the need for thorough +testing with the time constraints of the project.) + +Integration testing: Unit tests are only one part of a comprehensive testing +strategy. Developers also need to perform integration testing to ensure that +all the components of the system are working together as expected. +Coordinating these different types of tests can be challenging. } # Separation of Concerns -* How? - * Reduce artificial dependencies - * Simplify change -* What? - * Split - * Segregate - * Extract - -* Orthogonality -* Cohesion -* Single Responsibility Principle (SRP) + +- How? + - Reduce artificial dependencies + - Simplify change +- What? + + - Split + - Segregate + - Extract + +- Orthogonality +- Cohesion +- Single Responsibility Principle (SRP) \note{ - The term separation of concerns was introduced by Edsger W. Dijkstra in his - 1974 paper "On the role of scientific thought". - - In computer science, separation of concerns is a design principle for - separating a computer program into distinct sections. Each section addresses - a separate concern, a set of information that affects the code of a computer - program. A concern can be as general as "the details of the hardware for an - application", or as specific as "the name of which class to instantiate". A - program that embodies SoC well is called a modular program. Modularity, - and hence separation of concerns, is achieved by encapsulating information - inside a section of code that has a well-defined interface. Encapsulation is - a means of information hiding. Layered designs in information systems are - another embodiment of separation of concerns; e.g., presentation layer, - business logic layer, data access layer, persistence layer. - - One of the best and proven solutions to separate concerns is to reduce - artificial dependencies and simplify change. - - Systems that are broken up into small, well-named, understandable pieces - enable faster work. The core of the idea is to split, segregate, or extract - pieces of functionality. - - The intent behind separation of concerns is to better understand and manage - complexity and thus design more modular software. This idea is probably as - old as software itself and hence has been given many different names. - - For instance, the same idea is called orthogonality by the Pragmatic - Programmers. They advise separating orthogonal aspects of software. Tom - DeMarco -- early developer of structured analysis in the 1970s. -- calls it - cohesion. Cohesion is a measure of the strength of association of the - elements inside a module. A highly cohesive module is a collection of - statements and data items that should be treated as a whole, because they are - so closely related.) Any attempt to divide them up would only result in - increased coupling and decreased readability.) In the SOLID principles one of - the most established sets of design principles, the idea is known as the - Single-Responsibility Principle, - - You can see here a reference to the Simon Sinek’s first and most popular book - Start with WHY. It is in the New York Times and Wall Street Journal - bestseller lists. In this book, Simon shows that the leaders who’ve had the - greatest influence in the world all think, act, and communicate the same - way—and it’s the opposite of what everyone else does. Simon calls this - powerful idea The Golden Circle, and it provides a framework upon which - organizations can be built, movements can be led, and people can be - inspired. And it all starts with WHY, following by How and What. +The term separation of concerns was introduced by Edsger W. Dijkstra in his +1974 paper "On the role of scientific thought". + +In computer science, separation of concerns is a design principle for +separating a computer program into distinct sections. Each section addresses +a separate concern, a set of information that affects the code of a computer +program. A concern can be as general as "the details of the hardware for an +application", or as specific as "the name of which class to instantiate". A +program that embodies SoC well is called a modular program. Modularity, +and hence separation of concerns, is achieved by encapsulating information +inside a section of code that has a well-defined interface. Encapsulation is +a means of information hiding. Layered designs in information systems are +another embodiment of separation of concerns; e.g., presentation layer, +business logic layer, data access layer, persistence layer. + +One of the best and proven solutions to separate concerns is to reduce +artificial dependencies and simplify change. + +Systems that are broken up into small, well-named, understandable pieces +enable faster work. The core of the idea is to split, segregate, or extract +pieces of functionality. + +The intent behind separation of concerns is to better understand and manage +complexity and thus design more modular software. This idea is probably as +old as software itself and hence has been given many different names. + +For instance, the same idea is called orthogonality by the Pragmatic +Programmers. They advise separating orthogonal aspects of software. Tom +DeMarco -- early developer of structured analysis in the 1970s. -- calls it +cohesion. Cohesion is a measure of the strength of association of the +elements inside a module. A highly cohesive module is a collection of +statements and data items that should be treated as a whole, because they are +so closely related.) Any attempt to divide them up would only result in +increased coupling and decreased readability.) In the SOLID principles one of +the most established sets of design principles, the idea is known as the +Single-Responsibility Principle, + +You can see here a reference to the Simon Sinek’s first and most popular book +Start with WHY. It is in the New York Times and Wall Street Journal +bestseller lists. In this book, Simon shows that the leaders who’ve had the +greatest influence in the world all think, act, and communicate the same +way—and it’s the opposite of what everyone else does. Simon calls this +powerful idea The Golden Circle, and it provides a framework upon which +organizations can be built, movements can be led, and people can be +inspired. And it all starts with WHY, following by How and What. } # Exercise 1 -* Prompt - * Rooms 1, 3, 5, 7, 9 - * Describe the method to define responsibilities. - * What to do if class has multiple functions? - * Are all of them a separate responsibility? - * Rooms 2, 4, 6, 8, 10 - * How users/actors/roles/responsibilities correlate? - * Are they the same? Could they differ? - * Provide example of same and different combinations of - users, actorsi, roles, and responsibilities. +- Prompt -* Time limit: 10 minutes + - Rooms 1, 3, 5, 7, 9 + - Describe the method to define responsibilities. + - What to do if class has multiple functions? + - Are all of them a separate responsibility? + - Rooms 2, 4, 6, 8, 10 + - How users/actors/roles/responsibilities correlate? + - Are they the same? Could they differ? + - Provide example of same and different combinations of + users, actors, roles, and responsibilities. + +- Time limit: 10 minutes # Definitions -* Actor - single source of change - * Roles - * Separate users of your software from the roles they playing -* Responsibility - * Responsibility, that your software has, is the responsibility to serve - different groups of customers who consumes those services. - * Responsibility is the source of change. - * Responsibilities are tied to the actors, not the users - * To find responsibilities, find families of functions with the similar - audience/users requesting changes. -* Two values of software - * Ability to change frequently - primary value - * Expected behavior - secondary value +- Actor - single source of change + - Roles + - Separate users of your software from the roles they playing +- Responsibility + - Responsibility, that your software has, is the responsibility to serve + different groups of customers who consumes those services. + - Responsibility is the source of change. + - Responsibilities are tied to the actors, not the users + - To find responsibilities, find families of functions with the similar + audience/users requesting changes. +- Two values of software + - Ability to change frequently - primary value + - Expected behavior - secondary value # SRP Overview -* Group only those things that truly belong together, and separate everything +- Group only those things that truly belong together, and separate everything that does not strictly belong -* How to design software: - * Identify the actors - * Responsibilities that serve those actors - * Allocate those responsibilities in modules - * Structure the software so that responsibilities became a plugins to the - rest of the application - * Separate source files +- How to design software: + - Identify the actors + - Responsibilities that serve those actors + - Allocate those responsibilities in modules + - Structure the software so that responsibilities became a plugins to the + rest of the application + - Separate source files # Exercise 2 -* Code review practice: - * Use the worksheet - * Based on the code, suggest code improvements, explain why. - * Use the worksheet to record your suggestions -* Time limit: 15 min +- Code review practice: + - Use the worksheet + - Based on the code, suggest code improvements, explain why. + - Use the worksheet to record your suggestions +- Time limit: 15 min # Exercise 2 code for review @@ -227,7 +229,9 @@ def place_order(customer, product, quantity): customer.credit -= total # Create an order object and add the order to the database - order = Order(customer=customer, product=product, quantity=quantity, total=total) + order = Order( + customer=customer, product=product, quantity=quantity, total=total + ) db.add_order(order) # Update the product inventory @@ -242,9 +246,10 @@ def place_order(customer, product, quantity): ``` # Group discussion -* Groups to share their findings -[//]: # (Facilitators to rate how many people mentioned particular pattern/idiom) +- Groups to share their findings + +[//]: # "Facilitators to rate how many people mentioned particular pattern/idiom" # Exercise 2 solution @@ -259,45 +264,47 @@ def place_order(customer, product, quantity): send_email_confirmation(customer, order) return order + def check_customer_credit(customer, order_total): if customer.credit < order_total: raise ValueError("Insufficient credit") + def reduce_customer_credit(customer, order_total): customer.credit -= order_total ``` \note{ - As you can see, each function now has a single responsibility. The - `place_order` function orchestrates the order placement process by calling - each of the functions in a specific order. Each of the functions is - responsible for a single task, such as calculating the order total or - updating the product inventory. - - By refactoring the code in this way, we have improved its readability and - maintainability. It is now easier to understand the code and make changes to - it if needed. Additionally, if one of the functions needs to be changed or - updated, it can be done without affecting the other functions or the overall - behavior of the place_order function. - - * Users: Customers, System Administrators - * Actors: Customer object, Product object, Order object, db object, email - object - * Roles: - * Customer: Initiates the order by placing the order, provides credit - for payment - * Order: Represents the order object with details of the product, - quantity, and total cost - * Inventory: Adds the order to the database and updates the product - inventory, provides the product information and current inventory) - * Confirmation sender: Sends email confirmation to the customer - * Responsibilities: - * Customer: financial status - * Product: Provides product information, updates inventory - * Order: Represents the order with details of the product, quantity, - and total cost - * Confirmation: Sends email confirmation to the customer -} +As you can see, each function now has a single responsibility. The +`place_order` function orchestrates the order placement process by calling +each of the functions in a specific order. Each of the functions is +responsible for a single task, such as calculating the order total or +updating the product inventory. + +By refactoring the code in this way, we have improved its readability and +maintainability. It is now easier to understand the code and make changes to +it if needed. Additionally, if one of the functions needs to be changed or +updated, it can be done without affecting the other functions or the overall +behavior of the place_order function. + +- Users: Customers, System Administrators +- Actors: Customer object, Product object, Order object, db object, email + object +- Roles: + - Customer: Initiates the order by placing the order, provides credit + for payment + - Order: Represents the order object with details of the product, + quantity, and total cost + - Inventory: Adds the order to the database and updates the product + inventory, provides the product information and current inventory) + - Confirmation sender: Sends email confirmation to the customer +- Responsibilities: + _Customer: financial status + _ Product: Provides product information, updates inventory + _Order: Represents the order with details of the product, quantity, + and total cost + _ Confirmation: Sends email confirmation to the customer + } # Exercise 2 solution (cont'd) @@ -305,28 +312,35 @@ def reduce_customer_credit(customer, order_total): def calculate_order_total(product, quantity): return product.price * quantity + def create_order(customer, product, quantity, order_total): - return Order(customer=customer, product=product, quantity=quantity, total=order_total) + return Order( + customer=customer, product=product, quantity=quantity, total=order_total + ) + def add_order_to_database(order): db.add_order(order) + def update_product_inventory(product, quantity): product.inventory -= quantity db.update_product(product) + def send_email_confirmation(customer, order): email.send_confirmation_email(customer.email, order) ``` # Exercise 3 -* Code review practice: - * Propose the code changes for the code snippet -* Use the worksheet to record your suggestions -* Time limit: 5 min +- Code review practice: + - Propose the code changes for the code snippet +- Use the worksheet to record your suggestions +- Time limit: 5 min # Exercise 3 code + ```python class Car: def __init__(self, engine_size, num_doors): @@ -345,7 +359,7 @@ class Car: # Group discussion -* Groups to share their findings +- Groups to share their findings \note{Facilitators to rate how many people mentioned particular pattern or idiom.} @@ -379,23 +393,23 @@ class DoorLocks: # Summary -* Conformance with SRP might require pulling apart +- Conformance with SRP might require pulling apart code/functions/classes/components -* Potential solutions: - * Dependency inversion - * Extract classes - * Use design patterns (facade) - * Interface segregation -* None of the solution are perfect -* Carefully allocating responsibilities to classes and modules we keep the +- Potential solutions: + - Dependency inversion + - Extract classes + - Use design patterns (facade) + - Interface segregation +- None of the solution are perfect +- Carefully allocating responsibilities to classes and modules we keep the primary value of software high -* When module has more than one responsibility, the system tends to became +- When module has more than one responsibility, the system tends to become fragile # What is next? -* Coding dojo to practice the Single Responsibility Principle -* Expect an e-mail with instructions for upcoming coding dojo +- Coding dojo to practice the Single Responsibility Principle +- Expect an e-mail with instructions for upcoming coding dojo # Final words