Scrum and Coding Principles

Coding Principles

• Application Architecture Cross – Cutting concerns (concerns across different layers / modules / classes within the application) should also be addressed.
• Example of some concerns are:
  • Performance & Scalability
  • Layering/partitioning Quality and validation
  • Reusability, Reliability, Availability, Serviceability, and Performance
  • Concurrency
  • Security
  • Maintenance
  • Error Handling
  • Logging
  • Caching and Transaction Management

Clean code principles and best practices

• common closure principal
• single responsibility principal
• decouple construction from runtime

DRY Principle

• Dry refers to the existence of minimum duplication in a code.
• DRY is the principle to avoid repetition of the same information in one system, preventing the same code from being produced multiple times on code base.
• Don’t repeat yourself (DRY) is a principle of software development aimed at reducing repetition and duplication of software codes.
• Don’t repeat yourself (DRY, or sometimes Do not Repeat Yourself) is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.
• The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”.
  • The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer.

DRY Benefits

• It saves overall development time and effort
• Code is easy to maintain
• It reduces the chances of bugs.

DRY and WET solutions

• Violations of DRY are typically referred to as WET solutions.
  • Wet Solutions which stands for either “write everything twice”, “we enjoy typing” or “waste everyone’s time”.
  • It is difficult to manage such code and if the logic changes, then developers have to make changes in all the places where they have written the code, thereby wasting everyone’s time.

Functionality Flow Principle

• Sunny Day, Rainy Day
• Happy Path, Sad Path
• Happy day (or sunny day) scenario and golden path are synonyms for happy path.

Happy-pass Testing

• Happy-path testing (or Sunny Day testing) is a type of software testing that uses known input and produces an expected output.
  • Also referred to as golden-path or sunny-day testing, the happy-path approach is tightly scripted.
  • The happy path does not duplicate real-world conditions and verifies only that the required functionality is in place and functions correctly.
  • If valid alternatives exist, the happy path is then identified as the default scenario or the most likely positive alternative featuring no exceptional or error conditions.
• In the context of software or information modeling, a happy path (sometimes called happy flow) is a default scenario featuring no exceptional or error conditions.
  • For example, the happy path for a function validating credit card numbers would be where none of the validation rules raise an error, thus letting execution continue successfully to the end, generating a positive response.
• Process steps for a happy path are also used in the context of a use case.
  • In contrast to the happy path, process steps for alternate paths and exception paths may also be documented.
• Happy path test is a well-defined test case using known input, which executes without exception and produces an expected output.
  • Happy path testing can show that a system meets its functional requirements but it doesn’t guarantee a graceful handling of error conditions or aid in finding hidden bugs.
• In use case analysis, there is only one happy path, but there may be any number of additional alternate path scenarios which are all valid optional outcomes.
  • If valid alternatives exist, the happy path is then identified as the default or most likely positive alternative.
  • The analysis may also show one or more exception paths.
  • An exception path is taken as the result of a fault condition.
  • Use cases and the resulting interactions are commonly modeled in graphical languages such as the Unified Modeling Language or SysML.

Sad-pass Testing

• Sad Pass (Unhappy Pass, Rainy Day)
• There is no agreed name for the opposite of happy paths : they may be known as sad paths, bad paths, or exception paths.
  • The term ‘unhappy path’ is gaining popularity as it suggests a complete opposite to ‘happy path’ and retains the same context.
  • Usually there is no extra ‘unhappy path’, leaving such ‘term’ meaningless, because the happy path reaches the utter end, but an ‘unhappy path’ is shorter, ends prematurely, and doesn’t reach the desired end, i.e. not even the last page of a wizard.
  • And in contrast to a single happy path, there are a lot of different ways in which things can go wrong, so there is no single criterion to determine ‘the unhappy path’.

KISS Principle

• The KISS principle states that most systems work best if they are kept simple rather than made complicated.
  • It is explained as “Keep it simple, silly”, “keep it short and simple”, “keep it simple and straightforward”, “keep it small and simple” and “keep it stupid simple”.
  • In addition, Simplicity should be a key goal in design.
  • KISS = Keep it simple stupid
  • KISS = Keep it simple, silly
  • KISS = Keep it small and simple

Last Responsible Moment

• A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision, the Last Responsible Moment
• There may not actually be such a thing as a perfect decision, but there certainly is an optimal time to make it.
  • There is a cost of deciding and a cost of deferring and the last responsible moment sits perfectly at the intersection.
  • It will be hard to always perfectly time your decisions, and only you will know where that point is, but the key is to understand that there is an optimal decision making point.
