Add files using upload-large-folder tool

.gitattributes

@@ -47,3 +47,8 @@ saved_model/**/* filter=lfs diff=lfs merge=lfs -text
 04[[:space:]]-[[:space:]]Eclipse[[:space:]]Tips[[:space:]]and[[:space:]]Tricks/002[[:space:]]Plugins[[:space:]]how[[:space:]]to[[:space:]]install[[:space:]]free[[:space:]]plugins,[[:space:]]eclipse[[:space:]]marketplace,[[:space:]]workspace[[:space:]]styles.mp4 filter=lfs diff=lfs merge=lfs -text
 03[[:space:]]-[[:space:]]Primitive[[:space:]]Data[[:space:]]Types,[[:space:]]Variables[[:space:]]and[[:space:]]Arrays/003[[:space:]]Arrays.mp4 filter=lfs diff=lfs merge=lfs -text
 04[[:space:]]-[[:space:]]Eclipse[[:space:]]Tips[[:space:]]and[[:space:]]Tricks/003[[:space:]]Code[[:space:]]Refactoring[[:space:]]in[[:space:]]Eclipse.mp4 filter=lfs diff=lfs merge=lfs -text
+05[[:space:]]-[[:space:]]Operators[[:space:]]and[[:space:]]Operations[[:space:]]with[[:space:]]primitive[[:space:]]types/002[[:space:]]Operations[[:space:]]with[[:space:]]integers[[:space:]]and[[:space:]]floating-point[[:space:]]numbers,[[:space:]]BigDecimal[[:space:]]type.mp4 filter=lfs diff=lfs merge=lfs -text
+05[[:space:]]-[[:space:]]Operators[[:space:]]and[[:space:]]Operations[[:space:]]with[[:space:]]primitive[[:space:]]types/003[[:space:]]Math[[:space:]]class,[[:space:]]NaN,[[:space:]]Infinity.mp4 filter=lfs diff=lfs merge=lfs -text
+05[[:space:]]-[[:space:]]Operators[[:space:]]and[[:space:]]Operations[[:space:]]with[[:space:]]primitive[[:space:]]types/004[[:space:]]Type[[:space:]]of[[:space:]]the[[:space:]]expression[[:space:]]in[[:space:]]Java.mp4 filter=lfs diff=lfs merge=lfs -text
+05[[:space:]]-[[:space:]]Operators[[:space:]]and[[:space:]]Operations[[:space:]]with[[:space:]]primitive[[:space:]]types/001[[:space:]]Operators[[:space:]]in[[:space:]]Java.mp4 filter=lfs diff=lfs merge=lfs -text
+05[[:space:]]-[[:space:]]Operators[[:space:]]and[[:space:]]Operations[[:space:]]with[[:space:]]primitive[[:space:]]types/006[[:space:]]Read[[:space:]]user[[:space:]]input[[:space:]]from[[:space:]]console.mp4 filter=lfs diff=lfs merge=lfs -text

05 - Operators and Operations with primitive types/001 Operators in Java.mp4

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:f4f590c0a1cef3a663c7e47acc3bdb9f4433e9594d17b8a60969f28985610bc8
+size 443480344

05 - Operators and Operations with primitive types/002 Operations with integers and floating-point numbers, BigDecimal type.mp4

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:ff154a87708debfc3d3bd1219445ba52d6679788517d1860270a43b706de251a
+size 106957149

05 - Operators and Operations with primitive types/003 Math class, NaN, Infinity.mp4

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:977dbe3b832ac29174cfaa5738bf15314f402b9bdc8550ea446c993ec7cc27bd
+size 121953508

05 - Operators and Operations with primitive types/004 Type of the expression in Java.mp4

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:cb979b611a72506a4e2af39975c5eee8efa141c774561746c965dd85277fca16
+size 90273337

05 - Operators and Operations with primitive types/006 Read user input from console.mp4

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:fa46d266a16e87f26969d42b3ad9e896b6e652adf9a0b7cfd6df779145bf6cd6
+size 44832403

106 - Structural Diagrams/external-links.txt

@@ -0,0 +1,21 @@
+
+001 Class-Diagram-Order-Processing
+https://drive.google.com/file/d/1JT9iraGj_-ETCLGK9TCFfOb4E8qf6LSh/view?usp=sharing
+
+002 Object-Diagram-Company-Structure
+https://drive.google.com/file/d/1hBULzktjLu634lIz7dA7GNp0RXOnScay/view?usp=sharing
+
+003 Component-Diagram-Order-Processing
+https://drive.google.com/file/d/1c-RAD_hDU4hWXL3KjB-7dq2hG5xJfkMH/view?usp=sharing
+
+004 Package-Diagram-Order-Processing
+https://drive.google.com/file/d/1gLNN0cdloKqcx_afh7Vdy3EIC5T-wry6/view?usp=sharing
+
+005 Deployment-Diagram-Example
+https://drive.google.com/file/d/1Q2sS_Dkp9I9vRXWVkqsEwoEKkmQYajwm/view?usp=sharing
+
+006 Composite-Structure-Diagram-PC
+https://drive.google.com/file/d/1N3akUJToBbzFRTZk3l4OVQRAdPXL7AQC/view?usp=sharing
+
+007 Profile-Diagram-EJB-Profile
+https://drive.google.com/file/d/1qBpP6aG6xDtsIFgTUpCnLi7SNbslQ8zn/view?usp=sharing

107 - Code Review Fundamentals/001 Introduction to Code Reviews_en.srt

@@ -0,0 +1,660 @@
+1
+00:00:05,000 --> 00:00:11,000
+Hello dear students, in this lesson we are going to have Introduction to Code review process.
+
+2
+00:00:11,000 --> 00:00:18,000
+We are going to hold an overview of what we are going to learn in this course about code review process
+
+3
+00:00:18,000 --> 00:00:21,000
+and what are objectives of this course.
+
+4
+00:00:22,000 --> 00:00:27,000
+I will explain you why secure, clean and scalable code is so important.
+
+5
+00:00:27,000 --> 00:00:29,000
+And what is the role of code reviews?
+
+6
+00:00:29,000 --> 00:00:36,000
+I will make an introduction to effective code review and we will discuss its impact on code quality
+
+7
+00:00:36,000 --> 00:00:37,000
+and team collaboration.
+
+8
+00:00:37,000 --> 00:00:39,000
+Let's start our lesson.
+
+9
+00:00:39,000 --> 00:00:42,000
+Let's make an overview of this course.
+
+10
+00:00:42,000 --> 00:00:43,000
+Objectives.
+
+11
+00:00:43,000 --> 00:00:50,000
+This course aims to provide participants with a comprehensive understanding of code reviews for creating
+
+12
+00:00:50,000 --> 00:00:55,000
+secure, clean and scalable code while fostering effective teamwork.
+
+13
+00:00:55,000 --> 00:00:57,000
+The key objectives include.
+
+14
+00:00:58,000 --> 00:01:02,000
+Explore the importance of code reviews in software development.
+
+15
+00:01:02,000 --> 00:01:06,000
+Understand the impact of code quality and team collaboration.
+
+16
+00:01:07,000 --> 00:01:11,000
+I will help you to grasp the basic principles and goals of code reviews.
+
+17
+00:01:11,000 --> 00:01:14,000
+Differentiate between various types of code reviews.
+
+18
+00:01:14,000 --> 00:01:17,000
+Defines the roles of code reviewer and author.
+
+19
+00:01:17,000 --> 00:01:21,000
+Together will develop a mindset for efficient code reviews.
+
+20
+00:01:22,000 --> 00:01:28,000
+Also during the course we will talk about code review tools and their significance using of automated
+
+21
+00:01:28,000 --> 00:01:30,000
+tools for code analysis.
+
+22
+00:01:30,000 --> 00:01:35,000
+I will share with you how you can integrate tools into the development process.
+
+23
+00:01:35,000 --> 00:01:40,000
+In the course, we will explore best practices for writing secure and scalable code.
+
+24
+00:01:41,000 --> 00:01:47,000
+I will share with you my experience to help you establish review guidelines and expectations in your
+
+25
+00:01:47,000 --> 00:01:48,000
+team.
+
+26
+00:01:48,000 --> 00:01:53,000
+Also, I will teach you how to provide fair and objective feedback and a separate lesson.
+
+27
+00:01:53,000 --> 00:01:56,000
+We will talk about using constructive criticism techniques.
+
+28
+00:01:57,000 --> 00:02:01,000
+We will learn how to communicate effectively during code reviews.
+
+29
+00:02:01,000 --> 00:02:06,000
+And of course we will hold an overview of coding standards and best practices.
+
+30
+00:02:07,000 --> 00:02:12,000
+Another important objective of this course is to learn how to create a positive code, review culture,
+
+31
+00:02:12,000 --> 00:02:20,000
+build trust among team members, engage in collaborative code reviews, and participate in team based
+
+32
+00:02:20,000 --> 00:02:22,000
+code review simulations.
+
+33
+00:02:22,000 --> 00:02:28,000
+In the separate section of the course, I will explain you how to set and enforce coding standards,
+
+34
+00:02:29,000 --> 00:02:35,000
+ensure code quality and consistency, develop code standards specific to different programming languages,
+
+35
+00:02:35,000 --> 00:02:38,000
+and create a code standards checklist.
+
+36
+00:02:39,000 --> 00:02:45,000
+Taking into account one of the goals of our course is to ensure creation of scalable code.
+
+37
+00:02:45,000 --> 00:02:50,000
+In the separate section, we will understand what scalability and software development is.
+
+38
+00:02:51,000 --> 00:02:57,000
+We will explore our best practices for scalable code, identify and address scalability challenges,
+
+39
+00:02:57,000 --> 00:02:59,000
+analyze code for scalability issues.
+
+40
+00:03:00,000 --> 00:03:06,000
+And of course, one of the most important objectives of this course is to learn how to ensure creation
+
+41
+00:03:06,000 --> 00:03:07,000
+of secure code.
+
+42
+00:03:07,000 --> 00:03:13,000
+Through the code review process, we will talk about importance of security in software development.
+
+43
+00:03:13,000 --> 00:03:18,000
+We will also identify common security vulnerabilities, integrate security best practices into code
+
+44
+00:03:18,000 --> 00:03:23,000
+reviews, and we will learn how to address and mitigate security flaws in code.
+
+45
+00:03:24,000 --> 00:03:30,000
+And besides all this, we will learn lots more things on our way to course objectives.
+
+46
+00:03:30,000 --> 00:03:36,000
+By the end of the course, all students should have the knowledge and skills to conduct effective,
+
+47
+00:03:36,000 --> 00:03:42,000
+secure and collaborative code reviews contributing to the development of high quality software.
+
+48
+00:03:43,000 --> 00:03:47,000
+Let me now explain the importance of writing secure, clean and scalable code.
+
+49
+00:03:48,000 --> 00:03:55,000
+The significance of developing secure, clean, and scalable code lies in its profound impact on the
+
+50
+00:03:55,000 --> 00:03:59,000
+overall success and sustainability of software projects.
+
+51
+00:04:00,000 --> 00:04:07,000
+Regarding security, writing secure code is essential to safeguard software from potential vulnerabilities
+
+52
+00:04:07,000 --> 00:04:08,000
+and cyber threats.
+
+53
+00:04:09,000 --> 00:04:16,000
+Secure code ensures the confidentiality and integrity of sensitive data, preventing unauthorized access
+
+54
+00:04:16,000 --> 00:04:17,000
+or manipulation.
+
+55
+00:04:18,000 --> 00:04:20,000
+Regarding clean code.
+
+56
+00:04:20,000 --> 00:04:26,000
+Clean code is easily readable and understandable, facilitating collaboration among team members and
+
+57
+00:04:26,000 --> 00:04:28,000
+making maintenance more efficient.
+
+58
+00:04:29,000 --> 00:04:35,000
+Well organized and clear code reduces the likelihood of introducing bugs and errors contributing to
+
+59
+00:04:35,000 --> 00:04:37,000
+overall software stability.
+
+60
+00:04:38,000 --> 00:04:40,000
+And regarding scalability aspect.
+
+61
+00:04:41,000 --> 00:04:50,000
+Scalable code allows software to adapt to increased demands, accommodating growth in users data features
+
+62
+00:04:50,000 --> 00:04:53,000
+without a significant drop in performance.
+
+63
+00:04:54,000 --> 00:05:02,000
+Scalable code minimizes the need for extensive rewrites or redesigns as a software expands, leading
+
+64
+00:05:02,000 --> 00:05:04,000
+to cost effective long tum development.
+
+65
+00:05:05,000 --> 00:05:12,000
+So prioritizing secure, clean, and scalable code is not only a best practice for maintaining the integrity
+
+66
+00:05:12,000 --> 00:05:18,000
+of software, but also contributes to collaboration, efficiency, and the long tum success of development
+
+67
+00:05:18,000 --> 00:05:19,000
+projects.
+
+68
+00:05:20,000 --> 00:05:21,000
+And why?
+
+69
+00:05:21,000 --> 00:05:23,000
+This course is about code review process.
+
+70
+00:05:23,000 --> 00:05:29,000
+What is the role of code review in production of secure, clean and scalable code?
+
+71
+00:05:30,000 --> 00:05:36,000
+Code reviews play a crucial role in ensuring the quality, maintainability and collaborative success
+
+72
+00:05:36,000 --> 00:05:38,000
+of software development projects.
+
+73
+00:05:39,000 --> 00:05:43,000
+Let me share with you a few important points and considerations.
+
+74
+00:05:44,000 --> 00:05:50,000
+Code reviews help identify and fix bugs, errors, and potential issues early in the development process,
+
+75
+00:05:50,000 --> 00:05:53,000
+improving overall software quality.
+
+76
+00:05:53,000 --> 00:06:00,000
+Reviewing code ensures adherence to coding standards, promoting consistency in the code base.
+
+77
+00:06:00,000 --> 00:06:06,000
+Code reviews provide a platform for team members to collaborate, share knowledge, and learn from each
+
+78
+00:06:06,000 --> 00:06:08,000
+other's expertise.
+
+79
+00:06:08,000 --> 00:06:13,000
+Senior team members can guide and mentor junior developers through code reviews.
+
+80
+00:06:13,000 --> 00:06:15,000
+Fostering skill development.
+
+81
+00:06:16,000 --> 00:06:23,000
+Reviews help ensure that code is clear, well documented and easy to understand, making it more maintainable
+
+82
+00:06:23,000 --> 00:06:24,000
+in the long run.
+
+83
+00:06:25,000 --> 00:06:31,000
+Regular reviews contribute to addressing technical debt by catching and fixing issues before they accumulate.
+
+84
+00:06:32,000 --> 00:06:38,000
+Code reviews offer opportunities for developers to learn new techniques, best practices, and coding
+
+85
+00:06:38,000 --> 00:06:40,000
+patterns from their peers.
+
+86
+00:06:41,000 --> 00:06:47,000
+Constructive feedback from code reviews allows developers to improve their skills and grow professionally.
+
+87
+00:06:48,000 --> 00:06:54,000
+Code reviews help in identifying and mitigating security vulnerabilities, ensuring that the software
+
+88
+00:06:54,000 --> 00:06:57,000
+is resilient to potential threats.
+
+89
+00:06:58,000 --> 00:07:04,000
+Regular reviews contribute to code stability by catching potential issues that could lead to system
+
+90
+00:07:04,000 --> 00:07:06,000
+failures or crashes.
+
+91
+00:07:07,000 --> 00:07:12,000
+Issues identified during code reviews can be addressed promptly, preventing them from escalating and
+
+92
+00:07:12,000 --> 00:07:14,000
+delaying the development process.
+
+93
+00:07:15,000 --> 00:07:21,000
+Efficient code reviews contribute to a smoother development workflow, reducing the likelihood of post-release
+
+94
+00:07:21,000 --> 00:07:22,000
+issues.
+
+95
+00:07:22,000 --> 00:07:28,000
+Code reviews ensures that the development team adheres to coding standards, industry best practices,
+
+96
+00:07:28,000 --> 00:07:30,000
+and project specific guidelines.
+
+97
+00:07:30,000 --> 00:07:37,000
+In essence, code reviews serve as a cornerstone in maintaining code quality, fostering collaboration,
+
+98
+00:07:37,000 --> 00:07:43,000
+and continuously improving the development process, ultimately contributing to the success of software
+
+99
+00:07:43,000 --> 00:07:44,000
+projects.
+
+100
+00:07:44,000 --> 00:07:49,000
+How we can make code review process effective and why it is important.
+
+101
+00:07:49,000 --> 00:07:55,000
+Effective code review is a critical practice in software development, contributing to the creation
+
+102
+00:07:55,000 --> 00:08:00,000
+of high quality, maintainable code and fostering collaboration within a development team.
+
+103
+00:08:01,000 --> 00:08:05,000
+Let me introduce key aspects of effective code review.
+
+104
+00:08:05,000 --> 00:08:11,000
+Effective code review aims to ensure the quality and reliability of the code base by catching bugs,
+
+105
+00:08:11,000 --> 00:08:15,000
+errors, and potential issues before they impact the software.
+
+106
+00:08:16,000 --> 00:08:22,000
+It serves as a mechanism for continuous improvement, allowing developers to learn from one another,
+
+107
+00:08:22,000 --> 00:08:25,000
+share knowledge, and refine their coding skills.
+
+108
+00:08:26,000 --> 00:08:31,000
+Code review provides an opportunity for team members to share their expertise, fostering a collaborative
+
+109
+00:08:31,000 --> 00:08:34,000
+environment where developers learn from each other.
+
+110
+00:08:34,000 --> 00:08:40,000
+Like we already mentioned before, senior developers can mentor junior team members through constructive
+
+111
+00:08:40,000 --> 00:08:43,000
+feedback and guidance during code review.
+
+112
+00:08:43,000 --> 00:08:50,000
+Effective code reviews involve providing constructive criticism, rather than merely pointing out flaws
+
+113
+00:08:50,000 --> 00:08:54,000
+and encouraging a positive and growth oriented atmosphere.
+
+114
+00:08:54,000 --> 00:09:01,000
+Reviewers focus on ensuring that the code is clear, well documented, and adheres to coding standards,
+
+115
+00:09:01,000 --> 00:09:04,000
+promoting readability and maintainability.
+
+116
+00:09:04,000 --> 00:09:12,000
+The reviewer plays a crucial role in evaluating the code for quality correctness and adherence to coding
+
+117
+00:09:12,000 --> 00:09:12,000
+standards.
+
+118
+00:09:13,000 --> 00:09:16,000
+They provide feedback and guidance to improve the code.
+
+119
+00:09:16,000 --> 00:09:22,000
+The author is responsible for presenting their code concisely, addressing commands, and learning from
+
+120
+00:09:22,000 --> 00:09:26,000
+the feedback provided during the review process.
+
+121
+00:09:26,000 --> 00:09:32,000
+Communication during code review should be clear, specific, and respectful, focusing on the improvement
+
+122
+00:09:32,000 --> 00:09:35,000
+of the code rather than personal criticism.
+
+123
+00:09:36,000 --> 00:09:43,000
+Both reviewers and authors should aim for timely responses to ensure a smooth and efficient review process.
+
+124
+00:09:44,000 --> 00:09:49,000
+Code review establishes a feedback loop where developers receive input on their work, facilitating
+
+125
+00:09:49,000 --> 00:09:53,000
+continuous learning and improvement through code review.
+
+126
+00:09:53,000 --> 00:10:00,000
+Teams can adopt and reinforce best practices, aligning their coding standards with industry norms.
+
+127
+00:10:01,000 --> 00:10:07,000
+Incorporating code review early in the development process helps identify and address issues at the
+
+128
+00:10:07,000 --> 00:10:12,000
+initial stages, reducing the likelihood of downstream problems.
+
+129
+00:10:12,000 --> 00:10:19,000
+Effective code review often involves the use of tools and automation to streamline the process and ensure
+
+130
+00:10:19,000 --> 00:10:20,000
+consistency.
+
+131
+00:10:21,000 --> 00:10:27,000
+As you can see, effective code review is a collaborative and continuous process that not only enhances
+
+132
+00:10:27,000 --> 00:10:34,000
+the quality of the code, but also cultivates a positive and knowledge sharing culture within the development
+
+133
+00:10:34,000 --> 00:10:34,000
+team.
+
+134
+00:10:35,000 --> 00:10:42,000
+Code reviews have a deep impact on both code quality and team collaboration and software development.
+
+135
+00:10:43,000 --> 00:10:50,000
+We already learned a lot, but let's make a summary to understand how code review process impacts on
+
+136
+00:10:50,000 --> 00:10:52,000
+code quality and team collaboration.
+
+137
+00:10:53,000 --> 00:10:59,000
+Code reviews serve as an additional layer of research, helping to detect and address bugs, errors,
+
+138
+00:10:59,000 --> 00:11:03,000
+and potential issues early in the development process.
+
+139
+00:11:03,000 --> 00:11:11,000
+Code reviews ensures that code follows established coding standards, promoting consistency and readability
+
+140
+00:11:11,000 --> 00:11:16,000
+throughout the code base by catching and addressing issues promptly.
+
+141
+00:11:16,000 --> 00:11:22,000
+Code reviews contribute to reducing technical debt, preventing the accumulation of unresolved problems.
+
+142
+00:11:23,000 --> 00:11:29,000
+Code reviews provide a platform for team members to share their knowledge, expertise, and best practices,
+
+143
+00:11:29,000 --> 00:11:31,000
+fostering a culture of continuous learning.
+
+144
+00:11:32,000 --> 00:11:40,000
+During the code review, a reviewers can seek clarification on code intent, ensuring that the purpose
+
+145
+00:11:40,000 --> 00:11:46,000
+and functionality are well understood, leading to more robust implementations.
+
+146
+00:11:46,000 --> 00:11:51,000
+Code review process may also have a positive impact on team morale.
+
+147
+00:11:51,000 --> 00:11:57,000
+Positive feedback during code reviews acknowledges the efforts and skills of individual team members,
+
+148
+00:11:57,000 --> 00:12:01,000
+boosting morale and creating a positive work environment.
+
+149
+00:12:01,000 --> 00:12:07,000
+Very often, code reviewers forgot about providing positive feedback to.
+
+150
+00:12:07,000 --> 00:12:14,000
+Code reviews facilitate the timely resolution of issues, ensuring a smoother development workflow with
+
+151
+00:12:14,000 --> 00:12:15,000
+fewer disruptions.
+
+152
+00:12:16,000 --> 00:12:22,000
+With a focus on quality assurance, code reviews contribute to increase productivity by minimizing the
+
+153
+00:12:22,000 --> 00:12:25,000
+likelihood of post-release issues.
+
+154
+00:12:25,000 --> 00:12:32,000
+In essence, effective code reviews are a cornerstone of achieving high code quality promoting collaboration,
+
+155
+00:12:32,000 --> 00:12:37,000
+and cultivating a culture of continuous improvement within a software development team.
+
+156
+00:12:38,000 --> 00:12:40,000
+That's all what I wanted to share with you in this lesson.
+
+157
+00:12:40,000 --> 00:12:46,000
+We still have lots more to learn, but let's recap what we have learned today.
+
+158
+00:12:47,000 --> 00:12:50,000
+Today we did an overview of objectives of the course.
+
+159
+00:12:50,000 --> 00:12:55,000
+I explained the importance of secure, clean and scalable code.
+
+160
+00:12:55,000 --> 00:12:59,000
+Also, we discussed why code review process is important.
+
+161
+00:12:59,000 --> 00:13:05,000
+We talked about effective code review and what can be considered as effective code review.
+
+162
+00:13:05,000 --> 00:13:12,000
+And also we made a summary of how effective code review impacts on code quality and team collaboration.
+
+163
+00:13:13,000 --> 00:13:14,000
+That's all for this lesson.
+
+164
+00:13:14,000 --> 00:13:16,000
+Thanks a lot for your attention.
+
+165
+00:13:16,000 --> 00:13:19,000
+Have a great day and see you in the next lesson.
+

107 - Code Review Fundamentals/002 Basics of Code Review Process_en.srt

@@ -0,0 +1,1236 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello.
+
+2
+00:00:06,000 --> 00:00:09,000
+In this lesson we'll learn basics of code review process.
+
+3
+00:00:09,000 --> 00:00:14,000
+We'll start the lesson from learning the basic principles and goals of code reviews.
+
+4
+00:00:14,000 --> 00:00:20,000
+I will explain you what different types of code reviews exist and which type is recommended for you
+
+5
+00:00:20,000 --> 00:00:22,000
+under which circumstances.
+
+6
+00:00:23,000 --> 00:00:29,000
+Today we'll review in details such fundamentals as rules of code, reviewer and author.
+
+7
+00:00:29,000 --> 00:00:34,000
+I will also explain you what the reviewer mindset is and how to develop it.
+
+8
+00:00:34,000 --> 00:00:38,000
+And by the end of the lesson, we'll talk about strategies for efficient code review.
+
+9
+00:00:39,000 --> 00:00:40,000
+Let's start our lesson.
+
+10
+00:00:41,000 --> 00:00:46,000
+And as I mentioned in agenda of the lesson, let's start from learning basic principles of code review
+
+11
+00:00:46,000 --> 00:00:46,000
+process.
+
+12
+00:00:47,000 --> 00:00:51,000
+On this stage, it is super important to create solid basement for our future learning.
+
+13
+00:00:52,000 --> 00:00:54,000
+Basic principles are.
+
+14
+00:00:54,000 --> 00:00:55,000
+Collaboration.
+
+15
+00:00:55,000 --> 00:00:56,000
+Feedback.
+
+16
+00:00:56,000 --> 00:00:57,000
+Continuous improvement.
+
+17
+00:00:57,000 --> 00:00:58,000
+Focus on objectives.
+
+18
+00:00:58,000 --> 00:01:00,000
+Code standards.
+
+19
+00:01:00,000 --> 00:01:01,000
+Code ownership.
+
+20
+00:01:01,000 --> 00:01:02,000
+Automation.
+
+21
+00:01:02,000 --> 00:01:03,000
+Timeliness.
+
+22
+00:01:03,000 --> 00:01:04,000
+Documentation.
+
+23
+00:01:05,000 --> 00:01:06,000
+Let's review them one by one.
+
+24
+00:01:07,000 --> 00:01:12,000
+Code review involves multiple team members collaborating to review each other's code.
+
+25
+00:01:12,000 --> 00:01:17,000
+It promotes knowledge sharing and spreads best practices.
+
+26
+00:01:17,000 --> 00:01:24,000
+Code review encourages discussions about design decisions, code structure, and potential improvements,
+
+27
+00:01:24,000 --> 00:01:28,000
+leading to better informed decisions and more effective teamwork.
+
+28
+00:01:28,000 --> 00:01:33,000
+Provide constructive feedback that helps the author improve their code.
+
+29
+00:01:33,000 --> 00:01:37,000
+Feedback should be specific, actionable, and respectful.
+
+30
+00:01:37,000 --> 00:01:43,000
+Code review is an iterative process aimed at continuously improving code quality.
+
+31
+00:01:43,000 --> 00:01:46,000
+It is about learning and growing as a team.
+
+32
+00:01:46,000 --> 00:01:52,000
+Code review encourages developers to reflect on their coding practices and seek opportunities for optimization
+
+33
+00:01:52,000 --> 00:01:54,000
+and refinement.
+
+34
+00:01:54,000 --> 00:02:01,000
+Reviewers should focus on the objectives of the code change, such as solving a particular problem or
+
+35
+00:02:01,000 --> 00:02:06,000
+implementing a new feature, rather than nitpicking on tribal issues.
+
+36
+00:02:06,000 --> 00:02:14,000
+This is important ensures that code adheres to the team's coding standards, style guidelines, and
+
+37
+00:02:14,000 --> 00:02:15,000
+best practices.
+
+38
+00:02:15,000 --> 00:02:19,000
+Consistency is crucial for maintainability and readability.
+
+39
+00:02:19,000 --> 00:02:26,000
+Respect the authors ownership of their code while also promoting collective code ownership.
+
+40
+00:02:27,000 --> 00:02:32,000
+Encourage authors to take responsibility for their code and address feedback accordingly.
+
+41
+00:02:32,000 --> 00:02:40,000
+Use automated tools such as linters and static code analysis tools to catch common issues and enforce
+
+42
+00:02:40,000 --> 00:02:41,000
+coding standards.
+
+43
+00:02:41,000 --> 00:02:46,000
+This helps streamline the review process and ensures consistency.
+
+44
+00:02:47,000 --> 00:02:52,000
+Conduct code reviews in a timely manner to avoid delays in the development process.
+
+45
+00:02:52,000 --> 00:02:59,000
+Set clear expectations for review turnaround times, and prioritize critical changes.
+
+46
+00:02:59,000 --> 00:03:06,000
+Document decisions made during the review process, especially regarding design choices, architectural
+
+47
+00:03:06,000 --> 00:03:08,000
+decisions, and lessons learned.
+
+48
+00:03:09,000 --> 00:03:15,000
+This helps maintain a record of discussions and facilitates onboarding of new team members.
+
+49
+00:03:15,000 --> 00:03:18,000
+The basic principles of code review process.
+
+50
+00:03:19,000 --> 00:03:20,000
+Let's review now.
+
+51
+00:03:20,000 --> 00:03:22,000
+Goals of code review process.
+
+52
+00:03:23,000 --> 00:03:27,000
+There are following goals of code review process quality assurance.
+
+53
+00:03:27,000 --> 00:03:35,000
+Knowledge sharing, consistency, risk reduction, code ownership, onboarding and mentoring.
+
+54
+00:03:35,000 --> 00:03:38,000
+Let me explain you each of these.
+
+55
+00:03:38,000 --> 00:03:45,000
+Ensure the quality of the code base by identifying and fixing defects, bugs, and potential issues
+
+56
+00:03:45,000 --> 00:03:48,000
+before you find them in production.
+
+57
+00:03:48,000 --> 00:03:56,000
+Code review helps in maintaining a high level of code quality, which ultimately leads to better software
+
+58
+00:03:56,000 --> 00:03:58,000
+reliability and user satisfaction.
+
+59
+00:03:59,000 --> 00:04:05,000
+Facilitate knowledge sharing among team members by providing an opportunity for developers to learn
+
+60
+00:04:05,000 --> 00:04:07,000
+from each other through code review.
+
+61
+00:04:07,000 --> 00:04:14,000
+Team members can gain insights into different coding styles, techniques, and approaches, thus improving
+
+62
+00:04:14,000 --> 00:04:18,000
+their own skills and understanding of the code base.
+
+63
+00:04:19,000 --> 00:04:26,000
+Enforce coding standards, best practices, and design patterns across the code base by reviewing code
+
+64
+00:04:26,000 --> 00:04:27,000
+changes.
+
+65
+00:04:27,000 --> 00:04:33,000
+Teams can ensure consistency in coding style architecture and implementation, making the code base
+
+66
+00:04:33,000 --> 00:04:37,000
+more maintainable and easier to understand for everyone.
+
+67
+00:04:38,000 --> 00:04:45,000
+Mitigate the risk of introducing defects and vulnerabilities into the code base by having multiple sets
+
+68
+00:04:45,000 --> 00:04:45,000
+of eyes.
+
+69
+00:04:45,000 --> 00:04:47,000
+Reviewing code changes.
+
+70
+00:04:47,000 --> 00:04:53,000
+Teams can catch potential issues early in the development process, reducing the likelihood of costly
+
+71
+00:04:53,000 --> 00:04:55,000
+bugs slipping into the production.
+
+72
+00:04:56,000 --> 00:05:03,000
+Foster a sense of ownership and accountability among team members by participating in code review.
+
+73
+00:05:03,000 --> 00:05:10,000
+Developers take responsibility for the quality and integrity of their code, leading to a more empowered
+
+74
+00:05:10,000 --> 00:05:11,000
+and motivated team.
+
+75
+00:05:12,000 --> 00:05:18,000
+Facilitate the onboarding process for new team members by exposing them to the code base and development
+
+76
+00:05:18,000 --> 00:05:20,000
+practices through code review.
+
+77
+00:05:21,000 --> 00:05:27,000
+Additionally, Code Review serves as a platform for more experienced developers to mentor junior members,
+
+78
+00:05:27,000 --> 00:05:30,000
+helping them grow and develop their skills.
+
+79
+00:05:30,000 --> 00:05:37,000
+Overall, the primary goals of the code review process are to improve code quality, foster collaboration
+
+80
+00:05:37,000 --> 00:05:42,000
+and learning, mitigate risks, and ultimately deliver better software products to users.
+
+81
+00:05:43,000 --> 00:05:47,000
+And now let's review different types of code reviews.
+
+82
+00:05:47,000 --> 00:05:53,000
+There are several types of code reviews, each with its own characteristics and objectives.
+
+83
+00:05:53,000 --> 00:05:55,000
+Here are some common types.
+
+84
+00:05:56,000 --> 00:05:57,000
+Pair programming.
+
+85
+00:05:57,000 --> 00:05:59,000
+In pair programming.
+
+86
+00:05:59,000 --> 00:06:01,000
+Two developers work together at the same workstation.
+
+87
+00:06:01,000 --> 00:06:09,000
+They collaboratively write and review code in real time, discussing design decisions and implementation
+
+88
+00:06:09,000 --> 00:06:10,000
+details as they go.
+
+89
+00:06:11,000 --> 00:06:16,000
+Pair programming fosters close collaboration and immediate feedback, leading to higher code quality
+
+90
+00:06:16,000 --> 00:06:18,000
+and knowledge sharing.
+
+91
+00:06:18,000 --> 00:06:21,000
+I used to work using pair programming technique.
+
+92
+00:06:22,000 --> 00:06:31,000
+My personal feedback is this is simply amazing, but sometimes better quality is not instantly visible,
+
+93
+00:06:31,000 --> 00:06:38,000
+and sometimes it is challenging to explain business stakeholders why two people are working on the same
+
+94
+00:06:38,000 --> 00:06:38,000
+task.
+
+95
+00:06:39,000 --> 00:06:43,000
+Because usually business stakeholders think in a straightforward way.
+
+96
+00:06:43,000 --> 00:06:49,000
+If there are two developers, they can produce twice as much code, so no sense for them to work in
+
+97
+00:06:49,000 --> 00:06:50,000
+pairs.
+
+98
+00:06:50,000 --> 00:06:53,000
+So, you know pros and cons.
+
+99
+00:06:53,000 --> 00:06:59,000
+And it is only matter of your decision now and how you will explain this to business stakeholders.
+
+100
+00:07:00,000 --> 00:07:05,000
+If you would have any questions, please do not hesitate to post your questions below the video and
+
+101
+00:07:05,000 --> 00:07:07,000
+I will be happy to answer.
+
+102
+00:07:07,000 --> 00:07:11,000
+Another type of code review is ad hoc reviews.
+
+103
+00:07:12,000 --> 00:07:18,000
+AD hoc reviews are informal and spontaneous code reviews that occur on an as needed basis.
+
+104
+00:07:18,000 --> 00:07:24,000
+Developers may request feedback from their colleagues or spontaneously review each other's code without
+
+105
+00:07:24,000 --> 00:07:26,000
+following a structured process.
+
+106
+00:07:27,000 --> 00:07:33,000
+While less formal, ad hoc reviews can still provide valuable insights and help identify issues early
+
+107
+00:07:33,000 --> 00:07:34,000
+in the development process.
+
+108
+00:07:35,000 --> 00:07:37,000
+Over the shoulder reviews.
+
+109
+00:07:38,000 --> 00:07:43,000
+Over the shoulder reviews involve one developer physically sitting with another and reviewing their
+
+110
+00:07:43,000 --> 00:07:44,000
+code.
+
+111
+00:07:44,000 --> 00:07:50,000
+The reviewer provides feedback and suggestions in real time as they examine the code together.
+
+112
+00:07:51,000 --> 00:07:56,000
+Over the shoulder reviews are beneficial for immediate feedback and knowledge transfer, but may not
+
+113
+00:07:56,000 --> 00:07:59,000
+be practical for remote or distributed teams.
+
+114
+00:08:00,000 --> 00:08:02,000
+Tool assisted reviews.
+
+115
+00:08:03,000 --> 00:08:09,000
+Tool assisted reviews utilize specialized code review tools or platforms to facilitate the review process.
+
+116
+00:08:10,000 --> 00:08:18,000
+These tools offer features such as code diffing to highlight all differences instantly, inline commenting,
+
+117
+00:08:18,000 --> 00:08:25,000
+issue tracking, and workflow management to streamline the review process and enhance collaboration.
+
+118
+00:08:25,000 --> 00:08:31,000
+Example of code review tools include GitHub, GitLab, Bitbucket, and others.
+
+119
+00:08:32,000 --> 00:08:34,000
+Formal inspections.
+
+120
+00:08:34,000 --> 00:08:43,000
+Formal inspections, also known as peer reviews or walkthroughs, are structured and thorough code review
+
+121
+00:08:43,000 --> 00:08:48,000
+processes conducted according to predefined guidelines and checklists.
+
+122
+00:08:48,000 --> 00:08:55,000
+Participants typically include developers, testers, and other stakeholders who systematically examine
+
+123
+00:08:55,000 --> 00:09:00,000
+the code for defects, compliance with standards, and adherence to requirements.
+
+124
+00:09:01,000 --> 00:09:08,000
+Formal inspections are more time consuming, but can be highly effective for identifying complex issues
+
+125
+00:09:08,000 --> 00:09:11,000
+and ensuring high quality code.
+
+126
+00:09:12,000 --> 00:09:13,000
+Synchronous code review.
+
+127
+00:09:13,000 --> 00:09:21,000
+In this type, the coder produces the code independently and then reviews it immediately, with the
+
+128
+00:09:21,000 --> 00:09:24,000
+reviewer discussing and improving the code together.
+
+129
+00:09:24,000 --> 00:09:30,000
+It is useful when the reviewer lacks knowledge about the task goals or when extensive code improvements
+
+130
+00:09:30,000 --> 00:09:31,000
+are expected.
+
+131
+00:09:32,000 --> 00:09:34,000
+Asynchronous code review.
+
+132
+00:09:34,000 --> 00:09:39,000
+Here, the coder completes the code and makes it available for review.
+
+133
+00:09:39,000 --> 00:09:47,000
+The reviewer then reviews the code at their own pace, providing commands and suggestions asynchronously.
+
+134
+00:09:47,000 --> 00:09:54,000
+This type is beneficial when there is no direct dependency between the code and the reviewer, and allows
+
+135
+00:09:54,000 --> 00:09:56,000
+for flexibility in scheduling.
+
+136
+00:09:56,000 --> 00:10:01,000
+Asynchronous code review can be done with assistance of different tools for code review.
+
+137
+00:10:03,000 --> 00:10:03,000
+Code review.
+
+138
+00:10:03,000 --> 00:10:10,000
+Once in a while, this method involves periodic code review sessions conducted by the entire team,
+
+139
+00:10:10,000 --> 00:10:17,000
+where one developer presents a piece of code they have been working on, and the team collectively reviews
+
+140
+00:10:17,000 --> 00:10:18,000
+and discusses it.
+
+141
+00:10:19,000 --> 00:10:24,000
+While not a permanent option, it can be useful for teams new to code reviews.
+
+142
+00:10:25,000 --> 00:10:31,000
+Each type of code review has its own strengths and weaknesses, and the choice of which to use depends
+
+143
+00:10:31,000 --> 00:10:38,000
+on factors such as team size, project complexity, development methodology, and organizational culture.
+
+144
+00:10:38,000 --> 00:10:44,000
+Combining different types of code, reviews can provide a comprehensive approach to code quality assurance
+
+145
+00:10:44,000 --> 00:10:47,000
+and collaboration within software development teams.
+
+146
+00:10:47,000 --> 00:10:53,000
+When selecting the type of code review to use, several factors should be considered to ensure that
+
+147
+00:10:53,000 --> 00:10:58,000
+it aligns the team's goals, workflow, and project requirements.
+
+148
+00:10:58,000 --> 00:11:02,000
+So, how to select the type of code reviews that will suit your team's best?
+
+149
+00:11:03,000 --> 00:11:08,000
+Let me provide you with a more detailed explanation of when to choose each type.
+
+150
+00:11:08,000 --> 00:11:10,000
+Asynchronous code reviews.
+
+151
+00:11:10,000 --> 00:11:16,000
+Asynchronous code reviews are suitable as a default option for professional development teams due to
+
+152
+00:11:16,000 --> 00:11:18,000
+their flexibility and efficiency.
+
+153
+00:11:19,000 --> 00:11:25,000
+They allow developers to review code at their own pace without being tied to synchronous collaboration.
+
+154
+00:11:26,000 --> 00:11:32,000
+Asynchronous reviews prevent the need for force context switching, where developers are interrupted
+
+155
+00:11:32,000 --> 00:11:35,000
+from their current tasks to participate in a review session.
+
+156
+00:11:36,000 --> 00:11:39,000
+This helps maintain focus and productivity.
+
+157
+00:11:40,000 --> 00:11:46,000
+Asynchronous reviews are effective for most common use cases, where developers can review code independently
+
+158
+00:11:46,000 --> 00:11:48,000
+and provide feedback asynchronously.
+
+159
+00:11:48,000 --> 00:11:54,000
+This type is ideal for teams with diverse schedules and distributed members.
+
+160
+00:11:54,000 --> 00:12:00,000
+Synchronous code reviews are appropriate when the reviewer lacks understanding of the changes made by
+
+161
+00:12:00,000 --> 00:12:01,000
+the coder.
+
+162
+00:12:01,000 --> 00:12:08,000
+In such cases, immediate collaboration and explanation can help clarify the code and ensure that feedback
+
+163
+00:12:08,000 --> 00:12:10,000
+is relevant and accurate.
+
+164
+00:12:10,000 --> 00:12:17,000
+If extensive code improvements are expected due to the coders lack of experience or familiarity with
+
+165
+00:12:17,000 --> 00:12:18,000
+the task.
+
+166
+00:12:18,000 --> 00:12:22,000
+Synchronous reviews allow for real time discussion and iteration on the code.
+
+167
+00:12:23,000 --> 00:12:28,000
+This can accelerate the review process and ensures that improvements are made efficiently.
+
+168
+00:12:29,000 --> 00:12:37,000
+Pair programming or instant code review is beneficial when solving complex business problems that require
+
+169
+00:12:37,000 --> 00:12:40,000
+close collaboration and immediate feedback to developers.
+
+170
+00:12:40,000 --> 00:12:47,000
+Working together can brainstorm solutions, discuss edge cases, and ensure that all scenarios are properly
+
+171
+00:12:47,000 --> 00:12:48,000
+handled in the code.
+
+172
+00:12:49,000 --> 00:12:55,000
+Pair programming works best when both developers have similar levels of expertise, allowing them to
+
+173
+00:12:55,000 --> 00:13:00,000
+work at a consistent pace and effectively collaborate on problem solving.
+
+174
+00:13:00,000 --> 00:13:07,000
+It fosters mutual learning and motivation, leading to higher productivity and code quality.
+
+175
+00:13:08,000 --> 00:13:14,000
+So asynchronous code reviews are the recommended default option for professional development teams due
+
+176
+00:13:14,000 --> 00:13:17,000
+to their flexibility and efficiency.
+
+177
+00:13:17,000 --> 00:13:19,000
+Synchronous reviews are.
+
+178
+00:13:19,000 --> 00:13:24,000
+Pair programming can be utilized when necessary, such as when immediate collaboration is required,
+
+179
+00:13:24,000 --> 00:13:27,000
+or for solving complex business problems.
+
+180
+00:13:27,000 --> 00:13:33,000
+Ultimately, the choice of code review type should be based on the specific needs and circumstances
+
+181
+00:13:33,000 --> 00:13:35,000
+of the team and the project.
+
+182
+00:13:36,000 --> 00:13:42,000
+Understanding the roles of both the code reviewer and the code author is crucial for an effective code
+
+183
+00:13:42,000 --> 00:13:43,000
+review process.
+
+184
+00:13:43,000 --> 00:13:46,000
+Here is an explanation of each role.
+
+185
+00:13:47,000 --> 00:13:48,000
+Code reviewer.
+
+186
+00:13:48,000 --> 00:13:54,000
+The code reviewer is responsible for evaluating the code changes submitted by the author.
+
+187
+00:13:54,000 --> 00:14:02,000
+This involves examining the code for errors, bugs, readability issues, and adherence to coding standards.
+
+188
+00:14:02,000 --> 00:14:08,000
+The reviewer provides constructive feedback to the author based on their evaluation of the code.
+
+189
+00:14:08,000 --> 00:14:14,000
+Feedback should be specific, actionable, and respectful, aimed at helping the author improve the
+
+190
+00:14:14,000 --> 00:14:15,000
+quality of their code.
+
+191
+00:14:16,000 --> 00:14:21,000
+Reviewers often share their expertise and knowledge with the author during the review process.
+
+192
+00:14:22,000 --> 00:14:28,000
+They may suggest alternative solutions, best practices, or improvements based on their experience
+
+193
+00:14:28,000 --> 00:14:30,000
+and understanding of the code base.
+
+194
+00:14:30,000 --> 00:14:37,000
+In some cases, the reviewer acts as a gatekeeper insurance that only high quality code is merged into
+
+195
+00:14:37,000 --> 00:14:38,000
+the code base.
+
+196
+00:14:38,000 --> 00:14:45,000
+They may reject code changes that do not meet the required standards, or pose risks to the stability
+
+197
+00:14:45,000 --> 00:14:47,000
+and integrity of the software.
+
+198
+00:14:47,000 --> 00:14:53,000
+Reviewers collaborate with the author to discuss and address issues identified during the review.
+
+199
+00:14:53,000 --> 00:14:59,000
+This collaboration fosters communication, teamwork, and collective ownership of the code base.
+
+200
+00:14:59,000 --> 00:15:03,000
+Let's now talk about code author role.
+
+201
+00:15:03,000 --> 00:15:08,000
+The code author is a developer who wrote the code changes being reviewed.
+
+202
+00:15:09,000 --> 00:15:14,000
+They are responsible for implementing the requested feature, fixing bugs, or making improvements to
+
+203
+00:15:14,000 --> 00:15:15,000
+the code base.
+
+204
+00:15:16,000 --> 00:15:21,000
+The author presents the code changes to the reviewer for evaluation and feedback.
+
+205
+00:15:21,000 --> 00:15:28,000
+They may provide context, explanations, or documentation to help the reviewer understand the purpose
+
+206
+00:15:28,000 --> 00:15:30,000
+and intent of the changes.
+
+207
+00:15:31,000 --> 00:15:37,000
+Authors receive feedback from the reviewer and are expected to consider it seriously.
+
+208
+00:15:37,000 --> 00:15:43,000
+They should be open to constructive criticism and willing to make necessary revisions to improve the
+
+209
+00:15:43,000 --> 00:15:45,000
+quality of their code.
+
+210
+00:15:46,000 --> 00:15:50,000
+Authors use code reviews as an opportunity to learn and grow.
+
+211
+00:15:50,000 --> 00:15:57,000
+As developers, they gain insights into the best practices, coding standards, and areas for improvement
+
+212
+00:15:57,000 --> 00:15:59,000
+through feedback provided by reviewers.
+
+213
+00:16:00,000 --> 00:16:07,000
+Ultimately, the author is responsible for addressing issues identified during the review and ensuring
+
+214
+00:16:07,000 --> 00:16:11,000
+that their code meets the required standards and quality criteria.
+
+215
+00:16:11,000 --> 00:16:18,000
+They may need to make revisions, clarify requirements, or seek assistance from other team members
+
+216
+00:16:18,000 --> 00:16:19,000
+as needed.
+
+217
+00:16:19,000 --> 00:16:23,000
+Let's now talk about development of a reviewer mindset.
+
+218
+00:16:24,000 --> 00:16:29,000
+Developing a reviewer mindset is essential for conducting effective code reviews.
+
+219
+00:16:29,000 --> 00:16:34,000
+Let's review some key aspects to consider when growing this mindset.
+
+220
+00:16:34,000 --> 00:16:38,000
+Pay close attention to the details of the code being reviewed.
+
+221
+00:16:38,000 --> 00:16:45,000
+Look for syntax errors, logic flaws, performance issues, and adherence to coding standards.
+
+222
+00:16:46,000 --> 00:16:52,000
+A keen eye for detail helps ensure that no potential issues go unnoticed.
+
+223
+00:16:53,000 --> 00:16:56,000
+Approach the review process with a critical mindset.
+
+224
+00:16:56,000 --> 00:17:02,000
+Question assumptions, challenge design decisions, and look for alternative solutions.
+
+225
+00:17:03,000 --> 00:17:10,000
+Critical thinking helps identify weaknesses in the code and suggests improvements that enhance its quality
+
+226
+00:17:10,000 --> 00:17:11,000
+and robustness.
+
+227
+00:17:12,000 --> 00:17:17,000
+Put yourself in the shoes of the code author and consider their perspective.
+
+228
+00:17:18,000 --> 00:17:25,000
+Understand the challenges they faced, the constraints they worked under, and the reasons behind their
+
+229
+00:17:25,000 --> 00:17:26,000
+decisions.
+
+230
+00:17:26,000 --> 00:17:32,000
+Empathy fosters constructive feedback and promotes a supportive and collaborative review environment.
+
+231
+00:17:33,000 --> 00:17:36,000
+Effectively communicate your feedback to the code author.
+
+232
+00:17:36,000 --> 00:17:43,000
+Clearly articulate your thoughts, suggestions, and concerns in a respectful and professional manner.
+
+233
+00:17:43,000 --> 00:17:45,000
+Use descriptive language.
+
+234
+00:17:45,000 --> 00:17:51,000
+Provide examples, and offer explanations to ensure that your feedback is understood and actionable.
+
+235
+00:17:52,000 --> 00:17:58,000
+Be open to different ideas, approaches and solutions presented in the code being reviewed.
+
+236
+00:17:58,000 --> 00:18:03,000
+Avoid being overly attached to your own preferences or biases.
+
+237
+00:18:04,000 --> 00:18:11,000
+Embrace diversity of thought and welcome feedback from others, even if it challenges your own perspective.
+
+238
+00:18:12,000 --> 00:18:17,000
+Approach each code review as an opportunity to learn and grow as a developer.
+
+239
+00:18:17,000 --> 00:18:23,000
+Stay curious, ask questions, and seek to expand your knowledge and understanding of different programming
+
+240
+00:18:23,000 --> 00:18:26,000
+languages, frameworks, and design patterns.
+
+241
+00:18:27,000 --> 00:18:32,000
+Embrace feedback from others as a means of personal and professional development.
+
+242
+00:18:32,000 --> 00:18:36,000
+Advocate for code quality and best practices within the team.
+
+243
+00:18:37,000 --> 00:18:39,000
+Encourage adherence to coding standards.
+
+244
+00:18:39,000 --> 00:18:44,000
+Consistency in coding style and adoption of software engineering principles.
+
+245
+00:18:45,000 --> 00:18:51,000
+Support initiatives that promote code quality such as code refactoring, automated testing, and code
+
+246
+00:18:51,000 --> 00:18:52,000
+reviews.
+
+247
+00:18:52,000 --> 00:18:57,000
+Be patient and respectful towards the code author during the review process.
+
+248
+00:18:57,000 --> 00:19:04,000
+Recognize that everyone makes mistakes and that code reviews are meant to improve, not criticize.
+
+249
+00:19:05,000 --> 00:19:11,000
+Offer feedback in a constructive and supportive manner, focusing on the code rather than the individual.
+
+250
+00:19:11,000 --> 00:19:18,000
+By embracing these principles and adopting a reviewer mindset, you can become an effective code reviewer
+
+251
+00:19:18,000 --> 00:19:23,000
+who contributes to the overall quality and success of the software development process.
+
+252
+00:19:23,000 --> 00:19:29,000
+And now it is time to review code review strategies in order to make a code review process even more
+
+253
+00:19:29,000 --> 00:19:30,000
+efficient.
+
+254
+00:19:31,000 --> 00:19:37,000
+Efficient code review requires careful planning, effective communication, and streamlined processes.
+
+255
+00:19:37,000 --> 00:19:42,000
+Let's review some strategies to conduct efficient code reviews.
+
+256
+00:19:42,000 --> 00:19:46,000
+Define the goals and expectations of the code review process up front.
+
+257
+00:19:47,000 --> 00:19:54,000
+Clarify what aspects of the code need to be reviewed, such as functionality, readability, performance,
+
+258
+00:19:54,000 --> 00:19:55,000
+and adherence to coding standards.
+
+259
+00:19:56,000 --> 00:20:03,000
+Develop and communicate clear guidelines for code reviews, including criteria for evaluating code quality,
+
+260
+00:20:03,000 --> 00:20:09,000
+standards for coding style and formatting, and expectations for reviewer and author behavior.
+
+261
+00:20:10,000 --> 00:20:14,000
+Consistent guidelines help ensure that reviews are focused and productive.
+
+262
+00:20:15,000 --> 00:20:20,000
+Take advantage of automated tools and utilities to streamline the review process.
+
+263
+00:20:20,000 --> 00:20:27,000
+Use code Linters, static analyzers and continuous integration systems to catch common issues and provide
+
+264
+00:20:27,000 --> 00:20:28,000
+feedback automatically.
+
+265
+00:20:29,000 --> 00:20:35,000
+This reduces the manual effort required for review and ensures consistency in code quality.
+
+266
+00:20:35,000 --> 00:20:42,000
+Break down large code changes into smaller, manageable chunks that can be reviewed independently.
+
+267
+00:20:42,000 --> 00:20:49,000
+This makes it easier for reviewers to focus on specific aspects of the code and provides more granular
+
+268
+00:20:49,000 --> 00:20:50,000
+feedback.
+
+269
+00:20:50,000 --> 00:20:56,000
+It also reduces the risk of overwhelming reviewers with too much information at once.
+
+270
+00:20:57,000 --> 00:21:04,000
+Prioritize code reviews based on factors such as impact of the change, the urgency of the task, and
+
+271
+00:21:04,000 --> 00:21:06,000
+the expertise of the reviewers.
+
+272
+00:21:07,000 --> 00:21:13,000
+Focus on reviewing critical or high risk changes first to minimize the potential for bugs and issues
+
+273
+00:21:13,000 --> 00:21:14,000
+to slip through.
+
+274
+00:21:15,000 --> 00:21:20,000
+Set limits on the size and scope of code changes to be reviewed in each session.
+
+275
+00:21:20,000 --> 00:21:27,000
+Aim for reviews that can be completed within a reasonable amount of time, such as 30 minutes to an
+
+276
+00:21:27,000 --> 00:21:27,000
+hour.
+
+277
+00:21:28,000 --> 00:21:33,000
+This helps maintain focus and prevents fatigue and burnout among reviewers.
+
+278
+00:21:34,000 --> 00:21:39,000
+Encourage developers to perform self reviews of their code before submitting it for review.
+
+279
+00:21:40,000 --> 00:21:46,000
+This allows authors to catch and address common issues and mistakes on their own, reducing the burden
+
+280
+00:21:46,000 --> 00:21:50,000
+on reviewers and accelerating the review process.
+
+281
+00:21:51,000 --> 00:21:54,000
+Provide timely feedback to authors during the review process.
+
+282
+00:21:54,000 --> 00:22:01,000
+Avoid unnecessary delays in reviewing code changes, as this can lead to bottlenecks and prolong the
+
+283
+00:22:01,000 --> 00:22:02,000
+development cycle.
+
+284
+00:22:02,000 --> 00:22:07,000
+Aim to review code changes promptly and provide feedback within a reasonable time frame.
+
+285
+00:22:08,000 --> 00:22:15,000
+Foster a collaborative environment where reviewers and authors can discuss code changes openly and constructively.
+
+286
+00:22:16,000 --> 00:22:22,000
+Encourage open communication, active participation, and mutual respect among team members.
+
+287
+00:22:22,000 --> 00:22:28,000
+Collaboration leads to better understanding, alignment, and ultimately higher quality code.
+
+288
+00:22:28,000 --> 00:22:34,000
+Continuously validate and refine the code review process based on feedback and lessons learned.
+
+289
+00:22:35,000 --> 00:22:42,000
+Ask for an input from team members on ways to improve efficiency, effectiveness, and overall satisfaction
+
+290
+00:22:42,000 --> 00:22:43,000
+with the review process.
+
+291
+00:22:44,000 --> 00:22:50,000
+Adapt and iterate on your strategies to ensure that code reviews remain valuable and productive over
+
+292
+00:22:50,000 --> 00:22:50,000
+time.
+
+293
+00:22:51,000 --> 00:22:57,000
+By implementing these strategies, teams can conduct efficient and effective code reviews that improve
+
+294
+00:22:57,000 --> 00:23:02,000
+code quality, promote knowledge sharing, and foster collaboration within the development team.
+
+295
+00:23:03,000 --> 00:23:04,000
+That's all.
+
+296
+00:23:04,000 --> 00:23:06,000
+What I wanted to share with you today.
+
+297
+00:23:06,000 --> 00:23:09,000
+Let's recap what we have learned in the lesson.
+
+298
+00:23:09,000 --> 00:23:11,000
+In this lesson, we have learned a lot.
+
+299
+00:23:12,000 --> 00:23:15,000
+We learned basic principles and goals of code review.
+
+300
+00:23:15,000 --> 00:23:22,000
+I explained you different types of code review, and I explained what types of code review are applicable
+
+301
+00:23:22,000 --> 00:23:23,000
+in which case.
+
+302
+00:23:23,000 --> 00:23:26,000
+We learned role of code reviewer and author.
+
+303
+00:23:26,000 --> 00:23:31,000
+I shared with you guidelines that will help you to develop reviewer mindset.
+
+304
+00:23:31,000 --> 00:23:36,000
+And at the end of the lesson we learned strategies for efficient code review.
+
+305
+00:23:36,000 --> 00:23:42,000
+And just to remind you that in case you have any questions, please do not hesitate to post your questions
+
+306
+00:23:42,000 --> 00:23:45,000
+below the video and I will be happy to answer.
+
+307
+00:23:45,000 --> 00:23:47,000
+That's it for this lesson.
+
+308
+00:23:47,000 --> 00:23:49,000
+Thanks a lot for your attention.
+
+309
+00:23:49,000 --> 00:23:52,000
+Have a great day and see you in the next lesson.
+

108 - Tools, Automation, and Industry Best Practices/001 Tools for Code Review and Code Analysis_en.srt

@@ -0,0 +1,1244 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Tim.
+
+2
+00:00:06,000 --> 00:00:10,000
+In this lesson we'll talk about code review tools.
+
+3
+00:00:10,000 --> 00:00:15,000
+We are going to start our lesson from learning tools for code reviews that can facilitate the code review
+
+4
+00:00:15,000 --> 00:00:16,000
+process.
+
+5
+00:00:16,000 --> 00:00:21,000
+After that, we will talk about tools for code analysis, when we will learn tools and understand their
+
+6
+00:00:21,000 --> 00:00:22,000
+benefits.
+
+7
+00:00:22,000 --> 00:00:27,000
+I will explain how you can integrate these tools into software development process.
+
+8
+00:00:27,000 --> 00:00:33,000
+And at the end of the lesson, we will talk about best practices for secure and scalable code, because
+
+9
+00:00:33,000 --> 00:00:39,000
+using of tools for code monitoring and code analysis opens the stage for improving your code and making
+
+10
+00:00:39,000 --> 00:00:41,000
+it more secure and scalable.
+
+11
+00:00:41,000 --> 00:00:43,000
+So let's start our lesson.
+
+12
+00:00:44,000 --> 00:00:50,000
+As I told you in agenda of the lesson, I suggest to start from the short overview of code review tools.
+
+13
+00:00:50,000 --> 00:00:56,000
+Code review tools are software applications designed to facilitate the process of reviewing code within
+
+14
+00:00:56,000 --> 00:00:57,000
+a development team.
+
+15
+00:00:57,000 --> 00:01:04,000
+These tools help developers collaborate more efficiently, ensuring that code is of high quality, adheres
+
+16
+00:01:04,000 --> 00:01:09,000
+to coding standards, and is free of errors or vulnerabilities.
+
+17
+00:01:09,000 --> 00:01:13,000
+Let's review some common code review tools.
+
+18
+00:01:13,000 --> 00:01:20,000
+GitLab GitLab offers built in code review features as part of its version control platform.
+
+19
+00:01:20,000 --> 00:01:27,000
+It allows for inline comments and discussions and merge requests, enabling seamless collaboration among
+
+20
+00:01:27,000 --> 00:01:28,000
+team members.
+
+21
+00:01:29,000 --> 00:01:30,000
+GitHub.
+
+22
+00:01:30,000 --> 00:01:36,000
+GitHub provides a similar set of features to GitLab, including pull requests, inline comments, and
+
+23
+00:01:36,000 --> 00:01:37,000
+code discussions.
+
+24
+00:01:37,000 --> 00:01:42,000
+It's widely used in open source community and by many development teams for code review.
+
+25
+00:01:43,000 --> 00:01:50,000
+Bitbucket, another popular version control platform, offers code review capabilities similar to GitLab
+
+26
+00:01:50,000 --> 00:01:51,000
+and GitHub.
+
+27
+00:01:51,000 --> 00:01:57,000
+It supports pull requests, inline commenting and integration with issue tracking systems.
+
+28
+00:01:57,000 --> 00:02:03,000
+Has native integration with all Atlassian products like Jira, for example.
+
+29
+00:02:04,000 --> 00:02:10,000
+Fabricator is an open source suite of development tools that includes a code review tool.
+
+30
+00:02:10,000 --> 00:02:18,000
+It provides features like differential revisions similar to pull requests, inline comments, and automated
+
+31
+00:02:18,000 --> 00:02:19,000
+code analysis.
+
+32
+00:02:20,000 --> 00:02:27,000
+Reviewboard is an open source, web based code review tool that supports various version control systems
+
+33
+00:02:27,000 --> 00:02:30,000
+like git, subversion, and Mercurial.
+
+34
+00:02:31,000 --> 00:02:36,000
+It allows for reviewing code changes, commenting, and integrating with issue trackers.
+
+35
+00:02:37,000 --> 00:02:40,000
+It can be considered as an alternative to Garrett.
+
+36
+00:02:40,000 --> 00:02:45,000
+Garrett is a code review tool specifically designed for teams using git.
+
+37
+00:02:45,000 --> 00:02:52,000
+It provides a web based interface for reviewing code changes, along with features like access control,
+
+38
+00:02:52,000 --> 00:02:56,000
+code search, and integration with continuous integration systems.
+
+39
+00:02:57,000 --> 00:03:03,000
+Crucible, developed by Atlassian, is a code review tool that integrates with Jira and Bitbucket.
+
+40
+00:03:03,000 --> 00:03:10,000
+It supports Pre-commit and post commit reviews, code discussions and metrics to track code review activity.
+
+41
+00:03:11,000 --> 00:03:12,000
+Collaborator.
+
+42
+00:03:12,000 --> 00:03:18,000
+Collaborator is a code review tools that supports reviewing code changes in various version control
+
+43
+00:03:18,000 --> 00:03:22,000
+systems, including git, subversion, and Perforce.
+
+44
+00:03:22,000 --> 00:03:28,000
+It offers features like side by side, gives commands, and reporting.
+
+45
+00:03:29,000 --> 00:03:36,000
+These code review tools helps teams maintain code quality, catch bugs early, and ensure consistency
+
+46
+00:03:36,000 --> 00:03:37,000
+in coding standards.
+
+47
+00:03:37,000 --> 00:03:43,000
+By enabling efficient collaboration and communication among team members, they contribute to the overall
+
+48
+00:03:43,000 --> 00:03:46,000
+success of software development projects.
+
+49
+00:03:46,000 --> 00:03:52,000
+So now you know the list of tools that are designed to facilitate the process of reviewing the code.
+
+50
+00:03:52,000 --> 00:03:56,000
+In what other ways we can improve the code review process?
+
+51
+00:03:56,000 --> 00:04:00,000
+What other tools can come in handy to improve code analysis?
+
+52
+00:04:00,000 --> 00:04:05,000
+Let's answer these questions and talk about using of automated tools for code analysis.
+
+53
+00:04:06,000 --> 00:04:12,000
+Automated tools for code analysis play a crucial role in modern software development by helping developers
+
+54
+00:04:12,000 --> 00:04:17,000
+identify potential issues, enforce coding standards, and improve overall code quality.
+
+55
+00:04:18,000 --> 00:04:21,000
+Let's review automated tools for code analysis.
+
+56
+00:04:21,000 --> 00:04:27,000
+During the review, I will list few examples of tools, but taking into account they have similar features
+
+57
+00:04:27,000 --> 00:04:28,000
+and functionality.
+
+58
+00:04:28,000 --> 00:04:32,000
+I will just provide you with detailed explanation for just one tool from the list.
+
+59
+00:04:33,000 --> 00:04:38,000
+Static code analysis tools analyze source code without executing it.
+
+60
+00:04:38,000 --> 00:04:45,000
+They can detect various issues such as syntax errors, potential bugs, code smells, and adherence
+
+61
+00:04:45,000 --> 00:04:47,000
+to coding standards.
+
+62
+00:04:47,000 --> 00:04:48,000
+Tools.
+
+63
+00:04:48,000 --> 00:04:52,000
+Examples are Findbugs for Java.
+
+64
+00:04:52,000 --> 00:04:53,000
+Rubocop for Ruby.
+
+65
+00:04:54,000 --> 00:04:55,000
+Sonarqube.
+
+66
+00:04:56,000 --> 00:05:02,000
+For example, Sonar Cube is an open source platform that performs static code analysis to identify bugs,
+
+67
+00:05:02,000 --> 00:05:04,000
+vulnerabilities, and code smells.
+
+68
+00:05:04,000 --> 00:05:10,000
+It supports various programming languages and provide detailed reports on code quality.
+
+69
+00:05:11,000 --> 00:05:18,000
+Linters are a type of static code analysis tool that focus on identifying code style issues and potential
+
+70
+00:05:18,000 --> 00:05:19,000
+errors.
+
+71
+00:05:19,000 --> 00:05:25,000
+They enforce coding conventions and can be configured to flag deviations from best practices.
+
+72
+00:05:26,000 --> 00:05:35,000
+The tools examples are flake8 for Python, stylecop for C sharp, es, lint for JavaScript.
+
+73
+00:05:36,000 --> 00:05:42,000
+And if we're talking about ES lint, it's worth to mention that it is popular linter for JavaScript
+
+74
+00:05:42,000 --> 00:05:48,000
+that helps enforce coding standards, detect errors, and highlight potential issues in the code.
+
+75
+00:05:48,000 --> 00:05:55,000
+It offers a wide range of configurable rules and integrates seamlessly with build systems and Ides.
+
+76
+00:05:56,000 --> 00:05:57,000
+Code quality metrics.
+
+77
+00:05:58,000 --> 00:06:04,000
+Automated tools can measure code quality metrics such as cyclomatic complexity, code duplication,
+
+78
+00:06:04,000 --> 00:06:06,000
+and code coverage.
+
+79
+00:06:06,000 --> 00:06:12,000
+These metrics provide insights into the maintainability, readability, and testability of the code
+
+80
+00:06:12,000 --> 00:06:13,000
+base.
+
+81
+00:06:14,000 --> 00:06:15,000
+Recommended tools are.
+
+82
+00:06:16,000 --> 00:06:17,000
+Secret sonar.
+
+83
+00:06:17,000 --> 00:06:19,000
+Cloud code.
+
+84
+00:06:19,000 --> 00:06:20,000
+Climate.
+
+85
+00:06:20,000 --> 00:06:27,000
+For example, if we talk about cold climate, it works to mention that it analyzes code quality metrics
+
+86
+00:06:27,000 --> 00:06:31,000
+such as code duplication, complexity, and test coverage.
+
+87
+00:06:31,000 --> 00:06:38,000
+It provides insights into code maintainability and helps teams prioritize improvements to enhance overall
+
+88
+00:06:38,000 --> 00:06:40,000
+code quality.
+
+89
+00:06:40,000 --> 00:06:43,000
+Let's now talk about security scanners.
+
+90
+00:06:43,000 --> 00:06:49,000
+Security focused code analysis tools identify vulnerabilities and security weaknesses in the code,
+
+91
+00:06:49,000 --> 00:06:57,000
+such as injection flaws, cross-site scripting vulnerabilities, and insecure configuration settings.
+
+92
+00:06:57,000 --> 00:07:02,000
+They help developers address security risks before deploying the software.
+
+93
+00:07:03,000 --> 00:07:06,000
+Let's review some examples of tools.
+
+94
+00:07:06,000 --> 00:07:09,000
+Sneak Whitesource bolt.
+
+95
+00:07:09,000 --> 00:07:12,000
+Black duck by Synopsys.
+
+96
+00:07:12,000 --> 00:07:14,000
+Avast dependency check.
+
+97
+00:07:14,000 --> 00:07:20,000
+Avast Dependency Check is a security scanner that identifies known vulnerabilities in a project.
+
+98
+00:07:20,000 --> 00:07:21,000
+Dependencies.
+
+99
+00:07:21,000 --> 00:07:28,000
+It scans dependencies for outdated or vulnerable components and provides actionable insights to mitigate
+
+100
+00:07:28,000 --> 00:07:30,000
+security risks.
+
+101
+00:07:31,000 --> 00:07:33,000
+Continuous integration pipelines.
+
+102
+00:07:33,000 --> 00:07:40,000
+CI pipelines often include automated code analysis steps that run whenever code changes are pushed to
+
+103
+00:07:40,000 --> 00:07:42,000
+the version control system.
+
+104
+00:07:42,000 --> 00:07:49,000
+This ensures that code quality checks are performed regularly and integrated seamlessly into the development
+
+105
+00:07:49,000 --> 00:07:50,000
+workflow.
+
+106
+00:07:50,000 --> 00:07:53,000
+Among CI tools, it worth to mention the following ones.
+
+107
+00:07:53,000 --> 00:07:58,000
+Circleci Travis CI Jenkins.
+
+108
+00:07:58,000 --> 00:08:05,000
+Jenkins is a widely used CI CD tools that allows developers to automate code analysis as part of their
+
+109
+00:08:05,000 --> 00:08:06,000
+build pipelines.
+
+110
+00:08:06,000 --> 00:08:13,000
+It integrates with various code analysis tools and version control systems, enabling continuous feedback
+
+111
+00:08:13,000 --> 00:08:14,000
+on code quality.
+
+112
+00:08:15,000 --> 00:08:17,000
+Integration with version control systems.
+
+113
+00:08:18,000 --> 00:08:24,000
+Automated code analysis tools can integrate with version control systems like git, allowing them to
+
+114
+00:08:24,000 --> 00:08:28,000
+analyze code changes as they are committed or pushed.
+
+115
+00:08:28,000 --> 00:08:35,000
+This enables early detection and resolution of issues before they are merged into the main code base.
+
+116
+00:08:35,000 --> 00:08:39,000
+I am talking about such tools as GitLab CI, CD.
+
+117
+00:08:39,000 --> 00:08:41,000
+Cut cough.
+
+118
+00:08:41,000 --> 00:08:48,000
+Cut cough integrates with version control systems like GitHub and GitLab to provide code coverage reports
+
+119
+00:08:48,000 --> 00:08:49,000
+for automated tests.
+
+120
+00:08:49,000 --> 00:08:57,000
+It helps developers track code coverage trends and identify errors of the code base that require additional
+
+121
+00:08:57,000 --> 00:08:58,000
+testing.
+
+122
+00:08:59,000 --> 00:09:01,000
+Custom rules and configurations.
+
+123
+00:09:01,000 --> 00:09:08,000
+Many code analysis tools allow developers to define custom rules and configurations tailored to their
+
+124
+00:09:08,000 --> 00:09:10,000
+project specific requirements.
+
+125
+00:09:10,000 --> 00:09:17,000
+This flexibility ensures that analysis is aligned with the team's coding standards and practices.
+
+126
+00:09:17,000 --> 00:09:22,000
+The examples of tools are PHP code sniffer for PHP.
+
+127
+00:09:22,000 --> 00:09:25,000
+Tslint for TypeScript.
+
+128
+00:09:25,000 --> 00:09:27,000
+Checkstyle for Java.
+
+129
+00:09:27,000 --> 00:09:33,000
+Checkstyle is a customizable static code analysis tool for Java that enforces coding standards and best
+
+130
+00:09:33,000 --> 00:09:34,000
+practices.
+
+131
+00:09:34,000 --> 00:09:41,000
+It allows developers to define custom rules and configurations to ensure a consistent code quality across
+
+132
+00:09:41,000 --> 00:09:41,000
+projects.
+
+133
+00:09:42,000 --> 00:09:44,000
+Feedback mechanisms.
+
+134
+00:09:44,000 --> 00:09:50,000
+Automated code analysis tools provide feedback to developers in various forms, such as reports, notifications,
+
+135
+00:09:50,000 --> 00:09:53,000
+and integrations with issue tracking systems.
+
+136
+00:09:54,000 --> 00:10:00,000
+This feedback loop helps developers address issues promptly and continuously improve code quality.
+
+137
+00:10:00,000 --> 00:10:09,000
+Examples of automated tools in this group are Bitbucket pipelines GitHub actions GitHub actions is a
+
+138
+00:10:09,000 --> 00:10:16,000
+CI CD service provided by GitHub that allows developers to automate workflows, including code analysis.
+
+139
+00:10:16,000 --> 00:10:22,000
+It provides feedback on code quality directly within pull requests, enabling quick review and resolution
+
+140
+00:10:22,000 --> 00:10:23,000
+of issues.
+
+141
+00:10:23,000 --> 00:10:30,000
+By leveraging automated tools for code analysis, development teams can enhance productivity, reduce
+
+142
+00:10:30,000 --> 00:10:35,000
+bugs and vulnerabilities, and deliver high quality software more efficiently.
+
+143
+00:10:36,000 --> 00:10:43,000
+These tools complement manual code reviews and testing efforts, contributing to a robust software development
+
+144
+00:10:43,000 --> 00:10:43,000
+process.
+
+145
+00:10:44,000 --> 00:10:50,000
+Integrating tools into the development process is crucial for ensuring the effectiveness and maximizing
+
+146
+00:10:50,000 --> 00:10:55,000
+their impact on code quality, productivity, and overall project success.
+
+147
+00:10:56,000 --> 00:11:01,000
+So far, we learned tools that facilitate code review process and tools for code analysis.
+
+148
+00:11:02,000 --> 00:11:06,000
+Let's review even more tools that can be useful during the development.
+
+149
+00:11:06,000 --> 00:11:13,000
+But first, let's answer how we will integrate tools that we reviewed into the development process.
+
+150
+00:11:14,000 --> 00:11:16,000
+Static code analysis.
+
+151
+00:11:16,000 --> 00:11:24,000
+Integrate Pylint, Findbugs or Rubocop into the development process by configuring them to run as part
+
+152
+00:11:24,000 --> 00:11:26,000
+of the CI pipeline.
+
+153
+00:11:26,000 --> 00:11:31,000
+Developers push their code changes to the version control system.
+
+154
+00:11:31,000 --> 00:11:37,000
+The CI pipeline triggers static code analysis using the configured tools, providing feedback on code
+
+155
+00:11:37,000 --> 00:11:39,000
+quality and potential issues.
+
+156
+00:11:39,000 --> 00:11:47,000
+Integrate Flake8, ESLint, or Stylecop into the development process by configuring them to run locally
+
+157
+00:11:47,000 --> 00:11:50,000
+during the development and as part of the CI pipeline.
+
+158
+00:11:51,000 --> 00:11:57,000
+Developers use Linters during local development to ensure adherence to coding standards.
+
+159
+00:11:57,000 --> 00:12:03,000
+Linters are also configured to run automatically in the CI pipeline, providing consistent code quality
+
+160
+00:12:03,000 --> 00:12:05,000
+checks across all code changes.
+
+161
+00:12:06,000 --> 00:12:07,000
+Integrate code climate.
+
+162
+00:12:07,000 --> 00:12:13,000
+Better Code Hub or sooner cloud into the CI pipeline to analyze code quality metrics.
+
+163
+00:12:13,000 --> 00:12:20,000
+After each code change is pushed to the version control system, the CI pipeline triggers code quality
+
+164
+00:12:20,000 --> 00:12:22,000
+analysis using the selected tools.
+
+165
+00:12:22,000 --> 00:12:29,000
+Developers review the generated reports to identify areas for improvement and prioritize refactoring
+
+166
+00:12:29,000 --> 00:12:29,000
+efforts.
+
+167
+00:12:30,000 --> 00:12:37,000
+Security scanners integrate sneak, Whitesource, bolt or Black Dog into the CI pipeline to scan for
+
+168
+00:12:37,000 --> 00:12:41,000
+security vulnerabilities in dependencies and code.
+
+169
+00:12:41,000 --> 00:12:47,000
+Security scans are automatically performed as part of the CI pipeline upon code changes.
+
+170
+00:12:47,000 --> 00:12:53,000
+Developers receive alerts for any identified vulnerabilities and take appropriate action to remediate
+
+171
+00:12:53,000 --> 00:12:54,000
+them.
+
+172
+00:12:55,000 --> 00:13:04,000
+Continuous integration pipelines use Jenkins Circleci or Travis CI to set up CI pipelines that automate
+
+173
+00:13:04,000 --> 00:13:07,000
+building, testing, and deploying code changes.
+
+174
+00:13:07,000 --> 00:13:13,000
+Developers push code changes to the version control system, triggering the CI pipeline.
+
+175
+00:13:13,000 --> 00:13:19,000
+The pipeline performs automated tasks such as building the code, running tests, and executing code
+
+176
+00:13:19,000 --> 00:13:22,000
+analysis tools before deploying changes to production.
+
+177
+00:13:23,000 --> 00:13:26,000
+Integration with version control systems.
+
+178
+00:13:26,000 --> 00:13:33,000
+Integrate Codecov on GitLab CI CD with version control system to provide code coverage, reports and
+
+179
+00:13:33,000 --> 00:13:34,000
+other insights.
+
+180
+00:13:35,000 --> 00:13:39,000
+Code coverage reports are generated automatically as part of the CI pipeline.
+
+181
+00:13:40,000 --> 00:13:46,000
+Developers use these reports to assess test coverage and identify areas of the code base that require
+
+182
+00:13:46,000 --> 00:13:47,000
+additional testing.
+
+183
+00:13:48,000 --> 00:13:50,000
+Custom rules and configurations.
+
+184
+00:13:50,000 --> 00:13:58,000
+Integrate Checkstyle PHP code sniffer or Tslint into the CI pipeline to enforce custom coding standards
+
+185
+00:13:58,000 --> 00:13:59,000
+and configurations.
+
+186
+00:13:59,000 --> 00:14:04,000
+Custom rules and configurations are applied during code analysis in the CI pipeline.
+
+187
+00:14:05,000 --> 00:14:11,000
+Developers receive feedback on code adherence to coding standards and make necessary adjustments accordingly.
+
+188
+00:14:12,000 --> 00:14:14,000
+Feedback mechanisms.
+
+189
+00:14:14,000 --> 00:14:22,000
+Use GitHub actions GitLab, CI, CD or Bitbucket pipelines to automate feedback mechanisms such as notifications
+
+190
+00:14:22,000 --> 00:14:23,000
+and alerts.
+
+191
+00:14:24,000 --> 00:14:30,000
+Automated notifications are sent to developers via their preferred communication channels, for example
+
+192
+00:14:30,000 --> 00:14:37,000
+slack or email for events like build failures, test errors, or security vulnerabilities, enabling
+
+193
+00:14:37,000 --> 00:14:39,000
+quick response and resolution.
+
+194
+00:14:40,000 --> 00:14:42,000
+Version control system.
+
+195
+00:14:42,000 --> 00:14:49,000
+Integration tools like git, mercurial, or SVN serve as a backbone of version control for most projects.
+
+196
+00:14:50,000 --> 00:14:56,000
+Integration with version control systems allows for seamless code review, automated testing and deployment
+
+197
+00:14:56,000 --> 00:14:57,000
+processes.
+
+198
+00:14:57,000 --> 00:15:04,000
+Developers commit their changes to the version control system, triggering automated processes such
+
+199
+00:15:04,000 --> 00:15:07,000
+as code analysis and continuous integration.
+
+200
+00:15:08,000 --> 00:15:08,000
+Code review.
+
+201
+00:15:08,000 --> 00:15:10,000
+Tools integration.
+
+202
+00:15:10,000 --> 00:15:17,000
+Code review tools like GitHub, GitLab, or Bitbucket provide features for peer code review, including
+
+203
+00:15:17,000 --> 00:15:20,000
+pull requests, code commenting, and discussions.
+
+204
+00:15:20,000 --> 00:15:27,000
+Developers create pull requests or merge requests for proposed changes which trigger code review processes.
+
+205
+00:15:28,000 --> 00:15:33,000
+Integrating code review tools with version control systems ensures that code changes are thoroughly
+
+206
+00:15:33,000 --> 00:15:37,000
+reviewed before being merged into the main code base.
+
+207
+00:15:38,000 --> 00:15:38,000
+Issue tracking.
+
+208
+00:15:38,000 --> 00:15:40,000
+System integration.
+
+209
+00:15:40,000 --> 00:15:48,000
+Issue tracking systems like Jira, Trello, or Asana help manage and prioritize tasks, bugs, and feature
+
+210
+00:15:48,000 --> 00:15:49,000
+requests.
+
+211
+00:15:49,000 --> 00:15:55,000
+Integration with version control and CI tools allows for automatic linkage between code changes and
+
+212
+00:15:55,000 --> 00:15:57,000
+corresponding issues.
+
+213
+00:15:57,000 --> 00:16:03,000
+Developers can reference issues in commit messages or pull requests, facilitating traceability and
+
+214
+00:16:03,000 --> 00:16:05,000
+collaboration across teams.
+
+215
+00:16:06,000 --> 00:16:07,000
+Documentation tools.
+
+216
+00:16:07,000 --> 00:16:08,000
+Integration.
+
+217
+00:16:08,000 --> 00:16:17,000
+Documentation tools like Sphinx, Doxygen or IMCa docs assist in creating and maintaining project documentation.
+
+218
+00:16:17,000 --> 00:16:25,000
+Integration with version control systems ensures that the communication is versioned and updated alongside
+
+219
+00:16:25,000 --> 00:16:26,000
+code changes.
+
+220
+00:16:26,000 --> 00:16:33,000
+Automated processes can be set up to generate and publish documentation as part of CI CD pipelines,
+
+221
+00:16:33,000 --> 00:16:36,000
+ensuring that it remains up to date and accessible.
+
+222
+00:16:37,000 --> 00:16:40,000
+Alerting and notification integration.
+
+223
+00:16:40,000 --> 00:16:47,000
+Alerting and notification systems such as slack, email, or SMS provide real time feedback on critical
+
+224
+00:16:47,000 --> 00:16:48,000
+events or issues.
+
+225
+00:16:49,000 --> 00:16:55,000
+Integration with CI CD tools allows for immediate notification of build failures, test errors, or
+
+226
+00:16:55,000 --> 00:16:57,000
+security vulnerabilities.
+
+227
+00:16:57,000 --> 00:17:03,000
+Developers can receive alerts and take prompt action to address issues, preventing them from escalating
+
+228
+00:17:03,000 --> 00:17:05,000
+and impacting the project.
+
+229
+00:17:05,000 --> 00:17:12,000
+By integrating these tools into the development process, teams can streamline workflows, improve collaboration,
+
+230
+00:17:12,000 --> 00:17:18,000
+and maintain high standards of code quality, reliability, and efficiencies throughout the software
+
+231
+00:17:18,000 --> 00:17:20,000
+development life cycle.
+
+232
+00:17:20,000 --> 00:17:26,000
+Understanding how code review tools and automated analysis enhance development processes.
+
+233
+00:17:26,000 --> 00:17:32,000
+Sets the stage for implementing best practices in writing secure and scalable code.
+
+234
+00:17:33,000 --> 00:17:39,000
+By effectively leveraging these tools, developers can detect potential security vulnerabilities and
+
+235
+00:17:39,000 --> 00:17:41,000
+scalability issues early on.
+
+236
+00:17:41,000 --> 00:17:48,000
+Integrating them seamlessly into workflows enables continuous monitoring and adherence to coding standards,
+
+237
+00:17:48,000 --> 00:17:54,000
+fostering the adoption of secure coding practices and scalability considerations.
+
+238
+00:17:54,000 --> 00:18:02,000
+Thus, proficiency in utilizing these tools empowers developers to prioritize security and scalability,
+
+239
+00:18:02,000 --> 00:18:07,000
+ensuring resilient software in the face of evolving demands and threats.
+
+240
+00:18:08,000 --> 00:18:12,000
+So let me share with you best practices for secure and scalable code.
+
+241
+00:18:12,000 --> 00:18:18,000
+Of course, this is not a topic for a few minutes, and I have a few courses on this topic like Secure
+
+242
+00:18:18,000 --> 00:18:21,000
+coding, Clean code, and other courses.
+
+243
+00:18:22,000 --> 00:18:25,000
+Feel free to check the details on my instructor's page.
+
+244
+00:18:25,000 --> 00:18:31,000
+But in scope of this lesson, let me just make a summary of the most important points to consider.
+
+245
+00:18:32,000 --> 00:18:33,000
+Input validation.
+
+246
+00:18:34,000 --> 00:18:40,000
+Always validate input from external sources such as user input APIs or files.
+
+247
+00:18:41,000 --> 00:18:49,000
+This helps prevent security vulnerabilities such as injection attacks like SQL injection or cross-site
+
+248
+00:18:49,000 --> 00:18:52,000
+scripting, and ensures data integrity.
+
+249
+00:18:52,000 --> 00:18:55,000
+Secure authentication and authorization.
+
+250
+00:18:56,000 --> 00:19:05,000
+Use secure authentication mechanisms, for example like AWS or JWT, and implement proper authorization
+
+251
+00:19:05,000 --> 00:19:08,000
+checks to control access to sensitive resources.
+
+252
+00:19:09,000 --> 00:19:15,000
+Avoid hardcoding credentials and always hash passwords using strong cryptographic algorithms.
+
+253
+00:19:16,000 --> 00:19:19,000
+Data sanitization and encoding.
+
+254
+00:19:20,000 --> 00:19:28,000
+Sanitize and encode user supplied data before processing or displaying it to prevent cross-site scripting
+
+255
+00:19:28,000 --> 00:19:30,000
+and other injection attacks.
+
+256
+00:19:30,000 --> 00:19:34,000
+Use proper encoding methods based on the context.
+
+257
+00:19:34,000 --> 00:19:37,000
+For example HTML entity encoding.
+
+258
+00:19:37,000 --> 00:19:38,000
+URL encoding.
+
+259
+00:19:40,000 --> 00:19:47,000
+Least privilege principle follows the principle of least privilege by granting only the minimum permissions
+
+260
+00:19:47,000 --> 00:19:51,000
+necessary for users or processes to perform their tasks.
+
+261
+00:19:52,000 --> 00:19:57,000
+Limit access to sensitive data and functionality to authorized users only.
+
+262
+00:19:58,000 --> 00:20:05,000
+Secure configuration ensures that your application and server configurations are secure by disabling
+
+263
+00:20:05,000 --> 00:20:06,000
+unnecessary services.
+
+264
+00:20:06,000 --> 00:20:14,000
+Using strong encryption for data in transit and at rest, and keeping software dependencies up to date
+
+265
+00:20:14,000 --> 00:20:15,000
+with security patches.
+
+266
+00:20:16,000 --> 00:20:18,000
+Error handling and logging.
+
+267
+00:20:19,000 --> 00:20:25,000
+Implement robust error handling mechanisms to gracefully handle unexpected errors and prevent information
+
+268
+00:20:25,000 --> 00:20:26,000
+disclosure.
+
+269
+00:20:27,000 --> 00:20:34,000
+Log security, relevant events and errors with sufficient details for debugging and auditing purposes.
+
+270
+00:20:35,000 --> 00:20:37,000
+Secure coding practices.
+
+271
+00:20:37,000 --> 00:20:44,000
+Follow secure coding practices such as avoiding hard coded secrets, using parameterized queries for
+
+272
+00:20:44,000 --> 00:20:49,000
+database access, and escaping output to prevent injection attacks.
+
+273
+00:20:49,000 --> 00:20:54,000
+Adhere to industry standard security guidelines and coding standards.
+
+274
+00:20:55,000 --> 00:20:56,000
+Secure communication.
+
+275
+00:20:57,000 --> 00:21:05,000
+Use https tls for secure communication between client and server to protect data confidentiality and
+
+276
+00:21:05,000 --> 00:21:05,000
+integrity.
+
+277
+00:21:06,000 --> 00:21:13,000
+Avoid transmitting sensitive information over insecure channels and implement proper certificate management
+
+278
+00:21:13,000 --> 00:21:13,000
+practices.
+
+279
+00:21:14,000 --> 00:21:22,000
+In my course Java From zero to first job, we learned with students how to configure https tls connection
+
+280
+00:21:22,000 --> 00:21:24,000
+for your web application.
+
+281
+00:21:24,000 --> 00:21:31,000
+In case you will have any related questions, please do not hesitate to post your questions below the
+
+282
+00:21:31,000 --> 00:21:33,000
+video and I will be happy to answer.
+
+283
+00:21:34,000 --> 00:21:41,000
+Security testing, conduct regular security assessments, penetration testing, and code reviews to
+
+284
+00:21:41,000 --> 00:21:46,000
+identify and remediate security vulnerabilities early in the development life cycle.
+
+285
+00:21:46,000 --> 00:21:51,000
+Use automated security scanning tools to augment manual testing efforts.
+
+286
+00:21:52,000 --> 00:21:54,000
+Scalability considerations.
+
+287
+00:21:54,000 --> 00:22:01,000
+Design your code with scalability in mind by following architectural patterns such as microservices,
+
+288
+00:22:01,000 --> 00:22:05,000
+asynchronous processing, and horizontal scaling.
+
+289
+00:22:05,000 --> 00:22:13,000
+Use caching mechanisms, load balancing, and database sharding to distribute workload efficiently.
+
+290
+00:22:14,000 --> 00:22:15,000
+Performance optimization.
+
+291
+00:22:16,000 --> 00:22:21,000
+Optimize code performance to ensure scalability by minimizing resource usage.
+
+292
+00:22:21,000 --> 00:22:27,000
+Optimizing database queries and implementing efficient algorithms and data structures.
+
+293
+00:22:28,000 --> 00:22:34,000
+Monitor application performance and scalability metrics to identify bottlenecks and areas for improvement.
+
+294
+00:22:35,000 --> 00:22:37,000
+Documentation and knowledge sharing.
+
+295
+00:22:37,000 --> 00:22:44,000
+Document security best practices, design decisions and threat models to educate developers and promote
+
+296
+00:22:44,000 --> 00:22:46,000
+security awareness within the team.
+
+297
+00:22:47,000 --> 00:22:53,000
+Encourage knowledge sharing and collaboration on security related topics to foster a security conscious
+
+298
+00:22:53,000 --> 00:22:54,000
+culture.
+
+299
+00:22:54,000 --> 00:23:01,000
+By following these best practices, you can develop code that is not only secure but also scalable,
+
+300
+00:23:01,000 --> 00:23:05,000
+reliable and maintainable throughout its life cycle.
+
+301
+00:23:06,000 --> 00:23:12,000
+Regularly update and improve your security practices to adapt to evolving threats and technology trends.
+
+302
+00:23:13,000 --> 00:23:14,000
+That's all.
+
+303
+00:23:14,000 --> 00:23:16,000
+What I wanted to share with you in this lesson.
+
+304
+00:23:16,000 --> 00:23:19,000
+Let's recap what we have learned today.
+
+305
+00:23:20,000 --> 00:23:22,000
+Today we learned tools for code review.
+
+306
+00:23:22,000 --> 00:23:25,000
+I also shared with you tools for code analysis.
+
+307
+00:23:25,000 --> 00:23:31,000
+Then we learned how to integrate these tools into the development process and take advantage of them.
+
+308
+00:23:31,000 --> 00:23:36,000
+And at the end of the lesson, we learned best practices for secure and scalable code.
+
+309
+00:23:37,000 --> 00:23:38,000
+That's it.
+
+310
+00:23:38,000 --> 00:23:40,000
+Thanks a lot for your attention.
+
+311
+00:23:40,000 --> 00:23:43,000
+Have a great day and see you in the next lesson.
+

108 - Tools, Automation, and Industry Best Practices/002 All-resources-and-links-for-the-lesson.url

@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://docs.google.com/document/d/1q9dNmR60DlQLoNVxxzjNy9VJS6WxOFKsOfW8c2jb5x0/edit?usp=sharing

108 - Tools, Automation, and Industry Best Practices/002 Part 1 - Checkstyle Adhering Coding Standards_en.srt

@@ -0,0 +1,772 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Jim.
+
+2
+00:00:06,000 --> 00:00:10,000
+In this session we will learn more about such tool as Checkstyle.
+
+3
+00:00:10,000 --> 00:00:16,000
+We are going to start the lesson from learning some general information about Checkstyle tool, what
+
+4
+00:00:16,000 --> 00:00:22,000
+it is, its features, use cases, when to use and how it can help us during the development.
+
+5
+00:00:23,000 --> 00:00:30,000
+You will understand the purpose of this tool and then we are going to have a lot of demo and examples.
+
+6
+00:00:30,000 --> 00:00:37,000
+Today I will show you how to install Checkstyle plugin, how you can configure Checkstyle rules.
+
+7
+00:00:37,000 --> 00:00:45,000
+We'll try to fix all violations that our Checkstyle plugin will find, and you will understand how Checkstyle
+
+8
+00:00:45,000 --> 00:00:48,000
+can be integrated into the development workflow.
+
+9
+00:00:49,000 --> 00:00:54,000
+And then we'll integrate Checkstyle Maven plugin into the build process.
+
+10
+00:00:54,000 --> 00:01:02,000
+And we will generate Checkstyle report, and we'll learn how to analyze Checkstyle report and believe
+
+11
+00:01:02,000 --> 00:01:07,000
+this knowledge will help to increase code quality and consistency in your team.
+
+12
+00:01:08,000 --> 00:01:10,000
+So let's start our lesson.
+
+13
+00:01:11,000 --> 00:01:17,000
+I already mentioned such tool as Checkstyle and some previous lessons, so it is time to learn what
+
+14
+00:01:17,000 --> 00:01:18,000
+this tool is all about.
+
+15
+00:01:18,000 --> 00:01:21,000
+Let me start with introduction to Checkstyle.
+
+16
+00:01:22,000 --> 00:01:29,000
+Checkstyle is a static code analysis tool used in software development to ensure that code adheres to
+
+17
+00:01:29,000 --> 00:01:34,000
+a defined set of coding standards, conventions, and best practices.
+
+18
+00:01:34,000 --> 00:01:38,000
+High quality code is essential for several reasons.
+
+19
+00:01:38,000 --> 00:01:43,000
+It enhances readability, maintainability, and scalability of the code base.
+
+20
+00:01:43,000 --> 00:01:50,000
+Moreover, it reduces the likelihood of bugs and errors, leading to more robust and reliable software.
+
+21
+00:01:51,000 --> 00:01:57,000
+Checkstyle plays a crucial role in maintaining code quality throughout the software development life
+
+22
+00:01:57,000 --> 00:01:57,000
+cycle.
+
+23
+00:01:58,000 --> 00:02:05,000
+It acts as a gatekeeper, enforcing coding standards and best practices, thereby helping teams produce
+
+24
+00:02:05,000 --> 00:02:08,000
+cleaner, more consistent code.
+
+25
+00:02:08,000 --> 00:02:16,000
+The standard Checkstyle checks are applicable to general Java coding style and require no external libraries.
+
+26
+00:02:16,000 --> 00:02:20,000
+The standard checks are included in the base distribution.
+
+27
+00:02:20,000 --> 00:02:27,000
+It is helpful and important to ask developers to run checkstyle checks before they merge their code,
+
+28
+00:02:27,000 --> 00:02:35,000
+because fixing sinks on local environment is always faster comparing to creation of code review, fixing
+
+29
+00:02:35,000 --> 00:02:41,000
+updating branch with most recent change again, then again making code review.
+
+30
+00:02:41,000 --> 00:02:47,000
+So basically using checkstyle locally should boost teams productivity and increase code quality.
+
+31
+00:02:47,000 --> 00:02:55,000
+Checkstyle offers a wide range of features and capabilities, including checking code against coding
+
+32
+00:02:55,000 --> 00:03:03,000
+standards, indentation, naming conventions, etc., identifying potential code smells and anti-patterns.
+
+33
+00:03:04,000 --> 00:03:08,000
+Customizable configuration to suit specific project requirements.
+
+34
+00:03:08,000 --> 00:03:12,000
+Integration with popular development tools and build systems.
+
+35
+00:03:12,000 --> 00:03:19,000
+Checkstyle is widely used across various industries and organizations for multiple purposes, including
+
+36
+00:03:19,000 --> 00:03:23,000
+ensuring compliance with coding standards and style guides.
+
+37
+00:03:23,000 --> 00:03:30,000
+Facilitating code reviews by highlighting potential issues early in the development process, and forcing
+
+38
+00:03:30,000 --> 00:03:34,000
+consistent coding practices across development teams and projects.
+
+39
+00:03:34,000 --> 00:03:41,000
+Checkstyle is a tool used in software development to make sure code follows certain style guidelines.
+
+40
+00:03:41,000 --> 00:03:49,000
+Its purpose is to help keep code consistent and readable, making it easier to maintain and understand
+
+41
+00:03:49,000 --> 00:03:50,000
+for developers.
+
+42
+00:03:50,000 --> 00:03:57,000
+By using Checkstyle, teams can enforce coding standards, catch common mistakes, and promote good
+
+43
+00:03:57,000 --> 00:03:58,000
+coding practices.
+
+44
+00:03:59,000 --> 00:04:06,000
+This can lead to improved code quality, reused blocks, and enhanced collaboration among team members.
+
+45
+00:04:06,000 --> 00:04:12,000
+Overall, the benefits of using Checkstyle include better code consistency, increased productivity,
+
+46
+00:04:12,000 --> 00:04:14,000
+and higher quality software.
+
+47
+00:04:15,000 --> 00:04:19,000
+And in this lesson, we are going to have a lot of practical examples and demo.
+
+48
+00:04:19,000 --> 00:04:25,000
+So let me start screen sharing and we will cover all practical aspects of using Checkstyle, starting
+
+49
+00:04:25,000 --> 00:04:32,000
+from its installation to configuration of Checkstyle rules and reading Checkstyle reports.
+
+50
+00:04:32,000 --> 00:04:35,000
+Let's start from installation of Checkstyle.
+
+51
+00:04:36,000 --> 00:04:40,000
+Taking into account Checkstyle is used primarily for Java.
+
+52
+00:04:40,000 --> 00:04:46,000
+It is well integrated with Java oriented integrated development environments like eclipse and IntelliJ
+
+53
+00:04:46,000 --> 00:04:47,000
+Idea.
+
+54
+00:04:48,000 --> 00:04:53,000
+I use eclipse, so today I will show how Checkstyle can be installed in eclipse.
+
+55
+00:04:54,000 --> 00:04:57,000
+There are different ways of how you can install Checkstyle.
+
+56
+00:04:57,000 --> 00:05:04,000
+You can install Eclipse marketplace link where Eclipse Marketplace client and from the update site.
+
+57
+00:05:05,000 --> 00:05:11,000
+I will leave a link to official website and attachments to the video, where you can find detailed description
+
+58
+00:05:11,000 --> 00:05:13,000
+of each of these options.
+
+59
+00:05:13,000 --> 00:05:18,000
+Right now I will show you how we can install Checkstyle using Eclipse Marketplace.
+
+60
+00:05:19,000 --> 00:05:23,000
+So in eclipse click on Help Eclipse Marketplace.
+
+61
+00:05:24,000 --> 00:05:29,000
+In the search bar, type Checkstyle and find it in the list.
+
+62
+00:05:30,000 --> 00:05:37,000
+As you can see, I have it already installed here and it is shown that the plugin is installed.
+
+63
+00:05:37,000 --> 00:05:42,000
+But for you just click the install button and that's it.
+
+64
+00:05:42,000 --> 00:05:45,000
+Just follow hints from the screen.
+
+65
+00:05:45,000 --> 00:05:52,000
+You would need to read and accept license agreements and after installation you will be asked to reload
+
+66
+00:05:52,000 --> 00:05:56,000
+eclipse and you are done with installation.
+
+67
+00:05:57,000 --> 00:06:01,000
+So congratulations, you have just installed Checkstyle plugin.
+
+68
+00:06:01,000 --> 00:06:05,000
+Let me show you how it works and some basic use cases.
+
+69
+00:06:05,000 --> 00:06:10,000
+First of all, let me show you where a configuration for Checkstyle is stored.
+
+70
+00:06:11,000 --> 00:06:16,000
+Click on Window Preferences and then find Check Style.
+
+71
+00:06:19,000 --> 00:06:22,000
+Here you can change the language of rule message.
+
+72
+00:06:22,000 --> 00:06:28,000
+And what is also very important here is the section with the global chat configurations.
+
+73
+00:06:29,000 --> 00:06:31,000
+Here you can select Check Configuration.
+
+74
+00:06:31,000 --> 00:06:35,000
+By default these are only two check configurations exist.
+
+75
+00:06:35,000 --> 00:06:37,000
+Google check and Sun check.
+
+76
+00:06:38,000 --> 00:06:39,000
+Why do we need this?
+
+77
+00:06:39,000 --> 00:06:45,000
+Let's imagine you are a team lead and you want to create a configuration for your team.
+
+78
+00:06:45,000 --> 00:06:50,000
+Or you received configuration from your team lead and you need to import it.
+
+79
+00:06:51,000 --> 00:06:56,000
+This is done to have similar code style on the project, and to make everyone follow the same rules
+
+80
+00:06:56,000 --> 00:06:59,000
+during the code formatting.
+
+81
+00:06:59,000 --> 00:07:04,000
+For example, as you can see, I have some copies of the sun checks.
+
+82
+00:07:04,000 --> 00:07:06,000
+You can select it and click configure.
+
+83
+00:07:07,000 --> 00:07:11,000
+Then you can adjust existing rules, enable or disable them.
+
+84
+00:07:12,000 --> 00:07:14,000
+Here is the annotations module.
+
+85
+00:07:14,000 --> 00:07:22,000
+If I expand it I can see multiple checks rules or any other modules that you would expand.
+
+86
+00:07:22,000 --> 00:07:27,000
+You can find different rules expand regular expressions module.
+
+87
+00:07:27,000 --> 00:07:32,000
+And now let's say that you want to use regular expression multi-line check.
+
+88
+00:07:32,000 --> 00:07:35,000
+You can check the description in the window below.
+
+89
+00:07:35,000 --> 00:07:41,000
+Or you can check the description of each rule in the official documentation that you can find on the
+
+90
+00:07:41,000 --> 00:07:43,000
+Checkstyle website.
+
+91
+00:07:43,000 --> 00:07:50,000
+I select Regular Expression and click add and here I have configuration of Regular Expression module.
+
+92
+00:07:51,000 --> 00:07:56,000
+As you can see, there are some different configurable properties that I can adjust.
+
+93
+00:07:56,000 --> 00:08:02,000
+My recommendation for you would be to spend just some time by reviewing available modules and reading
+
+94
+00:08:02,000 --> 00:08:04,000
+descriptions.
+
+95
+00:08:04,000 --> 00:08:10,000
+This will help you to get better understanding of the tool itself and about available modules.
+
+96
+00:08:10,000 --> 00:08:18,000
+Once you add some check, you enable or disable it as you wish, and in this way you can build your
+
+97
+00:08:18,000 --> 00:08:19,000
+own configuration.
+
+98
+00:08:19,000 --> 00:08:22,000
+Once you configure it some checks.
+
+99
+00:08:22,000 --> 00:08:23,000
+Click a key button here.
+
+100
+00:08:23,000 --> 00:08:27,000
+And now you can export this configuration if you wish.
+
+101
+00:08:27,000 --> 00:08:34,000
+It will be exported as a file that you can share with your team and ask them to import it.
+
+102
+00:08:34,000 --> 00:08:39,000
+If you received this file and you need to import it, click on new.
+
+103
+00:08:39,000 --> 00:08:42,000
+Set the name and click import button.
+
+104
+00:08:42,000 --> 00:08:47,000
+File explorer will be opened and you can find the files that you need to import.
+
+105
+00:08:47,000 --> 00:08:49,000
+Everything is simple.
+
+106
+00:08:50,000 --> 00:08:56,000
+Kim, just remind you that in case you face any difficulties or something is still not clear for you,
+
+107
+00:08:56,000 --> 00:08:59,000
+I am staying available for you in Q&A section.
+
+108
+00:08:59,000 --> 00:09:02,000
+Just post your question below the video.
+
+109
+00:09:02,000 --> 00:09:09,000
+I will check and provide you with detailed response, so don't hesitate to ask your questions please.
+
+110
+00:09:10,000 --> 00:09:17,000
+So that was, in short, how you can work with configurations, how you can adjust configuration, export
+
+111
+00:09:17,000 --> 00:09:18,000
+and import it.
+
+112
+00:09:18,000 --> 00:09:22,000
+For the sake of our today's demo, let me select some checks.
+
+113
+00:09:22,000 --> 00:09:23,000
+Configuration.
+
+114
+00:09:23,000 --> 00:09:29,000
+Even despite it is a default configuration, I still find it very useful.
+
+115
+00:09:29,000 --> 00:09:36,000
+So just click on it, then click set as default button and tick will be set next to the selected check
+
+116
+00:09:36,000 --> 00:09:37,000
+configuration.
+
+117
+00:09:38,000 --> 00:09:41,000
+After that click apply and close.
+
+118
+00:09:41,000 --> 00:09:47,000
+Specially for this lesson, I created a simple Java file to demo you how to work with Checkstyle.
+
+119
+00:09:47,000 --> 00:09:51,000
+You can find the reference to this file in attachments to the lesson.
+
+120
+00:09:52,000 --> 00:09:54,000
+In order to check file was checked style.
+
+121
+00:09:54,000 --> 00:10:01,000
+Make mouse right click and select Check Style and then check code with check style.
+
+122
+00:10:01,000 --> 00:10:07,000
+And now all violations according to selected checks configuration are highlighted.
+
+123
+00:10:07,000 --> 00:10:10,000
+You can do this in the scope of the single file.
+
+124
+00:10:10,000 --> 00:10:14,000
+Or you can run check style on the whole package or project.
+
+125
+00:10:15,000 --> 00:10:21,000
+To do this, find and select same option while selecting package or the whole project.
+
+126
+00:10:22,000 --> 00:10:24,000
+And we see a lot of errors.
+
+127
+00:10:24,000 --> 00:10:26,000
+Let's try to fix them one by one.
+
+128
+00:10:27,000 --> 00:10:29,000
+Let's start from the top.
+
+129
+00:10:29,000 --> 00:10:35,000
+When you hover mouse over notes, you can read what is wrong here.
+
+130
+00:10:35,000 --> 00:10:39,000
+For example, here we can see missing package info Java file.
+
+131
+00:10:40,000 --> 00:10:43,000
+Let me explain you what it is and why we will not fix it.
+
+132
+00:10:44,000 --> 00:10:48,000
+Because not all errors should be fixed if you have fragmentation.
+
+133
+00:10:48,000 --> 00:10:54,000
+Just a reminder, you can configure checks for your needs to avoid redundant errors.
+
+134
+00:10:55,000 --> 00:11:02,000
+The package Info Java file is a special file in Java that can be used to provide package level documentation.
+
+135
+00:11:02,000 --> 00:11:10,000
+This file, if present, typically contains commands that describe the purpose and usage of the package.
+
+136
+00:11:10,000 --> 00:11:16,000
+We will not fix this error because package info file is not necessary for small projects.
+
+137
+00:11:17,000 --> 00:11:23,000
+I believe that this is maintenance overhead because according to our approach clarity through code,
+
+138
+00:11:23,000 --> 00:11:27,000
+you should name your package and entities in such way.
+
+139
+00:11:27,000 --> 00:11:32,000
+They wouldn't need additional text file to explain what it is about.
+
+140
+00:11:32,000 --> 00:11:38,000
+So for the sake of the demo, let's keep this one and continue with the next one.
+
+141
+00:11:38,000 --> 00:11:42,000
+We can see errors next to import statement.
+
+142
+00:11:42,000 --> 00:11:45,000
+Multiple markers are at this line.
+
+143
+00:11:45,000 --> 00:11:52,000
+The import java.util is never used, and using the asterisks form of import should be avoided.
+
+144
+00:11:52,000 --> 00:11:56,000
+So it is always recommended to optimize imports.
+
+145
+00:11:57,000 --> 00:12:00,000
+Optimized imports improve readability.
+
+146
+00:12:00,000 --> 00:12:06,000
+Prevent name clashes, may also reduce compilation time and brings other benefits.
+
+147
+00:12:07,000 --> 00:12:15,000
+And thanks to Checkstyle were also received a flag that this import is not used in eclipse.
+
+148
+00:12:15,000 --> 00:12:18,000
+There is a shortcut to optimize all import statements.
+
+149
+00:12:19,000 --> 00:12:28,000
+Just press Ctrl shift O simultaneously one more time, Ctrl shift all simultaneously.
+
+150
+00:12:29,000 --> 00:12:35,000
+And all import statements will be optimized taking into account we don't use this import statement at
+
+151
+00:12:35,000 --> 00:12:38,000
+all, it is simply removed.
+
+152
+00:12:38,000 --> 00:12:41,000
+Let's continue in this line.
+
+153
+00:12:41,000 --> 00:12:43,000
+We also have multiple rules violated.
+
+154
+00:12:43,000 --> 00:12:48,000
+They are missing a Javadoc command parameter.
+
+155
+00:12:48,000 --> 00:12:54,000
+A should be final parameter, B should be final parameter should be final.
+
+156
+00:12:54,000 --> 00:12:57,000
+By the way, I really like this rule.
+
+157
+00:12:57,000 --> 00:13:02,000
+Final modifier on method parameters will prevent reassignment.
+
+158
+00:13:02,000 --> 00:13:05,000
+Will help compiler to optimize the code.
+
+159
+00:13:05,000 --> 00:13:08,000
+Prevent potential defects and side effects.
+
+160
+00:13:09,000 --> 00:13:16,000
+Immutable nature of method parameters may contribute to the thread safety of your program in case you
+
+161
+00:13:16,000 --> 00:13:17,000
+use multi-threading techniques.
+
+162
+00:13:18,000 --> 00:13:24,000
+If you want to learn more about final modifier in Java, check my course Java from zero to first job
+
+163
+00:13:24,000 --> 00:13:27,000
+where we learn in details final modifier.
+
+164
+00:13:27,000 --> 00:13:34,000
+So I would say that having final method parameters is a good style and I like it personally.
+
+165
+00:13:34,000 --> 00:13:38,000
+So let's add final keyword to method parameters.
+
+166
+00:13:38,000 --> 00:13:45,000
+After modifications, if you want to recheck everything, you need to rerun checkstyle scanning one
+
+167
+00:13:45,000 --> 00:13:46,000
+more time.
+
+168
+00:13:46,000 --> 00:13:49,000
+Let me rerun it again and you see.
+
+169
+00:13:50,000 --> 00:13:53,000
+So only missing a Java doc rule violation is left.
+
+170
+00:13:54,000 --> 00:14:01,000
+And with regards to Java Doc, you need to know one thing in case you didn't customize rules.
+
+171
+00:14:01,000 --> 00:14:09,000
+And in case you use default sound checks, it will also show you rules violation for tab character and
+
+172
+00:14:09,000 --> 00:14:13,000
+by default eclipse uses stops when creating Java Doc.
+
+173
+00:14:13,000 --> 00:14:21,000
+You can easily configure and adjust rule or tell eclipse to not use stop, but instead use spaces.
+
+174
+00:14:21,000 --> 00:14:23,000
+Let me show you how to do this.
+
+175
+00:14:24,000 --> 00:14:26,000
+Click on Window Preferences.
+
+176
+00:14:26,000 --> 00:14:33,000
+Find text editors here and check the Insert Spaces for tabs checkbox.
+
+177
+00:14:33,000 --> 00:14:36,000
+Then click apply and close.
+
+178
+00:14:36,000 --> 00:14:39,000
+Now we are good and we can continue.
+
+179
+00:14:39,000 --> 00:14:43,000
+So let's generate Javadoc here.
+
+180
+00:14:43,000 --> 00:14:45,000
+I will save your time a bit.
+
+181
+00:14:46,000 --> 00:14:53,000
+There is also a rule that Javadoc should contain sentence, as it is started with a capital letter and
+
+182
+00:14:53,000 --> 00:14:54,000
+finished with period.
+
+183
+00:14:55,000 --> 00:15:01,000
+Of course, there are always ways to find the workaround, and Checkstyle won't be able to check the
+
+184
+00:15:01,000 --> 00:15:03,000
+content of this sentence.
+
+185
+00:15:03,000 --> 00:15:09,000
+But still, these rules help to make developers think about code style.
+
+186
+00:15:09,000 --> 00:15:17,000
+I can type something like this, calculate some method period and that would be totally fine for the
+
+187
+00:15:17,000 --> 00:15:18,000
+check style.
+
+188
+00:15:18,000 --> 00:15:23,000
+Let's just make sure we remove tab character from the first line.
+
+189
+00:15:23,000 --> 00:15:28,000
+Otherwise there will be rule violation according to current configuration.
+
+190
+00:15:29,000 --> 00:15:32,000
+Why this rule is important for Checkstyle.
+
+191
+00:15:32,000 --> 00:15:35,000
+It is about portable formatting.
+
+192
+00:15:35,000 --> 00:15:42,000
+Different text editors and environments may interpret tab character differently in terms of spacing
+
+193
+00:15:42,000 --> 00:15:43,000
+and alignment.
+

108 - Tools, Automation, and Industry Best Practices/003 All-resources-and-links-for-the-lesson.url

@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://docs.google.com/document/d/1q9dNmR60DlQLoNVxxzjNy9VJS6WxOFKsOfW8c2jb5x0/edit?usp=sharing

108 - Tools, Automation, and Industry Best Practices/003 Part 2 - Checkstyle Adhering Coding Standards_en.srt

@@ -0,0 +1,780 @@
+1
+00:00:04,000 --> 00:00:06,000
+Let's rerun checks again now.
+
+2
+00:00:07,000 --> 00:00:09,000
+And we have the new error.
+
+3
+00:00:09,000 --> 00:00:16,000
+Now the line has trailing spaces in Checkstyle the line has trailing spaces.
+
+4
+00:00:16,000 --> 00:00:22,000
+Error indicates that there are extra spaces at the end of the lines in your source code files.
+
+5
+00:00:23,000 --> 00:00:29,000
+Trailing spaces are spaces that appear after the last visible character on a line, and before the new
+
+6
+00:00:29,000 --> 00:00:30,000
+line.
+
+7
+00:00:30,000 --> 00:00:38,000
+Character Checkstyle asks us to not keep trailing spaces in order to achieve consistent code style and
+
+8
+00:00:38,000 --> 00:00:47,000
+avoid unexpected version control differences in the file, let's manually remove spaces and rerun Checkstyle
+
+9
+00:00:47,000 --> 00:00:47,000
+again.
+
+10
+00:00:50,000 --> 00:00:51,000
+And we are almost good.
+
+11
+00:00:52,000 --> 00:00:55,000
+But now we have another rule violation.
+
+12
+00:00:55,000 --> 00:00:59,000
+Return tag should be present and have description.
+
+13
+00:00:59,000 --> 00:01:03,000
+We have returned tag but it doesn't have a description.
+
+14
+00:01:03,000 --> 00:01:05,000
+Let's add some description.
+
+15
+00:01:05,000 --> 00:01:09,000
+For example, return sum of two int parameters.
+
+16
+00:01:11,000 --> 00:01:12,000
+Rerun check style again.
+
+17
+00:01:15,000 --> 00:01:16,000
+And voila!
+
+18
+00:01:16,000 --> 00:01:17,000
+We did it.
+
+19
+00:01:18,000 --> 00:01:21,000
+The same things we need to do for our second message.
+
+20
+00:01:22,000 --> 00:01:27,000
+Let me just copy and paste the same Javadoc, just for the sake of example.
+
+21
+00:01:27,000 --> 00:01:33,000
+And to save your time, let's also make parameter variables final.
+
+22
+00:01:34,000 --> 00:01:37,000
+We can do the same for the main market.
+
+23
+00:01:37,000 --> 00:01:46,000
+Make args parameter final, but we need to adjust javadoc this time because in case I would rerun Checkstyle
+
+24
+00:01:46,000 --> 00:01:54,000
+with the same javadoc, Checkstyle will be able to recognize that I don't have A and B parameters here,
+
+25
+00:01:54,000 --> 00:01:58,000
+and I don't have any value returned from the method.
+
+26
+00:01:58,000 --> 00:02:02,000
+So this type of sinks Checkstyle can recognize.
+
+27
+00:02:03,000 --> 00:02:11,000
+So let's remove rows about return statement and be argument and make sure that we have param args in
+
+28
+00:02:11,000 --> 00:02:12,000
+Javadoc.
+
+29
+00:02:13,000 --> 00:02:16,000
+Let's rerun Checkstyle one more time.
+
+30
+00:02:17,000 --> 00:02:18,000
+Great.
+
+31
+00:02:18,000 --> 00:02:18,000
+Well.
+
+32
+00:02:18,000 --> 00:02:19,000
+Almost done.
+
+33
+00:02:19,000 --> 00:02:22,000
+Only few comments left here.
+
+34
+00:02:23,000 --> 00:02:26,000
+There is again mentioned about top character.
+
+35
+00:02:27,000 --> 00:02:35,000
+As I explained, many integrated development environments and code analysis tools default to using spaces
+
+36
+00:02:35,000 --> 00:02:37,000
+over tabs for consistency.
+
+37
+00:02:38,000 --> 00:02:43,000
+Adhering to this convention helps ensure compatibility with common development tools.
+
+38
+00:02:44,000 --> 00:02:48,000
+Let's rerun Checkstyle to make sure that everything is fixed.
+
+39
+00:02:48,000 --> 00:02:57,000
+And now we have only ten and five highlighted because this is anti-pattern that is called magic numbers.
+
+40
+00:02:57,000 --> 00:03:05,000
+The term magic numbers refers to hard coded numerical values that appear directly in code, without
+
+41
+00:03:05,000 --> 00:03:06,000
+explanation or context.
+
+42
+00:03:07,000 --> 00:03:14,000
+These numbers are often considered magic because their meaning or significance is not immediately apparent
+
+43
+00:03:14,000 --> 00:03:16,000
+for someone reading the code.
+
+44
+00:03:17,000 --> 00:03:19,000
+How to solve magic number Antipattern.
+
+45
+00:03:20,000 --> 00:03:27,000
+To address the issues associated with magic numbers, developers are encouraged to use constants to
+
+46
+00:03:27,000 --> 00:03:29,000
+represent these values.
+
+47
+00:03:30,000 --> 00:03:38,000
+By giving meaningful names to constants, the code becomes self-documenting and easier to understand.
+
+48
+00:03:39,000 --> 00:03:47,000
+This practice improves code quality, reduces errors, and enhances collaboration among developers working
+
+49
+00:03:47,000 --> 00:03:48,000
+on the same code base.
+
+50
+00:03:49,000 --> 00:03:56,000
+Therefore, avoiding magic numbers contributes to writing cleaner, more maintainable, and more comprehensible
+
+51
+00:03:56,000 --> 00:03:57,000
+code.
+
+52
+00:03:58,000 --> 00:04:01,000
+That's why let's create two constants now.
+
+53
+00:04:01,000 --> 00:04:09,000
+You can select the value mouse, right click refactor and then click Extract Constant.
+
+54
+00:04:09,000 --> 00:04:16,000
+For access modifier, select public and with regards to the name and the most important to give meaningful
+
+55
+00:04:16,000 --> 00:04:18,000
+names for constants.
+
+56
+00:04:19,000 --> 00:04:23,000
+In our particular case we have demo of sum and difference masses.
+
+57
+00:04:24,000 --> 00:04:27,000
+And we just need two parameters for demo.
+
+58
+00:04:28,000 --> 00:04:32,000
+So let's call the first constant as a demo variable.
+
+59
+00:04:32,000 --> 00:04:35,000
+And let's call the second constant B demo variable.
+
+60
+00:04:44,000 --> 00:04:46,000
+That's it.
+
+61
+00:04:46,000 --> 00:04:51,000
+Now we just need to substitute method arguments in our demo method calls.
+
+62
+00:05:05,000 --> 00:05:07,000
+Let's rerun Checkstyle again.
+
+63
+00:05:09,000 --> 00:05:14,000
+Now we see another rules violation for two long line.
+
+64
+00:05:15,000 --> 00:05:22,000
+This is also important rule to align formatting, but nowadays all developers usually have big monitors,
+
+65
+00:05:22,000 --> 00:05:26,000
+so 120 characters per line should be fine too.
+
+66
+00:05:27,000 --> 00:05:31,000
+Sometimes developers prefer to keep their monitor vertical.
+
+67
+00:05:31,000 --> 00:05:36,000
+In this case, it is better to have lines up to 80 characters.
+
+68
+00:05:36,000 --> 00:05:42,000
+So in this case, following the rules that exist by default in Checkstyle makes sense.
+
+69
+00:05:43,000 --> 00:05:47,000
+And I showed you you can configure these rules.
+
+70
+00:05:47,000 --> 00:05:54,000
+In case you don't see other characters because of weird colored combination, you can clear a checkstyle
+
+71
+00:05:54,000 --> 00:05:56,000
+violations in the same menu.
+
+72
+00:05:57,000 --> 00:06:04,000
+So just do mouse right click Checkstyle and select clear Checkstyle violations.
+
+73
+00:06:05,000 --> 00:06:07,000
+Now I have better visibility.
+
+74
+00:06:07,000 --> 00:06:09,000
+Where to put new line characters.
+
+75
+00:06:10,000 --> 00:06:17,000
+Also, there is another rule for Java when it is recommended to keep a plus sign during string concatenation
+
+76
+00:06:17,000 --> 00:06:18,000
+on the new line.
+
+77
+00:06:19,000 --> 00:06:24,000
+And also in case of calculate difference method, I still see a long line.
+
+78
+00:06:24,000 --> 00:06:28,000
+So let's also put the new line be demo variable.
+
+79
+00:06:29,000 --> 00:06:34,000
+Let's also check that each line doesn't have trailing spaces.
+
+80
+00:06:34,000 --> 00:06:36,000
+So we formatted it.
+
+81
+00:06:37,000 --> 00:06:41,000
+And now let's run checkstyle checks again.
+
+82
+00:06:44,000 --> 00:06:48,000
+Some variations are around our generated constants.
+
+83
+00:06:49,000 --> 00:06:56,000
+We need to make sure that we don't use trailing spaces tab character, and that we have Javadoc for
+
+84
+00:06:56,000 --> 00:06:57,000
+these constants.
+
+85
+00:06:58,000 --> 00:07:01,000
+For the sake of the demo, let's keep it simple.
+
+86
+00:07:01,000 --> 00:07:07,000
+In Javadoc, I will just specify that this is demo variable A, and this is demo variable B.
+
+87
+00:07:12,000 --> 00:07:14,000
+We're on Checkstyle again.
+
+88
+00:07:17,000 --> 00:07:23,000
+Let me make just a few more iterations of Checkstyle checks, because I need to follow up on some errors
+
+89
+00:07:23,000 --> 00:07:30,000
+that we have already talked about, the ones related to formatting, basically related to tab character
+
+90
+00:07:30,000 --> 00:07:32,000
+and trailing spaces.
+
+91
+00:07:32,000 --> 00:07:38,000
+Just need to check one more time, everything carefully to make sure that I didn't miss anything.
+
+92
+00:07:38,000 --> 00:07:44,000
+You already familiar with this type of errors so there is nothing new for you.
+
+93
+00:07:44,000 --> 00:07:52,000
+Once I fixed everything, I run check style again and I hope that this is the last time I run it for
+
+94
+00:07:52,000 --> 00:07:53,000
+today for this file.
+
+95
+00:07:55,000 --> 00:07:58,000
+And there are no more rules violation.
+
+96
+00:07:58,000 --> 00:07:59,000
+We did a great job.
+
+97
+00:08:00,000 --> 00:08:04,000
+Now we are ready to commit our changes and make a pull request.
+
+98
+00:08:04,000 --> 00:08:11,000
+Now you can understand how Checkstyle can ensure consistency in code style across all your development
+
+99
+00:08:11,000 --> 00:08:11,000
+team.
+
+100
+00:08:12,000 --> 00:08:20,000
+Now let me show you one more amazing thing how you can integrate Checkstyle plugin into the build process
+
+101
+00:08:20,000 --> 00:08:22,000
+and generate cool reports.
+
+102
+00:08:22,000 --> 00:08:26,000
+In this case we have simple Maven Multi-module project.
+
+103
+00:08:27,000 --> 00:08:29,000
+This is not a lesson about Maven.
+
+104
+00:08:29,000 --> 00:08:34,000
+So we would keep maven project configuration outside of this lesson.
+
+105
+00:08:34,000 --> 00:08:40,000
+If we want to learn more about Maven, feel free to check my course Java from zero to First job.
+
+106
+00:08:41,000 --> 00:08:48,000
+We have learned in details about Maven build system, but in short, Maven is a build tool that helps
+
+107
+00:08:48,000 --> 00:08:54,000
+to compile your sources and pack your Java program and prepare it for deployment.
+
+108
+00:08:54,000 --> 00:08:59,000
+You can extend Maven functionality by adding so called plugins.
+
+109
+00:08:59,000 --> 00:09:02,000
+One of such plugins is called Checkstyle.
+
+110
+00:09:03,000 --> 00:09:08,000
+Don't worry, I will share with you the link to the source code of this example two and you will be
+
+111
+00:09:08,000 --> 00:09:12,000
+able to repeat this example on your local computer.
+
+112
+00:09:12,000 --> 00:09:19,000
+And in case something will remain unclear, don't hesitate to post your questions below the video and
+
+113
+00:09:19,000 --> 00:09:20,000
+I will be happy to answer.
+
+114
+00:09:21,000 --> 00:09:27,000
+Com XML is a main configuration file where all configuration for Maven is stored.
+
+115
+00:09:27,000 --> 00:09:34,000
+So in order to configure Checkstyle reporting and the plugin, you need to open this file and add some
+
+116
+00:09:34,000 --> 00:09:36,000
+lines of configuration.
+
+117
+00:09:36,000 --> 00:09:39,000
+I will show you now what you need to add.
+
+118
+00:09:39,000 --> 00:09:45,000
+First of all, you need couple of built plugins that are required to generate reports.
+
+119
+00:09:46,000 --> 00:09:51,000
+They are called Maven site plugin and Maven project info reports plugin.
+
+120
+00:09:52,000 --> 00:09:58,000
+The Maven site plugin is responsible for generating a website or documentation for your Maven project.
+
+121
+00:09:59,000 --> 00:10:06,000
+It is highly customizable and integrates with various content generation tools to produce HTML based
+
+122
+00:10:06,000 --> 00:10:08,000
+project documentation.
+
+123
+00:10:09,000 --> 00:10:15,000
+The Maven Project Info Reports plugin is used to generate various informational reports about your Maven
+
+124
+00:10:15,000 --> 00:10:16,000
+project.
+
+125
+00:10:17,000 --> 00:10:23,000
+These reports provide details about project metadata, dependencies, source control information and
+
+126
+00:10:23,000 --> 00:10:24,000
+more.
+
+127
+00:10:24,000 --> 00:10:29,000
+So to generate Checkstyle report we need these two build plugins.
+
+128
+00:10:29,000 --> 00:10:37,000
+And now we need to add Maven Checkstyle plugin to reporting part of the pom XML file.
+
+129
+00:10:37,000 --> 00:10:41,000
+The different versions of this Maven Checkstyle plugin.
+
+130
+00:10:41,000 --> 00:10:47,000
+By the moment you watch this lesson, there can be new version of plugin already, so just feel free
+
+131
+00:10:47,000 --> 00:10:49,000
+to check on the official website.
+
+132
+00:10:49,000 --> 00:10:50,000
+The latest version.
+
+133
+00:10:52,000 --> 00:10:59,000
+Another important thing is that by default, Maven Checkstyle plugin uses soundchecks configuration,
+
+134
+00:10:59,000 --> 00:11:07,000
+and if you want to use your own configuration, you can use configuration location property inside configuration
+
+135
+00:11:07,000 --> 00:11:13,000
+XML tag and specify pass to XML file with Checkstyle configuration.
+
+136
+00:11:14,000 --> 00:11:16,000
+I'll leave these lines commented.
+
+137
+00:11:16,000 --> 00:11:21,000
+So just in case you wouldn't forget about this configuration when you will check source code.
+
+138
+00:11:23,000 --> 00:11:30,000
+Also you can configure plugin in such way to fail build process in case the errors reported by Checkstyle
+
+139
+00:11:30,000 --> 00:11:31,000
+plugin.
+
+140
+00:11:31,000 --> 00:11:39,000
+But to be honest, I always stand for clean code design, but probably Checkstyle is not that plugin
+
+141
+00:11:39,000 --> 00:11:44,000
+or violations that can be considered as a reasonable thing to fail build.
+
+142
+00:11:44,000 --> 00:11:52,000
+But again, it will depend on your project specifics, team maturity, and many other different factors.
+
+143
+00:11:53,000 --> 00:12:00,000
+Being a team lead, I just keep an eye on this report and create related tag that items to address them
+
+144
+00:12:00,000 --> 00:12:02,000
+if they are not critical.
+
+145
+00:12:03,000 --> 00:12:09,000
+Like this I tried to achieve smart balance between pace of development and quality of the code.
+
+146
+00:12:10,000 --> 00:12:15,000
+So we are good to run a checkstyle checks and to generate report.
+
+147
+00:12:15,000 --> 00:12:18,000
+Let me open terminal window here.
+
+148
+00:12:18,000 --> 00:12:23,000
+I will execute Maven command with two Maven goals clean and side.
+
+149
+00:12:24,000 --> 00:12:31,000
+The clean goal is a standard maven life cycle goal that is used to clean the project by removing the
+
+150
+00:12:31,000 --> 00:12:32,000
+build directory.
+
+151
+00:12:32,000 --> 00:12:37,000
+Target directory and any generated artifacts.
+
+152
+00:12:37,000 --> 00:12:44,000
+When you execute the clean goal, Maven deletes the contents of the target directory, including compiled
+
+153
+00:12:44,000 --> 00:12:49,000
+classes, generated resources, and other build artifacts.
+
+154
+00:12:49,000 --> 00:12:54,000
+I call it just to make sure that new report will be generated with such configuration.
+
+155
+00:12:55,000 --> 00:13:02,000
+The side goal is a part of the Maven site plugin, and is used to generate project documentation in
+
+156
+00:13:02,000 --> 00:13:04,000
+the form of a website.
+
+157
+00:13:04,000 --> 00:13:13,000
+This goal generates HTML based documentation and reports based on configuring plugins and content sources.
+
+158
+00:13:13,000 --> 00:13:20,000
+This goal will detect Checkstyle plugin and will add the report Checkstyle checks report.
+
+159
+00:13:20,000 --> 00:13:24,000
+Let's give it some time to complete the report generation.
+
+160
+00:13:25,000 --> 00:13:26,000
+Rate.
+
+161
+00:13:26,000 --> 00:13:27,000
+It is done now.
+
+162
+00:13:27,000 --> 00:13:35,000
+And now you can find target folder inside your root folder of the project and inside target folder you
+
+163
+00:13:35,000 --> 00:13:42,000
+can see site directory and inside it there are a lot of different HTML files.
+
+164
+00:13:42,000 --> 00:13:49,000
+I recommend you to spend some time exploring them and opening different ones, but in scope of this
+
+165
+00:13:49,000 --> 00:13:54,000
+demo, let me open file that is named Checkstyle aggregate HTML.
+
+166
+00:13:55,000 --> 00:14:01,000
+This is a built in web browser in eclipse, so just make mouse right click on the file.
+
+167
+00:14:01,000 --> 00:14:03,000
+Open this web browser.
+
+168
+00:14:04,000 --> 00:14:07,000
+And here you can see brief summary of check.
+
+169
+00:14:08,000 --> 00:14:12,000
+This is a demo project with only three default files.
+
+170
+00:14:12,000 --> 00:14:18,000
+You can see there are different level of alerts, info, messages, warnings and errors.
+
+171
+00:14:18,000 --> 00:14:21,000
+And analysis is done per file.
+
+172
+00:14:21,000 --> 00:14:25,000
+Here you can see how much checkstyle errors you have per file.
+
+173
+00:14:26,000 --> 00:14:31,000
+In rules section you have summary of how much different rules were violated.
+
+174
+00:14:32,000 --> 00:14:38,000
+And in the details section you can see detailed breakdown of rules violated with message and with reference
+
+175
+00:14:38,000 --> 00:14:41,000
+to the specific line in the file.
+
+176
+00:14:41,000 --> 00:14:44,000
+And such analysis is done per each file.
+
+177
+00:14:45,000 --> 00:14:48,000
+So take your time to explore this report.
+
+178
+00:14:48,000 --> 00:14:51,000
+Try to create a report for your project.
+
+179
+00:14:51,000 --> 00:14:57,000
+And of course, in case you would have any questions, let me know in the comments below the video and
+
+180
+00:14:57,000 --> 00:14:59,000
+I will be happy to answer.
+
+181
+00:15:00,000 --> 00:15:02,000
+And also in attachments to the lesson.
+
+182
+00:15:02,000 --> 00:15:08,000
+I am going to leave a link to description of all checks that checkstyle provide.
+
+183
+00:15:09,000 --> 00:15:15,000
+This is a link to the official website where you can discover official documentation.
+
+184
+00:15:15,000 --> 00:15:19,000
+So take your time to get familiar with this site to.
+
+185
+00:15:19,000 --> 00:15:22,000
+That's all what I wanted to share with you in this lesson.
+
+186
+00:15:22,000 --> 00:15:25,000
+Let's recap what we have learned today.
+
+187
+00:15:26,000 --> 00:15:33,000
+So the day we learned what a Czech style tool is, we learned features, purpose and use cases.
+
+188
+00:15:33,000 --> 00:15:35,000
+When to use Czech style.
+
+189
+00:15:36,000 --> 00:15:40,000
+Now you know how to install Czech style plugin in your IDE.
+
+190
+00:15:41,000 --> 00:15:43,000
+How to configure Czech style rules.
+
+191
+00:15:43,000 --> 00:15:46,000
+How to use this plugin during the local development.
+
+192
+00:15:46,000 --> 00:15:53,000
+How to generate Czech style report via maven plugin and how to analyze Czech style report.
+
+193
+00:15:54,000 --> 00:15:56,000
+That's all for this lesson.
+
+194
+00:15:56,000 --> 00:15:59,000
+Thanks a lot for your attention.
+
+195
+00:15:59,000 --> 00:16:02,000
+Have a great day and see you in the next lesson.
+

108 - Tools, Automation, and Industry Best Practices/004 All-resources-and-links-for-the-lesson.url

@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://docs.google.com/document/d/1v6hhz-Lfk0R4XhyJqXT0GjUfhWiJGf1ZDsUZwdVP3nY/edit?usp=sharing

108 - Tools, Automation, and Industry Best Practices/004 PMD Static Code Analysis_en.srt

@@ -0,0 +1,1144 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Tim.
+
+2
+00:00:06,000 --> 00:00:11,000
+In this lesson we are going to learn how to use such tool for static code analysis as PMD.
+
+3
+00:00:12,000 --> 00:00:17,000
+We will start the lesson from learning general definitions to understand what PMD is.
+
+4
+00:00:17,000 --> 00:00:22,000
+I will explain the key features of PMD and what benefits you will get by using it.
+
+5
+00:00:23,000 --> 00:00:29,000
+Also, we will talk about role of PMD tool in the development process and after learning some theory,
+
+6
+00:00:29,000 --> 00:00:32,000
+we are going to have some practical exercise.
+
+7
+00:00:32,000 --> 00:00:39,000
+We will learn how to install PMD into integrated development environment, how to execute code check
+
+8
+00:00:39,000 --> 00:00:42,000
+how to analyze PMD report.
+
+9
+00:00:42,000 --> 00:00:45,000
+I will show you how to configure rules and rule sets for PMD.
+
+10
+00:00:46,000 --> 00:00:52,000
+Then I will show you on the real example how you can integrate PMD into the project, build process
+
+11
+00:00:52,000 --> 00:00:55,000
+and generate PMD reports during Project Build.
+
+12
+00:00:55,000 --> 00:00:57,000
+Let's start our lesson.
+
+13
+00:00:57,000 --> 00:01:04,000
+Let's start from learning the general information about PMD and understanding of what it is.
+
+14
+00:01:04,000 --> 00:01:10,000
+PMD tool is a software tool used in software development to perform static code analysis.
+
+15
+00:01:10,000 --> 00:01:15,000
+Its main purpose is to identify potential issues in Java and other programming languages.
+
+16
+00:01:15,000 --> 00:01:23,000
+Source code PMD checks the code against a set of predefined rules that detect common programming flaws,
+
+17
+00:01:23,000 --> 00:01:26,000
+bad practices, or inefficiencies.
+
+18
+00:01:26,000 --> 00:01:33,000
+The tool helps developers by pointing out errors of code that could be problematic, such as code style
+
+19
+00:01:33,000 --> 00:01:34,000
+issues.
+
+20
+00:01:34,000 --> 00:01:40,000
+PMD can detect deviations from coding conventions like naming conventions or formatting rules.
+
+21
+00:01:41,000 --> 00:01:42,000
+Potential bugs.
+
+22
+00:01:42,000 --> 00:01:49,000
+It identifies code patterns that are likely to be errors, such as null pointer references, unused
+
+23
+00:01:49,000 --> 00:01:52,000
+variables, or empty catch blocks.
+
+24
+00:01:52,000 --> 00:01:59,000
+Performance problems PMD can highlight inefficient code constructs that may impact performance like
+
+25
+00:01:59,000 --> 00:02:03,000
+an efficient string concatenation or unnecessary object creation.
+
+26
+00:02:03,000 --> 00:02:10,000
+Developers can configure PMD to use a specific set of rules tailored to their project's needs.
+
+27
+00:02:10,000 --> 00:02:16,000
+The tool can be integrated into the development process, typically running as part of a continuous
+
+28
+00:02:16,000 --> 00:02:21,000
+integration pipeline or directly within an integrated development environment.
+
+29
+00:02:22,000 --> 00:02:29,000
+By using PMD regularly, developers can catch issues early in the development life cycle, leading to
+
+30
+00:02:29,000 --> 00:02:31,000
+cleaner, more reliable code.
+
+31
+00:02:31,000 --> 00:02:34,000
+PMD is not limited to Java.
+
+32
+00:02:34,000 --> 00:02:42,000
+It supports several other languages, including JavaScript, Salesforce, apex, XML, and more, and
+
+33
+00:02:42,000 --> 00:02:45,000
+supports more than 400 built in roles.
+
+34
+00:02:45,000 --> 00:02:51,000
+Overall, it is a valuable tool for code quality assurance and can contribute significantly to producing
+
+35
+00:02:51,000 --> 00:02:53,000
+better software.
+
+36
+00:02:53,000 --> 00:03:00,000
+Now let's review features of PMD in more details to understand what it actually can do and how it can
+
+37
+00:03:00,000 --> 00:03:01,000
+help us.
+
+38
+00:03:02,000 --> 00:03:08,000
+PMD offers several powerful features that contribute to improving code quality and identifying potential
+
+39
+00:03:08,000 --> 00:03:10,000
+issues in software projects.
+
+40
+00:03:10,000 --> 00:03:17,000
+Code style violations detection PMD checks, source code against predefined coding conventions and style
+
+41
+00:03:17,000 --> 00:03:17,000
+guidelines.
+
+42
+00:03:17,000 --> 00:03:23,000
+Like I already mentioned, it detects and reports violations related to naming conventions for Martin
+
+43
+00:03:23,000 --> 00:03:27,000
+indentation and other stylistic preferences.
+
+44
+00:03:27,000 --> 00:03:33,000
+I already mentioned potential bug identification and performance inefficiency analysis.
+
+45
+00:03:34,000 --> 00:03:38,000
+On top of that, I would like to mention a few more features.
+
+46
+00:03:38,000 --> 00:03:46,000
+Customizable rule sets PMD allows users to define and customize rule configurations based on project
+
+47
+00:03:46,000 --> 00:03:47,000
+specific requirements.
+
+48
+00:03:48,000 --> 00:03:55,000
+Developers can enable disable rules, adjust severity levels, and create custom rule sets tailored
+
+49
+00:03:55,000 --> 00:03:57,000
+to their coding standards.
+
+50
+00:03:58,000 --> 00:04:01,000
+Integration with Ides and CI CD pipelines.
+
+51
+00:04:02,000 --> 00:04:08,000
+PMG integrates seamlessly with popular integrated development environments like IntelliJ Idea, Eclipse,
+
+52
+00:04:08,000 --> 00:04:10,000
+and Visual Studio Code.
+
+53
+00:04:10,000 --> 00:04:16,000
+It can be incorporated into continuous integration continuous deployment pipelines to automate code
+
+54
+00:04:16,000 --> 00:04:19,000
+analysis and enforce quality gates.
+
+55
+00:04:20,000 --> 00:04:25,000
+So what are the benefits of Pmwg and why you need to consider using it in the development?
+
+56
+00:04:26,000 --> 00:04:33,000
+First of all, early detection PMD catches issues early in the development process, reducing the likelihood
+
+57
+00:04:33,000 --> 00:04:36,000
+of bugs reaching production.
+
+58
+00:04:36,000 --> 00:04:37,000
+Consistency.
+
+59
+00:04:37,000 --> 00:04:44,000
+It helps maintain consistency in code style and adherence to coding standards across a project or team.
+
+60
+00:04:45,000 --> 00:04:48,000
+Efficiency by automating code analysis.
+
+61
+00:04:48,000 --> 00:04:53,000
+PMD saves developers time and effort in manual code reviews.
+
+62
+00:04:53,000 --> 00:04:55,000
+Continuous improvement.
+
+63
+00:04:55,000 --> 00:05:01,000
+PMD facilitates continuous improvement by promoting best practices and code refactoring.
+
+64
+00:05:01,000 --> 00:05:07,000
+And if we want to sum up the role of PMD tools in the software development process, then we need to
+
+65
+00:05:07,000 --> 00:05:09,000
+mention the following objectives of PMD.
+
+66
+00:05:09,000 --> 00:05:17,000
+To identify and code issues PMD scans source code to detect common programming mistakes, antipatterns
+
+67
+00:05:17,000 --> 00:05:20,000
+and inefficient code constructs.
+
+68
+00:05:20,000 --> 00:05:22,000
+Enforcing coding standards.
+
+69
+00:05:22,000 --> 00:05:29,000
+It ensures that developers adhere to predefined coding standards and best practices within a project.
+
+70
+00:05:30,000 --> 00:05:33,000
+Improving code quality by catching issues earlier.
+
+71
+00:05:34,000 --> 00:05:39,000
+PMD assists in producing cleaner, more reliable and maintainable code.
+
+72
+00:05:39,000 --> 00:05:40,000
+Supporting.
+
+73
+00:05:40,000 --> 00:05:41,000
+Refactoring.
+
+74
+00:05:42,000 --> 00:05:48,000
+PMD highlights areas of code that can be refactored for better readability, performance, and robustness.
+
+75
+00:05:49,000 --> 00:05:53,000
+And now it is time to learn how to work with PMD on real examples.
+
+76
+00:05:53,000 --> 00:05:56,000
+Let me show you on live demo how to install PMD.
+
+77
+00:05:56,000 --> 00:05:58,000
+How to use it in the project.
+
+78
+00:05:58,000 --> 00:06:00,000
+How to customize PMD rules.
+
+79
+00:06:00,000 --> 00:06:04,000
+And remember, if you have any question, don't wait.
+
+80
+00:06:04,000 --> 00:06:10,000
+Just pause the video and post your question below the video and I will be happy to answer.
+
+81
+00:06:10,000 --> 00:06:12,000
+Let me start screen sharing.
+
+82
+00:06:13,000 --> 00:06:19,000
+In this lesson, I will show you how to work with PMD on the example of Java Project and Eclipse IDE.
+
+83
+00:06:21,000 --> 00:06:28,000
+Like I already mentioned before, PMG is not related only to Java or only to eclipse IDE, but we need
+
+84
+00:06:28,000 --> 00:06:30,000
+to start from something, right?
+
+85
+00:06:30,000 --> 00:06:35,000
+Anyway, the principles of interaction with PMG will be the similar no matter with what programming
+
+86
+00:06:35,000 --> 00:06:37,000
+language you work with.
+
+87
+00:06:38,000 --> 00:06:44,000
+So to install PMG into eclipse you need to open Eclipse Marketplace and find PMG there.
+
+88
+00:06:45,000 --> 00:06:49,000
+Just click on help, select Eclipse Marketplace.
+
+89
+00:06:51,000 --> 00:06:53,000
+Type BMG in the search bar.
+
+90
+00:06:55,000 --> 00:07:01,000
+Find Pink Eclipse plugin with search logger and click install button.
+
+91
+00:07:02,000 --> 00:07:09,000
+I have it already installed, so I won't be able to show you what is going to happen next, but I am
+
+92
+00:07:09,000 --> 00:07:12,000
+sure you will handle next steps.
+
+93
+00:07:12,000 --> 00:07:13,000
+They're easy.
+
+94
+00:07:14,000 --> 00:07:19,000
+Just follow advices that you will see on the screen and complete installation.
+
+95
+00:07:20,000 --> 00:07:26,000
+Accept license agreement and agree to reload IDE to complete PMD configuration in eclipse.
+
+96
+00:07:26,000 --> 00:07:30,000
+Everything is pretty simple and straightforward with the installation.
+
+97
+00:07:30,000 --> 00:07:35,000
+And in case you would have any questions or challenges during the installation, please let me know
+
+98
+00:07:35,000 --> 00:07:37,000
+and I will be happy to answer you.
+
+99
+00:07:38,000 --> 00:07:44,000
+Specially for this lesson, I prepared an example that can demonstrate violation of different rules.
+
+100
+00:07:45,000 --> 00:07:51,000
+You will find the link to the source code in attachments to the lesson, and you will be able to check
+
+101
+00:07:51,000 --> 00:07:54,000
+the same example at your local computer.
+
+102
+00:07:54,000 --> 00:07:59,000
+So let's check this code with PMD and understand what is wrong here.
+
+103
+00:08:00,000 --> 00:08:08,000
+Once you installed PMD plugin, you can make mouse right click and find PMD menu here, select it and
+
+104
+00:08:08,000 --> 00:08:11,000
+then click Check Code.
+
+105
+00:08:12,000 --> 00:08:17,000
+Once scanning is performed, new perspective is opened in eclipse.
+
+106
+00:08:17,000 --> 00:08:23,000
+Here in the top right corner, you can see that PMD perspective is opened.
+
+107
+00:08:24,000 --> 00:08:31,000
+On this perspective, you can find different views that can help you to work with rules violation.
+
+108
+00:08:32,000 --> 00:08:33,000
+Violations.
+
+109
+00:08:33,000 --> 00:08:39,000
+Outline contains the list of all rules violations that are discovered in the file.
+
+110
+00:08:40,000 --> 00:08:42,000
+The columns are self-descriptive.
+
+111
+00:08:42,000 --> 00:08:47,000
+The first column is called priority to indicate priority of rule violation.
+
+112
+00:08:47,000 --> 00:08:53,000
+By the way, if you would click on three dots here, you can filter violations by priorities.
+
+113
+00:08:54,000 --> 00:09:02,000
+As you can see, there are five priorities where blocker is the most dangerous one then goes critical,
+
+114
+00:09:02,000 --> 00:09:04,000
+urgent, important and warning.
+
+115
+00:09:05,000 --> 00:09:09,000
+So feel free to filter only those violations that you are most interested in.
+
+116
+00:09:10,000 --> 00:09:17,000
+In the rule column, it is set which rule was violated and the error message gives you more context
+
+117
+00:09:17,000 --> 00:09:19,000
+about the rule violation.
+
+118
+00:09:20,000 --> 00:09:24,000
+The second view that you can find here is called violations.
+
+119
+00:09:24,000 --> 00:09:25,000
+Overview.
+
+120
+00:09:25,000 --> 00:09:32,000
+This view is important when you scan the whole package or the whole project, because you basically
+
+121
+00:09:32,000 --> 00:09:38,000
+can run PMG scanning on a group of files in the same way like we did with one single file.
+
+122
+00:09:39,000 --> 00:09:46,000
+As you can see when I click on the package, I also see PMU option available and can check all code
+
+123
+00:09:46,000 --> 00:09:47,000
+in child packages.
+
+124
+00:09:48,000 --> 00:09:53,000
+So when you scan multiple files, it is easier for you to use this violations.
+
+125
+00:09:53,000 --> 00:09:58,000
+Overview view to navigate between different files in different packages.
+
+126
+00:09:58,000 --> 00:10:02,000
+Also, you can use this bar to filter violations.
+
+127
+00:10:03,000 --> 00:10:11,000
+If you want to clear all rules violation, just make mouse right click select PMG and click on Clear
+
+128
+00:10:11,000 --> 00:10:12,000
+Violations.
+
+129
+00:10:13,000 --> 00:10:20,000
+After this, notifications about all violations in views that we have just reviewed and on the side
+
+130
+00:10:20,000 --> 00:10:23,000
+of code editor will disappear.
+
+131
+00:10:24,000 --> 00:10:30,000
+I want you to run this check on your local computer and get more familiar with the type of violations.
+
+132
+00:10:30,000 --> 00:10:37,000
+Believe me, if your team would follow the standard rules configured, you will see how your code base
+
+133
+00:10:37,000 --> 00:10:43,000
+has changed, how it become more clean, more consistent, and more robust.
+
+134
+00:10:43,000 --> 00:10:50,000
+Among typical violations that you can see here is declaring local variables final when it is possible.
+
+135
+00:10:51,000 --> 00:11:00,000
+So Pmwg analyzes the whole file, and in this case it sees the h variable can be final and name variable
+
+136
+00:11:00,000 --> 00:11:02,000
+can't be final.
+
+137
+00:11:02,000 --> 00:11:07,000
+That's why Pmwg race alert telling me that h variable can be final.
+
+138
+00:11:08,000 --> 00:11:15,000
+Also, you can work with rules violations by paying attention to small flags that you can find on the
+
+139
+00:11:15,000 --> 00:11:17,000
+side of code editor.
+
+140
+00:11:18,000 --> 00:11:24,000
+For example, you can see that using of System.out.println is discouraged because it is better to use
+
+141
+00:11:24,000 --> 00:11:30,000
+logger to log some messages instead of just posting those to console.
+
+142
+00:11:30,000 --> 00:11:37,000
+Another interesting and in my opinion important note is not to use literals in if condition.
+
+143
+00:11:38,000 --> 00:11:41,000
+In general, using of magic numbers is discouraged.
+
+144
+00:11:41,000 --> 00:11:48,000
+If you watched my lesson about Checkstyle, then you should remember what magic numbers are and why
+
+145
+00:11:48,000 --> 00:11:51,000
+it is not good tone to use magic numbers in code.
+
+146
+00:11:52,000 --> 00:11:56,000
+Also there is such rule violation as short variable name.
+
+147
+00:11:57,000 --> 00:12:03,000
+Basically, naming value like x or y doesn't bring a lot of sense.
+
+148
+00:12:04,000 --> 00:12:07,000
+You should name variables with meaningful names.
+
+149
+00:12:07,000 --> 00:12:12,000
+In case the variable is never used, another rule will be violated.
+
+150
+00:12:12,000 --> 00:12:13,000
+Unused local variable.
+
+151
+00:12:14,000 --> 00:12:19,000
+Another important thing is to understand what PMG can't do.
+
+152
+00:12:20,000 --> 00:12:27,000
+Taking into account this is a static code analysis tool it can't find for us runtime exceptions.
+
+153
+00:12:28,000 --> 00:12:36,000
+For example, in this for loop you can see that there is potential runtime exception array index out
+
+154
+00:12:36,000 --> 00:12:37,000
+of bound exception.
+
+155
+00:12:37,000 --> 00:12:40,000
+But PMD doesn't see this.
+
+156
+00:12:40,000 --> 00:12:47,000
+So just be aware about this that PMD will not protect you from runtime exceptions.
+
+157
+00:12:47,000 --> 00:12:50,000
+With regards to the next steps.
+
+158
+00:12:50,000 --> 00:12:55,000
+Follow the steps that I showed in the demo and check your project.
+
+159
+00:12:55,000 --> 00:12:59,000
+Try to understand which rules are violated and try to fix them.
+
+160
+00:13:00,000 --> 00:13:05,000
+And in case something will be not clear for you, please do not hesitate to let me know in the comments
+
+161
+00:13:05,000 --> 00:13:08,000
+below the video and I will be happy to answer.
+
+162
+00:13:08,000 --> 00:13:12,000
+And now let me show you how you can configure PMG.
+
+163
+00:13:13,000 --> 00:13:18,000
+Click on window, select preferences and search for PMG.
+
+164
+00:13:19,000 --> 00:13:22,000
+Here you can find rule configuration.
+
+165
+00:13:23,000 --> 00:13:25,000
+You can enable or disable rules.
+
+166
+00:13:26,000 --> 00:13:29,000
+Select how to group rules.
+
+167
+00:13:29,000 --> 00:13:32,000
+You can export or import rule set.
+
+168
+00:13:32,000 --> 00:13:34,000
+This is needed when you need to align.
+
+169
+00:13:34,000 --> 00:13:40,000
+Approach inside a big team to make sure that all team members have the same rule set.
+
+170
+00:13:41,000 --> 00:13:44,000
+If you want, you can add your own rule.
+
+171
+00:13:44,000 --> 00:13:46,000
+Just click on the plus sign.
+
+172
+00:13:47,000 --> 00:13:50,000
+Then fill out the data in the pop up.
+
+173
+00:13:51,000 --> 00:13:52,000
+It includes rule name.
+
+174
+00:13:52,000 --> 00:13:53,000
+Rule set.
+
+175
+00:13:54,000 --> 00:13:58,000
+Implemented by Java class or XPath script.
+
+176
+00:13:58,000 --> 00:14:00,000
+Implementation class.
+
+177
+00:14:00,000 --> 00:14:01,000
+Target language.
+
+178
+00:14:01,000 --> 00:14:05,000
+Minimum and maximum version and priority.
+
+179
+00:14:05,000 --> 00:14:11,000
+So as you may understand, based on the description, your rule should be implemented somewhere in Java
+
+180
+00:14:11,000 --> 00:14:12,000
+class.
+
+181
+00:14:12,000 --> 00:14:17,000
+One of the ways to implement custom rule is to create your own class.
+
+182
+00:14:17,000 --> 00:14:25,000
+That extends abstract Java rule from PMG library that you can add as a dependency to your project.
+
+183
+00:14:26,000 --> 00:14:33,000
+Basically, you would need to override wizard method and add violation when it will be discovered.
+
+184
+00:14:34,000 --> 00:14:40,000
+In attachments to the lesson, you will be able to find the detailed guide from the official website
+
+185
+00:14:40,000 --> 00:14:42,000
+with all PMD documentation.
+
+186
+00:14:43,000 --> 00:14:48,000
+I checked that guide and I can confirm that this is really a good guide.
+
+187
+00:14:48,000 --> 00:14:53,000
+Check step by step guide and try to create your own rule if you are interested.
+
+188
+00:14:54,000 --> 00:14:58,000
+This is a more complex topic that lies beyond the current lesson.
+
+189
+00:14:58,000 --> 00:15:03,000
+In case you would like to learn more about this, let me know in the comments below the video and I
+
+190
+00:15:03,000 --> 00:15:09,000
+will help you, because it would require a separate lesson to explain how to create separate PMU rule.
+
+191
+00:15:09,000 --> 00:15:15,000
+But at least now you know that this is possible and you received direction.
+
+192
+00:15:15,000 --> 00:15:19,000
+And one more important thing that I want to show you on example.
+
+193
+00:15:20,000 --> 00:15:28,000
+You can create PMG report in the form of HTML pages, and you can integrate PMG into your build process.
+
+194
+00:15:29,000 --> 00:15:35,000
+In this example, I will show you how you can integrate PMG into your build process when using Maven.
+
+195
+00:15:36,000 --> 00:15:38,000
+This is not a lesson about Maven.
+
+196
+00:15:38,000 --> 00:15:41,000
+That's why I wouldn't stop too much on this topic.
+
+197
+00:15:41,000 --> 00:15:48,000
+But in short, Maven is one of the most popular build tools that is used for Java applications.
+
+198
+00:15:48,000 --> 00:15:55,000
+Please watch the previous lesson about Checkstyle, because in that lesson I also shared some details
+
+199
+00:15:55,000 --> 00:15:57,000
+about Maven configuration.
+
+200
+00:15:58,000 --> 00:16:02,000
+So we'll use Maven template project that is called Maven Multi.
+
+201
+00:16:03,000 --> 00:16:05,000
+It has multiple maven modules.
+
+202
+00:16:05,000 --> 00:16:07,000
+I open Pom.xml.
+
+203
+00:16:08,000 --> 00:16:11,000
+This is the main configuration file for Maven.
+
+204
+00:16:11,000 --> 00:16:18,000
+So basically Maven will read configurations from this file and will work per instructions described
+
+205
+00:16:18,000 --> 00:16:19,000
+in this file.
+
+206
+00:16:20,000 --> 00:16:27,000
+In order to be able to generate HTML reports, we need to add a few plugins that we already added in
+
+207
+00:16:27,000 --> 00:16:30,000
+the previous lesson when we learned Checkstyle.
+
+208
+00:16:30,000 --> 00:16:39,000
+But still, let me remind you, we need to add Maven site plugin and Maven Project Info reports plugin.
+
+209
+00:16:40,000 --> 00:16:46,000
+As I already mentioned, I explained what these plugins are in the previous lesson.
+
+210
+00:16:46,000 --> 00:16:49,000
+That's why I will not repeat myself.
+
+211
+00:16:49,000 --> 00:16:54,000
+And in the reporting tag you need to add Cpmv plugin.
+
+212
+00:16:54,000 --> 00:16:56,000
+It is called Maven PMD plugin.
+
+213
+00:16:57,000 --> 00:17:04,000
+And now important thing you need to configure which rule sets to apply during the code analysis.
+
+214
+00:17:05,000 --> 00:17:11,000
+In PMG, rule sets are configurations that define which specific rules should be applied during the
+
+215
+00:17:11,000 --> 00:17:13,000
+static code analysis process.
+
+216
+00:17:14,000 --> 00:17:20,000
+A rule set essentially contains a collection of rules that PMC will use to check your code for potential
+
+217
+00:17:20,000 --> 00:17:27,000
+issues, violations, or patterns that do not conform to best practices or coding standards.
+
+218
+00:17:28,000 --> 00:17:31,000
+You can check all rules in the official PMD documentation.
+
+219
+00:17:32,000 --> 00:17:38,000
+Don't worry, I will add this link to attachments of the lesson and you will be able to investigate
+
+220
+00:17:38,000 --> 00:17:40,000
+this link after the lesson.
+
+221
+00:17:40,000 --> 00:17:47,000
+So in this case, Best practices is a rule set that consists of the following rules.
+
+222
+00:17:47,000 --> 00:17:54,000
+There is also code style rule set that consists of the following rules and so on.
+
+223
+00:17:54,000 --> 00:18:00,000
+So in case you want to learn more about rules and rule sets, you can check them on this page.
+
+224
+00:18:00,000 --> 00:18:03,000
+You can click on each rule to learn more.
+
+225
+00:18:03,000 --> 00:18:09,000
+In the Maven PMD plugin there are predefined rule sets in PMD.
+
+226
+00:18:09,000 --> 00:18:17,000
+Default rule sets are predefined sets of rules that come bundled with the PMD tool, and in order to
+
+227
+00:18:17,000 --> 00:18:24,000
+use them, you need to specify rule sets inside the rule sets tag like you can see in this example.
+
+228
+00:18:24,000 --> 00:18:28,000
+Category Java Best Practices dot XML.
+
+229
+00:18:29,000 --> 00:18:35,000
+You already saw a Best practices rule set in the official documentation, and you can check the which
+
+230
+00:18:35,000 --> 00:18:37,000
+rules are inside this rule set.
+
+231
+00:18:38,000 --> 00:18:43,000
+Based on this example, let's understand how this line is formed.
+
+232
+00:18:43,000 --> 00:18:51,000
+So the POS slash category slash Java slash best practices dot XML refers to a specific rule configuration
+
+233
+00:18:51,000 --> 00:18:58,000
+file within the PMU rule set Iraqi that focuses on best practices for Java programming.
+
+234
+00:18:59,000 --> 00:19:01,000
+Let's break down this POS.
+
+235
+00:19:02,000 --> 00:19:03,000
+Category.
+
+236
+00:19:03,000 --> 00:19:08,000
+This represents the top level category or group of rules within PMD.
+
+237
+00:19:09,000 --> 00:19:16,000
+Categories organized rules into logical groupings based on the aspect of code quality they address,
+
+238
+00:19:17,000 --> 00:19:18,000
+for example best practices.
+
+239
+00:19:18,000 --> 00:19:20,000
+Performance design.
+
+240
+00:19:21,000 --> 00:19:21,000
+Java.
+
+241
+00:19:22,000 --> 00:19:27,000
+This specifies the programming language for which the ruleset is intended.
+
+242
+00:19:27,000 --> 00:19:31,000
+In this case, the ruleset applies specifically to Java code.
+
+243
+00:19:31,000 --> 00:19:33,000
+Best practices XML.
+
+244
+00:19:34,000 --> 00:19:41,000
+This indicates the specific rule set file that contains rules related to best practices for Java programming.
+
+245
+00:19:41,000 --> 00:19:43,000
+The best practices.
+
+246
+00:19:43,000 --> 00:19:50,000
+XML file contains a collection of rules that are considered to promote good coding practices and maintainability
+
+247
+00:19:50,000 --> 00:19:56,000
+in Java code, and in the similar way I added multiple other rule sets.
+
+248
+00:19:56,000 --> 00:19:58,000
+So that's the key thing.
+
+249
+00:19:59,000 --> 00:20:05,000
+Just in case, I will leave a link to the official documentation of PMD plugin where you can find even
+
+250
+00:20:05,000 --> 00:20:07,000
+more details.
+
+251
+00:20:07,000 --> 00:20:14,000
+And remember, in case you want to clarify something or in case something is not clear, please let
+
+252
+00:20:14,000 --> 00:20:18,000
+me know in the comments below the video and I will be happy to answer.
+
+253
+00:20:19,000 --> 00:20:25,000
+So now everything is configured and we are ready to generate PMG report.
+
+254
+00:20:25,000 --> 00:20:31,000
+I open terminal window in the root folder of my project and I execute the following command.
+
+255
+00:20:32,000 --> 00:20:34,000
+And then clean site.
+
+256
+00:20:35,000 --> 00:20:41,000
+Clean is the default Maven goal that would clean all artifacts created during the previous build.
+
+257
+00:20:41,000 --> 00:20:46,000
+Basically, the target folder will be removed like this.
+
+258
+00:20:46,000 --> 00:20:53,000
+We will be able to become sure that our configuration works properly, because all new reports will
+
+259
+00:20:53,000 --> 00:20:55,000
+be generated from scratch.
+
+260
+00:20:55,000 --> 00:21:01,000
+And sight is a goal that is used to generate project reports in a standardized format.
+
+261
+00:21:02,000 --> 00:21:09,000
+After execution of this command, we need to give some time to Maven to complete all operations.
+
+262
+00:21:09,000 --> 00:21:17,000
+When you can see information that build was successful, you can check target folder, inside target
+
+263
+00:21:17,000 --> 00:21:23,000
+folder and inside side folder you will find PMG HTML file.
+
+264
+00:21:24,000 --> 00:21:24,000
+Open it.
+
+265
+00:21:25,000 --> 00:21:32,000
+You can open it in your web browser on your local computer, or you can use built in browser in eclipse.
+
+266
+00:21:33,000 --> 00:21:39,000
+Just make mouse right click on the file, select open with and click on web browser.
+
+267
+00:21:40,000 --> 00:21:41,000
+And here it is.
+
+268
+00:21:42,000 --> 00:21:44,000
+This is our PMD report for this project.
+
+269
+00:21:44,000 --> 00:21:52,000
+As you can see, all rules violations are grouped by priority violations with priority two are located
+
+270
+00:21:52,000 --> 00:21:56,000
+in the following files main, core, main, persistence and app.
+
+271
+00:21:57,000 --> 00:22:00,000
+Taking into account this is a simple demo project.
+
+272
+00:22:00,000 --> 00:22:07,000
+I don't have too many files here that goes violations with priority three and priority four, and the
+
+273
+00:22:07,000 --> 00:22:14,000
+similar way you can generate reports for all your projects and keep track of quality of your code.
+
+274
+00:22:15,000 --> 00:22:18,000
+That's all what I wanted to share with you in this lesson.
+
+275
+00:22:18,000 --> 00:22:24,000
+But in case you still have any questions regarding PMD, you are welcome to ask them in comments below
+
+276
+00:22:24,000 --> 00:22:25,000
+this video.
+
+277
+00:22:25,000 --> 00:22:29,000
+And in the meantime, let's recap what we have learned today.
+
+278
+00:22:30,000 --> 00:22:33,000
+We learned what PMD is now you know.
+
+279
+00:22:33,000 --> 00:22:36,000
+Features and benefits of using PMA.
+
+280
+00:22:36,000 --> 00:22:43,000
+I explained you the role of PMD tool in the development process, and then we had a lot of practical
+
+281
+00:22:43,000 --> 00:22:45,000
+activity on practical examples.
+
+282
+00:22:45,000 --> 00:22:53,000
+We learned how to install PMD, how to check code with PMD, how to analyze PMD reports, and how to
+
+283
+00:22:53,000 --> 00:22:55,000
+integrate PMD into build process.
+
+284
+00:22:56,000 --> 00:22:58,000
+That's all for this lesson.
+
+285
+00:22:58,000 --> 00:23:00,000
+Thanks a lot for your attention.
+
+286
+00:23:00,000 --> 00:23:03,000
+Have a great day and see you in the next lesson.
+

108 - Tools, Automation, and Industry Best Practices/external-links.txt

@@ -0,0 +1,9 @@
+
+002 All-resources-and-links-for-the-lesson
+https://docs.google.com/document/d/1q9dNmR60DlQLoNVxxzjNy9VJS6WxOFKsOfW8c2jb5x0/edit?usp=sharing
+
+003 All-resources-and-links-for-the-lesson
+https://docs.google.com/document/d/1q9dNmR60DlQLoNVxxzjNy9VJS6WxOFKsOfW8c2jb5x0/edit?usp=sharing
+
+004 All-resources-and-links-for-the-lesson
+https://docs.google.com/document/d/1v6hhz-Lfk0R4XhyJqXT0GjUfhWiJGf1ZDsUZwdVP3nY/edit?usp=sharing

109 - Advanced Code Review Strategies/001 All-documents-shared-in-the-lesson.url

@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://drive.google.com/drive/folders/174RXHMxjVbVNg4DSQ7nxOQAK4I5StLdp?usp=sharing

109 - Advanced Code Review Strategies/002 Coding Standards, Code Quality & Consistency_en.srt

@@ -0,0 +1,1280 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Tim.
+
+2
+00:00:06,000 --> 00:00:11,000
+In this lesson we are going to talk about coding standards, code quality and consistency.
+
+3
+00:00:11,000 --> 00:00:17,000
+We will start the lesson from understanding of what coding standards are, what they consist of and
+
+4
+00:00:17,000 --> 00:00:18,000
+why we need them.
+
+5
+00:00:19,000 --> 00:00:24,000
+Then we'll review examples of coding standards that I prepared specially for this lesson.
+
+6
+00:00:24,000 --> 00:00:30,000
+You will be able to reuse the template provided for your own project by adding your project specific
+
+7
+00:00:30,000 --> 00:00:30,000
+details.
+
+8
+00:00:31,000 --> 00:00:36,000
+After learning all this, we will discuss how to enforce coding standards in your team.
+
+9
+00:00:37,000 --> 00:00:40,000
+We will review key strategies that are supposed to help you.
+
+10
+00:00:40,000 --> 00:00:45,000
+Then we will talk about ensuring code quality and consistency on the project.
+
+11
+00:00:45,000 --> 00:00:51,000
+And at the end of the lesson, we will make overview of coding standards for different programming languages.
+
+12
+00:00:51,000 --> 00:00:53,000
+So let's start our lesson.
+
+13
+00:00:53,000 --> 00:00:58,000
+Let's understand what coding standards are and what they usually include.
+
+14
+00:00:59,000 --> 00:01:05,000
+Coding standards are guidelines or rules that dictate how code should be written and formatted in a
+
+15
+00:01:05,000 --> 00:01:07,000
+consistent and readable manner.
+
+16
+00:01:07,000 --> 00:01:15,000
+These standards help ensure that code is easier to understand, maintain, and debug by both the original
+
+17
+00:01:15,000 --> 00:01:19,000
+coder and others who may work with the code in the future.
+
+18
+00:01:19,000 --> 00:01:21,000
+Here is a basic overview.
+
+19
+00:01:21,000 --> 00:01:25,000
+Let me make a basic overview of what coding standards may include.
+
+20
+00:01:26,000 --> 00:01:28,000
+Naming conventions.
+
+21
+00:01:28,000 --> 00:01:34,000
+Standards for naming variables, functions, methods, classes, and other elements should be clear
+
+22
+00:01:34,000 --> 00:01:35,000
+and descriptive.
+
+23
+00:01:35,000 --> 00:01:40,000
+This helps in understanding the purpose and functionality of each element.
+
+24
+00:01:40,000 --> 00:01:42,000
+Formatting.
+
+25
+00:01:42,000 --> 00:01:47,000
+Consistent indentation, spacing and line breaks improve code readability.
+
+26
+00:01:48,000 --> 00:01:55,000
+Common formatting styles include tabs versus spaces, line lengths, limits, and placement of braces
+
+27
+00:01:55,000 --> 00:01:56,000
+and parentheses.
+
+28
+00:01:57,000 --> 00:01:58,000
+Comments.
+
+29
+00:01:58,000 --> 00:02:05,000
+Guidelines for adding comments to explain complex logic, assumptions or intentions behind the code.
+
+30
+00:02:05,000 --> 00:02:09,000
+Comments should be clear and concise, avoiding unnecessary confusion.
+
+31
+00:02:10,000 --> 00:02:17,000
+Documentation standards for documenting code, including the purpose of modules, classes, functions
+
+32
+00:02:17,000 --> 00:02:18,000
+and parameters.
+
+33
+00:02:18,000 --> 00:02:24,000
+Documentation may include usage examples and explanations of return values and exceptions.
+
+34
+00:02:25,000 --> 00:02:32,000
+Error handling guidelines for handling errors and exceptions, including when to use try catch blocks,
+
+35
+00:02:32,000 --> 00:02:37,000
+how to report errors, and how to handle unexpected situations gracefully.
+
+36
+00:02:38,000 --> 00:02:45,000
+Code structure standards for organizing code into logical units such as modules, classes, and functions.
+
+37
+00:02:46,000 --> 00:02:52,000
+This includes principles such as separation of concerns and single responsibility, which help keep
+
+38
+00:02:52,000 --> 00:02:54,000
+code modular and maintainable.
+
+39
+00:02:55,000 --> 00:03:02,000
+Performance guidelines for writing efficient code, such as avoiding unnecessary computations, minimizing
+
+40
+00:03:02,000 --> 00:03:07,000
+memory usage, and optimizing algorithms when it is possible.
+
+41
+00:03:07,000 --> 00:03:15,000
+Security standards for writing secure code, including best practices for input validation, data sanitization,
+
+42
+00:03:15,000 --> 00:03:17,000
+authentication, and encryption.
+
+43
+00:03:18,000 --> 00:03:24,000
+Testing guidelines for writing testable code and creating unit tests to verify functionality.
+
+44
+00:03:25,000 --> 00:03:30,000
+This may include standards for test coverage, test naming conventions and assertions.
+
+45
+00:03:31,000 --> 00:03:37,000
+Version control standards for using version control systems such as git, including commit message conventions,
+
+46
+00:03:37,000 --> 00:03:40,000
+branching strategies, and code review processes.
+
+47
+00:03:41,000 --> 00:03:47,000
+Overall coding standards promote consistency, reliability, maintainability, and collaboration among
+
+48
+00:03:47,000 --> 00:03:49,000
+developers working on a project.
+
+49
+00:03:49,000 --> 00:03:56,000
+They help ensure that code is of high quality and can be easily understood and maintained over time.
+
+50
+00:03:57,000 --> 00:04:03,000
+So in order to understand what coding standards are and how they look like, let's review example.
+
+51
+00:04:04,000 --> 00:04:06,000
+Let's pretend that we have a web application.
+
+52
+00:04:06,000 --> 00:04:11,000
+And Kim, who uses Java stack for web development of the application.
+
+53
+00:04:11,000 --> 00:04:19,000
+We also have test automation framework that is written on Java using selenium WebDriver and cucumber
+
+54
+00:04:19,000 --> 00:04:20,000
+library for BDD.
+
+55
+00:04:20,000 --> 00:04:21,000
+Scenario description.
+
+56
+00:04:22,000 --> 00:04:23,000
+This is just an example.
+
+57
+00:04:23,000 --> 00:04:29,000
+Of course there can be different combination of technology stack and applications under development,
+
+58
+00:04:29,000 --> 00:04:33,000
+and it is only up to you how you would like to tailor the recommended template.
+
+59
+00:04:34,000 --> 00:04:38,000
+So let me walk you through this example and I will give you my comments.
+
+60
+00:04:38,000 --> 00:04:44,000
+As we go in the document you will find explanation and example on Java programming language.
+
+61
+00:04:45,000 --> 00:04:51,000
+Just to remind you that this is just an example, and you need to tailor this document to your project
+
+62
+00:04:51,000 --> 00:04:55,000
+needs and your project requirements.
+
+63
+00:04:55,000 --> 00:05:01,000
+If your project doesn't use Java, then obviously there is no sense in having Java examples.
+
+64
+00:05:02,000 --> 00:05:07,000
+Regarding naming conventions, you can see that for class names we use Pascal case.
+
+65
+00:05:07,000 --> 00:05:15,000
+For variables and methods we use camel case constants should be in uppercase with underscore separating
+
+66
+00:05:15,000 --> 00:05:16,000
+words.
+
+67
+00:05:16,000 --> 00:05:21,000
+Packages should be in lower case and follow a reverse domain name convention.
+
+68
+00:05:22,000 --> 00:05:26,000
+This reflects standards that are described in Java naming conventions.
+
+69
+00:05:27,000 --> 00:05:32,000
+If you have any other specifics for naming, you can describe them here.
+
+70
+00:05:32,000 --> 00:05:36,000
+And here is an example of naming convention applied in code.
+
+71
+00:05:36,000 --> 00:05:39,000
+I bet you already heard about camel case.
+
+72
+00:05:39,000 --> 00:05:46,000
+That describes a case when you don't use spaces between words, but instead you start with lowercase
+
+73
+00:05:46,000 --> 00:05:48,000
+and then capitalize each new word.
+
+74
+00:05:49,000 --> 00:05:56,000
+If you didn't hear before about Pascal case, it is a variable naming convention in programming in which
+
+75
+00:05:56,000 --> 00:06:03,000
+the first letter of each word is uppercase and the remaining letters are lowercase with no spaces or
+
+76
+00:06:03,000 --> 00:06:05,000
+other separators between words.
+
+77
+00:06:05,000 --> 00:06:09,000
+But each new word is started with uppercase.
+
+78
+00:06:10,000 --> 00:06:14,000
+But anyway, these are specific terms and concepts.
+
+79
+00:06:14,000 --> 00:06:20,000
+I will make just a brief overview of them, because the main focus is on the structure of the document.
+
+80
+00:06:20,000 --> 00:06:27,000
+Like I mentioned, all this content will be project specific, but in case you would have any questions,
+
+81
+00:06:27,000 --> 00:06:33,000
+please do not hesitate to post your questions below the video and I will be happy to answer.
+
+82
+00:06:33,000 --> 00:06:36,000
+The next section is about formatting.
+
+83
+00:06:36,000 --> 00:06:42,000
+Usually, team agrees on some code formatting in order to make sure code is readable.
+
+84
+00:06:42,000 --> 00:06:49,000
+For example, you can set the limit on the line length about position of braces because there are different
+
+85
+00:06:49,000 --> 00:06:51,000
+styles of where to put braces.
+
+86
+00:06:51,000 --> 00:06:58,000
+And in case you are not consistent within one code repository, this might look confusing.
+
+87
+00:06:58,000 --> 00:07:04,000
+These rules can be used for configuration, spatial extensions and plugins in the integrated development
+
+88
+00:07:04,000 --> 00:07:05,000
+environments.
+
+89
+00:07:05,000 --> 00:07:08,000
+So how this is happening on practice.
+
+90
+00:07:09,000 --> 00:07:13,000
+Tech lead configures these rules and share configuration file with team members.
+
+91
+00:07:14,000 --> 00:07:22,000
+Team members just import it into IDE and when they apply auto formatting code is formatted according
+
+92
+00:07:22,000 --> 00:07:24,000
+to the defined rules.
+
+93
+00:07:24,000 --> 00:07:29,000
+This is just a hint for you how to scale and how to ensure consistency.
+
+94
+00:07:29,000 --> 00:07:35,000
+For example, such feature is available in Eclipse Integrated Development Environment for Java developers.
+
+95
+00:07:36,000 --> 00:07:39,000
+And here you can see just some examples of the formatting.
+
+96
+00:07:40,000 --> 00:07:44,000
+The next section is about comments and documentation.
+
+97
+00:07:44,000 --> 00:07:47,000
+In real life there are different approaches for comment and code.
+
+98
+00:07:47,000 --> 00:07:55,000
+For example, in case you have extensive suite of unit tests, they can serve as your project documentation
+
+99
+00:07:55,000 --> 00:07:57,000
+and you don't need to have comments.
+
+100
+00:07:58,000 --> 00:08:05,000
+But still in comments you can describe algorithms, reasoning for decisions made, and lots more.
+
+101
+00:08:05,000 --> 00:08:12,000
+So I believe it is important to describe coding standards for comments two in this particular case I
+
+102
+00:08:12,000 --> 00:08:14,000
+use the reference to the Java doc format.
+
+103
+00:08:15,000 --> 00:08:21,000
+So in case some standard already exists and you just need to reuse it, feel free just to put statement
+
+104
+00:08:21,000 --> 00:08:26,000
+that will follow this standard and desirably specify hyper reference.
+
+105
+00:08:26,000 --> 00:08:27,000
+This will be enough.
+
+106
+00:08:28,000 --> 00:08:30,000
+Error handling section.
+
+107
+00:08:30,000 --> 00:08:33,000
+There are always different styles of error handling.
+
+108
+00:08:33,000 --> 00:08:37,000
+Sometimes we just let specific thread of execution to fail.
+
+109
+00:08:37,000 --> 00:08:40,000
+Sometimes we have global error handlers.
+
+110
+00:08:40,000 --> 00:08:43,000
+As I already said before, there are different styles.
+
+111
+00:08:43,000 --> 00:08:50,000
+In my opinion, it is mandatory to lock all exceptions with available logger, and I prefer to have
+
+112
+00:08:50,000 --> 00:08:56,000
+this rule written in all, the team members wouldn't forget about it during the code review process.
+
+113
+00:08:56,000 --> 00:09:03,000
+As you can see, that's why it is so important to have mature leader in your teams.
+
+114
+00:09:03,000 --> 00:09:09,000
+No matter whether it is a mature project manager with technical background and technical experience
+
+115
+00:09:09,000 --> 00:09:15,000
+or mature technical leader, somebody should execute this role to foster best practices of software
+
+116
+00:09:15,000 --> 00:09:17,000
+development on the project.
+
+117
+00:09:18,000 --> 00:09:24,000
+Regarding testing, you can highlight on naming conventions and describe how you name tests.
+
+118
+00:09:25,000 --> 00:09:32,000
+In this particular case, I define that we use format where I start each test with shoot and then put
+
+119
+00:09:32,000 --> 00:09:36,000
+verbs focusing on the behavior of the module or system.
+
+120
+00:09:37,000 --> 00:09:44,000
+And when we are dealing with tests, I bet we shouldn't feel shy to write long method names even extra
+
+121
+00:09:44,000 --> 00:09:52,000
+long, because sometimes test method name is the only thing that we have to understand the expected
+
+122
+00:09:52,000 --> 00:10:00,000
+behavior in a natural human language, without delving into the details of the code or test structure.
+
+123
+00:10:00,000 --> 00:10:03,000
+In the Version Control System standards.
+
+124
+00:10:03,000 --> 00:10:06,000
+I also made a reference to git flow branching model.
+
+125
+00:10:07,000 --> 00:10:12,000
+This is a popular branching model, so no need to describe it in details.
+
+126
+00:10:12,000 --> 00:10:16,000
+It would be enough to make a reference on it in this particular case.
+
+127
+00:10:17,000 --> 00:10:23,000
+Very important in my opinion is to highlight that on the project we try to achieve clean git history.
+
+128
+00:10:23,000 --> 00:10:30,000
+That's why before creating pull requests, we have to do git rebase on the development branch but not
+
+129
+00:10:30,000 --> 00:10:32,000
+git pull command.
+
+130
+00:10:32,000 --> 00:10:35,000
+Just a quick technical note here.
+
+131
+00:10:35,000 --> 00:10:41,000
+Git pull may create a separate commit when merging changes from two different branches.
+
+132
+00:10:41,000 --> 00:10:42,000
+Git rebase.
+
+133
+00:10:42,000 --> 00:10:49,000
+Just put your commit on top of all other changes made before yours in different branches.
+
+134
+00:10:49,000 --> 00:10:53,000
+Anyway, this is not a topic of this specific lesson.
+
+135
+00:10:53,000 --> 00:10:59,000
+If you are interested to learn more about how to use git, feel free to check my course about git from
+
+136
+00:10:59,000 --> 00:11:01,000
+Basics to advance.
+
+137
+00:11:02,000 --> 00:11:09,000
+You can use Swan on your project, but not yet as SVN is just another system for code version control,
+
+138
+00:11:09,000 --> 00:11:14,000
+so feel free to describe in this section any project specific rules.
+
+139
+00:11:14,000 --> 00:11:21,000
+In the Code Structure section, you can describe any specifics related to structuring of your code of
+
+140
+00:11:21,000 --> 00:11:21,000
+the program.
+
+141
+00:11:22,000 --> 00:11:28,000
+For example, if you have modular structure, then highlight that each code should be placed in the
+
+142
+00:11:28,000 --> 00:11:31,000
+specific module because you follow modular structure.
+
+143
+00:11:32,000 --> 00:11:38,000
+In case there is some code that is going to be reused by multiple modules, it should be placed in the
+
+144
+00:11:38,000 --> 00:11:39,000
+core module.
+
+145
+00:11:39,000 --> 00:11:46,000
+In case there is a code related only to the web application and front end part, then it should be placed
+
+146
+00:11:46,000 --> 00:11:47,000
+into the web module.
+
+147
+00:11:47,000 --> 00:11:55,000
+And it is also never hurts to mention to follow the principle of separation of concerns and solid principles.
+
+148
+00:11:56,000 --> 00:12:01,000
+Solid is an abbreviation of five principles of code design in object oriented programming.
+
+149
+00:12:02,000 --> 00:12:04,000
+This is bigger topic for discussion.
+
+150
+00:12:04,000 --> 00:12:09,000
+If you are interested in the object oriented programming, you can check my course.
+
+151
+00:12:09,000 --> 00:12:12,000
+Object oriented programming from basics to advanced level.
+
+152
+00:12:12,000 --> 00:12:19,000
+In case in your project you use functional programming approach, then solid principles are not applicable
+
+153
+00:12:19,000 --> 00:12:20,000
+to your code base.
+
+154
+00:12:21,000 --> 00:12:28,000
+In performance section, it is useful to describe key principles and approaches to follow performance
+
+155
+00:12:28,000 --> 00:12:29,000
+standards in your code.
+
+156
+00:12:30,000 --> 00:12:38,000
+In this case, it is just a formal mention that each developer should always keep in mind, namely the
+
+157
+00:12:38,000 --> 00:12:41,000
+with unnecessary computations and minimize memory usage.
+
+158
+00:12:41,000 --> 00:12:46,000
+And of course to optimize algorithms when it is possible to improve performance.
+
+159
+00:12:47,000 --> 00:12:52,000
+For example, to reduce amount of loops iterations if you see how to apply improvements.
+
+160
+00:12:53,000 --> 00:12:54,000
+Security.
+
+161
+00:12:54,000 --> 00:12:55,000
+Samsung.
+
+162
+00:12:55,000 --> 00:12:59,000
+What engineers use to postpone on the very last moment.
+
+163
+00:12:59,000 --> 00:13:07,000
+My recommendation never postpone work on security items and never create technical debt items from security
+
+164
+00:13:07,000 --> 00:13:07,000
+requirements.
+
+165
+00:13:08,000 --> 00:13:13,000
+Treat security requirements with the same level of attention as functional requirements.
+
+166
+00:13:14,000 --> 00:13:20,000
+Regarding coding standards, you can see there is a mansion to write secure code by implementing best
+
+167
+00:13:20,000 --> 00:13:27,000
+practices for input validation, data sanitization, authentication, and encryption.
+
+168
+00:13:27,000 --> 00:13:34,000
+Also this important to consider a vast top ten list of risks and vulnerabilities in web applications
+
+169
+00:13:34,000 --> 00:13:36,000
+during the development.
+
+170
+00:13:36,000 --> 00:13:41,000
+In scope of this lesson, we will not have enough time to cover requirements of Avast.
+
+171
+00:13:41,000 --> 00:13:41,000
+Top ten.
+
+172
+00:13:41,000 --> 00:13:48,000
+But I have a separate course about OWASp top ten with Java examples, so if you are interested in the
+
+173
+00:13:48,000 --> 00:13:51,000
+topic, you can refer to the separate course.
+
+174
+00:13:52,000 --> 00:13:53,000
+That's it.
+
+175
+00:13:53,000 --> 00:13:54,000
+Regarding this template.
+
+176
+00:13:55,000 --> 00:14:01,000
+Of course you can add any other sections, but I believe that this template covers a lot of potential
+
+177
+00:14:01,000 --> 00:14:05,000
+sections that you would like to keep in coding standards of your project.
+
+178
+00:14:06,000 --> 00:14:12,000
+In case you will have any questions regarding this template, please do not hesitate to post your questions
+
+179
+00:14:12,000 --> 00:14:15,000
+below the video and I will be happy to answer.
+
+180
+00:14:16,000 --> 00:14:17,000
+Let's continue.
+
+181
+00:14:18,000 --> 00:14:22,000
+Okay, so at this point of the lesson, we already know what coding standards are.
+
+182
+00:14:22,000 --> 00:14:25,000
+We saw coding standards document example.
+
+183
+00:14:25,000 --> 00:14:32,000
+And now let's discuss how we can enforce coding standards on our project and where to start with introduction
+
+184
+00:14:32,000 --> 00:14:34,000
+of coding standards.
+
+185
+00:14:34,000 --> 00:14:41,000
+Like we already discussed before, setting and enforcing coding standards is crucial for maintaining
+
+186
+00:14:41,000 --> 00:14:45,000
+consistency, reliability, and maintainability across a software project.
+
+187
+00:14:46,000 --> 00:14:51,000
+Let's review approach to establish and uphold coding standards efficiently.
+
+188
+00:14:51,000 --> 00:14:55,000
+Step number one define coding standards.
+
+189
+00:14:55,000 --> 00:15:01,000
+Begin by defining clear and comprehensive coding standards tailored to your project's requirements,
+
+190
+00:15:01,000 --> 00:15:04,000
+technologies, and team preferences.
+
+191
+00:15:04,000 --> 00:15:10,000
+Consider aspects such as naming conventions, formatting guidelines, comments, documentation, error
+
+192
+00:15:10,000 --> 00:15:16,000
+handling, testing practices, code structure, performance considerations, security measures, and
+
+193
+00:15:16,000 --> 00:15:18,000
+version control practices.
+
+194
+00:15:18,000 --> 00:15:21,000
+At least everything what we have reviewed in my example.
+
+195
+00:15:22,000 --> 00:15:29,000
+Step number two document Standards documents the coding standards in a centralized location such as
+
+196
+00:15:29,000 --> 00:15:35,000
+conference page, a Readme file in your version control repository, or a dedicated document in your
+
+197
+00:15:35,000 --> 00:15:36,000
+project management system.
+
+198
+00:15:36,000 --> 00:15:42,000
+Ensure that all team members have access to and are familiar with the coding standards.
+
+199
+00:15:42,000 --> 00:15:43,000
+Documentation.
+
+200
+00:15:44,000 --> 00:15:48,000
+Step number three training and onboarding.
+
+201
+00:15:48,000 --> 00:15:55,000
+Provide training and onboarding sessions for new team members to familiarize them with the coding standards.
+
+202
+00:15:56,000 --> 00:16:03,000
+Emphasize the importance of adhering to the standards to maintain code quality and facilitate collaboration.
+
+203
+00:16:04,000 --> 00:16:07,000
+The next step is called reviews.
+
+204
+00:16:07,000 --> 00:16:15,000
+Incorporate code reviews into your development process as a means of enforcing coding standards require
+
+205
+00:16:15,000 --> 00:16:24,000
+all changes to undergo peer review before being merged into the main code base during code reviews ensures
+
+206
+00:16:24,000 --> 00:16:30,000
+that reviewers check for adherence to coding standards, in addition to functional correctness and efficiency.
+
+207
+00:16:31,000 --> 00:16:38,000
+That's why it is super important to make code reviewers be aware about all the details of coding standards
+
+208
+00:16:39,000 --> 00:16:40,000
+that would be easy to make.
+
+209
+00:16:40,000 --> 00:16:46,000
+If potential code reviewers are involved in the development of coding standards on your project.
+
+210
+00:16:46,000 --> 00:16:54,000
+In this way, you can be sure that your expectations are aligned and you are all on the same page regarding
+
+211
+00:16:54,000 --> 00:16:55,000
+coding standards.
+
+212
+00:16:56,000 --> 00:17:04,000
+The next thing to remember is automated tools utilize automated tools and linters to enforce coding
+
+213
+00:17:04,000 --> 00:17:04,000
+standards.
+
+214
+00:17:04,000 --> 00:17:13,000
+Consistently integrate tools such as Checkstyle, PMD, find box, ESLint or Pylint into your build
+
+215
+00:17:13,000 --> 00:17:19,000
+process or IDE to automatically detect and flag violations of coding standards.
+
+216
+00:17:20,000 --> 00:17:25,000
+Configure these tools according to your defined coding standards to ensure alignment.
+
+217
+00:17:26,000 --> 00:17:28,000
+Continuous integration.
+
+218
+00:17:28,000 --> 00:17:35,000
+Integrate coding standards checks into your CI CD pipeline to enforce standards automatically with each
+
+219
+00:17:35,000 --> 00:17:36,000
+code change.
+
+220
+00:17:37,000 --> 00:17:43,000
+Set up CI jobs to run static code analysis and linting tools as part of the build process.
+
+221
+00:17:44,000 --> 00:17:48,000
+Fails the build if any coding standards violations are detected.
+
+222
+00:17:48,000 --> 00:17:51,000
+Encouraging developers to address them promptly.
+
+223
+00:17:52,000 --> 00:17:54,000
+Feedback and iteration.
+
+224
+00:17:54,000 --> 00:18:00,000
+Gather feedback from team members on the effectiveness of the coding standards and their enforcement
+
+225
+00:18:00,000 --> 00:18:01,000
+mechanisms.
+
+226
+00:18:01,000 --> 00:18:07,000
+Regularly review and update the coding standards documentation based on lessons learned.
+
+227
+00:18:07,000 --> 00:18:10,000
+Changes in technology or evolving best practices.
+
+228
+00:18:11,000 --> 00:18:17,000
+Continuously refine the enforcement process to strike the right balance between maintaining code quality
+
+229
+00:18:17,000 --> 00:18:19,000
+and developer productivity.
+
+230
+00:18:20,000 --> 00:18:22,000
+Lead by example.
+
+231
+00:18:22,000 --> 00:18:23,000
+Lead by example.
+
+232
+00:18:23,000 --> 00:18:25,000
+As a senior developer or team.
+
+233
+00:18:25,000 --> 00:18:31,000
+Lead by consistently adhering to coding standards in your own code contributions.
+
+234
+00:18:31,000 --> 00:18:38,000
+Encourage and mentor junior developers to follow coding standards, reinforcing the importance of coding
+
+235
+00:18:38,000 --> 00:18:41,000
+standards through your actions.
+
+236
+00:18:42,000 --> 00:18:48,000
+By following these steps and integrating coding standards into your development workflow, you can ensure
+
+237
+00:18:48,000 --> 00:18:56,000
+that your team produces high quality code that is consistent, maintainable, and conducive to collaboration.
+
+238
+00:18:56,000 --> 00:19:00,000
+What you can do to ensure code quality and consistency.
+
+239
+00:19:00,000 --> 00:19:06,000
+Ensuring code quality and consistency is essential for long term maintainability and reliability of
+
+240
+00:19:06,000 --> 00:19:08,000
+a software project.
+
+241
+00:19:08,000 --> 00:19:12,000
+Some of the key strategies to achieve this we already reviewed.
+
+242
+00:19:12,000 --> 00:19:13,000
+They are.
+
+243
+00:19:13,000 --> 00:19:14,000
+Code reviews.
+
+244
+00:19:14,000 --> 00:19:15,000
+Automated testing.
+
+245
+00:19:15,000 --> 00:19:22,000
+Static code analysis tools, code linters, continuous integration documentation, introduction of coding
+
+246
+00:19:22,000 --> 00:19:23,000
+standards and trainings.
+
+247
+00:19:24,000 --> 00:19:29,000
+We review these practices and all of them will help you to ensure code quality and consistency.
+
+248
+00:19:29,000 --> 00:19:33,000
+But besides them, I would like to mention two more strategies.
+
+249
+00:19:33,000 --> 00:19:37,000
+They are refactoring and peer collaboration.
+
+250
+00:19:37,000 --> 00:19:39,000
+Refactoring.
+
+251
+00:19:39,000 --> 00:19:44,000
+Regularly refactor the code to improve readability, maintainability and performance.
+
+252
+00:19:44,000 --> 00:19:51,000
+Refactoring eliminates code smells, reduces technical debt, and aligns code with a woven requirements
+
+253
+00:19:51,000 --> 00:19:52,000
+and best practices.
+
+254
+00:19:53,000 --> 00:20:00,000
+Peer collaboration foster a culture of collaboration and knowledge sharing among team members.
+
+255
+00:20:00,000 --> 00:20:06,000
+Encourage open communication, pair programming, and mentoring to leverage collective expertise and
+
+256
+00:20:06,000 --> 00:20:09,000
+ensure that code quality and consistency are upheld.
+
+257
+00:20:10,000 --> 00:20:16,000
+By incorporating these practices into your development process, you can maintain high code quality,
+
+258
+00:20:16,000 --> 00:20:22,000
+consistency, and reliability throughout the life cycle of your software project.
+
+259
+00:20:22,000 --> 00:20:24,000
+For different programming languages.
+
+260
+00:20:24,000 --> 00:20:26,000
+There are different coding standards.
+
+261
+00:20:27,000 --> 00:20:33,000
+Of course, it is not possible to cover all coding standards for all programming languages in scope
+
+262
+00:20:33,000 --> 00:20:39,000
+of one lesson, but let's try to cover at least some heat points for some programming languages.
+
+263
+00:20:40,000 --> 00:20:45,000
+This will help you to have general awareness about coding standards in different programming languages.
+
+264
+00:20:46,000 --> 00:20:52,000
+And in case you would have any questions or clarifications regarding other programming languages, please
+
+265
+00:20:52,000 --> 00:20:55,000
+Asking Questions section below the video.
+
+266
+00:20:55,000 --> 00:21:00,000
+Here are some common coding standards and best practices for different programming languages.
+
+267
+00:21:01,000 --> 00:21:07,000
+For Java follows the Java naming conventions for classes, methods, variables, and packages.
+
+268
+00:21:08,000 --> 00:21:13,000
+Use camel case for method names and variables, and Pascal case for class names.
+
+269
+00:21:14,000 --> 00:21:17,000
+Limit line lengths to 120 characters.
+
+270
+00:21:18,000 --> 00:21:22,000
+Use Javadoc commands to document classes, methods, and variables.
+
+271
+00:21:22,000 --> 00:21:27,000
+Use try catch blocks for error handling and provide meaningful error messages.
+
+272
+00:21:28,000 --> 00:21:34,000
+Follow the principles of object oriented programming such as encapsulation, inheritance, and polymorphism.
+
+273
+00:21:35,000 --> 00:21:39,000
+Use enums for representing fixed sets of constants.
+
+274
+00:21:39,000 --> 00:21:46,000
+Python programming language follows a pep8 style guide for Python code.
+
+275
+00:21:47,000 --> 00:21:51,000
+Use snake case for variable names and function names.
+
+276
+00:21:52,000 --> 00:21:55,000
+Limit line lengths to 79 characters.
+
+277
+00:21:55,000 --> 00:22:00,000
+Use docstrings to document modules, classes, functions and methods.
+
+278
+00:22:00,000 --> 00:22:07,000
+Use list comprehensions and generator expressions for concise and readable code.
+
+279
+00:22:08,000 --> 00:22:12,000
+Prefer built in functions and modules over custom implementations.
+
+280
+00:22:13,000 --> 00:22:20,000
+Use virtual environments like for example, virtualenv or venv for dependency management.
+
+281
+00:22:21,000 --> 00:22:22,000
+For JavaScript language.
+
+282
+00:22:23,000 --> 00:22:28,000
+Follow the Airbnb JavaScript Style Guide or the Google JavaScript Style Guide.
+
+283
+00:22:28,000 --> 00:22:32,000
+Use camel Case for variable names and function names.
+
+284
+00:22:32,000 --> 00:22:34,000
+Use Pascalcase for class names.
+
+285
+00:22:35,000 --> 00:22:41,000
+Use ESLint or Jshint for static code analysis and enforcing coding standards.
+
+286
+00:22:42,000 --> 00:22:47,000
+Use async await for asynchronous programming instead of callbacks or promises.
+
+287
+00:22:48,000 --> 00:22:53,000
+Minimize the use of global variables and avoid polluting the global namespace.
+
+288
+00:22:54,000 --> 00:22:58,000
+Use strict mode to enforce stricter parsing and error handling.
+
+289
+00:22:59,000 --> 00:23:08,000
+For C sharp language follows a Microsoft C sharp coding conventions use Pascal case for class names,
+
+290
+00:23:08,000 --> 00:23:10,000
+method names and property names.
+
+291
+00:23:10,000 --> 00:23:14,000
+Use camel case for parameter names and local variable names.
+
+292
+00:23:14,000 --> 00:23:17,000
+Limit line length to 100 characters.
+
+293
+00:23:18,000 --> 00:23:24,000
+Use XML documentation comments to document classes, methods and properties.
+
+294
+00:23:24,000 --> 00:23:29,000
+Use try catch blocks for error handling and provide meaningful error messages.
+
+295
+00:23:29,000 --> 00:23:33,000
+Prefer Linq for querying collections instead of loops.
+
+296
+00:23:34,000 --> 00:23:36,000
+For rabbit programming language.
+
+297
+00:23:36,000 --> 00:23:38,000
+Follow the rabbit style guide.
+
+298
+00:23:38,000 --> 00:23:41,000
+Use snake Case for method names and variable names.
+
+299
+00:23:41,000 --> 00:23:44,000
+Use camel case for class names and module names.
+
+300
+00:23:44,000 --> 00:23:47,000
+Limit the line lengths to 80 characters.
+
+301
+00:23:47,000 --> 00:23:53,000
+Use frozen string literal true to ensure that string literals are immutable.
+
+302
+00:23:54,000 --> 00:23:57,000
+Use Rubygems for dependency management.
+
+303
+00:23:58,000 --> 00:24:04,000
+Follow the principle of least surprise and write code that is easy to understand and predictable.
+
+304
+00:24:04,000 --> 00:24:08,000
+These are just some general guidelines for each programming language.
+
+305
+00:24:09,000 --> 00:24:15,000
+It's essential to consult the official documentation and community standards for each language and framework
+
+306
+00:24:15,000 --> 00:24:17,000
+you use in your project.
+
+307
+00:24:17,000 --> 00:24:23,000
+Additionally, coding standards may vary depending on the specific requirements and conventions of your
+
+308
+00:24:23,000 --> 00:24:25,000
+organization or team.
+
+309
+00:24:26,000 --> 00:24:27,000
+That's all.
+
+310
+00:24:27,000 --> 00:24:32,000
+What I wanted to share with you in this lesson, let's recap what we have learned today.
+
+311
+00:24:32,000 --> 00:24:36,000
+Today we learned what coding standards are and why we need them.
+
+312
+00:24:36,000 --> 00:24:43,000
+We reviewed the example of coding standards that potentially you can reuse on your project, and tailor
+
+313
+00:24:43,000 --> 00:24:45,000
+template provided to your project needs.
+
+314
+00:24:46,000 --> 00:24:50,000
+After that, we discussed how to enforce coding standards in your team.
+
+315
+00:24:50,000 --> 00:24:54,000
+We reviewed key strategies that are supposed to help you.
+
+316
+00:24:55,000 --> 00:24:59,000
+Also, we learned how to ensure code quality and consistency.
+
+317
+00:24:59,000 --> 00:25:04,000
+And at the end of the lesson we reviewed coding standards for different programming languages.
+
+318
+00:25:05,000 --> 00:25:06,000
+That's it for this lesson.
+
+319
+00:25:06,000 --> 00:25:08,000
+Thanks a lot for your attention.
+
+320
+00:25:08,000 --> 00:25:11,000
+Have a great day and see you in the next lesson.
+

109 - Advanced Code Review Strategies/002 Coding-Standards-and-Guidelines.url

@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://drive.google.com/file/d/1q0-V9_574YNKpCB9W_UZm9F8Vk5sYZuR/view?usp=sharing

109 - Advanced Code Review Strategies/003 Provide Feedback like a Pro_en.srt

@@ -0,0 +1,1032 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:11,000
+In this lesson I will teach you how to provide feedback as a true professional.
+
+3
+00:00:11,000 --> 00:00:17,000
+After today's lesson, you will improve your soft skills and you will find techniques that will help
+
+4
+00:00:17,000 --> 00:00:22,000
+you to build more efficient code review process and better collaboration inside the team.
+
+5
+00:00:23,000 --> 00:00:29,000
+We will start from learning what constructive criticism is, why it is important and what constructive
+
+6
+00:00:29,000 --> 00:00:31,000
+criticism techniques are.
+
+7
+00:00:32,000 --> 00:00:38,000
+I will share with you advices about how to build effective communication during code review process.
+
+8
+00:00:38,000 --> 00:00:43,000
+I will teach you how to provide fair and objective feedback and to not gain new enemies.
+
+9
+00:00:44,000 --> 00:00:50,000
+We will talk about creation of a positive code review, culture building trust among team members and
+
+10
+00:00:50,000 --> 00:00:52,000
+creation of collaborative code review process.
+
+11
+00:00:53,000 --> 00:00:54,000
+Let's start our lesson.
+
+12
+00:00:55,000 --> 00:00:59,000
+Let's start the lesson from learning constructive criticism techniques.
+
+13
+00:00:59,000 --> 00:01:01,000
+What is constructive criticism?
+
+14
+00:01:02,000 --> 00:01:08,000
+Constructive criticism is a process of providing feedback in a helpful and supportive manner, with
+
+15
+00:01:08,000 --> 00:01:13,000
+the intention of helping someone in improving their performance, behavior or work.
+
+16
+00:01:14,000 --> 00:01:21,000
+It involves identifying areas for improvement, while also offering practical suggestions or solutions
+
+17
+00:01:21,000 --> 00:01:26,000
+for how the individual can enhance their skills or address any shortcomings.
+
+18
+00:01:27,000 --> 00:01:33,000
+The goal of constructive criticism is to facilitate the growth and development, rather than simply
+
+19
+00:01:33,000 --> 00:01:35,000
+pointing out faults or shortcomings.
+
+20
+00:01:35,000 --> 00:01:42,000
+It typically involves a respectful and empathetic approach, focusing on specific behaviors or actions,
+
+21
+00:01:42,000 --> 00:01:46,000
+rather than attacking the individual's character or personality.
+
+22
+00:01:47,000 --> 00:01:54,000
+Overall, constructive criticism aims to empower individuals to recognize their strengths and weaknesses
+
+23
+00:01:54,000 --> 00:01:58,000
+and take steps to enhance their performance or achieve their goals.
+
+24
+00:01:58,000 --> 00:02:02,000
+While learning constructive criticism techniques is important.
+
+25
+00:02:02,000 --> 00:02:08,000
+This is super important because being a code reviewer, you need to help your team to stay efficient.
+
+26
+00:02:08,000 --> 00:02:11,000
+I mean, you need to be able to support code quality level.
+
+27
+00:02:11,000 --> 00:02:18,000
+On the defined level, you need to be able to foster coding standards and best practices of code design,
+
+28
+00:02:18,000 --> 00:02:22,000
+and at the same time, keep your team members motivated.
+
+29
+00:02:22,000 --> 00:02:29,000
+Because we are all people and sometimes we can take some comments as a personal thing, and this can
+
+30
+00:02:29,000 --> 00:02:33,000
+decrease our motivation to do our work faster and better.
+
+31
+00:02:33,000 --> 00:02:37,000
+That's why learning constructive criticism techniques is super important.
+
+32
+00:02:38,000 --> 00:02:42,000
+Now we know what constructive criticism is and why it is important.
+
+33
+00:02:43,000 --> 00:02:47,000
+Let's now learn constructive criticism techniques itself.
+
+34
+00:02:47,000 --> 00:02:50,000
+The first point to remember be specific.
+
+35
+00:02:50,000 --> 00:02:56,000
+Instead of making vague statements, provide specific examples to illustrate your points.
+
+36
+00:02:57,000 --> 00:03:00,000
+Focus on behavior, not personality.
+
+37
+00:03:00,000 --> 00:03:06,000
+Critical actions or behaviors, rather than attacking someone's character or personality.
+
+38
+00:03:07,000 --> 00:03:09,000
+Offer suggestions for improvement.
+
+39
+00:03:09,000 --> 00:03:11,000
+Don't just point out flaws.
+
+40
+00:03:11,000 --> 00:03:14,000
+Provide a constructive suggestions on how to improve.
+
+41
+00:03:14,000 --> 00:03:18,000
+Always remember that you are not here to blame someone.
+
+42
+00:03:18,000 --> 00:03:21,000
+You are here to help someone to become better.
+
+43
+00:03:21,000 --> 00:03:24,000
+You are not the person who claiming a problem.
+
+44
+00:03:24,000 --> 00:03:27,000
+You are part of the solution of the problem.
+
+45
+00:03:27,000 --> 00:03:29,000
+Use I statements.
+
+46
+00:03:30,000 --> 00:03:36,000
+Express your thoughts and feelings using I statements to take ownership of your perspective.
+
+47
+00:03:36,000 --> 00:03:40,000
+For example, I feel that or I think that.
+
+48
+00:03:41,000 --> 00:03:44,000
+Balanced, positive and negative feedback.
+
+49
+00:03:44,000 --> 00:03:50,000
+Highlight strengths along with areas for improvement to maintain a balanced perspective.
+
+50
+00:03:51,000 --> 00:03:58,000
+Be timely, provide feedback in a timely manner so that it is relevant to the situation and can be acted
+
+51
+00:03:58,000 --> 00:04:00,000
+upon promptly.
+
+52
+00:04:00,000 --> 00:04:02,000
+Maintain a supportive tone.
+
+53
+00:04:02,000 --> 00:04:10,000
+Use a supportive and encouraging tone to show that your intention is to help rather than criticise.
+
+54
+00:04:10,000 --> 00:04:12,000
+Listen actively.
+
+55
+00:04:12,000 --> 00:04:19,000
+Allow the other person to express their thoughts and feelings and listen actively to understand their
+
+56
+00:04:19,000 --> 00:04:20,000
+perspective.
+
+57
+00:04:21,000 --> 00:04:23,000
+Focus on the issue, not the person.
+
+58
+00:04:24,000 --> 00:04:30,000
+Keep the discussion centered on the specific issue at hand, rather than making personal attacks.
+
+59
+00:04:30,000 --> 00:04:32,000
+Encourage dialogue.
+
+60
+00:04:32,000 --> 00:04:39,000
+Create an open and constructive dialogue where both parties can share their perspectives and work towards
+
+61
+00:04:39,000 --> 00:04:41,000
+a solution collaboratively.
+
+62
+00:04:42,000 --> 00:04:47,000
+Remember, the goal of constructive criticism is to help the individual grow and improve.
+
+63
+00:04:47,000 --> 00:04:54,000
+So approach the conversation with empathy and the desire to support their development.
+
+64
+00:04:54,000 --> 00:05:00,000
+And now let me share with you some advices of effective communication during code reviews.
+
+65
+00:05:00,000 --> 00:05:06,000
+Effective communication during code reviews is crucial for ensuring high quality code and fostering
+
+66
+00:05:06,000 --> 00:05:09,000
+collaboration within a development team.
+
+67
+00:05:09,000 --> 00:05:13,000
+Let's review some tips for effective communication during code reviews.
+
+68
+00:05:14,000 --> 00:05:15,000
+Be respectful.
+
+69
+00:05:15,000 --> 00:05:21,000
+Approach code reviews with a respectful attitude towards your colleague's work and efforts.
+
+70
+00:05:21,000 --> 00:05:23,000
+Provide clear feedback.
+
+71
+00:05:23,000 --> 00:05:29,000
+Clearly articulate your feedback, focusing on specific issues or areas for improvement.
+
+72
+00:05:30,000 --> 00:05:31,000
+Use a positive tone.
+
+73
+00:05:32,000 --> 00:05:37,000
+Use constructive language and a positive tone to encourage collaboration and avoid demotivating team
+
+74
+00:05:37,000 --> 00:05:38,000
+members.
+
+75
+00:05:39,000 --> 00:05:41,000
+As I already mentioned, be specific.
+
+76
+00:05:41,000 --> 00:05:48,000
+Provide specific commands and suggestions referencing relevant lines of code or sections of the code
+
+77
+00:05:48,000 --> 00:05:48,000
+base.
+
+78
+00:05:49,000 --> 00:05:52,000
+Focus on the code, not the person.
+
+79
+00:05:52,000 --> 00:05:57,000
+Keep feedback focused on the code itself rather than criticizing the developer personally.
+
+80
+00:05:58,000 --> 00:05:59,000
+Encourage discussion.
+
+81
+00:05:59,000 --> 00:06:04,000
+Invite the developer to discuss any questions or concerns they have about the feedback.
+
+82
+00:06:04,000 --> 00:06:07,000
+Fostering open communication and collaboration.
+
+83
+00:06:08,000 --> 00:06:11,000
+Offer solutions instead of just pointing out problems.
+
+84
+00:06:11,000 --> 00:06:15,000
+Offer suggestions or alternative approaches for addressing them.
+
+85
+00:06:16,000 --> 00:06:20,000
+Do not force other people to guess your thoughts.
+
+86
+00:06:20,000 --> 00:06:22,000
+This is not constructive approach.
+
+87
+00:06:23,000 --> 00:06:24,000
+Prioritize feedback.
+
+88
+00:06:24,000 --> 00:06:30,000
+Focus on the most critical issues first, addressing them before moving on to the less significant concerns.
+
+89
+00:06:31,000 --> 00:06:33,000
+Acknowledge good work.
+
+90
+00:06:33,000 --> 00:06:39,000
+Don't forget to acknowledge well written code or good practices that you observe during the review.
+
+91
+00:06:40,000 --> 00:06:41,000
+Follow up.
+
+92
+00:06:42,000 --> 00:06:47,000
+After providing feedback, follow up with the developer to ensure that they understand the comments
+
+93
+00:06:47,000 --> 00:06:51,000
+and suggestions and to see if they need any further assistance.
+
+94
+00:06:52,000 --> 00:06:58,000
+By following these steps, you can ensure that code reviews are conducted effectively, leading to improved
+
+95
+00:06:58,000 --> 00:07:02,000
+code quality, enhance collaboration, and a positive team dynamic.
+
+96
+00:07:03,000 --> 00:07:11,000
+So now in these rules, let's try to make a summary of how to provide fair and objective feedback and
+
+97
+00:07:11,000 --> 00:07:12,000
+to not gain new enemies.
+
+98
+00:07:13,000 --> 00:07:19,000
+Providing fair and objective feedback is essential for fostering trust, growth and improvement within
+
+99
+00:07:19,000 --> 00:07:21,000
+a team or organization.
+
+100
+00:07:22,000 --> 00:07:26,000
+Let's review some tips for delivering feedback in a fair and objective manner.
+
+101
+00:07:27,000 --> 00:07:29,000
+Focus on observations.
+
+102
+00:07:29,000 --> 00:07:35,000
+Base your feedback on specific observations and facts rather than assumptions or personal opinions.
+
+103
+00:07:36,000 --> 00:07:37,000
+Stay neutral.
+
+104
+00:07:37,000 --> 00:07:44,000
+Maintain a neutral tone and avoid letting personal biases or emotions influence your feedback.
+
+105
+00:07:45,000 --> 00:07:47,000
+Use quantifiable metrics.
+
+106
+00:07:47,000 --> 00:07:54,000
+Where possible, use quantifiable metrics or data to support your feedback and make it more objective.
+
+107
+00:07:54,000 --> 00:08:02,000
+Instead of putting comments and the pull requests something like why you don't write unit tests at all?
+
+108
+00:08:02,000 --> 00:08:05,000
+Be specific and leave such comments.
+
+109
+00:08:05,000 --> 00:08:11,000
+For example, after your pull request, our line test code coverage dropped by 2%.
+
+110
+00:08:11,000 --> 00:08:13,000
+We need to improve this.
+
+111
+00:08:13,000 --> 00:08:16,000
+As you can see, this is completely different approach.
+
+112
+00:08:17,000 --> 00:08:18,000
+Provide context.
+
+113
+00:08:18,000 --> 00:08:25,000
+Offer context of your feedback by explaining why certain behaviors or outcomes are important and how
+
+114
+00:08:25,000 --> 00:08:28,000
+they align with organizational goals or standards.
+
+115
+00:08:29,000 --> 00:08:37,000
+Be consistent applies the same standards and criteria to all team members when providing feedback to
+
+116
+00:08:37,000 --> 00:08:39,000
+ensure fairness and consistency.
+
+117
+00:08:40,000 --> 00:08:42,000
+Acknowledge effort and improvement.
+
+118
+00:08:42,000 --> 00:08:50,000
+Recognize and acknowledge the efforts made by individuals, even if the outcomes are not yet perfect.
+
+119
+00:08:50,000 --> 00:08:54,000
+Encourage continued improvement by highlighting progress over time.
+
+120
+00:08:55,000 --> 00:08:57,000
+Offer specific examples.
+
+121
+00:08:57,000 --> 00:09:05,000
+Support your feedback with specific examples or instances to illustrate your points and make them more
+
+122
+00:09:05,000 --> 00:09:06,000
+tangible.
+
+123
+00:09:06,000 --> 00:09:09,000
+Encourage self-reflection.
+
+124
+00:09:09,000 --> 00:09:16,000
+Encourage individuals to reflect on their own performance and seek feedback from others to foster self-awareness
+
+125
+00:09:16,000 --> 00:09:18,000
+and continuous learning.
+
+126
+00:09:19,000 --> 00:09:25,000
+Focus on behavior, not personality, as this is the rules that I repeated multiple of times already
+
+127
+00:09:25,000 --> 00:09:32,000
+during this lesson because it is important when providing feedback, focus on specific behaviors or
+
+128
+00:09:32,000 --> 00:09:37,000
+actions rather than making judgments about a person's character or personality.
+
+129
+00:09:38,000 --> 00:09:40,000
+Seek feedback yourself.
+
+130
+00:09:41,000 --> 00:09:47,000
+Be open to receiving feedback from others, and use it to improve your own ability to provide fair and
+
+131
+00:09:47,000 --> 00:09:48,000
+objective feedback.
+
+132
+00:09:49,000 --> 00:09:55,000
+By following these tips, you can ensure that your feedback is fair, objective and constructive, helping
+
+133
+00:09:55,000 --> 00:10:01,000
+individuals to grow and develop professionally while also contributing to a positive and supportive
+
+134
+00:10:01,000 --> 00:10:02,000
+team environment.
+
+135
+00:10:03,000 --> 00:10:09,000
+And now, let me share with you some recommendations about how to create a positive code review culture
+
+136
+00:10:09,000 --> 00:10:10,000
+in your team.
+
+137
+00:10:11,000 --> 00:10:12,000
+Creating a positive code review.
+
+138
+00:10:12,000 --> 00:10:19,000
+Culture is essential for fostering collaboration, learning and continuous improvement within the development
+
+139
+00:10:19,000 --> 00:10:19,000
+team.
+
+140
+00:10:20,000 --> 00:10:25,000
+Let's review some strategies for building and maintaining a positive code review culture.
+
+141
+00:10:26,000 --> 00:10:28,000
+Set clear expectations.
+
+142
+00:10:28,000 --> 00:10:35,000
+Establish clear guidelines and expectations for code reviews, including the goals, process, and standards
+
+143
+00:10:35,000 --> 00:10:36,000
+to be followed.
+
+144
+00:10:36,000 --> 00:10:38,000
+Promote a growth mindset.
+
+145
+00:10:38,000 --> 00:10:45,000
+Encourage a growth mindset within the team where feedback is viewed as an opportunity for learning and
+
+146
+00:10:45,000 --> 00:10:47,000
+improvement rather than criticism.
+
+147
+00:10:48,000 --> 00:10:50,000
+Lead by example.
+
+148
+00:10:50,000 --> 00:10:57,000
+Set a positive example by providing constructive feedback, being open to receiving feedback and demonstrating
+
+149
+00:10:57,000 --> 00:10:59,000
+a willingness to learn and grow.
+
+150
+00:11:00,000 --> 00:11:01,000
+Create a safe environment.
+
+151
+00:11:02,000 --> 00:11:08,000
+Foster a safe and supportive environment where team members feel comfortable sharing their code, asking
+
+152
+00:11:08,000 --> 00:11:12,000
+questions and providing feedback without fear of judgement.
+
+153
+00:11:13,000 --> 00:11:14,000
+Encourage collaboration.
+
+154
+00:11:15,000 --> 00:11:19,000
+Emphasize the importance of collaboration and teamwork in code reviews.
+
+155
+00:11:19,000 --> 00:11:24,000
+Encouraging developers to work together to solve problems and share knowledge.
+
+156
+00:11:25,000 --> 00:11:27,000
+Provide training and support.
+
+157
+00:11:27,000 --> 00:11:34,000
+Offer training and support to help team members develop their code review skills, including providing
+
+158
+00:11:34,000 --> 00:11:37,000
+guidance on how to give and receive feedback effectively.
+
+159
+00:11:38,000 --> 00:11:40,000
+Celebrate success.
+
+160
+00:11:40,000 --> 00:11:46,000
+Recognize and celebrate the achievements and contributions of team members, including successful code
+
+161
+00:11:46,000 --> 00:11:48,000
+reviews and improvements to the code base.
+
+162
+00:11:49,000 --> 00:11:56,000
+In some companies, there can be motivational badges that you can send online to colleagues or any other
+
+163
+00:11:56,000 --> 00:11:57,000
+form of appraisal.
+
+164
+00:11:58,000 --> 00:12:01,000
+Regularly review and update processes.
+
+165
+00:12:02,000 --> 00:12:04,000
+Regularly review and update your code.
+
+166
+00:12:04,000 --> 00:12:11,000
+Review processes and guidelines based on feedback and lessons learned to ensure they remain effective
+
+167
+00:12:11,000 --> 00:12:12,000
+and relevant.
+
+168
+00:12:12,000 --> 00:12:15,000
+Encourage diverse perspectives.
+
+169
+00:12:15,000 --> 00:12:20,000
+Encourage team members to offer diverse perspectives and viewpoints during code reviews.
+
+170
+00:12:20,000 --> 00:12:26,000
+Recognizing the value of different experiences and backgrounds in improving code quality.
+
+171
+00:12:27,000 --> 00:12:29,000
+Provide feedback channels.
+
+172
+00:12:29,000 --> 00:12:35,000
+Establish clear channels for providing feedback on the code review process itself, allowing team members
+
+173
+00:12:35,000 --> 00:12:39,000
+to share their thoughts, suggestions, and concerns openly.
+
+174
+00:12:40,000 --> 00:12:45,000
+By implementing these strategies, you can create a positive code review culture where team members
+
+175
+00:12:45,000 --> 00:12:50,000
+feel valued, supported and motivated to collaborate and improve continuously.
+
+176
+00:12:51,000 --> 00:12:57,000
+Another important aspect of building an efficient team and fruitful collaboration during the code review
+
+177
+00:12:57,000 --> 00:13:00,000
+process is a trust among team members.
+
+178
+00:13:00,000 --> 00:13:06,000
+If you have this trust between people, then a lot of challenges will not even appear.
+
+179
+00:13:06,000 --> 00:13:11,000
+Let me share with you my experience of how to build a trust among team members.
+
+180
+00:13:12,000 --> 00:13:18,000
+Building trust among team members is essential for fostering collaboration, productivity and a positive
+
+181
+00:13:18,000 --> 00:13:19,000
+work environment.
+
+182
+00:13:20,000 --> 00:13:23,000
+Let's review some strategies for building trust within a team.
+
+183
+00:13:24,000 --> 00:13:27,000
+Communicate openly and transparently.
+
+184
+00:13:27,000 --> 00:13:34,000
+Foster open and transparent communication by sharing information, updates and feedback openly with
+
+185
+00:13:34,000 --> 00:13:35,000
+team members.
+
+186
+00:13:35,000 --> 00:13:40,000
+As I already mentioned, and this is very efficient rule lead by example.
+
+187
+00:13:40,000 --> 00:13:48,000
+Demonstrate reliability through your actions and behavior such as keeping commitments, being honest,
+
+188
+00:13:48,000 --> 00:13:50,000
+and respecting confidentiality.
+
+189
+00:13:51,000 --> 00:13:53,000
+Show empathy and understanding.
+
+190
+00:13:54,000 --> 00:13:57,000
+Take the time to listen actively to your team members.
+
+191
+00:13:57,000 --> 00:14:02,000
+Show empathy and understand their perspectives, feelings, and concerns.
+
+192
+00:14:03,000 --> 00:14:03,000
+Delegates.
+
+193
+00:14:03,000 --> 00:14:05,000
+Responsibility.
+
+194
+00:14:05,000 --> 00:14:11,000
+Delegate tasks and responsibilities to team members, empowering them to take ownership and demonstrate
+
+195
+00:14:11,000 --> 00:14:12,000
+their capabilities.
+
+196
+00:14:13,000 --> 00:14:20,000
+Encourage collaboration, create opportunities for collaboration and teamwork where team members can
+
+197
+00:14:20,000 --> 00:14:25,000
+work together to solve problems, share ideas, and achieve common goals.
+
+198
+00:14:26,000 --> 00:14:27,000
+Be reliable.
+
+199
+00:14:28,000 --> 00:14:34,000
+Consistently deliver high quality work, meet deadlines, and fulfill your commitments to build trust
+
+200
+00:14:34,000 --> 00:14:36,000
+and confidence among team members.
+
+201
+00:14:37,000 --> 00:14:40,000
+Respect diversity and inclusion.
+
+202
+00:14:40,000 --> 00:14:46,000
+Embrace diversity and inclusion within the team, respecting different perspectives, backgrounds and
+
+203
+00:14:46,000 --> 00:14:51,000
+experiences, and creating a safe and inclusive environment for all.
+
+204
+00:14:52,000 --> 00:14:54,000
+Provide support and feedback.
+
+205
+00:14:54,000 --> 00:15:01,000
+Offer support, guidance and feedback to team members to help them grow, develop and improve their
+
+206
+00:15:01,000 --> 00:15:02,000
+skills and capabilities.
+
+207
+00:15:03,000 --> 00:15:05,000
+Build personal connections.
+
+208
+00:15:06,000 --> 00:15:10,000
+Take the time to get to know your team members on a personal level.
+
+209
+00:15:10,000 --> 00:15:18,000
+Building rapport and trust through casual conversations, team building activities, and social interactions.
+
+210
+00:15:18,000 --> 00:15:24,000
+By implementing these strategies consistently, you can create a trusting and supportive team environment
+
+211
+00:15:24,000 --> 00:15:31,000
+where team members feel valued, respected, and motivated to collaborate and work together.
+
+212
+00:15:32,000 --> 00:15:36,000
+If you would follow all the rules that we have learned during the lesson.
+
+213
+00:15:36,000 --> 00:15:40,000
+This would lead you to collaborative and efficient code review process.
+
+214
+00:15:40,000 --> 00:15:46,000
+But there are some other recommendations on top of what we have already discussed.
+
+215
+00:15:47,000 --> 00:15:53,000
+Collaborative code reviews involve team members working together to review and improve code before it
+
+216
+00:15:53,000 --> 00:15:54,000
+is merged into the code base.
+
+217
+00:15:55,000 --> 00:15:59,000
+Let's review some tips for conducting collaborative code reviews effectively.
+
+218
+00:16:00,000 --> 00:16:02,000
+Establish clear guidelines.
+
+219
+00:16:02,000 --> 00:16:09,000
+Define clear guidelines for code reviews, including expectations for review, frequency, DApps and
+
+220
+00:16:09,000 --> 00:16:09,000
+etiquette.
+
+221
+00:16:10,000 --> 00:16:15,000
+And in this course, I have separate lessons about code review guidelines, where we reviewed a real
+
+222
+00:16:15,000 --> 00:16:16,000
+example.
+
+223
+00:16:17,000 --> 00:16:18,000
+Assign roles.
+
+224
+00:16:19,000 --> 00:16:25,000
+Assign roles such as the reviewer and author to team members to ensure clarity and accountability during
+
+225
+00:16:25,000 --> 00:16:26,000
+the review process.
+
+226
+00:16:26,000 --> 00:16:30,000
+Sometimes there are can be permanent reviewers.
+
+227
+00:16:30,000 --> 00:16:36,000
+Sometimes each team member may act as a code reviewer if you have mature team.
+
+228
+00:16:37,000 --> 00:16:45,000
+Use version control tools, utilize version control tools like git, and platforms like GitHub or GitLab
+
+229
+00:16:45,000 --> 00:16:51,000
+to facilitate code reviews with features such as pull requests, comments, and inline diffs.
+
+230
+00:16:52,000 --> 00:16:54,000
+Set realistic expectations.
+
+231
+00:16:55,000 --> 00:17:02,000
+Set realistic timelines and expectations for code reviews to ensure that their sorrow, but not overly
+
+232
+00:17:02,000 --> 00:17:03,000
+time consuming.
+
+233
+00:17:04,000 --> 00:17:06,000
+Encourage constructive feedback.
+
+234
+00:17:06,000 --> 00:17:12,000
+Foster a culture of constructive feedback, where team members provide feedback in a respectful and
+
+235
+00:17:12,000 --> 00:17:18,000
+helpful manner, focusing on improving the code rather than criticising the developer.
+
+236
+00:17:19,000 --> 00:17:21,000
+Leverage automation.
+
+237
+00:17:21,000 --> 00:17:27,000
+Use automated tools for code analysis, linting, and testing to catch common issues and streamline
+
+238
+00:17:27,000 --> 00:17:28,000
+the review process.
+
+239
+00:17:29,000 --> 00:17:31,000
+Document decisions.
+
+240
+00:17:31,000 --> 00:17:37,000
+Document decisions and discussions made during the code review process to provide context for future
+
+241
+00:17:37,000 --> 00:17:40,000
+reference and to facilitate knowledge sharing.
+
+242
+00:17:41,000 --> 00:17:45,000
+Follow up on code review feedback by addressing any issues raised.
+
+243
+00:17:45,000 --> 00:17:51,000
+Making necessary changes and ensuring that the code meets the team's quality standards before merging.
+
+244
+00:17:52,000 --> 00:17:58,000
+By following these steps, teams can conduct collaborative code reviews effectively, leading to higher
+
+245
+00:17:58,000 --> 00:18:05,000
+code quality, improves collaboration, and enhance learning and skill development among team members.
+
+246
+00:18:05,000 --> 00:18:06,000
+That's all.
+
+247
+00:18:06,000 --> 00:18:09,000
+What I wanted to review with you in this lesson.
+
+248
+00:18:09,000 --> 00:18:11,000
+Let's recap what we have learned today.
+
+249
+00:18:12,000 --> 00:18:15,000
+Today we learned constructive criticism techniques.
+
+250
+00:18:15,000 --> 00:18:21,000
+We learned what it is, why it is important, and we learned techniques itself.
+
+251
+00:18:21,000 --> 00:18:27,000
+I shared with you advices how to build effective communication during the code review process.
+
+252
+00:18:27,000 --> 00:18:34,000
+Also, we talked about how to provide fair and objective feedback and to not gain new enemies inside
+
+253
+00:18:34,000 --> 00:18:34,000
+the team.
+
+254
+00:18:35,000 --> 00:18:41,000
+We discuss how to create positive code, review culture within the team, how to build trust among team
+
+255
+00:18:41,000 --> 00:18:45,000
+members, and how to build collaborative code review process.
+
+256
+00:18:45,000 --> 00:18:47,000
+That's all for this lesson.
+
+257
+00:18:47,000 --> 00:18:49,000
+Thanks a lot for your attention.
+
+258
+00:18:49,000 --> 00:18:52,000
+Have a great day and see you in the next lesson.
+

109 - Advanced Code Review Strategies/004 Security Considerations During Code Review_en.srt

@@ -0,0 +1,824 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Tim.
+
+2
+00:00:06,000 --> 00:00:13,000
+In this lesson, we'll learn more about security considerations in code and their role during code review.
+
+3
+00:00:14,000 --> 00:00:19,000
+We'll start our lesson from understanding the importance of security in software development.
+
+4
+00:00:19,000 --> 00:00:25,000
+Then I will share with you a list of common security vulnerabilities when developing web applications.
+
+5
+00:00:26,000 --> 00:00:31,000
+In this lesson, I will share with you my experience of integration, security, best practices in code
+
+6
+00:00:31,000 --> 00:00:32,000
+review process.
+
+7
+00:00:32,000 --> 00:00:35,000
+And at the end of the lesson we will learn security scanners.
+
+8
+00:00:35,000 --> 00:00:41,000
+We will discuss tools for security scanning that you can integrate into development process.
+
+9
+00:00:41,000 --> 00:00:43,000
+Let's start our lesson.
+
+10
+00:00:43,000 --> 00:00:50,000
+Let me explain you first why it is so important to be concerned about security during the software development.
+
+11
+00:00:50,000 --> 00:00:57,000
+Security and software development is crucial for safeguarding sensitive data, protecting user privacy,
+
+12
+00:00:57,000 --> 00:01:01,000
+and preventing unauthorized access or malicious attacks.
+
+13
+00:01:01,000 --> 00:01:04,000
+Here is why it is important.
+
+14
+00:01:04,000 --> 00:01:11,000
+First of all, data protection software often deals with sensitive information such as personal details,
+
+15
+00:01:11,000 --> 00:01:15,000
+financial data, or intellectual property.
+
+16
+00:01:15,000 --> 00:01:23,000
+Security measures help to encrypt and secure this data, preventing unauthorized access or theft.
+
+17
+00:01:23,000 --> 00:01:25,000
+User trust.
+
+18
+00:01:25,000 --> 00:01:31,000
+Security breaches can ruin user trust and damage a company's reputation.
+
+19
+00:01:31,000 --> 00:01:39,000
+Users expect their data to be handled securely, and failure to do so can lead to loss of customers
+
+20
+00:01:39,000 --> 00:01:40,000
+and revenue.
+
+21
+00:01:41,000 --> 00:01:43,000
+Compliance requirements.
+
+22
+00:01:43,000 --> 00:01:51,000
+Many industries have strict regulations governing the handling of sensitive data, such as GDPR in Europe
+
+23
+00:01:51,000 --> 00:01:54,000
+or HIPAA in the healthcare industry.
+
+24
+00:01:54,000 --> 00:02:02,000
+Adhering to these regulations is not just a legal requirement, but also essential for maintaining trust
+
+25
+00:02:02,000 --> 00:02:03,000
+with customers.
+
+26
+00:02:04,000 --> 00:02:06,000
+Preventing cyber attacks.
+
+27
+00:02:06,000 --> 00:02:14,000
+The threat landscape is constantly evolving, with hackers employing sophisticated techniques to exploit
+
+28
+00:02:14,000 --> 00:02:15,000
+vulnerabilities and software.
+
+29
+00:02:17,000 --> 00:02:24,000
+Implementing robust security measures helps to mitigate the risk of cyber attacks such as malware,
+
+30
+00:02:24,000 --> 00:02:26,000
+ransomware, or phishing attempts.
+
+31
+00:02:27,000 --> 00:02:29,000
+Financial impact.
+
+32
+00:02:30,000 --> 00:02:37,000
+Security breaches can result in significant financial losses for organisations, including costs associated
+
+33
+00:02:37,000 --> 00:02:45,000
+with data recovery, legal fees, regulatory fines and damage to brand reputation.
+
+34
+00:02:45,000 --> 00:02:52,000
+Investing in security up front can save money in the long run by preventing these incidents.
+
+35
+00:02:52,000 --> 00:02:54,000
+Continuity of operations.
+
+36
+00:02:54,000 --> 00:03:02,000
+Security incidents can disrupt normal business operations, leading to downtime and loss of productivity.
+
+37
+00:03:02,000 --> 00:03:09,000
+By implementing security best practices, organisations can ensure the continuity of their operations
+
+38
+00:03:09,000 --> 00:03:12,000
+even in the face of potential threats.
+
+39
+00:03:13,000 --> 00:03:14,000
+Competitive advantage.
+
+40
+00:03:15,000 --> 00:03:21,000
+In today's digital landscape, customers prioritize security when choosing software products or services.
+
+41
+00:03:22,000 --> 00:03:29,000
+By demonstrating a commitment to security, organisations can gain a competitive advantage and differentiate
+
+42
+00:03:29,000 --> 00:03:32,000
+themselves from competitors.
+
+43
+00:03:32,000 --> 00:03:38,000
+Overall, integrating security into the software development life cycle is essential for protecting
+
+44
+00:03:38,000 --> 00:03:45,000
+valuable assets, maintaining trust with users, and ensuring the long term success of organisations.
+
+45
+00:03:46,000 --> 00:03:49,000
+Now let's talk about common security vulnerabilities.
+
+46
+00:03:49,000 --> 00:03:53,000
+To be honest, it is not a short topic to talk about.
+
+47
+00:03:53,000 --> 00:03:58,000
+I have separate courses about secure coding and Java and about Avast.
+
+48
+00:03:58,000 --> 00:04:04,000
+Top ten vulnerabilities, where we reviewed the most common security vulnerabilities for web applications.
+
+49
+00:04:05,000 --> 00:04:12,000
+So depending on the type of applications that you develop programming paradigm, there might be different
+
+50
+00:04:12,000 --> 00:04:13,000
+security vulnerabilities.
+
+51
+00:04:13,000 --> 00:04:20,000
+But still, let me try to cover some of the most common security vulnerabilities for web applications.
+
+52
+00:04:21,000 --> 00:04:22,000
+Injection attacks.
+
+53
+00:04:23,000 --> 00:04:30,000
+This occurs when untrusted data is sent to an interpreter as part of a command or query.
+
+54
+00:04:30,000 --> 00:04:38,000
+Examples include SQL injection, where malicious SQL commands are injected into input fields to manipulate
+
+55
+00:04:38,000 --> 00:04:46,000
+a database, and operating system command injection, where commands are injected into operating system
+
+56
+00:04:46,000 --> 00:04:47,000
+commands.
+
+57
+00:04:48,000 --> 00:04:48,000
+Broken.
+
+58
+00:04:48,000 --> 00:04:50,000
+Authentication.
+
+59
+00:04:50,000 --> 00:04:57,000
+Weakness in authentication mechanisms can allow attackers to compromise user accounts, such as through
+
+60
+00:04:57,000 --> 00:05:03,000
+brute force attacks, credential stuffing, or session hijacking.
+
+61
+00:05:04,000 --> 00:05:06,000
+Sensitive data exposure.
+
+62
+00:05:06,000 --> 00:05:13,000
+Failure to properly protect sensitive data such as passwords, credit card numbers, or personal information
+
+63
+00:05:13,000 --> 00:05:16,000
+can lead to unauthorized access.
+
+64
+00:05:16,000 --> 00:05:23,000
+This vulnerability often occurs due to inadequate encryption or improper handling of data.
+
+65
+00:05:23,000 --> 00:05:25,000
+Security misconfiguration.
+
+66
+00:05:26,000 --> 00:05:33,000
+Incorrectly configured security settings such as default passwords, unnecessary services, or excessive
+
+67
+00:05:33,000 --> 00:05:36,000
+permissions can expose systems to attacks.
+
+68
+00:05:36,000 --> 00:05:43,000
+Attackers may exploit these misconfigurations to gain unauthorized access or escalate privileges.
+
+69
+00:05:44,000 --> 00:05:45,000
+Cross-site scripting.
+
+70
+00:05:46,000 --> 00:05:53,000
+Cross-site scripting attacks occur when malicious scripts are injected into web pages viewed by other
+
+71
+00:05:53,000 --> 00:05:53,000
+users.
+
+72
+00:05:54,000 --> 00:06:02,000
+This can lead to the theft of session cookies, damage of websites, or redirection to malicious sites.
+
+73
+00:06:03,000 --> 00:06:05,000
+Broken access control.
+
+74
+00:06:05,000 --> 00:06:13,000
+Inadequate access controls can allow unauthorized users to access sensitive functionality or data.
+
+75
+00:06:13,000 --> 00:06:21,000
+This includes issues such as missing or ineffective access controls, insecure direct object references,
+
+76
+00:06:21,000 --> 00:06:23,000
+or insufficient authorization checks.
+
+77
+00:06:24,000 --> 00:06:32,000
+Security headers, missing or misconfigured security headers such as content security policy, strict
+
+78
+00:06:32,000 --> 00:06:39,000
+transport security, or cross-origin resource sharing can leave web applications vulnerable to various
+
+79
+00:06:39,000 --> 00:06:44,000
+attacks such as cross-site scripting or clickjacking.
+
+80
+00:06:45,000 --> 00:06:47,000
+Cross-site request forgery.
+
+81
+00:06:48,000 --> 00:06:58,000
+CSRF attacks occur when an attacker tricks a user into performing unintended actions on a web application
+
+82
+00:06:58,000 --> 00:07:00,000
+where they are authenticated.
+
+83
+00:07:01,000 --> 00:07:08,000
+This can lead to actions such as changing account settings, making purchases, or initiate and transfers
+
+84
+00:07:08,000 --> 00:07:10,000
+without the user's consent.
+
+85
+00:07:11,000 --> 00:07:14,000
+Using components with known vulnerabilities.
+
+86
+00:07:14,000 --> 00:07:21,000
+Incorporating a third party libraries or components with known security vulnerabilities can expose software
+
+87
+00:07:21,000 --> 00:07:23,000
+to exploitation.
+
+88
+00:07:23,000 --> 00:07:29,000
+It's essential to regularly update and patch dependencies to mitigate these risks.
+
+89
+00:07:30,000 --> 00:07:32,000
+Insufficient login and monitoring.
+
+90
+00:07:33,000 --> 00:07:39,000
+Inadequate login and monitoring make it difficult to detect and respond to security incidents.
+
+91
+00:07:39,000 --> 00:07:47,000
+Organizations should implement comprehensive login practices and establish monitoring systems to identify
+
+92
+00:07:47,000 --> 00:07:50,000
+and investigate suspicious activities.
+
+93
+00:07:50,000 --> 00:07:56,000
+By understanding and addressing these common vulnerabilities, software developers can build more secure
+
+94
+00:07:56,000 --> 00:08:00,000
+applications and protect against potential threats.
+
+95
+00:08:00,000 --> 00:08:06,000
+So it is super important to integrate security best practices into code review process.
+
+96
+00:08:07,000 --> 00:08:13,000
+It is essential for identifying and mitigating vulnerabilities early in the software development life
+
+97
+00:08:13,000 --> 00:08:14,000
+cycle.
+
+98
+00:08:14,000 --> 00:08:17,000
+Here is how you can do it effectively.
+
+99
+00:08:17,000 --> 00:08:25,000
+First of all, establish guidelines, define clear security coding guidelines and standards that developers
+
+100
+00:08:25,000 --> 00:08:26,000
+should follow.
+
+101
+00:08:26,000 --> 00:08:34,000
+These guidelines should cover topics such as input validation or syndication authorization, data encryption,
+
+102
+00:08:34,000 --> 00:08:37,000
+error handling, and secure configuration.
+
+103
+00:08:38,000 --> 00:08:45,000
+Train reviewers provide training to code reviewers on common security vulnerabilities and best practices,
+
+104
+00:08:45,000 --> 00:08:52,000
+ensure they understand how to identify security issues during code reviews, and provide actionable
+
+105
+00:08:52,000 --> 00:08:53,000
+feedback to developers.
+
+106
+00:08:55,000 --> 00:09:01,000
+Automated tools use automated security scanning tools as part of the code review process.
+
+107
+00:09:01,000 --> 00:09:08,000
+These tools can help identify potential security vulnerabilities such as code injections, cross-site
+
+108
+00:09:08,000 --> 00:09:12,000
+scripting, cross-site request forgery, and insecure dependencies.
+
+109
+00:09:13,000 --> 00:09:20,000
+Integrate these tools into CI CD pipeline to catch issues early in the development process.
+
+110
+00:09:20,000 --> 00:09:24,000
+We are going to review examples of these tools later in the lesson.
+
+111
+00:09:25,000 --> 00:09:26,000
+Checklists.
+
+112
+00:09:27,000 --> 00:09:35,000
+Develop code review checklists specifically focused on security concerns include items related to input
+
+113
+00:09:35,000 --> 00:09:42,000
+validation, authentication mechanisms, data encryption, access controls, error handling, and security
+
+114
+00:09:42,000 --> 00:09:43,000
+configurations.
+
+115
+00:09:44,000 --> 00:09:50,000
+Reviewers can use these checklists to systematically evaluate code for security vulnerabilities.
+
+116
+00:09:51,000 --> 00:09:59,000
+Peer reviews encourage peer reviews, where developers review each other's code for security issues.
+
+117
+00:09:59,000 --> 00:10:06,000
+This collaborative approach helps spread security awareness throughout the team and provides an additional
+
+118
+00:10:06,000 --> 00:10:07,000
+layer of verification.
+
+119
+00:10:08,000 --> 00:10:10,000
+Threat modeling.
+
+120
+00:10:10,000 --> 00:10:16,000
+Integrate threat modeling into the code review process to proactively identify potential security threats
+
+121
+00:10:16,000 --> 00:10:24,000
+and vulnerabilities by analyzing the system's architecture and identifying potential attack vectors.
+
+122
+00:10:24,000 --> 00:10:28,000
+Developers can prioritize security considerations during code reviews.
+
+123
+00:10:29,000 --> 00:10:31,000
+Security review meetings.
+
+124
+00:10:31,000 --> 00:10:38,000
+Hold regular security review meetings where developers, security experts, and other stakeholders discuss
+
+125
+00:10:38,000 --> 00:10:41,000
+security concerns and review code together.
+
+126
+00:10:42,000 --> 00:10:49,000
+These meetings provide an opportunity to address complex security issues and ensure alignment with security
+
+127
+00:10:49,000 --> 00:10:50,000
+requirements.
+
+128
+00:10:51,000 --> 00:10:57,000
+Provide feedback ensures that code reviewers provide clear and actionable feedback to developers on
+
+129
+00:10:57,000 --> 00:10:59,000
+identified security issues.
+
+130
+00:10:59,000 --> 00:11:06,000
+Explain why certain practices are insecure and provide guidance on how to remediate them.
+
+131
+00:11:07,000 --> 00:11:10,000
+Encourage a culture of continuous improvement and learning.
+
+132
+00:11:11,000 --> 00:11:12,000
+Track metrics.
+
+133
+00:11:13,000 --> 00:11:19,000
+Track and analyze security related metrics, such as the number of security issues identified during
+
+134
+00:11:19,000 --> 00:11:20,000
+code reviews.
+
+135
+00:11:20,000 --> 00:11:25,000
+Time to remediate vulnerabilities and trends over time.
+
+136
+00:11:25,000 --> 00:11:32,000
+Use this data to measure the effectiveness of your security review process and identify areas for improvement.
+
+137
+00:11:33,000 --> 00:11:34,000
+Documentation.
+
+138
+00:11:34,000 --> 00:11:41,000
+Document security related decisions, discussions, and remediation efforts during code reviews.
+
+139
+00:11:41,000 --> 00:11:48,000
+This documentation serves as a valuable resource for future reference and helps maintain consistency
+
+140
+00:11:48,000 --> 00:11:51,000
+in security practices across the development team.
+
+141
+00:11:52,000 --> 00:11:58,000
+By integrating these best practices into code review process, organizations can make stronger their
+
+142
+00:11:58,000 --> 00:12:04,000
+overall security posture and reduce the risk of security breaches in their software applications.
+
+143
+00:12:05,000 --> 00:12:08,000
+Separately, I'd like to talk about security scanners.
+
+144
+00:12:08,000 --> 00:12:15,000
+Integration into a development process, including security scanners in the code review process is indeed
+
+145
+00:12:15,000 --> 00:12:19,000
+an important aspect of integrating security best practices.
+
+146
+00:12:20,000 --> 00:12:23,000
+Here is how you can incorporate security scanners.
+
+147
+00:12:24,000 --> 00:12:31,000
+Automated scanning tools utilize automated security scanning tools to analyze code for vulnerabilities.
+
+148
+00:12:31,000 --> 00:12:39,000
+These tools can identify common security issues such as injection attacks, cross-site scripting, cross-site
+
+149
+00:12:39,000 --> 00:12:43,000
+request forgery, and secure dependencies and misconfigurations.
+
+150
+00:12:44,000 --> 00:12:51,000
+Integrate security scanners into your CI CD pipeline to automatically scan code as part of the build
+
+151
+00:12:51,000 --> 00:12:52,000
+process.
+
+152
+00:12:52,000 --> 00:13:00,000
+For example, you can use such tools as sonar, cube, check marks, or 45 to perform static code analysis
+
+153
+00:13:00,000 --> 00:13:04,000
+and identify vulnerabilities in the code base.
+
+154
+00:13:04,000 --> 00:13:07,000
+Static application security testing.
+
+155
+00:13:07,000 --> 00:13:15,000
+These tools analyze source code or compiled binaries to identify security vulnerabilities without executing
+
+156
+00:13:15,000 --> 00:13:16,000
+the application.
+
+157
+00:13:16,000 --> 00:13:23,000
+These tools can detect issues such as SQL injection, cross-site scripting, buffer overflows, and
+
+158
+00:13:23,000 --> 00:13:31,000
+insecure cryptographic implementations by examining the code for patterns indicative of vulnerabilities.
+
+159
+00:13:32,000 --> 00:13:40,000
+Examples utilize such tools as Veracode or Coverity to analyze source code for vulnerabilities.
+
+160
+00:13:41,000 --> 00:13:43,000
+Dynamic application security testing.
+
+161
+00:13:44,000 --> 00:13:50,000
+These tools interact with running applications to identify security vulnerabilities from the outside.
+
+162
+00:13:51,000 --> 00:13:58,000
+They simulate attacks and analyze responses to detect issues such as injection attacks, authentication,
+
+163
+00:13:58,000 --> 00:14:02,000
+bypass, and insecure configurations.
+
+164
+00:14:02,000 --> 00:14:09,000
+Dynamic application security testing tools can provide valuable insights into vulnerabilities that may
+
+165
+00:14:09,000 --> 00:14:12,000
+not be apparent from static analysis alone.
+
+166
+00:14:13,000 --> 00:14:15,000
+Examples of tools.
+
+167
+00:14:15,000 --> 00:14:24,000
+You can use such tools as a wasp, zap, or burp suit to simulate attacks against running applications
+
+168
+00:14:24,000 --> 00:14:26,000
+and identify vulnerabilities.
+
+169
+00:14:27,000 --> 00:14:29,000
+Dependency scanning.
+
+170
+00:14:29,000 --> 00:14:35,000
+Use dependency scanning tools to identify known vulnerabilities in third party libraries and components
+
+171
+00:14:35,000 --> 00:14:37,000
+used in your software.
+
+172
+00:14:38,000 --> 00:14:44,000
+These tools analyze dependencies against vulnerability databases and alert developers to any security
+
+173
+00:14:44,000 --> 00:14:45,000
+issues.
+
+174
+00:14:45,000 --> 00:14:51,000
+Integrate dependency scanning into your build process to automatically check for vulnerabilities in
+
+175
+00:14:51,000 --> 00:14:52,000
+dependencies.
+
+176
+00:14:53,000 --> 00:15:01,000
+Use dependency scanning tools such as OWASp, Dependency Check or Snake to identify known vulnerabilities
+
+177
+00:15:01,000 --> 00:15:04,000
+in third party libraries and components.
+
+178
+00:15:04,000 --> 00:15:06,000
+Container security scanning.
+
+179
+00:15:07,000 --> 00:15:14,000
+If you use containerized applications, incorporate container security scanning tools into your CI CD
+
+180
+00:15:14,000 --> 00:15:15,000
+pipeline.
+
+181
+00:15:16,000 --> 00:15:23,000
+These tools scan container images for vulnerabilities in operating system packages, libraries, and
+
+182
+00:15:23,000 --> 00:15:24,000
+configurations.
+
+183
+00:15:24,000 --> 00:15:32,000
+Container security scanning helps ensure that your containerized applications are free from known security
+
+184
+00:15:32,000 --> 00:15:34,000
+vulnerabilities before deployment.
+
+185
+00:15:35,000 --> 00:15:43,000
+Use container security scanning tools like Encore or Clair to scan container images for vulnerabilities
+
+186
+00:15:43,000 --> 00:15:46,000
+in operating system packages and libraries.
+
+187
+00:15:47,000 --> 00:15:48,000
+Continuous monitoring.
+
+188
+00:15:49,000 --> 00:15:56,000
+Implement continuous monitoring solutions that analyze runtime behavior and network traffic to detect
+
+189
+00:15:56,000 --> 00:15:59,000
+security anomalies and potential attacks.
+
+190
+00:16:00,000 --> 00:16:07,000
+These solutions complement static and dynamic analysis by providing real time insights into security
+
+191
+00:16:07,000 --> 00:16:10,000
+threats and vulnerabilities in production environments.
+
+192
+00:16:10,000 --> 00:16:19,000
+Implement a continuous monitoring solution such as Splunk or Elk stack to analyze logs and network traffic
+
+193
+00:16:19,000 --> 00:16:22,000
+for security anomalies and potential attacks.
+
+194
+00:16:22,000 --> 00:16:31,000
+The Elk stack is an acronym used to describe a stack that comprises three popular projects Elasticsearch,
+
+195
+00:16:31,000 --> 00:16:33,000
+Logstash, and Kibana.
+
+196
+00:16:33,000 --> 00:16:41,000
+By incorporating security scanners into your code review process, you can identify and remediate security
+
+197
+00:16:41,000 --> 00:16:47,000
+vulnerabilities more effectively, enhancing the overall security of your software applications.
+
+198
+00:16:47,000 --> 00:16:51,000
+That's all what I wanted to share with you in this lesson.
+
+199
+00:16:51,000 --> 00:16:54,000
+Let's recap what we have learned today.
+
+200
+00:16:55,000 --> 00:16:59,000
+In this lesson, we learned the importance of security in software development.
+
+201
+00:17:00,000 --> 00:17:02,000
+We discussed common security vulnerabilities.
+
+202
+00:17:03,000 --> 00:17:09,000
+I shared with you advices about how to integrate security best practices in code review process.
+
+203
+00:17:10,000 --> 00:17:13,000
+And at the end of the lesson, we learned tools for security scanning.
+
+204
+00:17:14,000 --> 00:17:16,000
+That's all for this lesson.
+
+205
+00:17:16,000 --> 00:17:18,000
+Thanks a lot for your attention.
+
+206
+00:17:18,000 --> 00:17:21,000
+Have a great day and see you in the next lesson.
+

109 - Advanced Code Review Strategies/005 Scalability Principles in Code_en.srt

@@ -0,0 +1,748 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Tim.
+
+2
+00:00:06,000 --> 00:00:11,000
+In this lesson we are going to learn scalability principles in code and how we can verify them.
+
+3
+00:00:11,000 --> 00:00:13,000
+During code review.
+
+4
+00:00:13,000 --> 00:00:18,000
+We are going to start the lesson from learning what scalability is in software development.
+
+5
+00:00:18,000 --> 00:00:25,000
+Then I will explain you best practices for scalable code that will help you to increase the quality
+
+6
+00:00:25,000 --> 00:00:28,000
+of your code significantly.
+
+7
+00:00:28,000 --> 00:00:34,000
+After that, we will talk about how to identify and address scalability challenges in your code.
+
+8
+00:00:34,000 --> 00:00:41,000
+And by the end of the lesson, we will have enough knowledge to understand how we can identify scalability
+
+9
+00:00:41,000 --> 00:00:43,000
+challenges during code review.
+
+10
+00:00:44,000 --> 00:00:45,000
+Let's start our lesson.
+
+11
+00:00:46,000 --> 00:00:52,000
+Let's learn what do we call scalability when we talk about scalability in software development?
+
+12
+00:00:52,000 --> 00:00:59,000
+Scalability and software development is all about making sure that your software can handle more work
+
+13
+00:00:59,000 --> 00:01:01,000
+as the demand increases.
+
+14
+00:01:01,000 --> 00:01:08,000
+It's like making sure your car can carry more passengers without breaking down or slowing down.
+
+15
+00:01:08,000 --> 00:01:15,000
+There are a few key things to keep in mind when thinking about scalability, performance, capacity,
+
+16
+00:01:15,000 --> 00:01:17,000
+and flexibility.
+
+17
+00:01:17,000 --> 00:01:19,000
+Performance.
+
+18
+00:01:19,000 --> 00:01:23,000
+This is about how fast your software can respond to requests.
+
+19
+00:01:23,000 --> 00:01:29,000
+If lots of people start using your software at the same time, you want it to still work quickly and
+
+20
+00:01:29,000 --> 00:01:30,000
+smoothly.
+
+21
+00:01:30,000 --> 00:01:36,000
+To improve performance, you might need to optimize your code, use better hardware, or distribute
+
+22
+00:01:36,000 --> 00:01:39,000
+the workload across multiple servers.
+
+23
+00:01:39,000 --> 00:01:40,000
+Capacity.
+
+24
+00:01:40,000 --> 00:01:44,000
+This is about how much your software can handle at once.
+
+25
+00:01:44,000 --> 00:01:50,000
+If you have a sudden spike in users, your software should be able to handle it without crashing or
+
+26
+00:01:50,000 --> 00:01:52,000
+slowing down too much.
+
+27
+00:01:53,000 --> 00:01:59,000
+To increase capacity, you might need to add more servers or upgrade your existing ones.
+
+28
+00:02:00,000 --> 00:02:01,000
+Flexibility.
+
+29
+00:02:01,000 --> 00:02:07,000
+This is about how easily you can adapt your software to handle changes in demand.
+
+30
+00:02:07,000 --> 00:02:13,000
+You want to be able to quickly scale up or down depending on what your users need.
+
+31
+00:02:13,000 --> 00:02:21,000
+This might involve using cloud services that let you add or remove resources as needed, or designing
+
+32
+00:02:21,000 --> 00:02:27,000
+your software in a way that makes it easy to add new features or change existing ones.
+
+33
+00:02:27,000 --> 00:02:34,000
+By focusing on performance, capacity, and flexibility, you can make sure that your software can grow
+
+34
+00:02:34,000 --> 00:02:40,000
+with your users and continue to provide a good experience even as demand increases.
+
+35
+00:02:41,000 --> 00:02:42,000
+So let's learn now.
+
+36
+00:02:42,000 --> 00:02:44,000
+Best practices for scalable code.
+
+37
+00:02:45,000 --> 00:02:52,000
+Creating scalable code means writing code that can handle rows and users data or traffic without sacrificing
+
+38
+00:02:52,000 --> 00:02:56,000
+performance or reliability like we just discussed.
+
+39
+00:02:57,000 --> 00:03:00,000
+Let's review some best practices to keep in mind.
+
+40
+00:03:01,000 --> 00:03:06,000
+Modular design break your code into smaller, reusable modules.
+
+41
+00:03:06,000 --> 00:03:11,000
+This makes it easier to understand, maintain, and scale.
+
+42
+00:03:11,000 --> 00:03:17,000
+Each module should have a single responsibility and be loosely coupled with others.
+
+43
+00:03:18,000 --> 00:03:25,000
+Efficient algorithms and data structures use algorithms and data structures that are efficient in terms
+
+44
+00:03:25,000 --> 00:03:28,000
+of time and space complexity.
+
+45
+00:03:28,000 --> 00:03:35,000
+This ensures that your code can handle larger data sets and perform well under increased load.
+
+46
+00:03:36,000 --> 00:03:38,000
+Optimized database queries.
+
+47
+00:03:39,000 --> 00:03:44,000
+Design database queries to be efficient and minimize the number of queries executed.
+
+48
+00:03:44,000 --> 00:03:50,000
+Use indexes, query optimization techniques and caching to improve database performance.
+
+49
+00:03:51,000 --> 00:03:56,000
+Implement caching to store frequently accessed data in memory.
+
+50
+00:03:56,000 --> 00:04:01,000
+This reduces the load on your database and improves response time.
+
+51
+00:04:01,000 --> 00:04:08,000
+Use caching solutions like Radius or Memcached to store and retrieve cached data efficiently.
+
+52
+00:04:09,000 --> 00:04:11,000
+Asynchronous processing.
+
+53
+00:04:12,000 --> 00:04:19,000
+Use asynchronous programming techniques to handle tasks that can be executed independently or in the
+
+54
+00:04:19,000 --> 00:04:19,000
+background.
+
+55
+00:04:19,000 --> 00:04:26,000
+This allows your application to continue serving requests without waiting for long running tasks to
+
+56
+00:04:26,000 --> 00:04:26,000
+complete.
+
+57
+00:04:27,000 --> 00:04:29,000
+Horizontal scaling.
+
+58
+00:04:29,000 --> 00:04:36,000
+Design your application to be horizontally scalable, meaning it can be deployed across multiple servers
+
+59
+00:04:36,000 --> 00:04:37,000
+or instances.
+
+60
+00:04:37,000 --> 00:04:43,000
+Use load balancers to distribute incoming traffic evenly across these instances.
+
+61
+00:04:44,000 --> 00:04:51,000
+Monitoring and logging, implement monitoring and logging to track the performance and health of your
+
+62
+00:04:51,000 --> 00:04:52,000
+application.
+
+63
+00:04:52,000 --> 00:05:01,000
+Use tools like Prometheus, Grafana, or Elk stack to monitor metrics and identify bottlenecks and troubleshoot
+
+64
+00:05:01,000 --> 00:05:02,000
+issues.
+
+65
+00:05:03,000 --> 00:05:06,000
+Ilhc stack stands for Elasticsearch.
+
+66
+00:05:06,000 --> 00:05:07,000
+Logstash.
+
+67
+00:05:07,000 --> 00:05:08,000
+Kibana.
+
+68
+00:05:09,000 --> 00:05:11,000
+Automated testing.
+
+69
+00:05:11,000 --> 00:05:16,000
+Write automated tests to ensure the reliability and correctness of your code.
+
+70
+00:05:16,000 --> 00:05:24,000
+Include unit tests, integration tests and performance tests in your testing strategy to catch issues
+
+71
+00:05:24,000 --> 00:05:26,000
+early and prevent regressions.
+
+72
+00:05:27,000 --> 00:05:29,000
+Continuous integration and deployment.
+
+73
+00:05:29,000 --> 00:05:35,000
+Set up a CI CD pipeline to automate the build, testing and deployment process.
+
+74
+00:05:35,000 --> 00:05:41,000
+This allows you to quickly iterate on your code, deploy updates safely, and scale your application
+
+75
+00:05:41,000 --> 00:05:42,000
+more efficiently.
+
+76
+00:05:43,000 --> 00:05:45,000
+Scalable infrastructure.
+
+77
+00:05:45,000 --> 00:05:50,000
+Choose a scalable infrastructure that can grow with your application.
+
+78
+00:05:50,000 --> 00:05:58,000
+Use cloud services like AWS, Google Cloud, or Azure to dynamically provision resources based on demand.
+
+79
+00:05:59,000 --> 00:06:05,000
+By following these best practices, you can write code that is scalable, maintainable, and capable
+
+80
+00:06:05,000 --> 00:06:10,000
+of handling rows without compromising performance or reliability.
+
+81
+00:06:11,000 --> 00:06:15,000
+And how we can identify and address scalability challenges.
+
+82
+00:06:16,000 --> 00:06:22,000
+It identifies scalability challenges is crucial for ensuring that your software can handle increased
+
+83
+00:06:22,000 --> 00:06:23,000
+demand.
+
+84
+00:06:23,000 --> 00:06:27,000
+Here are some common scalability challenges and how to address them.
+
+85
+00:06:28,000 --> 00:06:29,000
+Performance bottlenecks.
+
+86
+00:06:30,000 --> 00:06:34,000
+Identify areas of your application where performance is degrading under load.
+
+87
+00:06:35,000 --> 00:06:43,000
+This can be due to inefficient algorithms, slow database queries, or resource intensive operations.
+
+88
+00:06:43,000 --> 00:06:49,000
+Use profiling tools to pinpoint bottlenecks and optimize the code where necessary.
+
+89
+00:06:50,000 --> 00:06:57,000
+Profiling tools are software utilities used to analyze the performance of computer programs, typically
+
+90
+00:06:57,000 --> 00:07:04,000
+by measuring various aspects of their execution, such as CPU usage, memory usage, and function call
+
+91
+00:07:04,000 --> 00:07:05,000
+frequencies.
+
+92
+00:07:06,000 --> 00:07:09,000
+Let me share with you some examples of profilers.
+
+93
+00:07:09,000 --> 00:07:15,000
+CPU profilers like G and you gprof perf.
+
+94
+00:07:15,000 --> 00:07:16,000
+Visual studio profiler.
+
+95
+00:07:17,000 --> 00:07:18,000
+Memory profilers.
+
+96
+00:07:19,000 --> 00:07:20,000
+Valgrind.
+
+97
+00:07:20,000 --> 00:07:21,000
+Dot memory.
+
+98
+00:07:21,000 --> 00:07:21,000
+Xcode.
+
+99
+00:07:21,000 --> 00:07:22,000
+Instruments.
+
+100
+00:07:22,000 --> 00:07:26,000
+Profilers for web applications like Chrome DevTools.
+
+101
+00:07:26,000 --> 00:07:34,000
+Firefox profiler, and profilers for specific platforms like for example, Java profilers Java flight
+
+102
+00:07:34,000 --> 00:07:36,000
+recorder Visualvm.
+
+103
+00:07:37,000 --> 00:07:42,000
+In case you have any questions, please feel free to post your questions below the video and I will
+
+104
+00:07:42,000 --> 00:07:43,000
+be happy to answer.
+
+105
+00:07:44,000 --> 00:07:50,000
+The next scalability challenge to identify is database scaling issues.
+
+106
+00:07:50,000 --> 00:07:57,000
+As your application grows, your database may struggle to handle the increased volume of data and queries.
+
+107
+00:07:57,000 --> 00:08:04,000
+Consider strategies such as database sharding, replication, or using distributed databases to distribute
+
+108
+00:08:04,000 --> 00:08:07,000
+the workload across multiple nodes.
+
+109
+00:08:07,000 --> 00:08:09,000
+Single point of failure.
+
+110
+00:08:10,000 --> 00:08:16,000
+Identify any components of your system that represent single points of failure, such as single server
+
+111
+00:08:16,000 --> 00:08:22,000
+or service, that, if it fails, would bring down the entire system.
+
+112
+00:08:22,000 --> 00:08:29,000
+Implement redundancy and failover mechanisms to ensure high availability and reliability.
+
+113
+00:08:30,000 --> 00:08:32,000
+An efficient resource utilization.
+
+114
+00:08:32,000 --> 00:08:41,000
+Monitor resource usage across your system, including CPU, memory, disk, I, O, and network bandwidth.
+
+115
+00:08:42,000 --> 00:08:50,000
+Look for areas where resources are underutilized or over utilized and optimize resource allocation accordingly.
+
+116
+00:08:51,000 --> 00:08:57,000
+Consider using autoscaling to automatically adjust resource capacity based on demand.
+
+117
+00:08:58,000 --> 00:09:00,000
+Purely designed APIs.
+
+118
+00:09:00,000 --> 00:09:08,000
+If your APIs are not designed for scalability, they can become a bottleneck as traffic increases.
+
+119
+00:09:08,000 --> 00:09:14,000
+Design your APIs to be efficient, stateless, and horizontally scalable.
+
+120
+00:09:14,000 --> 00:09:21,000
+Use techniques such as caching, rate limiting, and pagination to improve performance and reliability.
+
+121
+00:09:22,000 --> 00:09:25,000
+Data consistency and replication.
+
+122
+00:09:25,000 --> 00:09:31,000
+Maintaining data consistency across distributed systems can be challenging.
+
+123
+00:09:31,000 --> 00:09:39,000
+Choose an appropriate consistency model for your application, such as eventual consistency or strong
+
+124
+00:09:39,000 --> 00:09:46,000
+consistency, and implement replication and synchronization mechanisms to ensure data integrity.
+
+125
+00:09:46,000 --> 00:09:48,000
+Communication overhead.
+
+126
+00:09:48,000 --> 00:09:54,000
+As your system scales, communication between components can become a bottleneck.
+
+127
+00:09:54,000 --> 00:10:01,000
+Minimize unnecessary communication and consider using asynchronous messaging or event driven architectures
+
+128
+00:10:01,000 --> 00:10:05,000
+to decouple components and improve scalability.
+
+129
+00:10:06,000 --> 00:10:13,000
+Inadequate testing and monitoring ensure that your testing and monitoring practices are robust enough
+
+130
+00:10:13,000 --> 00:10:16,000
+to detect scalability issues before they impact users.
+
+131
+00:10:17,000 --> 00:10:24,000
+Perform load testing to simulate high traffic scenarios, and monitor key performance metrics to identify
+
+132
+00:10:24,000 --> 00:10:26,000
+and address scalability challenges proactively.
+
+133
+00:10:27,000 --> 00:10:33,000
+By proactively identifying and addressing scalability challenges, you can ensure that your software
+
+134
+00:10:33,000 --> 00:10:39,000
+can scale effectively to meet the needs of your users as your application grows.
+
+135
+00:10:40,000 --> 00:10:45,000
+Is it possible for us to identify scalability challenges during code review and how?
+
+136
+00:10:46,000 --> 00:10:53,000
+During a code review, it's essential to keep an eye out for potential scalability challenges that could
+
+137
+00:10:53,000 --> 00:10:56,000
+affect the performance and scalability of the software.
+
+138
+00:10:57,000 --> 00:11:01,000
+Let's review some things to look for during the code review.
+
+139
+00:11:02,000 --> 00:11:05,000
+Resource intensive operations.
+
+140
+00:11:05,000 --> 00:11:13,000
+Check for any operations that could be resource intensive, such as nested loops, excessive memory
+
+141
+00:11:13,000 --> 00:11:16,000
+allocations, or inefficient algorithms.
+
+142
+00:11:16,000 --> 00:11:23,000
+This can lead to poor performance and scalability issues, especially as the volume of data or traffic
+
+143
+00:11:23,000 --> 00:11:24,000
+increases.
+
+144
+00:11:24,000 --> 00:11:26,000
+Database queries.
+
+145
+00:11:27,000 --> 00:11:32,000
+Review database queries to ensure they are optimized and indexed properly.
+
+146
+00:11:32,000 --> 00:11:39,000
+Look for queries that retrieve large amounts of data or perform unnecessary joins or calculations.
+
+147
+00:11:39,000 --> 00:11:47,000
+Suggest improvements such as adding indexes, optimizing query logic, or using caching where appropriate.
+
+148
+00:11:48,000 --> 00:11:50,000
+Concurrency and parallelism.
+
+149
+00:11:51,000 --> 00:11:56,000
+Evaluate how the code handles concurrent requests and parallel processing.
+
+150
+00:11:56,000 --> 00:12:03,000
+Look for potential race conditions that locks or bottlenecks in synchronization mechanisms.
+
+151
+00:12:03,000 --> 00:12:11,000
+Ensure that code is designed to scale horizontally by utilizing asynchronous processing and non-blocking
+
+152
+00:12:11,000 --> 00:12:13,000
+input output, where applicable.
+
+153
+00:12:14,000 --> 00:12:21,000
+Scalability patterns assess whether the code follows established scalability patterns and best practices
+
+154
+00:12:21,000 --> 00:12:26,000
+such as load balancing, caching, sharding, or partitioning.
+
+155
+00:12:26,000 --> 00:12:33,000
+Look for opportunities to improve scalability by decoupling components, implementing distributed architectures,
+
+156
+00:12:33,000 --> 00:12:36,000
+or using scalable data storage solutions.
+
+157
+00:12:36,000 --> 00:12:38,000
+Resource management.
+
+158
+00:12:38,000 --> 00:12:44,000
+Check how the code manages resources such as memory connections and threads.
+
+159
+00:12:44,000 --> 00:12:50,000
+Look for potential leaks or inefficiencies in resource allocation and deallocation.
+
+160
+00:12:51,000 --> 00:12:58,000
+Ensures that resources are released promptly to prevent resource exhaustion and degradation of performance
+
+161
+00:12:58,000 --> 00:12:59,000
+over time.
+
+162
+00:13:00,000 --> 00:13:03,000
+Monitoring and instrumentation.
+
+163
+00:13:03,000 --> 00:13:10,000
+Evaluate whether the code includes adequate monitoring and instrumentation for tracking performance
+
+164
+00:13:10,000 --> 00:13:13,000
+metrics and identifying scalability issues.
+
+165
+00:13:13,000 --> 00:13:20,000
+Look for logging statements, error handling, and metrics collection mechanisms that provide insights
+
+166
+00:13:20,000 --> 00:13:23,000
+into the behavior of the system under load.
+
+167
+00:13:24,000 --> 00:13:26,000
+Input, validation and sanitization.
+
+168
+00:13:27,000 --> 00:13:33,000
+Verify that the code properly validates and sanitizes user input to prevent security vulnerabilities
+
+169
+00:13:33,000 --> 00:13:36,000
+and denial of service attacks.
+
+170
+00:13:37,000 --> 00:13:43,000
+Inadequate input validation can lead to performance degradation or system instability under certain
+
+171
+00:13:43,000 --> 00:13:44,000
+conditions.
+
+172
+00:13:45,000 --> 00:13:52,000
+Documentation and comments ensures that the code is well documented and includes comments that explain
+
+173
+00:13:52,000 --> 00:13:57,000
+the rationale behind design decisions and potential scalability considerations.
+
+174
+00:13:58,000 --> 00:14:04,000
+Look for documentation on performance characteristics, scalability limitations, and recommended tuning
+
+175
+00:14:04,000 --> 00:14:05,000
+parameters.
+
+176
+00:14:06,000 --> 00:14:12,000
+By actively looking for these scalability challenges during code review, you can help identify potential
+
+177
+00:14:12,000 --> 00:14:18,000
+issues early in the development process and ensure that the software is designed and implemented to
+
+178
+00:14:18,000 --> 00:14:21,000
+scale effectively as the demand grows.
+
+179
+00:14:22,000 --> 00:14:24,000
+That's all what I wanted to review with you today.
+
+180
+00:14:24,000 --> 00:14:28,000
+In this lesson, let's recap what we have learned today.
+
+181
+00:14:29,000 --> 00:14:32,000
+We learned what scalability and software development means.
+
+182
+00:14:32,000 --> 00:14:35,000
+I explained best practices for scalable code.
+
+183
+00:14:36,000 --> 00:14:42,000
+Also, now you know how to identify and address scalability challenges in your code.
+
+184
+00:14:42,000 --> 00:14:48,000
+And we learned how to identify scalability challenges on early stages during the code review.
+
+185
+00:14:49,000 --> 00:14:50,000
+That's all for this lesson.
+
+186
+00:14:51,000 --> 00:14:52,000
+Thanks a lot for your attention.
+
+187
+00:14:52,000 --> 00:14:56,000
+Have a great day and see you in the next lesson.
+

109 - Advanced Code Review Strategies/external-links.txt

@@ -0,0 +1,6 @@
+
+001 All-documents-shared-in-the-lesson
+https://drive.google.com/drive/folders/174RXHMxjVbVNg4DSQ7nxOQAK4I5StLdp?usp=sharing
+
+002 Coding-Standards-and-Guidelines
+https://drive.google.com/file/d/1q0-V9_574YNKpCB9W_UZm9F8Vk5sYZuR/view?usp=sharing

11 - Enumerations in Java/001 Enumerations in Java_en.srt

@@ -0,0 +1,495 @@
+1
+00:00:00,000 --> 00:00:03,000
+Hello team, In this lesson we 
+will learn what enumerations are and 
+
+2
+00:00:03,000 --> 00:00:06,000
+how we can use them in 
+Java. We are also going to 
+
+3
+00:00:06,000 --> 00:00:10,000
+discuss how to declare enum and 
+how we can compare them. I 
+
+4
+00:00:10,000 --> 00:00:13,000
+will show you how enums can 
+have properties and custom methods. But 
+
+5
+00:00:13,000 --> 00:00:17,000
+first of all – what is 
+Enum type? An enum type is 
+
+6
+00:00:17,000 --> 00:00:20,000
+a special data type that enables 
+for a variable to be a 
+
+7
+00:00:20,000 --> 00:00:24,000
+set of predefined constants. The variable 
+of enum type always must be 
+
+8
+00:00:24,000 --> 00:00:28,000
+equal to one of the values 
+that have been predefined for it. 
+
+9
+00:00:28,000 --> 00:00:32,000
+When do we need enum types? 
+We need enum types to express 
+
+10
+00:00:32,000 --> 00:00:36,000
+some set of values that are 
+not infinite. You need to use 
+
+11
+00:00:36,000 --> 00:00:40,000
+enum for data sets where you 
+know all possible values at compile 
+
+12
+00:00:40,000 --> 00:00:46,000
+time. For example, seasons of the 
+year – WINTER, SPRING, SUMMER, FALL. 
+
+13
+00:00:46,000 --> 00:00:48,000
+There are very low chances that 
+you will need to add additional 
+
+14
+00:00:48,000 --> 00:00:53,000
+seasons in your program because no 
+other exists. Or let’s review real 
+
+15
+00:00:53,000 --> 00:00:57,000
+life scenario: together with students we 
+implemented simple truth or dare game 
+
+16
+00:00:57,000 --> 00:01:01,000
+for android. There are thousands of 
+cards in the game. Each card 
+
+17
+00:01:01,000 --> 00:01:05,000
+has its type and it can 
+be either TRUTH or DARE. So, 
+
+18
+00:01:05,000 --> 00:01:11,000
+in our program CardType will be 
+enumeration. Does it make sense? To 
+
+19
+00:01:11,000 --> 00:01:15,000
+make it clearer - let’s take 
+a look at examples. To create 
+
+20
+00:01:15,000 --> 00:01:19,000
+Enum make mouse right click on 
+the package and select Enum. Here 
+
+21
+00:01:19,000 --> 00:01:24,000
+you can specify Enum name and 
+package. I’ve already created Enums to 
+
+22
+00:01:24,000 --> 00:01:29,000
+save our time during the lesson. 
+Here I have ‘Priority’ enum type. 
+
+23
+00:01:29,000 --> 00:01:33,000
+In my program I’m going to 
+have only three types of priority, 
+
+24
+00:01:33,000 --> 00:01:37,000
+they are: high, medium, and low. 
+I want to draw your attention 
+
+25
+00:01:37,000 --> 00:01:41,000
+to the code style. Taking 
+into account that all enum values 
+
+26
+00:01:41,000 --> 00:01:45,000
+are constant we use capital letters 
+according to java naming convention. Let’s 
+
+27
+00:01:45,000 --> 00:01:49,000
+take a look how I use 
+this enum. I can declare variable 
+
+28
+00:01:49,000 --> 00:01:54,000
+of type Priority. As I mentioned 
+before - the variable of enum 
+
+29
+00:01:54,000 --> 00:01:57,000
+type always must be equal to 
+one of the values that have 
+
+30
+00:01:57,000 --> 00:02:01,000
+been predefined for it. You remember 
+that one of the data types 
+
+31
+00:02:01,000 --> 00:02:04,000
+that can be used in switch 
+statement – is enum type. And 
+
+32
+00:02:04,000 --> 00:02:08,000
+here is how you can use 
+it. Based on the value of 
+
+33
+00:02:08,000 --> 00:02:13,000
+‘priority’ variable during the runtime, different 
+case block will be executed. In 
+
+34
+00:02:13,000 --> 00:02:17,000
+this particular case when the value 
+of our priority variable is HIGH 
+
+35
+00:02:17,000 --> 00:02:20,000
+– this block will be executed. 
+So now you know how to 
+
+36
+00:02:20,000 --> 00:02:24,000
+declare custom enum type and how 
+to create variable of enum type 
+
+37
+00:02:24,000 --> 00:02:27,000
+to use it in the program. 
+Let’s move on. One more option 
+
+38
+00:02:27,000 --> 00:02:32,000
+to initialize enum variable. Let’s pretend 
+you are dealing with user input 
+
+39
+00:02:32,000 --> 00:02:35,000
+and you need to create enum 
+based on the user input. You 
+
+40
+00:02:35,000 --> 00:02:40,000
+can use ‘valueOf’ method to initialize 
+enum variable. Just use enum type 
+
+41
+00:02:40,000 --> 00:02:44,000
+name, call valueOf method and pass 
+string to this method. In case 
+
+42
+00:02:44,000 --> 00:02:48,000
+there are no enum value for 
+the string you entered – IllegalArgumentException 
+
+43
+00:02:48,000 --> 00:02:53,000
+will be thrown. You see when 
+I pass ‘high’ in lowercase exception 
+
+44
+00:02:53,000 --> 00:02:57,000
+is thrown. Take this into consideration 
+while doing your homework. To compare 
+
+45
+00:02:57,000 --> 00:03:02,000
+enumerations, you can use ‘equals to’ 
+operator. And again, you remember that 
+
+46
+00:03:02,000 --> 00:03:07,000
+Enumeration is not primitive type of 
+data. Thus, you might think that 
+
+47
+00:03:07,000 --> 00:03:12,000
+you should use ‘equals’ method to 
+compare enums. Not necessarily. For example, 
+
+48
+00:03:12,000 --> 00:03:15,000
+in this case we will get 
+false as expected. And in this 
+
+49
+00:03:15,000 --> 00:03:20,000
+case, we will get true as 
+expected. Why? Because each enum variable 
+
+50
+00:03:20,000 --> 00:03:23,000
+has its own ordinal. Take a 
+look here one more time: you 
+
+51
+00:03:23,000 --> 00:03:27,000
+have set of values which are 
+known during the compilation. And they 
+
+52
+00:03:27,000 --> 00:03:31,000
+are listed in the strict sequence. 
+The HIGH has zero ordinal, the 
+
+53
+00:03:31,000 --> 00:03:36,000
+MEDIUM - one and the LOW 
+- two. Taking into account each 
+
+54
+00:03:36,000 --> 00:03:40,000
+enum value has its own ordinal 
+we can easily compare them via 
+
+55
+00:03:40,000 --> 00:03:44,000
+‘equals to’ operator. You can use 
+‘ordinal()’ method to get ordinal of 
+
+56
+00:03:44,000 --> 00:03:48,000
+each enum value. In some cases 
+you might want to iterate over 
+
+57
+00:03:48,000 --> 00:03:53,000
+all values from specific enum type. 
+Just be aware that each enum 
+
+58
+00:03:53,000 --> 00:03:58,000
+type has ‘values()’ method that returns 
+array of enum values. You can 
+
+59
+00:03:58,000 --> 00:04:02,000
+iterate over this array as you 
+wish. You already know all 
+
+60
+00:04:02,000 --> 00:04:07,000
+iteration statements in Java. And now 
+probably the most interesting part. Each 
+
+61
+00:04:07,000 --> 00:04:11,000
+enum value may have its own 
+properties and methods. Let’s take a 
+
+62
+00:04:11,000 --> 00:04:15,000
+look at this ‘Month’ enum type. 
+We have next values: January, February, 
+
+63
+00:04:15,000 --> 00:04:20,000
+March and so on. The list 
+of constants is always terminated by 
+
+64
+00:04:20,000 --> 00:04:24,000
+a semicolon. Definition of properties and 
+methods always should go after the 
+
+65
+00:04:24,000 --> 00:04:29,000
+list of constants. And here I 
+declared a property – daysAmount. Each 
+
+66
+00:04:29,000 --> 00:04:34,000
+of these months should have this 
+property of int type. After that 
+
+67
+00:04:34,000 --> 00:04:38,000
+I declare special method to create 
+each enum. This special method is 
+
+68
+00:04:38,000 --> 00:04:43,000
+called ‘constructor’. It is used to 
+construct objects. Very soon we will 
+
+69
+00:04:43,000 --> 00:04:47,000
+get to the object-oriented programming and 
+I will explain you in detail 
+
+70
+00:04:47,000 --> 00:04:51,000
+what constructor is. Also ignore this 
+‘private’ modifiers as of now, we 
+
+71
+00:04:51,000 --> 00:04:55,000
+will discuss them during the OOP 
+topic when we will talk about 
+
+72
+00:04:55,000 --> 00:04:59,000
+encapsulation. Here you can see that 
+I can pass int value to 
+
+73
+00:04:59,000 --> 00:05:05,000
+constructor, and after I passed this 
+value, I initialize ‘daysAmount’ property for 
+
+74
+00:05:05,000 --> 00:05:11,000
+each enum. Here in parentheses I 
+call constructor and pass int. Similar 
+
+75
+00:05:11,000 --> 00:05:15,000
+to the method call, I call 
+constructor and pass value to it. 
+
+76
+00:05:15,000 --> 00:05:20,000
+So, for January, I pass thirty-one 
+and daysAmount is initialized with thirty-one. 
+
+77
+00:05:20,000 --> 00:05:24,000
+And you see ‘this’ keyword. This 
+is new to you. That means 
+
+78
+00:05:24,000 --> 00:05:30,000
+for THIS enum, in this specific 
+case for JANUARY, the daysAmount will 
+
+79
+00:05:30,000 --> 00:05:34,000
+be equal to thirty-one. And you 
+see that local variable name is 
+
+80
+00:05:34,000 --> 00:05:42,000
+also ‘daysAmount’. But ‘this.daysAmount’ and method 
+argument ‘daysAmount’ are different variables. Because 
+
+81
+00:05:42,000 --> 00:05:50,000
+‘this.daysAmount’ is this variable and ‘daysAmount’ 
+is just this local variable.  
+
+82
+00:05:50,000 --> 00:05:53,000
+For February I 
+pass twenty-eight, and daysAmount is initialized 
+
+83
+00:05:53,000 --> 00:05:59,000
+with twenty-eight value. For THIS enum, 
+days amount will be twenty-eight. Then, 
+
+84
+00:05:59,000 --> 00:06:03,000
+I can declare that each enum 
+has its own behavior. Namely: each 
+
+85
+00:06:03,000 --> 00:06:08,000
+month can tell me how many 
+days it has. ‘this’ keyword means 
+
+86
+00:06:08,000 --> 00:06:13,000
+THIS particular month. It can be 
+January, February, March or any other. 
+
+87
+00:06:13,000 --> 00:06:17,000
+Let’s take a look how we 
+can use properties and methods of 
+
+88
+00:06:17,000 --> 00:06:21,000
+Enum constants. We can call method 
+getDaysAmount for January enum variable. And 
+
+89
+00:06:21,000 --> 00:06:26,000
+for THIS month, for January, this 
+is thirty-one. Hope it is clear 
+
+90
+00:06:26,000 --> 00:06:30,000
+now. That’s it. Let’s take a 
+look at what we have learned 
+
+91
+00:06:30,000 --> 00:06:35,000
+from this lesson. From this lesson 
+we learned what enum types are. 
+
+92
+00:06:35,000 --> 00:06:40,000
+We can initialize enum variables, know how 
+to compare them. Also we learned how 
+
+93
+00:06:40,000 --> 00:06:44,000
+to iterate over all constants of 
+specific enum type and learned that 
+
+94
+00:06:44,000 --> 00:06:48,000
+enum type can have custom properties and 
+methods. Now you know everything you need 
+
+95
+00:06:48,000 --> 00:06:52,000
+to know to complete your homework. 
+Let’s take a look at the 
+
+96
+00:06:52,000 --> 00:06:57,000
+task. You need to implement simple console 
+application with two enums. Try to implement 
+
+97
+00:06:57,000 --> 00:07:01,000
+it by yourself and after that 
+take a look at my solution. 
+
+98
+00:07:01,000 --> 00:07:04,000
+And as always – you are welcome 
+to ask questions in case you have 
+
+99
+00:07:04,000 --> 00:07:08,000
+any. Thank you for your attention. 
+See you in the next lesson. 
+

11 - Enumerations in Java/001 Homework.url

@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://docs.google.com/document/d/1I8amzWwGUOKDJRz_x857qYd76wpJKz1WmQlUnsgcj3M/edit?usp=sharing

11 - Enumerations in Java/001 Solution-Message-type-priority.url

@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/learnit_java_core/tree/master/src/com/itbulls/learnit/javacore/enumerations/hw

11 - Enumerations in Java/001 Source-code-of-the-example-used-in-the-lesson.url

@@ -0,0 +1,2 @@
+[InternetShortcut]
+URL=https://github.com/AndriiPiatakha/learnit_java_core/tree/master/src/com/itbulls/learnit/javacore/enumerations

11 - Enumerations in Java/external-links.txt

@@ -0,0 +1,9 @@
+
+001 Homework
+https://docs.google.com/document/d/1I8amzWwGUOKDJRz_x857qYd76wpJKz1WmQlUnsgcj3M/edit?usp=sharing
+
+001 Source-code-of-the-example-used-in-the-lesson
+https://github.com/AndriiPiatakha/learnit_java_core/tree/master/src/com/itbulls/learnit/javacore/enumerations
+
+001 Solution-Message-type-priority
+https://github.com/AndriiPiatakha/learnit_java_core/tree/master/src/com/itbulls/learnit/javacore/enumerations/hw

110 - Metrics & KPIs to Monitor and Control Software Development Process/001 Why this section is in this course and why it is important.html

@@ -0,0 +1,69 @@
+<!DOCTYPE html>
+<html lang="en">
+    <head>
+        <meta charset="UTF-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+        <title>Why this section is in this course and why it is important</title>
+
+        <style>
+            * {
+                box-sizing: border-box;
+                margin: 0;
+                padding: 0;
+            }
+            body {
+                font-family: var(--font-stack-text);
+                font-weight: 400;
+                line-height: 1.4;
+                font-size: 1.6rem;
+                color: #2d2f31;
+            }
+            .container {
+                position: relative;
+                height: 100%;
+                overflow-y: auto;
+            }
+            .content {
+                padding: 3.2rem 4.8rem;
+                word-break: break-word;
+                max-width: 69.6rem;
+                margin: 0 auto;
+            }
+            .heading {
+                margin-bottom: 24px;
+                font-family: -apple-system, BlinkMacSystemFont, Roboto, "Segoe UI", Helvetica, Arial, sans-serif,
+                    "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
+                font-weight: 700;
+                line-height: 1.2;
+                letter-spacing: 0;
+                font-size: 32px;
+                max-width: 36em;
+            }
+            .article-asset-container {
+                padding: 2.4rem;
+            }
+            .article-asset-container p {
+                font-size: 19px;
+            }
+            code {
+                background-color: #fff;
+                border: 1px solid #d1d7dc;
+                color: #b4690e;
+                font-size: 80%;
+                padding: 0.2rem 0.4rem;
+                font-family: sfmono-regular, Consolas, liberation mono, Menlo, Courier, monospace;
+            }
+            p {
+                font-weight: 400;
+            }
+        </style>
+    </head>
+    <body>
+        <div class="container">
+            <div class="content">
+                <div class="heading">Why this section is in this course and why it is important</div>
+                <div class="article-asset-container"><p>This section is included in the course for Software Developers, Senior Software Engineers, Technical Leads, and Software Architects to emphasize the significance of metrics, Key Performance Indicators (KPIs), and Objectives and Key Results (OKR) in the software development lifecycle. Understanding and using these metrics is crucial for effective project management and continuous improvement.</p><p>Metrics provide measurable insights into various aspects of software development, such as the efficiency of the development process, the quality of the code, and the effectiveness of testing. By delving into software development, build, release, and QA metrics, professionals can gain a comprehensive understanding of the entire development pipeline.</p><p>For Technical Leads and Software Architects, these metrics aid in making informed decisions about architectural choices, resource allocation, and overall project planning. Senior Software Engineers and Software Developers can use metrics to assess the impact of their code changes, identify areas for optimization, and ensure the overall health of the software.</p><p>Incorporating KPIs and OKRs into the discussion highlights the importance of aligning individual and team goals with the broader organizational objectives. This alignment fosters a more strategic approach to software development, ensuring that efforts contribute to the overall success of the business.</p><p>This section is also crucial for Software Developers, Senior Software Engineers, Technical Leads, and Software Architects as it emphasizes the importance of metrics, Key Performance Indicators (KPIs), and Objectives and Key Results (OKR) in scaling software development without compromising quality.</p><p>As teams and projects grow, maintaining the same level of quality becomes challenging. Metrics play a vital role in managing scalability by providing insights into performance bottlenecks, resource utilization, and potential areas of improvement. Learning how to use metrics effectively enables professionals to identify and address issues that may arise as the scope and complexity of projects increase.</p><p>For Technical Leads and Software Architects, understanding these metrics is instrumental in designing scalable architectures and making informed decisions about infrastructure and technology choices. Senior Software Engineers and Software Developers benefit by optimizing their code and development processes to ensure scalability without sacrificing code quality.</p><p>In conclusion, this section is essential for professionals at different levels as it equips them with the knowledge and tools needed to measure, analyze, and improve key aspects of the software development process, ultimately leading to more efficient and successful projects.</p></div>
+            </div>
+        </div>
+    </body>
+</html>

110 - Metrics & KPIs to Monitor and Control Software Development Process/002 Metric, KPI & OKR_en.srt

@@ -0,0 +1,1224 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello team!
+
+2
+00:00:06,000 --> 00:00:11,000
+Today we are going to have interesting and very important lesson because today we are going to learn
+
+3
+00:00:11,000 --> 00:00:16,000
+such key concepts as metrics, KPIs and OKRs.
+
+4
+00:00:17,000 --> 00:00:21,000
+We are going to start the lesson from learning what a metric is.
+
+5
+00:00:21,000 --> 00:00:28,000
+To understand the concept better, we will discuss examples of metrics and use cases when it is recommended
+
+6
+00:00:28,000 --> 00:00:32,000
+to use metrics in the similar way, I will explain KPIs.
+
+7
+00:00:32,000 --> 00:00:36,000
+We'll review KPI examples together with use cases.
+
+8
+00:00:36,000 --> 00:00:42,000
+When it is recommended to use KPIs, then we'll compare metrics and KPIs.
+
+9
+00:00:42,000 --> 00:00:46,000
+This will help you to understand better the difference between these concepts.
+
+10
+00:00:47,000 --> 00:00:50,000
+After that we will learn what OKR is.
+
+11
+00:00:50,000 --> 00:00:57,000
+We'll review examples and use cases and at the end of the lesson we'll compare KPI and OKR.
+
+12
+00:00:58,000 --> 00:00:59,000
+Let's start our lesson.
+
+13
+00:01:00,000 --> 00:01:04,000
+Let's start from learning the definition of a metric in project management.
+
+14
+00:01:04,000 --> 00:01:11,000
+A metric is a measure used to assess and track various aspects of project's progress, performance,
+
+15
+00:01:11,000 --> 00:01:12,000
+and success.
+
+16
+00:01:12,000 --> 00:01:20,000
+Metrics provide quantifiable data that helps project managers and teams measure how well a project is,
+
+17
+00:01:20,000 --> 00:01:22,000
+meeting its objectives and staying on schedule.
+
+18
+00:01:23,000 --> 00:01:29,000
+Common project management metrics include completion time, budget adherence, resource utilization,
+
+19
+00:01:29,000 --> 00:01:32,000
+task completion rates, and others.
+
+20
+00:01:32,000 --> 00:01:35,000
+We are going to learn more of them during the course.
+
+21
+00:01:35,000 --> 00:01:42,000
+Using metrics helps in making informed decisions, identifying areas for improvement, and ensuring
+
+22
+00:01:42,000 --> 00:01:46,000
+that the project aligns with its goals.
+
+23
+00:01:46,000 --> 00:01:50,000
+To understand it better, let's review some examples of metrics.
+
+24
+00:01:51,000 --> 00:01:53,000
+Budget adherence.
+
+25
+00:01:53,000 --> 00:01:55,000
+The metric can sound like this.
+
+26
+00:01:55,000 --> 00:02:00,000
+Percentage of the budget used compared to the planned budget.
+
+27
+00:02:01,000 --> 00:02:08,000
+Thus completion rate percentage of completed tasks compared to the total number of tasks.
+
+28
+00:02:08,000 --> 00:02:10,000
+Defect density.
+
+29
+00:02:10,000 --> 00:02:17,000
+Number of defects or errors per unit of work, for example per line of code or per user story.
+
+30
+00:02:17,000 --> 00:02:23,000
+And what a user story is we are going to learn in other lessons, but in short, this is unit of work
+
+31
+00:02:23,000 --> 00:02:25,000
+the delivery team works on.
+
+32
+00:02:26,000 --> 00:02:29,000
+For scope changes, you can introduce the following metric.
+
+33
+00:02:29,000 --> 00:02:33,000
+Number of changes or additions to the project scope.
+
+34
+00:02:33,000 --> 00:02:36,000
+It can be evaluated in different measurement units.
+
+35
+00:02:36,000 --> 00:02:38,000
+Hours added.
+
+36
+00:02:38,000 --> 00:02:40,000
+Amount of tasks added.
+
+37
+00:02:40,000 --> 00:02:46,000
+If your team used scrum methodology, then you can evaluate scope changes in story points amount.
+
+38
+00:02:46,000 --> 00:02:53,000
+Later we will learn that story points are relative measurement of complexity that is used in scrum methodology.
+
+39
+00:02:54,000 --> 00:02:58,000
+Of course, there are much more metrics than I've just listed.
+
+40
+00:02:58,000 --> 00:03:04,000
+I will share with you my metrics libraries that help me deliver projects with investments of millions
+
+41
+00:03:04,000 --> 00:03:05,000
+of American dollars.
+
+42
+00:03:05,000 --> 00:03:09,000
+And you will learn all those metrics in this course.
+
+43
+00:03:09,000 --> 00:03:11,000
+These are just examples.
+
+44
+00:03:11,000 --> 00:03:14,000
+In order, you could understand what a metric is.
+
+45
+00:03:14,000 --> 00:03:16,000
+When to use metrics.
+
+46
+00:03:16,000 --> 00:03:23,000
+Metrics and project management are typically used throughout the project life cycle to assess progress,
+
+47
+00:03:23,000 --> 00:03:28,000
+identify areas for improvement, and ensure that the project stays on track.
+
+48
+00:03:28,000 --> 00:03:35,000
+I can provide you just some examples and use cases when you have to use metrics, but of course it is
+
+49
+00:03:35,000 --> 00:03:42,000
+hard to name all variety of use cases when to use metrics and will learn more use cases during the course.
+
+50
+00:03:43,000 --> 00:03:44,000
+Project planning.
+
+51
+00:03:44,000 --> 00:03:48,000
+Use metrics during the planning phase to set realistic goals.
+
+52
+00:03:48,000 --> 00:03:53,000
+Define project objectives and establish baselines for performance measurement.
+
+53
+00:03:54,000 --> 00:03:55,000
+Project Kickoff.
+
+54
+00:03:55,000 --> 00:04:02,000
+Implement metrics at the start of the project to establish a baseline for the key performance indicators,
+
+55
+00:04:02,000 --> 00:04:05,000
+and provide a clear starting point for measurement.
+
+56
+00:04:06,000 --> 00:04:11,000
+What key performance indicators are we will learn later in this lesson.
+
+57
+00:04:11,000 --> 00:04:13,000
+Regular monitoring.
+
+58
+00:04:13,000 --> 00:04:20,000
+Continuously use metrics during the execution phase to monitor project progress, track resource utilization
+
+59
+00:04:20,000 --> 00:04:24,000
+and identify any deviations from the plan.
+
+60
+00:04:25,000 --> 00:04:26,000
+Performance assessment.
+
+61
+00:04:26,000 --> 00:04:32,000
+Utilize metrics for ongoing performance assessments to evaluate whether the project is meeting its objectives.
+
+62
+00:04:32,000 --> 00:04:36,000
+Staying within budget and adhering to the schedule.
+
+63
+00:04:37,000 --> 00:04:38,000
+Issue identification.
+
+64
+00:04:38,000 --> 00:04:45,000
+Metrics are valuable for identifying and addressing issues promptly, allowing the project team to take
+
+65
+00:04:45,000 --> 00:04:48,000
+corrective actions before they escalate.
+
+66
+00:04:48,000 --> 00:04:56,000
+Being a project manager, it is similar to being a pilot in plain and metrics are your panel board that
+
+67
+00:04:56,000 --> 00:04:59,000
+gives you information about the flight.
+
+68
+00:04:59,000 --> 00:05:07,000
+Decision making metrics provide data driven insights that help in informed decision making.
+
+69
+00:05:07,000 --> 00:05:14,000
+Use them when making adjustments to the project plan or when deciding on resource allocations.
+
+70
+00:05:15,000 --> 00:05:19,000
+Post implementation evaluation after project completion.
+
+71
+00:05:19,000 --> 00:05:24,000
+Analyze metrics to conduct a comprehensive Post implementation evaluation.
+
+72
+00:05:24,000 --> 00:05:30,000
+This helps in identifying lessons learned and areas for improvement in future projects.
+
+73
+00:05:30,000 --> 00:05:37,000
+Continuous improvement use metrics as part of continuous improvement process, using feedback and data
+
+74
+00:05:37,000 --> 00:05:42,000
+from previous projects to refine project management processes and strategies.
+
+75
+00:05:42,000 --> 00:05:49,000
+Communication metrics can be useful in communicating project status and performance to stakeholders,
+
+76
+00:05:49,000 --> 00:05:52,000
+team members, and other relevant parties.
+
+77
+00:05:53,000 --> 00:06:00,000
+During my course for project managers, I also teach students how to build efficient reports and specific
+
+78
+00:06:00,000 --> 00:06:04,000
+data and measurements are always better than thousands of words.
+
+79
+00:06:05,000 --> 00:06:11,000
+Project closure evaluate metrics during the project closure phase to assess overall success.
+
+80
+00:06:11,000 --> 00:06:15,000
+Identify achievements and gather insights for future projects.
+
+81
+00:06:16,000 --> 00:06:22,000
+Using metrics at these various stages ensures a proactive approach to project management, enabling
+
+82
+00:06:22,000 --> 00:06:29,000
+teams to address issues early on, making informed decisions and continuously improve project delivery
+
+83
+00:06:29,000 --> 00:06:30,000
+processes.
+
+84
+00:06:31,000 --> 00:06:35,000
+So let's sum it up and answer question what a metric is.
+
+85
+00:06:35,000 --> 00:06:38,000
+A metric is nothing more than a value.
+
+86
+00:06:38,000 --> 00:06:43,000
+And as you saw an example, we can measure different aspects of our project.
+
+87
+00:06:43,000 --> 00:06:50,000
+The smart measurement of metrics and knowing what you need to measure and when will give you enough
+
+88
+00:06:50,000 --> 00:06:54,000
+information to make data driven decisions.
+
+89
+00:06:54,000 --> 00:06:58,000
+But metric itself wouldn't tell you whether it is good or bad.
+
+90
+00:06:58,000 --> 00:07:02,000
+For example, 80% task completion rate.
+
+91
+00:07:02,000 --> 00:07:03,000
+Is it good or bad?
+
+92
+00:07:03,000 --> 00:07:09,000
+Try to answer this question or scope change plus 40 hours added to our scope.
+
+93
+00:07:09,000 --> 00:07:11,000
+Is it good or bad?
+
+94
+00:07:11,000 --> 00:07:17,000
+We can have five software engineers in team, or we can have 50 software engineers in team.
+
+95
+00:07:17,000 --> 00:07:22,000
+Depending on this, 40 hours will make different impact on our roadmap.
+
+96
+00:07:22,000 --> 00:07:28,000
+Right metric will not answer this question because metric is just a value.
+
+97
+00:07:28,000 --> 00:07:32,000
+Let's continue and learn how to answer these questions.
+
+98
+00:07:32,000 --> 00:07:36,000
+So let me explain you what a KPI is.
+
+99
+00:07:36,000 --> 00:07:41,000
+In project management, KPI stands for Key Performance Indicator.
+
+100
+00:07:42,000 --> 00:07:49,000
+KPIs are specific type of performance measurement that are used to measure and evaluate the performance
+
+101
+00:07:49,000 --> 00:07:52,000
+of a project in achieving its objectives.
+
+102
+00:07:52,000 --> 00:07:58,000
+These indicators are crucial for assessing the success and effectiveness of a project.
+
+103
+00:07:59,000 --> 00:08:06,000
+KPIs help project managers and teams to focus on the most critical aspects of a project, enabling them
+
+104
+00:08:06,000 --> 00:08:12,000
+to monitor progress, make informed decisions, and take corrective actions when necessary.
+
+105
+00:08:13,000 --> 00:08:19,000
+These indicators are aligned with project goals and provide a clear picture of whether the project is
+
+106
+00:08:19,000 --> 00:08:21,000
+meeting its objectives.
+
+107
+00:08:21,000 --> 00:08:25,000
+Let's review some examples of KPIs in project management.
+
+108
+00:08:25,000 --> 00:08:29,000
+Task completion rate KPI can sound like this.
+
+109
+00:08:30,000 --> 00:08:36,000
+Percentage of completed tasks compared to the planned number of tasks for specific time period.
+
+110
+00:08:36,000 --> 00:08:43,000
+For example, this metric can tell you that 15 out of 20 planned tasks were completed within the reported
+
+111
+00:08:43,000 --> 00:08:44,000
+period.
+
+112
+00:08:45,000 --> 00:08:51,000
+We may have planned for two weeks iteration and just 15 tasks out of 20 were completed.
+
+113
+00:08:52,000 --> 00:08:53,000
+Is it KPI?
+
+114
+00:08:53,000 --> 00:08:54,000
+Not yet.
+
+115
+00:08:55,000 --> 00:09:00,000
+Green zone at least 90% completion of planned tasks.
+
+116
+00:09:00,000 --> 00:09:02,000
+This is KPI.
+
+117
+00:09:02,000 --> 00:09:03,000
+Do you understand the difference?
+
+118
+00:09:04,000 --> 00:09:08,000
+KPI is some target that you want to achieve.
+
+119
+00:09:08,000 --> 00:09:13,000
+You can set ranges for example between 80% but below 90%.
+
+120
+00:09:13,000 --> 00:09:18,000
+It is an amber zone and below 80% this is red zone.
+
+121
+00:09:18,000 --> 00:09:25,000
+In our case, we can easily calculate that 15 tasks out of 20 is 75%.
+
+122
+00:09:25,000 --> 00:09:30,000
+That means that we are in the red zone of our KPI.
+
+123
+00:09:30,000 --> 00:09:31,000
+Is it clear?
+
+124
+00:09:32,000 --> 00:09:36,000
+In the similar way you can set ranges for other KPIs.
+
+125
+00:09:36,000 --> 00:09:39,000
+Budget adherence KPI.
+
+126
+00:09:39,000 --> 00:09:44,000
+Percentage of actual project costs compared to the planned budget.
+
+127
+00:09:45,000 --> 00:09:47,000
+Defect rate KPI.
+
+128
+00:09:47,000 --> 00:09:51,000
+Number of defects or errors identified in the project.
+
+129
+00:09:51,000 --> 00:09:56,000
+Deliverables in the specific amount of time or in other KPI.
+
+130
+00:09:56,000 --> 00:09:59,000
+Number of critical defects on production environment.
+
+131
+00:10:00,000 --> 00:10:03,000
+More metrics and KPIs will learn during the course.
+
+132
+00:10:04,000 --> 00:10:07,000
+Let's learn when it is recommended to use KPIs.
+
+133
+00:10:08,000 --> 00:10:13,000
+Key performance indicators are used at various stages throughout the project life cycle and project
+
+134
+00:10:13,000 --> 00:10:14,000
+management.
+
+135
+00:10:14,000 --> 00:10:18,000
+But let's review key stages when KPIs are used.
+
+136
+00:10:18,000 --> 00:10:20,000
+Project planning.
+
+137
+00:10:20,000 --> 00:10:25,000
+Define KPIs during the planning phase to establish measurable objectives and performance indicators
+
+138
+00:10:25,000 --> 00:10:27,000
+aligned with project goals.
+
+139
+00:10:28,000 --> 00:10:29,000
+Goal setting.
+
+140
+00:10:29,000 --> 00:10:36,000
+Use KPIs to set specific, measurable, achievable, relevant and time bound goals for the project.
+
+141
+00:10:37,000 --> 00:10:40,000
+We'll learn smart technique later to.
+
+142
+00:10:41,000 --> 00:10:48,000
+Monitoring progress continuously use KPIs throughout the project execution phase to monitor progress
+
+143
+00:10:48,000 --> 00:10:52,000
+and track performance against established benchmarks.
+
+144
+00:10:53,000 --> 00:10:59,000
+Performance assessment Use KPIs for ongoing performance assessments to evaluate how well the project
+
+145
+00:10:59,000 --> 00:11:05,000
+is meeting its objectives and adherence to schedule, budget, and quality standards.
+
+146
+00:11:06,000 --> 00:11:15,000
+Issue identification KPIs help in identifying issues and deviations early on, allowing for timely corrective
+
+147
+00:11:15,000 --> 00:11:16,000
+actions to be taken.
+
+148
+00:11:17,000 --> 00:11:18,000
+Decision making.
+
+149
+00:11:18,000 --> 00:11:25,000
+Use KPIs for data driven decision making, providing a clear understanding of the project's status and
+
+150
+00:11:25,000 --> 00:11:27,000
+where adjustments may be needed.
+
+151
+00:11:28,000 --> 00:11:36,000
+Resource management KPIs can assist in managing resources effectively by tracking their utilization
+
+152
+00:11:36,000 --> 00:11:39,000
+and ensuring optimal allocation.
+
+153
+00:11:40,000 --> 00:11:42,000
+Stakeholder communication.
+
+154
+00:11:42,000 --> 00:11:49,000
+Incorporate KPIs in project status reports and communications to stakeholders, facilitating transparent
+
+155
+00:11:49,000 --> 00:11:51,000
+and informed discussions.
+
+156
+00:11:52,000 --> 00:11:54,000
+Continuous improvement.
+
+157
+00:11:54,000 --> 00:12:01,000
+Analyze KPI data to identify areas for improvement and refine project management processes for future
+
+158
+00:12:01,000 --> 00:12:02,000
+projects.
+
+159
+00:12:03,000 --> 00:12:04,000
+Project closure.
+
+160
+00:12:04,000 --> 00:12:10,000
+Evaluate KPIs during the project closure phase to assess overall success and capture lessons learned
+
+161
+00:12:10,000 --> 00:12:17,000
+for future initiatives by incorporating KPIs at these various stages.
+
+162
+00:12:17,000 --> 00:12:24,000
+Project managers can gain insights into project performance, make informed decisions, and ensure that
+
+163
+00:12:24,000 --> 00:12:27,000
+the project aligns with its objectives.
+
+164
+00:12:27,000 --> 00:12:34,000
+KPIs provide a systematic way to measure success and drive continuous improvements throughout the project
+
+165
+00:12:34,000 --> 00:12:35,000
+management process.
+
+166
+00:12:36,000 --> 00:12:41,000
+So now we're in a position to answer the question what is the difference between metric and KPI?
+
+167
+00:12:42,000 --> 00:12:45,000
+As you already learned, metric is just a value.
+
+168
+00:12:46,000 --> 00:12:48,000
+It is just some measurement.
+
+169
+00:12:48,000 --> 00:12:54,000
+But without setting KPIs, we can't say whether it is good or bad value.
+
+170
+00:12:54,000 --> 00:12:55,000
+And what does it mean?
+
+171
+00:12:56,000 --> 00:13:02,000
+Metrics are just measurements, but they will tell you nothing about project performance or project
+
+172
+00:13:02,000 --> 00:13:05,000
+success without setting specific KPI.
+
+173
+00:13:05,000 --> 00:13:09,000
+I hope that the difference between these two concepts is clear now.
+
+174
+00:13:10,000 --> 00:13:15,000
+And in case you have any questions, please let me know in the comments below the video and I will be
+
+175
+00:13:15,000 --> 00:13:16,000
+happy to answer.
+
+176
+00:13:17,000 --> 00:13:20,000
+Let's now learn what OKR is.
+
+177
+00:13:20,000 --> 00:13:28,000
+OKR stands for Objectives and Key Results, and it is a goal setting framework used in project management
+
+178
+00:13:28,000 --> 00:13:30,000
+and organizational management.
+
+179
+00:13:30,000 --> 00:13:37,000
+OKRs are designed to align teams and individuals with business objectives, providing a clear focus
+
+180
+00:13:37,000 --> 00:13:40,000
+on what needs to be achieved.
+
+181
+00:13:40,000 --> 00:13:43,000
+OKR consists of multiple components.
+
+182
+00:13:43,000 --> 00:13:47,000
+Here is breakdown of the components of OKRs.
+
+183
+00:13:48,000 --> 00:13:49,000
+Objectives.
+
+184
+00:13:49,000 --> 00:13:56,000
+Objectives are high level qualitative goals that define what an organization or team wants to achieve.
+
+185
+00:13:57,000 --> 00:14:02,000
+They are ambitious, inspiring and help set a clear direction.
+
+186
+00:14:02,000 --> 00:14:03,000
+Q results.
+
+187
+00:14:04,000 --> 00:14:10,000
+Q results are specific, measurable, and time bound outcomes that indicate progress toward achieving
+
+188
+00:14:10,000 --> 00:14:12,000
+the corresponding objective.
+
+189
+00:14:12,000 --> 00:14:17,000
+Key results are quantifiable and provide a way to track success.
+
+190
+00:14:18,000 --> 00:14:21,000
+The main characteristics of OKRs include.
+
+191
+00:14:21,000 --> 00:14:23,000
+Number one alignment.
+
+192
+00:14:23,000 --> 00:14:30,000
+OKRs align everyone in the organization towards common goals, ensuring that each team's objectives
+
+193
+00:14:30,000 --> 00:14:34,000
+contribute to the overall success of the organization.
+
+194
+00:14:34,000 --> 00:14:36,000
+Transparency.
+
+195
+00:14:36,000 --> 00:14:42,000
+OKRs are typically visible to everyone in the organization, fostering transparency and allowing teams
+
+196
+00:14:42,000 --> 00:14:47,000
+to understand how their work contributes to the larger picture.
+
+197
+00:14:48,000 --> 00:14:49,000
+Focus.
+
+198
+00:14:49,000 --> 00:14:56,000
+OKR helps teams and individuals prioritize their efforts by focusing on a small number of ambitious
+
+199
+00:14:56,000 --> 00:15:00,000
+objectives, rather than spreading resources too thin.
+
+200
+00:15:01,000 --> 00:15:03,000
+Continuous improvement.
+
+201
+00:15:03,000 --> 00:15:11,000
+OKRs are often set and reviewed in regular cycles, for example on quarterly basis, allowing for adjustments
+
+202
+00:15:11,000 --> 00:15:14,000
+and continuous improvement based on the results achieved.
+
+203
+00:15:14,000 --> 00:15:16,000
+Adaptability.
+
+204
+00:15:16,000 --> 00:15:23,000
+OKRs provide a framework that allows for adaptability, enabling teams to respond to changes in the
+
+205
+00:15:23,000 --> 00:15:24,000
+business environment.
+
+206
+00:15:24,000 --> 00:15:32,000
+OKRs are widely used in agile and iterative project management methodologies, promoting a results oriented
+
+207
+00:15:32,000 --> 00:15:37,000
+approach and encouraging collaboration across different levels of an organization.
+
+208
+00:15:37,000 --> 00:15:43,000
+They originated from Intel and were later popularized by companies like Google.
+
+209
+00:15:44,000 --> 00:15:50,000
+And to understand better what an OKR is, let me explain you what it is on examples.
+
+210
+00:15:51,000 --> 00:15:54,000
+For example, our objective may sound like this.
+
+211
+00:15:54,000 --> 00:16:02,000
+Improve project delivery efficiency and they are going to be the following key results within it.
+
+212
+00:16:02,000 --> 00:16:05,000
+Key result increase project completion rate.
+
+213
+00:16:06,000 --> 00:16:12,000
+Achieve a 95% or higher completion rate for planned project tasks by the end of the quarter.
+
+214
+00:16:12,000 --> 00:16:16,000
+Another key result reduce project lead time.
+
+215
+00:16:16,000 --> 00:16:22,000
+Decrease the average time taken to complete a project from initiation to delivery by 15% by the end
+
+216
+00:16:22,000 --> 00:16:29,000
+of the quarter, and the last but not the least, key result within this objective is enhanced team
+
+217
+00:16:29,000 --> 00:16:30,000
+collaboration.
+
+218
+00:16:30,000 --> 00:16:35,000
+Increase the utilization of collaborative tools and practices.
+
+219
+00:16:35,000 --> 00:16:41,000
+Aiming for a 20% improvement in team collaboration scores based on team surveys.
+
+220
+00:16:42,000 --> 00:16:45,000
+Let's review another OKR for objectives.
+
+221
+00:16:45,000 --> 00:16:46,000
+That sounds like this.
+
+222
+00:16:47,000 --> 00:16:49,000
+Increase client satisfaction.
+
+223
+00:16:49,000 --> 00:16:53,000
+We are going to have three key results within this objective.
+
+224
+00:16:53,000 --> 00:16:57,000
+The first one achieve high customer ratings.
+
+225
+00:16:57,000 --> 00:17:05,000
+Achieve a customer satisfaction rating of 4.5 out of five or higher in post-project surveys.
+
+226
+00:17:06,000 --> 00:17:15,000
+The second key result, timely issue resolution, ensures that 90% of customer reported issues are acknowledged
+
+227
+00:17:15,000 --> 00:17:18,000
+and resolved within 48 hours.
+
+228
+00:17:18,000 --> 00:17:26,000
+The third key result client feedback integration implement improvements based on client feedback in
+
+229
+00:17:26,000 --> 00:17:30,000
+at least three key project processes or deliverables during the quarter.
+
+230
+00:17:31,000 --> 00:17:39,000
+These examples illustrate how OKRs can be crafted to align with broader organizational goals, focusing
+
+231
+00:17:39,000 --> 00:17:46,000
+on specific, measurable outcomes that contribute to the success of a project and the well-being of
+
+232
+00:17:46,000 --> 00:17:47,000
+the team.
+
+233
+00:17:47,000 --> 00:17:49,000
+So when to use OKRs.
+
+234
+00:17:50,000 --> 00:17:57,000
+Objective and key results are typically used in various organizational settings to align team and individuals
+
+235
+00:17:57,000 --> 00:17:59,000
+with overarching goals.
+
+236
+00:17:59,000 --> 00:18:01,000
+Here are some examples.
+
+237
+00:18:01,000 --> 00:18:02,000
+When to use OKRs.
+
+238
+00:18:03,000 --> 00:18:04,000
+Strategic planning.
+
+239
+00:18:05,000 --> 00:18:11,000
+Use OKRs during strategic planning to define high level objectives and key results that align with the
+
+240
+00:18:11,000 --> 00:18:14,000
+organization's long terme vision and mission.
+
+241
+00:18:15,000 --> 00:18:16,000
+Goal setting.
+
+242
+00:18:16,000 --> 00:18:23,000
+Use OKRs for goal setting at different levels of the organization, including teams and individuals.
+
+243
+00:18:23,000 --> 00:18:26,000
+They provide clarity on what needs to be achieved.
+
+244
+00:18:27,000 --> 00:18:29,000
+Performance management.
+
+245
+00:18:29,000 --> 00:18:36,000
+Utilize OKRs as a performance management tool to set expectations, evaluate performance, and provide
+
+246
+00:18:36,000 --> 00:18:38,000
+a framework for employee development.
+
+247
+00:18:39,000 --> 00:18:47,000
+Project management integrate OKRs into project management to align project objectives with broader organizational
+
+248
+00:18:47,000 --> 00:18:52,000
+goals, ensuring that the project outcomes contribute to overall success.
+
+249
+00:18:53,000 --> 00:19:01,000
+Departmental alignment use OKRs to align departments and teams, ensuring that their objectives contribute
+
+250
+00:19:01,000 --> 00:19:04,000
+to the success of the organization as a whole.
+
+251
+00:19:05,000 --> 00:19:07,000
+Agile environments.
+
+252
+00:19:07,000 --> 00:19:15,000
+Apply OKRs in agile and iterative environments to provide a results oriented framework that supports
+
+253
+00:19:15,000 --> 00:19:18,000
+adaptability and continuous improvement.
+
+254
+00:19:19,000 --> 00:19:20,000
+Change management.
+
+255
+00:19:20,000 --> 00:19:29,000
+Implement OKRs during periods of organizational change to focus efforts on specific outcomes and facilitate
+
+256
+00:19:29,000 --> 00:19:30,000
+a smooth transition.
+
+257
+00:19:31,000 --> 00:19:39,000
+Quarterly planning setting review occurs on a quarterly basis, allowing for regular assessment adjustments
+
+258
+00:19:39,000 --> 00:19:43,000
+and alignment with changing business priorities.
+
+259
+00:19:43,000 --> 00:19:45,000
+Innovation initiatives.
+
+260
+00:19:46,000 --> 00:19:50,000
+Apply OKRs when launching innovation initiatives.
+
+261
+00:19:50,000 --> 00:19:57,000
+Guiding team to achieve specific outcomes related to the development and implementation of new ideas.
+
+262
+00:19:58,000 --> 00:20:05,000
+Cross-functional collaboration foster cross-functional collaboration by using OKRs to align teams from
+
+263
+00:20:05,000 --> 00:20:11,000
+different departments, ensuring that their efforts collectively contribute to organizational success.
+
+264
+00:20:12,000 --> 00:20:20,000
+Overall, OKRs are a versatile tool that can be applied in various contexts to drive alignment, focus,
+
+265
+00:20:20,000 --> 00:20:22,000
+and measurable results.
+
+266
+00:20:22,000 --> 00:20:28,000
+They are particularly effective in dynamic and fast paced environments where adaptability and clarity
+
+267
+00:20:28,000 --> 00:20:30,000
+on goals are crucial.
+
+268
+00:20:30,000 --> 00:20:38,000
+Do you feel already the difference between OKR and KPI objectives and key results and key performance
+
+269
+00:20:38,000 --> 00:20:39,000
+indicators?
+
+270
+00:20:39,000 --> 00:20:46,000
+Are both performance measurement frameworks, but they serve distinct purposes and have some differences.
+
+271
+00:20:47,000 --> 00:20:51,000
+Let's make comparison between OKRs and KPIs.
+
+272
+00:20:52,000 --> 00:20:58,000
+Purpose OKRs focus on aligning teams and individuals with strategic objectives.
+
+273
+00:20:58,000 --> 00:21:02,000
+They are aspirational and helped set ambitious goals.
+
+274
+00:21:03,000 --> 00:21:10,000
+KPIs primarily aim to measure specific, quantifiable aspects of performance and are often associated
+
+275
+00:21:10,000 --> 00:21:13,000
+with operational or tactical goals.
+
+276
+00:21:14,000 --> 00:21:15,000
+Nature.
+
+277
+00:21:15,000 --> 00:21:22,000
+Walkers typically consists of qualitative objectives and measurable key results.
+
+278
+00:21:22,000 --> 00:21:29,000
+Objectives are high level and inspirational, while key results are specific, measurable outcomes that
+
+279
+00:21:29,000 --> 00:21:30,000
+indicate success.
+
+280
+00:21:31,000 --> 00:21:38,000
+KPIs are typically quantitative metrics used to evaluate the performance of a particular aspect of a
+
+281
+00:21:38,000 --> 00:21:41,000
+project, process, or organization.
+
+282
+00:21:41,000 --> 00:21:43,000
+Time frame.
+
+283
+00:21:43,000 --> 00:21:48,000
+OKRs often set for a specific period, commonly a quarter or a year.
+
+284
+00:21:49,000 --> 00:21:53,000
+They encourage regular review and adjustment of goals.
+
+285
+00:21:53,000 --> 00:21:57,000
+KPIs can be both short tum and long terme metrics.
+
+286
+00:21:57,000 --> 00:22:03,000
+Some key PiS are tracked continuously, while others may be assessed periodically.
+
+287
+00:22:04,000 --> 00:22:05,000
+Scope.
+
+288
+00:22:05,000 --> 00:22:12,000
+OKRs are broader in scope, addressing strategic and high level goals that contribute to the overall
+
+289
+00:22:12,000 --> 00:22:14,000
+success of the organization.
+
+290
+00:22:15,000 --> 00:22:21,000
+KPIs are more specific and can address particular aspects of performance within a project, department,
+
+291
+00:22:21,000 --> 00:22:22,000
+or process.
+
+292
+00:22:23,000 --> 00:22:28,000
+I hope that now the difference between KPI and OKR is clear.
+
+293
+00:22:29,000 --> 00:22:34,000
+In case you would have any questions, please let me know in the comments below the video and I will
+
+294
+00:22:34,000 --> 00:22:35,000
+be happy to answer.
+
+295
+00:22:36,000 --> 00:22:40,000
+And that's all what I wanted to learn with you in scope of this lesson.
+
+296
+00:22:40,000 --> 00:22:43,000
+Let's recap what we have learned today.
+
+297
+00:22:43,000 --> 00:22:46,000
+Today we learned what metrics are.
+
+298
+00:22:46,000 --> 00:22:51,000
+We learned examples of metrics and use cases when it is appropriate to use metrics.
+
+299
+00:22:52,000 --> 00:22:58,000
+I explained you what KPIs are and we learned examples and use cases too.
+
+300
+00:22:58,000 --> 00:23:00,000
+We compared metrics with KPI.
+
+301
+00:23:00,000 --> 00:23:03,000
+After this lesson you know the difference.
+
+302
+00:23:03,000 --> 00:23:12,000
+We learned what OKR is in the similar way we learned examples of OKR and discussed when OKRs are applicable.
+
+303
+00:23:12,000 --> 00:23:16,000
+And then we compared KPIs with OKRs.
+
+304
+00:23:16,000 --> 00:23:18,000
+That's it for today.
+
+305
+00:23:18,000 --> 00:23:19,000
+Thanks a lot for your attention.
+
+306
+00:23:19,000 --> 00:23:22,000
+Have a great day and see you in the next lesson.
+

110 - Metrics & KPIs to Monitor and Control Software Development Process/003 RAG Status to Present KPI.html

@@ -0,0 +1,69 @@
+<!DOCTYPE html>
+<html lang="en">
+    <head>
+        <meta charset="UTF-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+        <title>RAG Status to Present KPI</title>
+
+        <style>
+            * {
+                box-sizing: border-box;
+                margin: 0;
+                padding: 0;
+            }
+            body {
+                font-family: var(--font-stack-text);
+                font-weight: 400;
+                line-height: 1.4;
+                font-size: 1.6rem;
+                color: #2d2f31;
+            }
+            .container {
+                position: relative;
+                height: 100%;
+                overflow-y: auto;
+            }
+            .content {
+                padding: 3.2rem 4.8rem;
+                word-break: break-word;
+                max-width: 69.6rem;
+                margin: 0 auto;
+            }
+            .heading {
+                margin-bottom: 24px;
+                font-family: -apple-system, BlinkMacSystemFont, Roboto, "Segoe UI", Helvetica, Arial, sans-serif,
+                    "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
+                font-weight: 700;
+                line-height: 1.2;
+                letter-spacing: 0;
+                font-size: 32px;
+                max-width: 36em;
+            }
+            .article-asset-container {
+                padding: 2.4rem;
+            }
+            .article-asset-container p {
+                font-size: 19px;
+            }
+            code {
+                background-color: #fff;
+                border: 1px solid #d1d7dc;
+                color: #b4690e;
+                font-size: 80%;
+                padding: 0.2rem 0.4rem;
+                font-family: sfmono-regular, Consolas, liberation mono, Menlo, Courier, monospace;
+            }
+            p {
+                font-weight: 400;
+            }
+        </style>
+    </head>
+    <body>
+        <div class="container">
+            <div class="content">
+                <div class="heading">RAG Status to Present KPI</div>
+                <div class="article-asset-container"><p><strong>What is RAG&nbsp;Status?</strong></p><p>The RAG status is a visual indicator system used to communicate the status or health of a project, task, or Key Performance Indicator (KPI). The acronym "RAG" stands for Red, Amber (or Yellow), and Green, which are color codes used to represent different levels of status:</p><ol><li><p><strong>Red:</strong></p><ul><li><p><strong>Meaning:</strong> Indicates a critical or problematic status that requires immediate attention.</p></li><li><p><strong>Usage:</strong> Used when there are significant issues, problems, or deviations from the expected performance. It signals that corrective actions are needed urgently.</p></li></ul></li><li><p><strong>Amber (or Yellow):</strong></p><ul><li><p><strong>Meaning:</strong> Suggests a cautionary or warning status, indicating potential issues or concerns that may need attention.</p></li><li><p><strong>Usage:</strong> Typically used when there are moderate concerns or risks that, while not critical, should be monitored and addressed to prevent escalation.</p></li></ul></li><li><p><strong>Green:</strong></p><ul><li><p><strong>Meaning:</strong> Represents a positive or acceptable status, signaling that everything is on track.</p></li><li><p><strong>Usage:</strong> Used when the project, task, or KPI is performing well within the expected parameters. It indicates that no immediate action is required.</p></li></ul></li></ol><p>The RAG status is commonly used in project management, performance reporting, and various business contexts. It provides a quick and intuitive way for stakeholders to assess the status of different aspects of a project or business operation. The use of color codes makes it easy to visually communicate the health of key elements, allowing for rapid decision-making and prioritization of efforts.</p><p><br></p><p><br></p><p><strong>RAG&nbsp;Status to Present KPI</strong></p><p>Presenting KPIs using the RAG (Red, Amber, Green) status involves using color codes to quickly convey the performance or health of each KPI. Here's how it typically works:</p><ol><li><p><strong>Red:</strong></p><ul><li><p><strong>Meaning:</strong> The KPI is below the acceptable threshold or target, and there are critical issues that need immediate attention.</p></li><li><p><strong>Implications:</strong> Urgent action or intervention is required to address the problems and bring the KPI back to an acceptable level.</p></li></ul></li><li><p><strong>Amber (or Yellow):</strong></p><ul><li><p><strong>Meaning:</strong> The KPI is in a cautionary state. It may be approaching or slightly below the acceptable threshold, indicating potential issues.</p></li><li><p><strong>Implications:</strong> While not critical, there are concerns that should be monitored, and proactive measures may be needed to prevent the KPI from becoming a significant problem.</p></li></ul></li><li><p><strong>Green:</strong></p><ul><li><p><strong>Meaning:</strong> The KPI is within or exceeds the acceptable range, and performance is satisfactory.</p></li><li><p><strong>Implications:</strong> No immediate action is needed, and the KPI is performing as expected.</p></li></ul></li></ol><p>By presenting KPIs with RAG status, stakeholders can quickly understand the state of performance and prioritize actions based on the urgency and severity of issues identified. It's a visual and effective way to communicate complex performance data.</p><p><br></p><p><br></p><p><strong>Why do we use RAG&nbsp;status to present KPI?</strong></p><p>While "Red, Amber, Green" (RAG) is not typically referred to as a Key Performance Indicator (KPI) in the traditional sense, it is a visual indicator system used to communicate the status of various metrics, including KPIs. The RAG status is often used to quickly convey the health or performance of a particular metric or project based on color codes:&nbsp;RED, AMBER, GREEN.</p><p>While RAG status itself is not a quantitative measurement, it serves as a powerful visual signal to quickly assess the performance or health of a specific aspect of a project or process. The use of RAG status is common in project management, performance reporting, and other areas where quick visual communication is beneficial. Each color code is associated with certain thresholds or criteria, helping stakeholders make informed decisions based on the current status.</p></div>
+            </div>
+        </div>
+    </body>
+</html>

110 - Metrics & KPIs to Monitor and Control Software Development Process/004 Introduction to Engineering Excellence Metrics & KPIs_en.srt

@@ -0,0 +1,240 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Tim.
+
+2
+00:00:06,000 --> 00:00:11,000
+This is an introductory lesson to engineering excellence, metrics and KPIs.
+
+3
+00:00:11,000 --> 00:00:17,000
+These metrics are super important for leaders on different levels to measure team performance, quality
+
+4
+00:00:17,000 --> 00:00:19,000
+of deliverables, and lots more.
+
+5
+00:00:19,000 --> 00:00:25,000
+Also, it is super important to use metrics from this section in real life because they will help to
+
+6
+00:00:25,000 --> 00:00:33,000
+identify bottlenecks in engineering processes and will indicate challenges before they are turned into
+
+7
+00:00:33,000 --> 00:00:33,000
+problems.
+
+8
+00:00:34,000 --> 00:00:40,000
+As a part of introduction to this learning section, let me explain why it is so important.
+
+9
+00:00:40,000 --> 00:00:46,000
+No matter whether you are project manager or technical lead or architect in general, you are responsible
+
+10
+00:00:46,000 --> 00:00:50,000
+for a group of people and quality of their deliverables.
+
+11
+00:00:50,000 --> 00:00:53,000
+You always have multiple options in front of you.
+
+12
+00:00:53,000 --> 00:01:01,000
+You can manage your team on ad hoc manner, or you can set clear indicators to measure different aspects
+
+13
+00:01:01,000 --> 00:01:07,000
+of the project and be able to indicate challenges or errors for improvements with ease.
+
+14
+00:01:07,000 --> 00:01:12,000
+Moreover, the bigger your team, the less attention you have to details.
+
+15
+00:01:12,000 --> 00:01:19,000
+That's why establishing some metrics and set KPIs for your team is important, because without it,
+
+16
+00:01:19,000 --> 00:01:22,000
+you simply won't be able to scale.
+
+17
+00:01:23,000 --> 00:01:29,000
+So after learning metrics and recommended KPIs from this section, you will learn tools that will help
+
+18
+00:01:29,000 --> 00:01:36,000
+you to support scaling of your team, productivity and volume of deliverables in the most efficient
+
+19
+00:01:36,000 --> 00:01:37,000
+way.
+
+20
+00:01:38,000 --> 00:01:44,000
+Before we go deep into the discussion of each particular metric, let me share with you the view of
+
+21
+00:01:44,000 --> 00:01:50,000
+what we are going to learn in this section, especially for my students, and made collection of all
+
+22
+00:01:50,000 --> 00:01:54,000
+metrics that I ever used on my different projects, in different use cases.
+
+23
+00:01:55,000 --> 00:02:01,000
+These metrics helped me to deliver multi-million projects with success, and when I started creation
+
+24
+00:02:01,000 --> 00:02:08,000
+of this catalog that I called Metrics Library, I realized that it is not so easy to put each metric
+
+25
+00:02:08,000 --> 00:02:10,000
+in just one single category.
+
+26
+00:02:11,000 --> 00:02:18,000
+Sometimes metrics are located on logical intersections between different areas and aspects of a project.
+
+27
+00:02:18,000 --> 00:02:25,000
+As you can see in metrics library, I have different practices and different areas within practice.
+
+28
+00:02:25,000 --> 00:02:32,000
+While I tried to be as accurate as it is possible when I categorized all these metrics at the same time,
+
+29
+00:02:32,000 --> 00:02:37,000
+I can admit that there may be open questions regarding categorizing of some of them.
+
+30
+00:02:38,000 --> 00:02:44,000
+Like for example, number of fixes in release candidate theoretically can go even to another practice
+
+31
+00:02:44,000 --> 00:02:45,000
+the quality assurance.
+
+32
+00:02:45,000 --> 00:02:46,000
+Right?
+
+33
+00:02:47,000 --> 00:02:52,000
+But still, in terms of this library I preferred to use in more general way.
+
+34
+00:02:52,000 --> 00:02:56,000
+And that's why I put it into engineering excellence practice.
+
+35
+00:02:56,000 --> 00:03:00,000
+Because in scope of this practice I have release cycle area.
+
+36
+00:03:00,000 --> 00:03:07,000
+So in scope of engineering excellence practice we are going to review metrics for such areas development
+
+37
+00:03:07,000 --> 00:03:09,000
+build and release cycle.
+
+38
+00:03:10,000 --> 00:03:16,000
+We are going to review each area one by one, in case you will have questions related to any of the
+
+39
+00:03:16,000 --> 00:03:23,000
+presented metrics or areas, please do not hesitate to ask your questions below the video and I will
+
+40
+00:03:23,000 --> 00:03:24,000
+be happy to answer.
+
+41
+00:03:24,000 --> 00:03:29,000
+During the whole section, we will make an assumption that we are working with software, product,
+
+42
+00:03:29,000 --> 00:03:32,000
+web application or web system.
+
+43
+00:03:32,000 --> 00:03:36,000
+This is important for better understanding of examples provided.
+
+44
+00:03:36,000 --> 00:03:42,000
+So all examples use cases will be oriented and focused on web software development.
+
+45
+00:03:42,000 --> 00:03:43,000
+Why?
+
+46
+00:03:43,000 --> 00:03:48,000
+Because on the market nowadays this is the most popular area of software development.
+
+47
+00:03:48,000 --> 00:03:53,000
+And why software development but not manufacturing domain?
+
+48
+00:03:53,000 --> 00:03:59,000
+Because an example of software development, it is easy to review different use cases and the most complicated
+
+49
+00:03:59,000 --> 00:04:00,000
+ones.
+
+50
+00:04:00,000 --> 00:04:07,000
+Moreover, IT industries consider it to be a benchmark industry that sets trends and introduce innovative
+
+51
+00:04:07,000 --> 00:04:10,000
+approaches, including management approaches.
+
+52
+00:04:10,000 --> 00:04:12,000
+But that doesn't mean that everything.
+
+53
+00:04:12,000 --> 00:04:18,000
+What I am going to share in this section is not applicable for other areas, domains, or other types
+
+54
+00:04:18,000 --> 00:04:19,000
+of product development.
+
+55
+00:04:20,000 --> 00:04:26,000
+Other types of products like embedded development, Internet of things projects, automotive projects,
+
+56
+00:04:26,000 --> 00:04:29,000
+and others may have some specifics and measurements.
+
+57
+00:04:29,000 --> 00:04:36,000
+In case you are managing one of mentioned projects and you have any questions, please do not hesitate
+
+58
+00:04:36,000 --> 00:04:42,000
+to ask your question and I will be happy to help you because I have experience of working in different
+
+59
+00:04:42,000 --> 00:04:47,000
+domains including Internet of things, projects, automotive and others.
+
+60
+00:04:47,000 --> 00:04:50,000
+So let's start learning new things.
+

110 - Metrics & KPIs to Monitor and Control Software Development Process/005 Development Metrics & KPIs Tech Debt Ratio & Index, Cyclomatic Complexity_en.srt

@@ -0,0 +1,1276 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello, Tim.
+
+2
+00:00:06,000 --> 00:00:11,000
+With this lesson we start learning engineering excellence, metrics and KPIs.
+
+3
+00:00:11,000 --> 00:00:15,000
+In this lesson we will learn metrics from development area.
+
+4
+00:00:15,000 --> 00:00:19,000
+Today we'll learn three metrics from my personal metrics library.
+
+5
+00:00:19,000 --> 00:00:28,000
+We'll learn such metrics tech that ratio tech that index and cyclomatic complexity.
+
+6
+00:00:29,000 --> 00:00:35,000
+We are going to learn each metric using the simple but at the same time very efficient and structured
+
+7
+00:00:35,000 --> 00:00:36,000
+approach.
+
+8
+00:00:36,000 --> 00:00:43,000
+For each metric, we'll learn definition use cases to review when it is recommended to use the metric
+
+9
+00:00:43,000 --> 00:00:51,000
+in order to understand practical value and benefits, how to measure it, how to read values and what
+
+10
+00:00:51,000 --> 00:00:52,000
+do they mean?
+
+11
+00:00:52,000 --> 00:00:54,000
+Recommended KPIs.
+
+12
+00:00:54,000 --> 00:00:56,000
+Recommended actions.
+
+13
+00:00:56,000 --> 00:01:02,000
+During the review of each metric, I am going to share with you tons of practical examples that will
+
+14
+00:01:02,000 --> 00:01:07,000
+help you to start using the metrics straight away, right after the lesson.
+
+15
+00:01:07,000 --> 00:01:09,000
+So let's start our lesson.
+
+16
+00:01:09,000 --> 00:01:17,000
+Let's learn each metric one by one, and we will start from the tech that ratio metric, the tech that
+
+17
+00:01:17,000 --> 00:01:24,000
+ratio is a metric designed to quantify the relationship between the effort required to address existing
+
+18
+00:01:24,000 --> 00:01:32,000
+technical debt and the effort needed for development new features or functionalities in a software project.
+
+19
+00:01:32,000 --> 00:01:39,000
+Besides all the information that you can see on the screen, let me explain you this metric with real
+
+20
+00:01:39,000 --> 00:01:41,000
+life examples.
+
+21
+00:01:41,000 --> 00:01:46,000
+Tech debt ratio is like an indicator for software development.
+
+22
+00:01:46,000 --> 00:01:53,000
+It helps teams understand the balance between fixing existing issues in their code base, technical
+
+23
+00:01:53,000 --> 00:01:55,000
+debt, and creating new features.
+
+24
+00:01:55,000 --> 00:02:03,000
+This ratio is expressed as a percentage and is calculated by dividing the estimated effort needed to
+
+25
+00:02:03,000 --> 00:02:08,000
+tackle technical debt by the estimated effort for developing new features.
+
+26
+00:02:08,000 --> 00:02:10,000
+Real life analogy.
+
+27
+00:02:10,000 --> 00:02:13,000
+Imagine you have a house over time.
+
+28
+00:02:13,000 --> 00:02:22,000
+It needs maintenance, fixing leaky roofs, updating plumbing, etc. this is similar to technical debt
+
+29
+00:02:22,000 --> 00:02:23,000
+in software.
+
+30
+00:02:23,000 --> 00:02:30,000
+Now, if you are planning to add a new room to the house new features, you need to decide how much
+
+31
+00:02:30,000 --> 00:02:36,000
+time and resources you can allocate to fixing existing issues before you start building.
+
+32
+00:02:37,000 --> 00:02:46,000
+Let's learn use cases when on practices is recommended for you to use this metric before planning iterations,
+
+33
+00:02:46,000 --> 00:02:51,000
+imagine that you are planning the next set of tasks for your software project.
+
+34
+00:02:52,000 --> 00:03:00,000
+Before diving into new features, check the tech debt ratio if it is in the red zone, which is more
+
+35
+00:03:00,000 --> 00:03:01,000
+than 20%.
+
+36
+00:03:01,000 --> 00:03:08,000
+It is like saying we have a lot of house maintenance to do before we can add that new room.
+
+37
+00:03:09,000 --> 00:03:14,000
+This prompts the team to prioritize fixing issues before building new things.
+
+38
+00:03:15,000 --> 00:03:18,000
+Another use case during the roadmap review.
+
+39
+00:03:18,000 --> 00:03:23,000
+Imagine that you are reviewing the long Tum plan for your software project.
+
+40
+00:03:23,000 --> 00:03:29,000
+Look at the tasks that require to understand the overall health of your code base.
+
+41
+00:03:29,000 --> 00:03:37,000
+If it is consistently in the amber zone, which is between 10 to 20%, it signals that ongoing attention
+
+42
+00:03:37,000 --> 00:03:40,000
+to technical debt is needed.
+
+43
+00:03:40,000 --> 00:03:45,000
+This ensures that the house maintenance is kept in check over the long run.
+
+44
+00:03:46,000 --> 00:03:51,000
+From where you can learn about this metric and how you can gather it.
+
+45
+00:03:51,000 --> 00:03:57,000
+Usually it is recommended to track technical debt somehow in task management tool.
+
+46
+00:03:57,000 --> 00:04:05,000
+For example, after some demo session, or after some release or during the development, Kim mentioned
+
+47
+00:04:05,000 --> 00:04:12,000
+that we don't need to forget to rework design of some module in order to support its scaling in the
+
+48
+00:04:12,000 --> 00:04:13,000
+future.
+
+49
+00:04:13,000 --> 00:04:20,000
+And if you are a good leader, good manager, you create a task and put it into task management tool.
+
+50
+00:04:21,000 --> 00:04:28,000
+You can track all technical debt tasks separately in one container, or put in some special label on
+
+51
+00:04:28,000 --> 00:04:35,000
+them in order to be able to find them quickly in the future so you can find them easily and estimate
+
+52
+00:04:35,000 --> 00:04:37,000
+them with the team.
+
+53
+00:04:37,000 --> 00:04:43,000
+If you don't track technical debt at all at your project, you have to start from tracking technical
+
+54
+00:04:43,000 --> 00:04:45,000
+debt first.
+
+55
+00:04:45,000 --> 00:04:53,000
+This is super important regarding metrics interpretation, I believe it is relatively simple and clear
+
+56
+00:04:53,000 --> 00:04:55,000
+to understand how to read this metric.
+
+57
+00:04:56,000 --> 00:05:05,000
+The bigger value, the bigger technical debt is 100% means that you have tagged that equal to remaining
+
+58
+00:05:05,000 --> 00:05:06,000
+estimated scope.
+
+59
+00:05:07,000 --> 00:05:15,000
+More than 100% means that your tech debt is bigger than new scope implementation.
+
+60
+00:05:16,000 --> 00:05:20,000
+Let's now learn target KPIs for this metric in order.
+
+61
+00:05:20,000 --> 00:05:23,000
+You could understand what we need to aim for.
+
+62
+00:05:24,000 --> 00:05:30,000
+If you don't know what KPI is, please check my lesson about metrics and KPIs.
+
+63
+00:05:30,000 --> 00:05:33,000
+So we have red, Amber and Green Zone.
+
+64
+00:05:34,000 --> 00:05:40,000
+During this course we are going to review my recommendations about target KPI for each metric.
+
+65
+00:05:40,000 --> 00:05:46,000
+But please remember that KPI is it is something specific to your project.
+
+66
+00:05:46,000 --> 00:05:52,000
+Each project has unique scope, specific timeframes, limit of resources.
+
+67
+00:05:52,000 --> 00:05:58,000
+Each project has different level of complexity, different size of the teams that works on the project.
+
+68
+00:05:58,000 --> 00:06:02,000
+Teams may have different levels of maturity and lots more.
+
+69
+00:06:03,000 --> 00:06:11,000
+There are hundreds of factors that may impact KPI, so treat my recommendations as recommendations and
+
+70
+00:06:11,000 --> 00:06:12,000
+apply them wisely.
+
+71
+00:06:13,000 --> 00:06:15,000
+Don't go back to your project blindly.
+
+72
+00:06:15,000 --> 00:06:21,000
+Set a new KPIs and telling your team that Andre from Udemy told you to do so.
+
+73
+00:06:21,000 --> 00:06:25,000
+Apply all KPIs wisely, considering project context.
+
+74
+00:06:25,000 --> 00:06:32,000
+So let's review recommended KPIs for tech that ratio metric, we can say that we are in the red zone
+
+75
+00:06:32,000 --> 00:06:36,000
+in case the value of the metric is more than 20%.
+
+76
+00:06:37,000 --> 00:06:38,000
+Real life analogy.
+
+77
+00:06:38,000 --> 00:06:44,000
+Your house needs urgent repairs before you can think about adding anything new.
+
+78
+00:06:45,000 --> 00:06:47,000
+Another analogy from software development.
+
+79
+00:06:48,000 --> 00:06:54,000
+For instance, if the application has severe security vulnerabilities, it is like having a critical
+
+80
+00:06:54,000 --> 00:06:57,000
+flaw in the foundation of your software.
+
+81
+00:06:58,000 --> 00:07:05,000
+You were so busy with feature development that you completely forgot about security requirements before
+
+82
+00:07:05,000 --> 00:07:08,000
+thinking about adding new functionalities.
+
+83
+00:07:08,000 --> 00:07:12,000
+Addressing these urgent issues becomes a top priority.
+
+84
+00:07:12,000 --> 00:07:19,000
+Immediate actions may involve patching security vulnerabilities, resolving critical bugs that impact
+
+85
+00:07:19,000 --> 00:07:23,000
+user experience, or improving the overall stability of the software.
+
+86
+00:07:24,000 --> 00:07:31,000
+So in this case, it is recommended to prioritize and schedule fixing technical debt in upcoming work.
+
+87
+00:07:31,000 --> 00:07:37,000
+We are in the amber zone in case value of the metric is between 10 and 20.
+
+88
+00:07:37,000 --> 00:07:39,000
+Real life analogy.
+
+89
+00:07:39,000 --> 00:07:43,000
+Your house needs regular maintenance to prevent major issues.
+
+90
+00:07:43,000 --> 00:07:50,000
+And if we're talking about software development example imagine the following case identifying moderate
+
+91
+00:07:50,000 --> 00:07:57,000
+code smells or performance bottlenecks that, while not urgent, could lead to more significant problems
+
+92
+00:07:57,000 --> 00:07:59,000
+if left unattended.
+
+93
+00:08:00,000 --> 00:08:08,000
+So it is always recommended regularly address high priority technical debt items and we are in the green
+
+94
+00:08:08,000 --> 00:08:13,000
+zone in case value of this metric is less than 10%.
+
+95
+00:08:13,000 --> 00:08:15,000
+Example from real life.
+
+96
+00:08:15,000 --> 00:08:20,000
+Your house is well maintained, allowing you to plan for improvements.
+
+97
+00:08:21,000 --> 00:08:23,000
+Example from software development.
+
+98
+00:08:23,000 --> 00:08:30,000
+It is like having a well maintained code base that allows for planned improvements and new features.
+
+99
+00:08:30,000 --> 00:08:38,000
+In this case, feel free to add technical debt items to the plan based on priority and available capacity.
+
+100
+00:08:39,000 --> 00:08:43,000
+Let's review recommended actions to achieve KPI.
+
+101
+00:08:43,000 --> 00:08:50,000
+Prioritize and address critical technical debt items that may impact stability or maintainability of
+
+102
+00:08:50,000 --> 00:08:51,000
+the code base.
+
+103
+00:08:51,000 --> 00:08:56,000
+Allocate resources to resolve high priority issues promptly.
+
+104
+00:08:56,000 --> 00:09:03,000
+Integrate automated code analysis tools into the development workflow to catch and address technical
+
+105
+00:09:03,000 --> 00:09:06,000
+debt early in the development process.
+
+106
+00:09:06,000 --> 00:09:11,000
+This proactive approach helps identify issues before they accumulate.
+
+107
+00:09:11,000 --> 00:09:18,000
+Schedule periodic refactoring and code improvement sprints to systematically reuse technical debt over
+
+108
+00:09:18,000 --> 00:09:19,000
+time.
+
+109
+00:09:19,000 --> 00:09:26,000
+Allocate dedicated time during the development cycles to address identified tech debt items.
+
+110
+00:09:27,000 --> 00:09:34,000
+Foster a culture of code quality and refactoring within the development team and encourage best practices.
+
+111
+00:09:34,000 --> 00:09:41,000
+Conduct regular code reviews and emphasize the importance of writing clean, maintainable code.
+
+112
+00:09:41,000 --> 00:09:47,000
+Regularly address high priority technical debt items identified through ongoing assessments.
+
+113
+00:09:47,000 --> 00:09:54,000
+Implement a consistent schedule for addressing these items to prevent them from escalating, and in
+
+114
+00:09:54,000 --> 00:10:02,000
+case you are in green zone of your KPI, add technical debt items to the iteration plan based on priority
+
+115
+00:10:02,000 --> 00:10:05,000
+and if capacity allows.
+
+116
+00:10:05,000 --> 00:10:11,000
+This can be done alongside feature development and ensuring a balanced approach that addresses tech
+
+117
+00:10:11,000 --> 00:10:14,000
+debt without compromising new functionalities.
+
+118
+00:10:15,000 --> 00:10:21,000
+These recommended actions provide a strategic approach for development teams to manage technical debt
+
+119
+00:10:21,000 --> 00:10:25,000
+effectively, based on the tech debt ratio.
+
+120
+00:10:25,000 --> 00:10:31,000
+Promoting the balance between addressing critical issues and fostering continuous improvement in code
+
+121
+00:10:31,000 --> 00:10:32,000
+quality.
+
+122
+00:10:32,000 --> 00:10:36,000
+So let's make a brief summary about this metric.
+
+123
+00:10:36,000 --> 00:10:42,000
+Understanding and managing technical debt is crucial for sustainable software development.
+
+124
+00:10:42,000 --> 00:10:50,000
+The tech that ratio provides a clear signal for teams to balance innovation, building new features
+
+125
+00:10:50,000 --> 00:10:53,000
+with the necessary maintenance.
+
+126
+00:10:53,000 --> 00:11:00,000
+Addressing technical debt to ensure the long tum health of their software projects.
+
+127
+00:11:00,000 --> 00:11:03,000
+Just like taking care of a house.
+
+128
+00:11:03,000 --> 00:11:10,000
+Keeping technical debt in check ensures a stable foundation for continuous growth and improvement in
+
+129
+00:11:10,000 --> 00:11:11,000
+software development.
+
+130
+00:11:11,000 --> 00:11:17,000
+The next metric that we are going to review is stack that index the same as previous metric.
+
+131
+00:11:17,000 --> 00:11:19,000
+It relates to technical debt.
+
+132
+00:11:20,000 --> 00:11:27,000
+The technical debt index is a metric that quantifies the overall technical debt within a software project.
+
+133
+00:11:28,000 --> 00:11:36,000
+Technical debt consists of the consequences of decisions taken, compromises and suboptimal design or
+
+134
+00:11:36,000 --> 00:11:40,000
+coding choices made during the development process.
+
+135
+00:11:40,000 --> 00:11:48,000
+This metric aims to measure the cumulative impact of these decisions, highlighting areas that may require
+
+136
+00:11:48,000 --> 00:11:49,000
+future attention.
+
+137
+00:11:50,000 --> 00:11:54,000
+Let's review use cases for real life analogy.
+
+138
+00:11:54,000 --> 00:11:59,000
+Consider technical debt as a delayed maintenance of a vehicle.
+
+139
+00:12:00,000 --> 00:12:08,000
+If you postpone necessary repairs, the overall condition of the vehicle degrades, requiring more effort
+
+140
+00:12:08,000 --> 00:12:10,000
+to address in the future.
+
+141
+00:12:10,000 --> 00:12:17,000
+Similarly, in software development, postponing necessary improvements can accumulate technical debt,
+
+142
+00:12:17,000 --> 00:12:22,000
+leading to increased maintenance efforts and challenges in future development.
+
+143
+00:12:22,000 --> 00:12:30,000
+Imagine a project where developers make rational decisions to meet tight deadlines, resulting in less
+
+144
+00:12:30,000 --> 00:12:31,000
+than optimal code.
+
+145
+00:12:32,000 --> 00:12:40,000
+As the project progresses, the team realizes that these decisions accumulate technical debt, impacting
+
+146
+00:12:40,000 --> 00:12:42,000
+system stability and future development.
+
+147
+00:12:43,000 --> 00:12:45,000
+How to measure this metric.
+
+148
+00:12:46,000 --> 00:12:53,000
+The technical debt index is calculated by summing the values of identified technical debt items.
+
+149
+00:12:53,000 --> 00:13:00,000
+These items can be measured in various units such as hours, days, study points, or other relevant
+
+150
+00:13:00,000 --> 00:13:01,000
+measurement units.
+
+151
+00:13:02,000 --> 00:13:10,000
+Like I already said, it is recommended to track tech debt separately using labels, epics or containers
+
+152
+00:13:10,000 --> 00:13:12,000
+in task management system.
+
+153
+00:13:12,000 --> 00:13:17,000
+We already discussed this during the review of tech debt ratio metric.
+
+154
+00:13:17,000 --> 00:13:21,000
+The recommendations for tech debt tracking are the same.
+
+155
+00:13:22,000 --> 00:13:25,000
+Interpretation how to read this value.
+
+156
+00:13:26,000 --> 00:13:30,000
+Think of technical debt as a growing to do list.
+
+157
+00:13:30,000 --> 00:13:35,000
+The longer the list, the more work is needed to enhance the system.
+
+158
+00:13:35,000 --> 00:13:43,000
+A higher technical debt index indicates a greater need for future refactoring or improvement efforts,
+
+159
+00:13:43,000 --> 00:13:49,000
+while lower levels suggest a code base that requires less immediate attention.
+
+160
+00:13:50,000 --> 00:13:54,000
+Let's talk about target KPIs that we aim to achieve.
+
+161
+00:13:55,000 --> 00:14:03,000
+The recommended target KPI is influenced by various factors such as tech debt, potential impact, project
+
+162
+00:14:03,000 --> 00:14:06,000
+duration, team seniority, and more.
+
+163
+00:14:06,000 --> 00:14:14,000
+High levels of technical debt suggest a greater need for future improvements, while lower levels indicate
+
+164
+00:14:14,000 --> 00:14:17,000
+a code base required less immediate attention.
+
+165
+00:14:18,000 --> 00:14:22,000
+There is another point that you should always remember about.
+
+166
+00:14:22,000 --> 00:14:29,000
+Imagine that you have technical debt that would increase cost of implementation of new feature ten times
+
+167
+00:14:29,000 --> 00:14:30,000
+more.
+
+168
+00:14:30,000 --> 00:14:37,000
+And in case you would refactor the code, change the design to achieve better code reusability, you
+
+169
+00:14:37,000 --> 00:14:40,000
+would save time for implementation of the new feature.
+
+170
+00:14:40,000 --> 00:14:46,000
+You will save time for testing new feature because existing code is tested already.
+
+171
+00:14:46,000 --> 00:14:48,000
+Thus you will save a lot of money.
+
+172
+00:14:48,000 --> 00:14:56,000
+Of course, this is just one test that work item, but it converts hundreds of other tasks that work
+
+173
+00:14:56,000 --> 00:15:02,000
+items like refactoring unit tests in modules that rarely used, for example.
+
+174
+00:15:02,000 --> 00:15:10,000
+So any way you will prioritize one technical debt work item over others and when you will measure tech
+
+175
+00:15:10,000 --> 00:15:18,000
+debt, you can also include priority scale to understand how many of high priority tech debt items you
+
+176
+00:15:18,000 --> 00:15:22,000
+have, and how many low priority tax debt items you have.
+
+177
+00:15:22,000 --> 00:15:29,000
+That's why for this specific metric, it is hard to recommend some specific and measurable KPIs because,
+
+178
+00:15:29,000 --> 00:15:36,000
+as you already understand, project specifics impacts a lot on KPIs for this metric.
+
+179
+00:15:37,000 --> 00:15:43,000
+Let's review recommended actions and what you can do to achieve KPIs.
+
+180
+00:15:43,000 --> 00:15:50,000
+So all advices from review of previous metric, like prioritizing critical technical debt items and
+
+181
+00:15:50,000 --> 00:15:54,000
+schedule periodic refactoring are applicable in this case too.
+
+182
+00:15:55,000 --> 00:16:02,000
+On top of that, I would like to give some more recommendations using sites from technical debt assessments
+
+183
+00:16:02,000 --> 00:16:10,000
+to set development practices, implement coding standards, conduct code reviews, and emphasize code
+
+184
+00:16:10,000 --> 00:16:15,000
+quality in the development process to prevent the accumulation of similar issues.
+
+185
+00:16:15,000 --> 00:16:20,000
+Communicate the importance of managing technical debt to stakeholders.
+
+186
+00:16:20,000 --> 00:16:28,000
+Provide clear explanation of how addressing technical debt contributes to a more sustainable and adaptable
+
+187
+00:16:28,000 --> 00:16:30,000
+software development process.
+
+188
+00:16:30,000 --> 00:16:38,000
+Plan work accordingly by incorporating tech debt into the regular work plan dependent on established
+
+189
+00:16:38,000 --> 00:16:39,000
+KPIs.
+
+190
+00:16:39,000 --> 00:16:47,000
+Allocate a portion of development cycles to address identified tech debt items alongside feature development.
+
+191
+00:16:47,000 --> 00:16:54,000
+And take my recommendation here if you would think that someday in the future, you will be given by
+
+192
+00:16:54,000 --> 00:17:00,000
+business stakeholders to weeks or months to address all tech debt.
+
+193
+00:17:00,000 --> 00:17:01,000
+Never believes this.
+
+194
+00:17:02,000 --> 00:17:02,000
+Really.
+
+195
+00:17:02,000 --> 00:17:03,000
+I'm not joking.
+
+196
+00:17:03,000 --> 00:17:11,000
+No matter how confident you are in the person business, very rarely, almost never prioritize work
+
+197
+00:17:11,000 --> 00:17:15,000
+on technical debt over new feature development.
+
+198
+00:17:15,000 --> 00:17:17,000
+So plan work on tech debt.
+
+199
+00:17:17,000 --> 00:17:25,000
+Gradually sprint by sprint, iteration by iteration by adding new portion of tech debt into each new
+
+200
+00:17:25,000 --> 00:17:26,000
+scope of work.
+
+201
+00:17:26,000 --> 00:17:33,000
+Pay attention to the potential impact and risks associated with different tech debt items.
+
+202
+00:17:33,000 --> 00:17:36,000
+Understand that not all items are equal.
+
+203
+00:17:36,000 --> 00:17:42,000
+One critical tag that item may impact the entire application's architecture.
+
+204
+00:17:43,000 --> 00:17:43,000
+Prioritize.
+
+205
+00:17:43,000 --> 00:17:47,000
+Work wisely based on potential risks and impacts.
+
+206
+00:17:48,000 --> 00:17:56,000
+If your project manager ensures that team validates and evaluates tech debt on regular basis, encourage
+
+207
+00:17:56,000 --> 00:18:02,000
+a culture of continuous improvement, emphasizing the value of addressing tech debt for long terme project
+
+208
+00:18:02,000 --> 00:18:03,000
+success.
+
+209
+00:18:03,000 --> 00:18:11,000
+To sum it up, the Technical Debt Index helps development teams and stakeholders understand the long
+
+210
+00:18:11,000 --> 00:18:14,000
+tum implications of technical decisions.
+
+211
+00:18:14,000 --> 00:18:21,000
+It emphasizes the need to balance speed with code quality, highlighting areas that may require.
+
+212
+00:18:22,000 --> 00:18:23,000
+Future attention.
+
+213
+00:18:23,000 --> 00:18:31,000
+The metric helps in planning by evaluating the amount of technical debt, allowing for informed decision
+
+214
+00:18:31,000 --> 00:18:35,000
+making during the planning of the next reporting period.
+
+215
+00:18:35,000 --> 00:18:42,000
+It encourages teams to prioritize wisely, addressing critical technical debt items that may impact
+
+216
+00:18:42,000 --> 00:18:45,000
+stability or maintainability.
+
+217
+00:18:45,000 --> 00:18:54,000
+Project managers play a crucial role in ensuring teams regularly validate and evaluate tech debt, allocating
+
+218
+00:18:54,000 --> 00:19:00,000
+time for periodic refactoring and code improvement sprints to reduce technical debt over time.
+
+219
+00:19:01,000 --> 00:19:07,000
+Communicating the importance of managing technical debt to stakeholders ensures it is considered in
+
+220
+00:19:07,000 --> 00:19:13,000
+project planning and decision making, contributing to a more sustainable and maintainable software
+
+221
+00:19:13,000 --> 00:19:14,000
+development process.
+
+222
+00:19:15,000 --> 00:19:16,000
+Let's move on.
+
+223
+00:19:17,000 --> 00:19:22,000
+And the last but not the least metric for today's lesson is Cyclomatic complexity.
+
+224
+00:19:22,000 --> 00:19:28,000
+Cyclomatic complexity is a metric used to measure the complexity of a software programs.
+
+225
+00:19:28,000 --> 00:19:29,000
+Control flow.
+
+226
+00:19:30,000 --> 00:19:37,000
+It provides a numerical value indicating the number of independent paths through a program's source
+
+227
+00:19:37,000 --> 00:19:40,000
+code, representing decision points or branches.
+
+228
+00:19:40,000 --> 00:19:48,000
+This metric helps assess the program's complexity, allowing developers to identify areas that might
+
+229
+00:19:48,000 --> 00:19:51,000
+be challenging to maintain or prone to errors.
+
+230
+00:19:52,000 --> 00:19:57,000
+Let's talk about use cases and let me provide you with real life analogy.
+
+231
+00:19:57,000 --> 00:20:00,000
+Think of a city road network.
+
+232
+00:20:00,000 --> 00:20:06,000
+The more intersections and choices a driver faces, the more complex the route.
+
+233
+00:20:07,000 --> 00:20:14,000
+Similarly, in software, the more decision points in the code, the higher the cyclomatic complexity.
+
+234
+00:20:14,000 --> 00:20:20,000
+Consider a function that involves multiple conditional statements, loops, or branching.
+
+235
+00:20:21,000 --> 00:20:27,000
+The cyclomatic complexity helps quantify the complexity of navigating through these different paths.
+
+236
+00:20:28,000 --> 00:20:31,000
+How to measure this metric and how it is calculated.
+
+237
+00:20:32,000 --> 00:20:42,000
+Cyclomatic complexity is calculated using the formula E minus n plus double P, where E is the number
+
+238
+00:20:42,000 --> 00:20:50,000
+of edges and is the number of nodes, and p is the number of connected components in the control flow
+
+239
+00:20:50,000 --> 00:20:51,000
+graph.
+
+240
+00:20:52,000 --> 00:21:00,000
+Static code analysis tools like Sonarqube automatically calculate Cyclomatic complexity based on the
+
+241
+00:21:00,000 --> 00:21:02,000
+program's control flow graph.
+
+242
+00:21:03,000 --> 00:21:07,000
+So you don't need to worry about calculating this metric manually.
+
+243
+00:21:07,000 --> 00:21:14,000
+In general, using of Sonarqube gives you an opportunity to measure a lot of other development metrics.
+
+244
+00:21:15,000 --> 00:21:17,000
+So how to read this value?
+
+245
+00:21:17,000 --> 00:21:26,000
+A lower cyclomatic complexity value, which is less than five, suggests simpler code with fewer decision
+
+246
+00:21:26,000 --> 00:21:31,000
+points, potentially leading to easier maintenance and fewer errors.
+
+247
+00:21:32,000 --> 00:21:40,000
+A moderate cyclomatic complexity value, which is between 5 and 10, indicates a moderate level of complexity.
+
+248
+00:21:41,000 --> 00:21:48,000
+A higher cyclomatic complexity value, which can be considered as more than ten, suggests more complex
+
+249
+00:21:48,000 --> 00:21:54,000
+code requiring additional attention and possibility refactoring for improved readability.
+
+250
+00:21:55,000 --> 00:22:01,000
+Let's review recommended KPIs that we want to achieve in the red zone.
+
+251
+00:22:01,000 --> 00:22:08,000
+A cyclomatic complexity value exceeding ten points to complex code sections that may resemble a tangle
+
+252
+00:22:08,000 --> 00:22:12,000
+of decision points, loops, and intricate logic.
+
+253
+00:22:12,000 --> 00:22:18,000
+Imagine a function with multiple nested if else statements, each containing further branching.
+
+254
+00:22:19,000 --> 00:22:25,000
+For instance, a payment processing module with numerous conditions for handling various payment methods
+
+255
+00:22:25,000 --> 00:22:29,000
+and exceptions might have high cyclomatic complexity.
+
+256
+00:22:30,000 --> 00:22:37,000
+In this scenario, developers need to prioritize addressing this complexity to enhance maintainability
+
+257
+00:22:37,000 --> 00:22:42,000
+and reduce the risk of introducing errors during future modifications.
+
+258
+00:22:42,000 --> 00:22:51,000
+Entering the umbra zone, where cyclomatic complexity falls between 5 and 10, you may encounter moderately
+
+259
+00:22:51,000 --> 00:22:54,000
+complex code that requires careful attention.
+
+260
+00:22:54,000 --> 00:23:01,000
+Consider a module responsible for user authentication, involving various checks for user roles, permissions,
+
+261
+00:23:01,000 --> 00:23:03,000
+and authentication methods.
+
+262
+00:23:04,000 --> 00:23:07,000
+This could lead to a moderate cyclomatic complexity.
+
+263
+00:23:08,000 --> 00:23:14,000
+Developers should regularly address high priority technical debt items, such as simplifying intricate
+
+264
+00:23:14,000 --> 00:23:19,000
+logic or breaking down complex functions into more manageable units.
+
+265
+00:23:19,000 --> 00:23:26,000
+Code reviews become pivotal to manage the balance between functionality and maintainability.
+
+266
+00:23:26,000 --> 00:23:35,000
+In the green Zone, with cyclomatic complexity below five, the code exhibits simplicity and clarity,
+
+267
+00:23:35,000 --> 00:23:38,000
+resembling a well-organized and straightforward structure.
+
+268
+00:23:39,000 --> 00:23:46,000
+Think of utility functions that performs a specific, clearly defined task with minimal branching.
+
+269
+00:23:46,000 --> 00:23:53,000
+For example, a utility function that converts temperature units or formats dates might have a low cyclomatic
+
+270
+00:23:53,000 --> 00:23:54,000
+complexity.
+
+271
+00:23:55,000 --> 00:24:02,000
+Developers can confidently add technical debt items to the iteration plan, focusing on coding standards
+
+272
+00:24:02,000 --> 00:24:07,000
+and best practices to maintain this favorable level of complexity.
+
+273
+00:24:07,000 --> 00:24:14,000
+The Green Zone represents an environment where code is easy to understand, minimizing the chances of
+
+274
+00:24:14,000 --> 00:24:16,000
+introducing errors during development.
+
+275
+00:24:16,000 --> 00:24:23,000
+Understanding these KPIs in practical terms empowers developers to assess and manage code complexity
+
+276
+00:24:23,000 --> 00:24:29,000
+effectively, ensuring the creation and maintenance of robust and sustainable software.
+
+277
+00:24:30,000 --> 00:24:36,000
+Now let's review some real life scenario and recommended actions to achieve KPI.
+
+278
+00:24:37,000 --> 00:24:44,000
+Imagine you are working on a critical module of an e-commerce application responsible for order processing.
+
+279
+00:24:44,000 --> 00:24:52,000
+The code for handling various audit scenarios has evolved over time, leading to a cyclomatic complexity
+
+280
+00:24:52,000 --> 00:24:53,000
+exceeding ten.
+
+281
+00:24:53,000 --> 00:25:00,000
+The code involves intricate decision points, loops, and nested conditions, making it challenging
+
+282
+00:25:00,000 --> 00:25:02,000
+to comprehend and modify.
+
+283
+00:25:03,000 --> 00:25:05,000
+So what actions can be taken?
+
+284
+00:25:06,000 --> 00:25:11,000
+Identify and prioritize sections of the code with excessive complexity.
+
+285
+00:25:11,000 --> 00:25:18,000
+Collaborate with team members to gain insights into different perspectives on how to address the complexity
+
+286
+00:25:18,000 --> 00:25:19,000
+effectively.
+
+287
+00:25:20,000 --> 00:25:25,000
+Develop a refactoring plan to simplify the complex code sections.
+
+288
+00:25:25,000 --> 00:25:32,000
+Break down large functions into smaller, more manageable ones and streamline decision making processes.
+
+289
+00:25:32,000 --> 00:25:38,000
+Ensure that refactoring efforts are aligned with maintaining or improving functionality.
+
+290
+00:25:39,000 --> 00:25:45,000
+Establish and enforce coding standards and best practices within the development team.
+
+291
+00:25:45,000 --> 00:25:51,000
+Define guidelines for writing clean, modular code and avoiding excessive nesting.
+
+292
+00:25:51,000 --> 00:25:58,000
+Encourage adherence to these standards to prevent the recurrence of high cyclomatic complexity.
+
+293
+00:25:59,000 --> 00:26:05,000
+Organize training sessions on knowledge sharing forums to enhance the team's awareness of effective
+
+294
+00:26:05,000 --> 00:26:11,000
+coding practices, refactoring patterns, and strategies to manage complexity.
+
+295
+00:26:11,000 --> 00:26:16,000
+Foster a learning environment where developers can share insights and experiences.
+
+296
+00:26:17,000 --> 00:26:22,000
+Introduce static code analysis tools such as Sonarqube into the development workflow.
+
+297
+00:26:23,000 --> 00:26:28,000
+Configure these tools to flag errors with high cyclomatic complexity in real time.
+
+298
+00:26:28,000 --> 00:26:34,000
+Use automated analysis to catch and address complexity issues early in the development cycle.
+
+299
+00:26:35,000 --> 00:26:41,000
+By following these recommended actions, developers can effectively address high cyclomatic complexity,
+
+300
+00:26:41,000 --> 00:26:47,000
+fostering a code base that is more understandable, maintainable, and less prone to errors.
+
+301
+00:26:48,000 --> 00:26:51,000
+Let's make a conclusion about this metric.
+
+302
+00:26:51,000 --> 00:26:57,000
+Cyclomatic complexity is a metric that quantifies code complexity based on decision points.
+
+303
+00:26:57,000 --> 00:27:04,000
+It helps developers identify complex areas, assess code quality, and make informed decisions during
+
+304
+00:27:04,000 --> 00:27:06,000
+code analysis.
+
+305
+00:27:06,000 --> 00:27:13,000
+Lower cyclomatic complexity values indicates simpler code, while higher values may suggest areas requiring
+
+306
+00:27:13,000 --> 00:27:16,000
+attention and possible refactoring.
+
+307
+00:27:17,000 --> 00:27:23,000
+The Metric Alliance was testing guidance, maintenance efforts, and overall software risk assessment
+
+308
+00:27:23,000 --> 00:27:24,000
+in the development process.
+
+309
+00:27:25,000 --> 00:27:26,000
+That's all.
+
+310
+00:27:26,000 --> 00:27:28,000
+What I wanted to share with you in this lesson.
+
+311
+00:27:29,000 --> 00:27:32,000
+Let's recap what we have learned today.
+
+312
+00:27:32,000 --> 00:27:38,000
+Today we learned three metrics from my personal metrics library from Engineering Excellence section
+
+313
+00:27:38,000 --> 00:27:40,000
+and Development area.
+
+314
+00:27:40,000 --> 00:27:47,000
+We learned tech debt ratio tech that index, and Cyclomatic complexity metric.
+
+315
+00:27:47,000 --> 00:27:54,000
+For each metric, we reviewed practical use cases, recommended KPIs, and recommended actions about
+
+316
+00:27:54,000 --> 00:27:56,000
+how you can achieve the KPI.
+
+317
+00:27:57,000 --> 00:27:58,000
+That's it.
+
+318
+00:27:58,000 --> 00:28:00,000
+Thank you all for your attention.
+
+319
+00:28:00,000 --> 00:28:03,000
+Have a great day and see you in the next lesson.
+

110 - Metrics & KPIs to Monitor and Control Software Development Process/006 Development Metrics & KPIs Unit Test Related Metrics - Part 1_en.srt

@@ -0,0 +1,772 @@
+1
+00:00:05,000 --> 00:00:06,000
+Hello dear students.
+
+2
+00:00:06,000 --> 00:00:12,000
+In this lesson we continue learning metrics from engineering excellence, practice from development
+
+3
+00:00:12,000 --> 00:00:19,000
+area and today we'll learn the unit test run, success rate, unit test code coverage and incremental
+
+4
+00:00:19,000 --> 00:00:20,000
+unit test coverage.
+
+5
+00:00:21,000 --> 00:00:27,000
+For today's lesson, it is important to you to understand the concept of unit testing because we'll
+
+6
+00:00:27,000 --> 00:00:30,000
+review metrics that are related with unit testing.
+
+7
+00:00:31,000 --> 00:00:36,000
+That's why we'll start our lesson from learning and refreshing the knowledge about unit testing concept.
+
+8
+00:00:37,000 --> 00:00:45,000
+I will explain you how unit tests work, what benefits of unit tests are, and what challenges and limitations
+
+9
+00:00:45,000 --> 00:00:48,000
+of unit tests you should be aware about.
+
+10
+00:00:48,000 --> 00:00:53,000
+And after that, we'll focus on learning three metrics that I already mentioned.
+
+11
+00:00:54,000 --> 00:01:01,000
+During review of each metric, we'll learn its definition, use cases, how to measure how to read metrics
+
+12
+00:01:01,000 --> 00:01:08,000
+and interpret them, what are recommended target KPIs, and what are recommended actions that you can
+
+13
+00:01:08,000 --> 00:01:10,000
+do after analysis of metrics.
+
+14
+00:01:11,000 --> 00:01:12,000
+Let's start the lesson.
+
+15
+00:01:13,000 --> 00:01:18,000
+As I already mentioned, all metrics that we are going to review today are connected with one single
+
+16
+00:01:18,000 --> 00:01:21,000
+concept unit testing.
+
+17
+00:01:21,000 --> 00:01:27,000
+So in case you are not familiar with this concept, let me explain it to you so that you can understand
+
+18
+00:01:27,000 --> 00:01:30,000
+the concept of metrics introduced in this lesson.
+
+19
+00:01:31,000 --> 00:01:37,000
+Unit tests are fundamental aspect of software development involving the testing of individual units
+
+20
+00:01:37,000 --> 00:01:39,000
+are components of code.
+
+21
+00:01:39,000 --> 00:01:47,000
+In isolation, a unit typically refers to the smallest testable part of an application, such as function,
+
+22
+00:01:47,000 --> 00:01:48,000
+method, or class.
+
+23
+00:01:49,000 --> 00:01:55,000
+The primary goal of unit testing is to validate that each unit of the software performs as designed,
+
+24
+00:01:55,000 --> 00:01:59,000
+ensuring its correctness and reliability.
+
+25
+00:01:59,000 --> 00:02:02,000
+Let's understand how unit tests work.
+
+26
+00:02:03,000 --> 00:02:09,000
+There are four principles isolation, automation, fast execution, and assertion.
+
+27
+00:02:10,000 --> 00:02:11,000
+Isolation.
+
+28
+00:02:11,000 --> 00:02:19,000
+Unit tests focus on a specific piece of code in isolation, excluding external dependencies or interactions.
+
+29
+00:02:19,000 --> 00:02:23,000
+This isolation helps pinpoint issues within the unit itself.
+
+30
+00:02:24,000 --> 00:02:31,000
+Automation unit tests are automated, meaning they are written as code and executed automatically as
+
+31
+00:02:31,000 --> 00:02:33,000
+part of the development or testing process.
+
+32
+00:02:34,000 --> 00:02:38,000
+This automation ensures consistent and repeatable testing.
+
+33
+00:02:38,000 --> 00:02:40,000
+Fast execution.
+
+34
+00:02:40,000 --> 00:02:45,000
+Unit tests are designed to be fast, allowing for quick verification of individual units.
+
+35
+00:02:46,000 --> 00:02:52,000
+Fast execution enables developers to run tests frequently during development, catching issues early
+
+36
+00:02:52,000 --> 00:02:54,000
+in the process.
+
+37
+00:02:54,000 --> 00:03:01,000
+Assertion unit tests include assertions that verify specific conditions or behaviors within the unit.
+
+38
+00:03:01,000 --> 00:03:07,000
+If an assertion fails during testing, it indicates a potential issue in the code.
+
+39
+00:03:08,000 --> 00:03:12,000
+There is also another terms that describes unit testing.
+
+40
+00:03:12,000 --> 00:03:13,000
+It is called first.
+
+41
+00:03:14,000 --> 00:03:18,000
+First stands for fast, isolated, repeatable self-validating sorrow.
+
+42
+00:03:19,000 --> 00:03:21,000
+But this is not the lesson about programming.
+
+43
+00:03:21,000 --> 00:03:27,000
+I believe you already understood the main concept, and if you want to learn more about unit testing,
+
+44
+00:03:27,000 --> 00:03:34,000
+including details about first terms, this is another topic that I learned with my students in my course
+
+45
+00:03:34,000 --> 00:03:36,000
+Java from zero to First Job.
+
+46
+00:03:36,000 --> 00:03:42,000
+And in case you have any questions, please do not hesitate to post your questions below the video and
+
+47
+00:03:42,000 --> 00:03:44,000
+I will be happy to answer.
+
+48
+00:03:44,000 --> 00:03:48,000
+At the meantime, let's get back to our agenda of this lesson.
+
+49
+00:03:48,000 --> 00:03:53,000
+Let's discuss benefits of unit testing, early detection of issues.
+
+50
+00:03:53,000 --> 00:04:00,000
+Unit tests help identify and fix issues at the earliest stage of development, reducing the likelihood
+
+51
+00:04:00,000 --> 00:04:03,000
+of bugs propagating to later stages.
+
+52
+00:04:03,000 --> 00:04:05,000
+Documentation.
+
+53
+00:04:05,000 --> 00:04:12,000
+Unit tests serve as executable documentation in providing insights into how each unit of code is intended
+
+54
+00:04:12,000 --> 00:04:13,000
+to function.
+
+55
+00:04:14,000 --> 00:04:18,000
+This helps developers who may work on the code in the future.
+
+56
+00:04:19,000 --> 00:04:23,000
+Facilitates refactoring with a robust suite of unit tests.
+
+57
+00:04:23,000 --> 00:04:31,000
+Developers gain confidence to refactor or modify code if the tests pass after changes, it indicates
+
+58
+00:04:31,000 --> 00:04:34,000
+that the functionality remains intact.
+
+59
+00:04:35,000 --> 00:04:38,000
+But what are challenges and limitations of unit testing?
+
+60
+00:04:39,000 --> 00:04:41,000
+First of all, it is limited scope.
+
+61
+00:04:41,000 --> 00:04:49,000
+Unit tests focus on isolated units, and some issues may only be notable when components interact.
+
+62
+00:04:49,000 --> 00:04:55,000
+Additional testing layers, such as integration and end to end testing are needed for comprehensive
+
+63
+00:04:55,000 --> 00:04:55,000
+coverage.
+
+64
+00:04:56,000 --> 00:05:01,000
+Another things that you need to remember is maintenance overhead as code evolves.
+
+65
+00:05:01,000 --> 00:05:05,000
+Unit tests may require updates to align with changes.
+
+66
+00:05:05,000 --> 00:05:11,000
+While this ensures test relevance, it also introduces maintenance overhead.
+
+67
+00:05:11,000 --> 00:05:15,000
+Unit test is a code that you also need to support.
+
+68
+00:05:15,000 --> 00:05:22,000
+Never forget about this and let me share with you real life analogy to help you understand better what
+
+69
+00:05:22,000 --> 00:05:23,000
+unit tests are.
+
+70
+00:05:24,000 --> 00:05:29,000
+Unit tests can be linked to quality control checks in a manufacturing process.
+
+71
+00:05:29,000 --> 00:05:37,000
+Each component undergoes specific tests to ensure it meets quality standards before being integrated
+
+72
+00:05:37,000 --> 00:05:38,000
+into the final product.
+
+73
+00:05:39,000 --> 00:05:43,000
+This systematic approach enhances the overall reliability of the product.
+
+74
+00:05:44,000 --> 00:05:47,000
+And now let's start the metrics review.
+
+75
+00:05:47,000 --> 00:05:52,000
+We will start from the definition of unit test run success rate metric.
+
+76
+00:05:53,000 --> 00:06:00,000
+The test run success rate is a vital metric that quantifies the percentage of successfully passed unit
+
+77
+00:06:00,000 --> 00:06:04,000
+tests out of the total executed within a software project.
+
+78
+00:06:05,000 --> 00:06:12,000
+Unit tests integral to the software development process are thoroughly created to check specific parts
+
+79
+00:06:12,000 --> 00:06:14,000
+of the code, one at a time.
+
+80
+00:06:14,000 --> 00:06:21,000
+These tests play a pivotal role in guaranteeing the reliability and robustness of software application
+
+81
+00:06:21,000 --> 00:06:26,000
+by verifying the correctness of specific components within the code base.
+
+82
+00:06:26,000 --> 00:06:33,000
+In essence, the unit test run success rate encapsulates the effectiveness of the unit testing process,
+
+83
+00:06:33,000 --> 00:06:39,000
+providing insights into the health and dependability of the software under research.
+
+84
+00:06:39,000 --> 00:06:46,000
+This metric serves as a barometer for development teams, offering a quantitative measure of how well
+
+85
+00:06:46,000 --> 00:06:49,000
+individual units of code perform in isolation.
+
+86
+00:06:50,000 --> 00:06:53,000
+To understand it better, let's review use cases.
+
+87
+00:06:54,000 --> 00:06:56,000
+Let me start with real life analogy.
+
+88
+00:06:57,000 --> 00:07:02,000
+Imagine assembling a puzzle where each piece represents a unit of code.
+
+89
+00:07:03,000 --> 00:07:09,000
+Unit tests are like verifying that each puzzle piece fits perfectly before completing the entire picture.
+
+90
+00:07:09,000 --> 00:07:18,000
+If each piece, which is a unit test fits accurately the final picture, the software application is
+
+91
+00:07:18,000 --> 00:07:21,000
+more likely to be correct and functional.
+
+92
+00:07:22,000 --> 00:07:24,000
+Let's consider another real life analogy.
+
+93
+00:07:24,000 --> 00:07:28,000
+Think of unit tests as checkpoints in construction projects.
+
+94
+00:07:29,000 --> 00:07:37,000
+Each checkpoint ensures that specific components like electrical wiring or plumbing function correctly.
+
+95
+00:07:37,000 --> 00:07:44,000
+Similarly, unit tests validate the functionality of isolated code units, ensuring the entire system
+
+96
+00:07:44,000 --> 00:07:45,000
+works seamlessly.
+
+97
+00:07:46,000 --> 00:07:49,000
+Now let's review use cases from software development area.
+
+98
+00:07:50,000 --> 00:07:53,000
+Consider navigation system in car software.
+
+99
+00:07:54,000 --> 00:08:01,000
+Unit tests could be designed to validate specific components such as calculating distances, ensuring
+
+100
+00:08:01,000 --> 00:08:06,000
+accurate turn by turn directions, and confirming the responsiveness of the interface.
+
+101
+00:08:07,000 --> 00:08:13,000
+Each unit tests ensures these critical functionalities work independently and collaboratively.
+
+102
+00:08:14,000 --> 00:08:16,000
+Another software development scenario.
+
+103
+00:08:16,000 --> 00:08:19,000
+Consider an e-commerce application.
+
+104
+00:08:19,000 --> 00:08:25,000
+Unit tests could verify individual components such as product sorting or payment processing, guaranteeing
+
+105
+00:08:25,000 --> 00:08:30,000
+these functionalities work independently and as part of the whole system.
+
+106
+00:08:31,000 --> 00:08:33,000
+So how we can measure this metric?
+
+107
+00:08:34,000 --> 00:08:39,000
+Determining the unit test run success rate involves a straightforward calculation.
+
+108
+00:08:40,000 --> 00:08:47,000
+The formula is expressed as successful runs divided by total runs multiplied by 100.
+
+109
+00:08:48,000 --> 00:08:54,000
+This process entails counting the number of unit tests that have successfully passed and dividing this
+
+110
+00:08:54,000 --> 00:08:57,000
+count by the total number of tests executed.
+
+111
+00:08:58,000 --> 00:09:05,000
+In essence, this calculation provides a percentage that reflects the proportion of unit tests that
+
+112
+00:09:05,000 --> 00:09:09,000
+have executed successfully out of the total number of tests conducted.
+
+113
+00:09:09,000 --> 00:09:17,000
+This straightforward formula encapsulates the essence of the metric, offering a clear and concise way
+
+114
+00:09:17,000 --> 00:09:21,000
+to quantify the success rate of unit tests in a software project.
+
+115
+00:09:22,000 --> 00:09:30,000
+Such unit test frameworks for different programming languages like JUnit testing for Java and unit for.
+
+116
+00:09:30,000 --> 00:09:32,000
+Net Pytest for Python.
+
+117
+00:09:32,000 --> 00:09:35,000
+Mocha for JavaScript R.
+
+118
+00:09:35,000 --> 00:09:40,000
+Spark for Ruby PHP unit for PHP can help you to measure this metric.
+
+119
+00:09:41,000 --> 00:09:43,000
+So let's answer another question.
+
+120
+00:09:43,000 --> 00:09:47,000
+What does the value of metric means for us and how to understand it?
+
+121
+00:09:47,000 --> 00:09:55,000
+A unit test run success rate close to 100 signifies a high degree of confidence in the reliability and
+
+122
+00:09:55,000 --> 00:09:56,000
+correctness of the code.
+
+123
+00:09:57,000 --> 00:10:04,000
+It indicates that the individual units of code, when tested in isolation, are functioning as intended.
+
+124
+00:10:05,000 --> 00:10:11,000
+A lower success rate may suggest issues such as bugs, incomplete implementations, or changes in the
+
+125
+00:10:11,000 --> 00:10:15,000
+code that have not been adequately addressed in the tests.
+
+126
+00:10:16,000 --> 00:10:20,000
+This can raise concerns about the overall robustness of the software.
+
+127
+00:10:21,000 --> 00:10:24,000
+Let's review recommended target KPIs.
+
+128
+00:10:25,000 --> 00:10:28,000
+Red zone below 95%.
+
+129
+00:10:29,000 --> 00:10:37,000
+A unit test run success rate below 95% raises concerns about the reliability of the testing process.
+
+130
+00:10:37,000 --> 00:10:45,000
+For example, if out of 100 unit tests only 90 are passing, it suggests that there might be critical
+
+131
+00:10:45,000 --> 00:10:49,000
+issues impacting the functionality and correctness of the code.
+
+132
+00:10:49,000 --> 00:10:55,000
+In such cases, developers should promptly address identified issues to ensure the software remains
+
+133
+00:10:55,000 --> 00:10:56,000
+robust.
+
+134
+00:10:57,000 --> 00:11:09,000
+Amazon between 95 to 99%, falling within 9,599% range indicates a moderately reliable test suit.
+
+135
+00:11:09,000 --> 00:11:18,000
+For instance, if 97 out of 100 unit tests pass, it suggests that the majority of tests are successful,
+
+136
+00:11:18,000 --> 00:11:21,000
+but there might be some errors requiring attention.
+
+137
+00:11:22,000 --> 00:11:28,000
+Developers should thoroughly investigate and address issues to improve the overall success rate, and
+
+138
+00:11:28,000 --> 00:11:31,000
+green zone is equal to 100%.
+
+139
+00:11:32,000 --> 00:11:40,000
+Achieving a 100% success rate is the ideal scenario, indicating a highly reliable unit test suit.
+
+140
+00:11:40,000 --> 00:11:47,000
+For example, if all 100 unit tests pass successfully, it provides a high level of assurance regarding
+
+141
+00:11:47,000 --> 00:11:50,000
+the quality and functionality of the code.
+
+142
+00:11:50,000 --> 00:11:58,000
+This implies that every individual unit of code, when tested in isolation, is functioning as intended,
+
+143
+00:11:58,000 --> 00:12:02,000
+contributing to a robust and error free software application.
+
+144
+00:12:02,000 --> 00:12:06,000
+These examples illustrate how the unit test runs success rate.
+
+145
+00:12:06,000 --> 00:12:13,000
+KPI serves as a practical benchmark for assessing the effectiveness of the testing process and ensuring
+
+146
+00:12:13,000 --> 00:12:15,000
+the reliability of the software code.
+
+147
+00:12:16,000 --> 00:12:22,000
+Being a consultant and doing audits on different projects, I saw cases when engineers just disable
+
+148
+00:12:22,000 --> 00:12:24,000
+failed unit tests.
+
+149
+00:12:24,000 --> 00:12:31,000
+For example, they think that tests are failed because they updated logic and it is expected that tests
+
+150
+00:12:31,000 --> 00:12:35,000
+to be failed, but no new test is introduced.
+
+151
+00:12:35,000 --> 00:12:38,000
+Instead, it is not recommended to do this.
+
+152
+00:12:38,000 --> 00:12:47,000
+Besides cases when unit tests are old and obsolete, unit tests are not relevant and new unit tests
+
+153
+00:12:47,000 --> 00:12:48,000
+are introduced instead.
+
+154
+00:12:49,000 --> 00:12:56,000
+But in general, if there was a unit test to test some class, you need to make sure that it works as
+
+155
+00:12:56,000 --> 00:12:57,000
+expected.
+
+156
+00:12:57,000 --> 00:13:04,000
+Thoroughly check failed unit tests or better start your development with creation of unit tests.
+
+157
+00:13:05,000 --> 00:13:09,000
+I have a separate section about test driven development in my course.
+
+158
+00:13:09,000 --> 00:13:12,000
+Software Architecture and Clean Code Design.
+
+159
+00:13:12,000 --> 00:13:16,000
+Taking into account TDD is not a subject of this course.
+
+160
+00:13:16,000 --> 00:13:18,000
+We will not go deep in it.
+
+161
+00:13:19,000 --> 00:13:20,000
+Let's continue.
+
+162
+00:13:20,000 --> 00:13:24,000
+So what actions can be taken based on analysis of the metric?
+
+163
+00:13:25,000 --> 00:13:32,000
+First of all, fix the code address code issues causing test failures to ensure the continued functionality
+
+164
+00:13:32,000 --> 00:13:34,000
+and correctness of the software.
+
+165
+00:13:35,000 --> 00:13:38,000
+The second option can be to fix the unit test.
+
+166
+00:13:39,000 --> 00:13:46,000
+Update unit tests to reflect valid changes in requirements, ensuring that tests accurately represent
+
+167
+00:13:46,000 --> 00:13:48,000
+the intended functionality of the code.
+
+168
+00:13:49,000 --> 00:13:52,000
+Another option is to mute or remove tests.
+
+169
+00:13:53,000 --> 00:13:58,000
+Mute or remove irrelevant tests due to significant requirement changes.
+
+170
+00:13:58,000 --> 00:14:00,000
+Streamlining the testing suite.
+
+171
+00:14:01,000 --> 00:14:03,000
+Carefully document decisions.
+
+172
+00:14:04,000 --> 00:14:08,000
+Do not forget to introduce new unit tests for updated logic.
+
+173
+00:14:09,000 --> 00:14:16,000
+There can be case when you removed a lot of code from the class, and it contains simplified logic with
+
+174
+00:14:16,000 --> 00:14:21,000
+multiple new unit tests covered, so just remove old tests.
+
+175
+00:14:22,000 --> 00:14:24,000
+Establish collaborative code review process.
+
+176
+00:14:25,000 --> 00:14:28,000
+Encourage collaborative code reviews with team members.
+
+177
+00:14:28,000 --> 00:14:35,000
+A fresh set of eyes can often identify issues that may be overlooked during individual development.
+
+178
+00:14:36,000 --> 00:14:41,000
+Code reviews also facilitate knowledge sharing and adherence to best practices.
+
+179
+00:14:42,000 --> 00:14:44,000
+Knowledge sharing sessions.
+
+180
+00:14:44,000 --> 00:14:49,000
+Organised knowledge sharing sessions within the team to discuss best practices for writing effective
+
+181
+00:14:49,000 --> 00:14:50,000
+unit tests.
+
+182
+00:14:50,000 --> 00:14:57,000
+Share insights, experiences and strategies to enhance the overall quality of unit testing practices.
+
+183
+00:14:58,000 --> 00:15:04,000
+These recommended actions aim to provide a more comprehensive approach to improving the unit test run
+
+184
+00:15:04,000 --> 00:15:05,000
+success rate.
+
+185
+00:15:06,000 --> 00:15:13,000
+In summary, the unit tests run success rate stands as a pivotal metric in software development, offering
+
+186
+00:15:13,000 --> 00:15:17,000
+a quantitative measure of the reliability of unit tests.
+
+187
+00:15:17,000 --> 00:15:24,000
+This metric serves as a guiding light for developers, steering them towards the path of maintaining
+
+188
+00:15:24,000 --> 00:15:30,000
+high code quality, addressing issues promptly, and fostering a robust testing process.
+
+189
+00:15:31,000 --> 00:15:38,000
+The success rate becomes a compass for developers, directing them towards consistent updates to unit
+
+190
+00:15:38,000 --> 00:15:44,000
+tests, a practice that contributes to the resilience and maintainability of the overall software system.
+
+191
+00:15:45,000 --> 00:15:52,000
+Embracing this metric as a key indicator enables a team to build and maintain software systems that
+
+192
+00:15:52,000 --> 00:15:59,000
+not only meet functional requirements, but also stand resilient in the face of evolving challenges.
+
+193
+00:15:59,000 --> 00:16:01,000
+Let's continue.
+

111 - Extreme Programming - Agile & Lean Development Techniques/007 Test-Driven Development (TDD).html

@@ -0,0 +1,69 @@
+<!DOCTYPE html>
+<html lang="en">
+    <head>
+        <meta charset="UTF-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+        <title>Test-Driven Development (TDD)</title>
+
+        <style>
+            * {
+                box-sizing: border-box;
+                margin: 0;
+                padding: 0;
+            }
+            body {
+                font-family: var(--font-stack-text);
+                font-weight: 400;
+                line-height: 1.4;
+                font-size: 1.6rem;
+                color: #2d2f31;
+            }
+            .container {
+                position: relative;
+                height: 100%;
+                overflow-y: auto;
+            }
+            .content {
+                padding: 3.2rem 4.8rem;
+                word-break: break-word;
+                max-width: 69.6rem;
+                margin: 0 auto;
+            }
+            .heading {
+                margin-bottom: 24px;
+                font-family: -apple-system, BlinkMacSystemFont, Roboto, "Segoe UI", Helvetica, Arial, sans-serif,
+                    "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
+                font-weight: 700;
+                line-height: 1.2;
+                letter-spacing: 0;
+                font-size: 32px;
+                max-width: 36em;
+            }
+            .article-asset-container {
+                padding: 2.4rem;
+            }
+            .article-asset-container p {
+                font-size: 19px;
+            }
+            code {
+                background-color: #fff;
+                border: 1px solid #d1d7dc;
+                color: #b4690e;
+                font-size: 80%;
+                padding: 0.2rem 0.4rem;
+                font-family: sfmono-regular, Consolas, liberation mono, Menlo, Courier, monospace;
+            }
+            p {
+                font-weight: 400;
+            }
+        </style>
+    </head>
+    <body>
+        <div class="container">
+            <div class="content">
+                <div class="heading">Test-Driven Development (TDD)</div>
+                <div class="article-asset-container"><p>Please, check another section in the course that is called "TDD, BDD &amp; ATTD". </p></div>
+            </div>
+        </div>
+    </body>
+</html>