Agile Software Development And how Patterns and Practices constitute

Agenda Why and what “Agile Software Development” Writing SOLID code Framework Design Guidelines Design Patterns Practices Real life

Why and what “Agile Software Development”

Why “Agile Software Development” Customers: Don’t know what they need Define requirements based on existing systems Need to be able to change requirements even late in the process Developers: Don’t know what customers need Interpret requirements based on their experience Must deliver working software

Results The Dutch government looses four up to five billions of euro’s every year! € 5.000.000.000 a year == € 1.585,49 per second € 296,72 per resident

What is “Agile Software Development”? Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight iterations throughout the development cycle.

Agile Manifesto Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan That is, while there is value in the items on the right, we value the items on the left more The Agile Manifesto In February 2001, 17 software developers met at the Snowbird, Utah resort, to discuss lightweight development methods. They published the Manifesto for Agile Software Development to define the approach now known as agile software development. Some of the manifesto's authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto's values and principles.

Writing SOLID code

What is SOLID code Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP) SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the "first five principles" named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design. The principles, when applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time. The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is part of an overall strategy of agile and adaptive programming.

Single Responsibility Principle A class should have only a single responsibility Only one potential change in the software's specification should be able to affect the specification of the class single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

Open/Closed Principle Software should be open for extension, but closed for modification. Open/Closed Principle Abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

Liskov Substitution Principle Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy. It is a semantic rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular.

Interface Segregation Principle No client should be forced to depend on methods it does not use Many client-specific interfaces are better than one general-purpose interface The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.

Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. Dependency Inversion Principle In conventional application architecture, lower-level components are designed to be consumed by higher-level components which enable increasingly complex systems to be built. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed), thus rendering high-level modules independent of the low-level module implementation details.

Result of writing SOLID code Your code will be: Maintainable Extensible Reusable Testable To be able to response to the changes that occur in agile projects all of the above are required!

Framework Design Guidelines

Framework Design Guidelines The Framework Design Guidelines are defined in the book “Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries” by Krzysztof Cwalina and Brad Abrams. These guidelines can also be found at the MSDN site: http://msdn.microsoft.com/en-us/library/ms229042(v=vs.110).aspx The goal of the Framework Design Guidelines is to help library designers ensure API consistency and ease of use by providing a unified programming model that is independent of the programming language used for development. We recommend that you follow these design guidelines when developing classes and components that extend the .NET Framework. Inconsistent library design adversely affects developer productivity and discourages adoption.

What is described in these guidelines? (1) Naming Guidelines Provides guidelines for naming assemblies, namespaces, types, and members in class libraries. Type Design Guidelines Provides guidelines for using static and abstract classes, interfaces, enumerations, structures, and other types. Member Design Guidelines Provides guidelines for designing and using properties, methods, constructors, fields, events, operators, and parameters. Designing for Extensibility Discusses extensibility mechanisms such as subclassing, using events, virtual members, and callbacks, and explains how to choose the mechanisms that best meet your framework's requirements.

What is described in these guidelines? (2) Design Guidelines for Exceptions Describes design guidelines for designing, throwing, and catching exceptions. Usage Guidelines Describes guidelines for using common types such as arrays, attributes, and collections, supporting serialization, and overloading equality operators. Common Design Patterns Provides guidelines for choosing and implementing dependency properties and the dispose pattern.

Result of writing code that aligns with the Framework Design Guidelines It is much more likely that the resulting code will be SOLID Your code will be much more readable and understandable by anyone that is familiar with the .NET framework To be able to work with a development team in agile projects all of the above are required!

Design Patterns

What is a design pattern? A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design

23 basic design patterns by the GoF. Creational Abstract Factory, Builder, Factory Method, Prototype, Singleton Structural Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy Behavioral Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

Singleton Ensure a class only has one instance, and provide a global point of access to it

Proxy Provide a surrogate or placeholder for another object to control access to it

Chain of Responsibility Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it

Result of using Design Patterns Assists in writing SOLID code Prevents reinventing the wheel Speeds up development Allows others to understand your design Allows you to understand the designs of others To deliver a working solution with a team of developers on every sprint all of the above are required!

Practices

What do I mean with practices? Being a good developer Think first, then do Really… think first, then do Follow the framework design guidelines Use existing patterns where possible Design your code (pen and paper, visio, or Visual Studio class designer) Spent extra time on naming conventions Test your code Write secure code (apply STRIDE) Think about logging / error handling Etc.

Result of following these practices? Your code will be: Maintainable, Extensible, Reusable, Testable, Debuggable, Secure, Understandable Allows for much faster development while maintaining decent quality It allows for agile development!

Real life

Understanding code MembershipProvider, ProfileProvider, ClaimsProvider HttpContext.Current, SPContext.Current DbProviderFactories, DbProviderFactory, SqlDbConnection, OleDbConnection, SqlDataAdapter Trace -> Listeners -> EventLogTraceListener, TextWriterTraceListener XmlWriter.Create(…) System.Web.UI.WebControls SPItemEventReceiver.OnAdded … OnAdding... SPItemEventProperties.Cancel

Sample NewsReaderWebPart User story defines a news reader web part that displays news from an RSS Feed

Issues with this design Web Part has to many responsibilities Get data, display the data, store properties Testable nor extensible

Changes in the user story Customer likes to display Atom feeds as well and choose a different view Bad design requires us to change the web part and this goes against the open/closed principle of solid design While the new NewsReaderWebPart in the design below can display multiple feed types the same issues are still there

Results of the previous design Our code implements the SOLID design principles (mostly) If the customer wants news from yet another source, we can extend our solution by creating two new objects f.e. SharePointNewsProviderFactory and SharePointNewsAdapter If we want to implement tests, we can create a TestNewsProviderFactory and TestNewsAdapter Anyone that knows the basic design patterns or has experience with the .NET framework can understand our solution by just looking at the class diagram and the names of the classes By first creating this basic design we are able to generate the code in a very short amount of time

Sample Client Information User story defines a web part that displays and allows for editing client information from Microsoft CRM Initial thought was to fetch the data through BCS in order to be able to also display external lists

Issues with this design Web Part has to many responsibilities again Get data, display the data, store properties Testable nor extensible Web Part has a direct dependency on BCS Calling BCS from code relies on reflection BCS is not strongly typed

Progressive insight BCS could not deliver enough performance to display external lists Client did not actually need external lists The web part rendered to slow 19-9-2018

If it was designed like this in the first place

We could change the design to this

Or even this…

Conclusion Agile development is a farce if the code is not designed with the patterns and practices in mind If you want to be a good developer you need to know the basic patterns and the framework design guidelines Must reads Framework Design Guidelines Design Patterns: Elements of Reusable Object-Oriented Software Writing Secure Code Code Complete 2nd Edition