• Options Thinking lead us to invest time and money in delaying decisions to a time where we know the most about it; the extreme application of the Decide as late as possible principle is the concept of Last Responsible Moment, the optimal point of the trade-off between the available time for a decision and the need to complete a story or a task.
• The last responsible moment is the instant in which the cost of the delay of a decision surpasses the benefit of delay; or the moment when failing to take a decision eliminates an important alternative.
  • For example, failing to provide a public HTTP API may make you lose an important customer, forcing you to publish an unfinished work.

Least Privilege Principle

• The principle of least privilege (PoLP; also known as the principle of least authority) is an important concept in computer security, promoting minimal user profile privileges on computers, based on users’ job necessities.
  • It can also be applied to processes on the computer; each system component or process should have the least authority necessary to perform its duties.
  • This helps reduce the “attack surface” of the computer by eliminating unnecessary privileges that can result in network exploits and computer compromises.
  • It can be applied to processes on the computer
  • It is also known as the principle of least authority
  • Promoting minimal user profile privileges on computers, based on users’ job necessities
  • Each system component or process should have the least authority necessary to perform its duties.

Naming Conventions Principle

• Name Standards / Code Conventions make it significantly easier for developers and analysts to understand what the system is doing and how to fix or extend the source code to apply for new needs.
• Every Sprint an Increment with one Functionality need to be produced, otherwise the Product Owner and Stakeholders won’t be able to inspect the increment accurately.

Naming Convention benefits

• To reduce the effort needed to read and understand source code;
• To enable code reviews to focus on more important issues than arguing over syntax and naming standards;
• To enable code quality review tools to focus their reporting mainly on significant issues other than syntax and style preferences;
• To help formalize expectations and promote consistency within a development team;
• To enable the use of automated refactoring or search and replace tools with minimal potential for error;
• To enhance clarity in cases of potential ambiguity;
• To enhance the aesthetic and professional appearance of work product (for example, by disallowing overly long names, comical or “cute” names, or abbreviations);
• To help avoid “naming collisions or frictions” that might occur when the work product of different organizations is combined;
• To provide meaningful data to be used in project handovers which require submission of program source code and all relevant documentation;
• To provide a better understanding in case of code reuse after a long interval of time.

Scout Rule

• The practice of always leaving the code base in a little better state than it was found before modifications, is called the Scout Rule. Scout Rule is a mean to progress towards Clean Code.

SOLID Principle

• SOLID is Object Oriented Design
• S.O.L.I.D is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin, popularly known as Uncle Bob.
  • These principles, when combined together, make it easy for a programmer to develop software that is easy to test, maintain, and extend.
  • They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.
  • It includes the following principles: Single responsibility principle, Open-closed principle, Liskov substitution principle, Interface segregation principle, and Dependency inversion principle.

Single Responsibility Principle

• S – Single-Responsibility Principle – This principle states that an object/class should only have one responsibility and that it should be completely encapsulated by the class.
  • The Single Responsibility Principle says to separate the code that different actors depend on.
    • Also, gather together the things that change for the same reasons.
    • Separate those things that change for different reasons.
    • To sum up, a class should have one and only one reason to change, meaning that a class should have only one job.

Open-closed Principle

• O – Open-Closed Principle, this Principle affirms that an entity allows its behavior to be extended but never by modifying its source code. Any class (or whatever you write) should be written in such a way that it can be used as is.
  • It can be extended if need be, but it can never be modified.
  • Objects or entities should be open for extension but closed for modification.

Liskov Substitution Principle

• L – Liskov Substitution Principle – This Principle confirms that objects should be replaceable by instances of their subtypes without affecting the functioning of your system from a client’s point of view.
  • Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Interface Segregation Principle

• I – Interface Segregation Principle. – This Principle States that once an interface is becoming too large/fat, we absolutely need to split it into small interfaces that are more specific.
  • Interface Segregation principle: A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use

Dependency Inversion Principle

• D – Dependency Inversion Principle. – this principle is primarily concerned with reducing dependencies amongst the code modules.
  • Dependency Inversion principle: Entities must depend on abstractions, not on concretions.
    • It states that the high-level module must not depend on the low-level module, but it should depend on abstractions.

SOLID principles help software developers to achieve scalability and avoid that your code breaks every time you face a change.

Ten-minutes Build Principle

• Ten-minutes Build Principle is non-negotiable rule from eXtreme Programming (XP).
  • When the build runs more than ten minutes, the developers may need to refactor their tests code.
  • When the build runs longer than ten minutes, developers are reluctant to continuously integrate their code.
  • When developers are not continuously integrating their code, they will lose feedback.
  • eXtreme Programming (XP) highly values feedback, faster build means faster feedback.

YAGNI Principle

• YAGNI stands for “You aren’t going to need it“, “You ain’t gonna need it.”
• YAGNI means always implement things when you actually need them, never when you just foresee that you need them.
  • It is a principle behind the eXtreme Programming (XP) practice of “do the simplest thing that could possibly work.”

More informations for the Scrum PSD certification here.

Updated : 02/10/2021