Agile Software Development: Patterns, Practices, and Real-Life Applications
Exploring the significance of Agile Software Development, focusing on writing SOLID code, Framework Design Guidelines, Design Patterns, and best practices. Discover the why and what behind Agile methodologies, with insights on their real-world applications.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
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
What is SOLID code Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP)
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
Open/Closed Principle Software should be open for extension, but closed for modification.
Liskov Substitution Principle Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program
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
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.
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 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!
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!
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!
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 RssNewsReaderWebPart -FeedUrl -ItemCount
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 NewsReaderWebPart -FeedType -FeedUrl -DisplayTemplate -ItemCount
NewsReaderWebPart NewsItem -ProviderType -Id -ConnectionString -DisplayTemplate -Title -Subject -Body -Author -ItemCount NewsProviderFactories NewsItemList : List<NewsItem> -GetNewsProviderFactory(providerType) -Items NewsProviderFactory -CreateNewsAdapter(connectionString) RssNewsProviderFactory AtomNewsProviderFactory -CreateNewsAdapter(connectionString) -CreateNewsAdapter(connectionString) NewsAdapter -Fill(newsItemList, itemCount) -GetNewsItemById(id) RssNewsAdapter AtomNewsAdapter -Fill(newsItemList, itemCount) -GetNewsItemById(id) -Fill(newsItemList, itemCount) -GetNewsItemById(id)
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 ClientInformationWebPart BCS WebServiceProxy -GetClient(clientId) -GetClients()
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 21-9-2024 40
If it was designed like this in the first place ClientIdFilterWebPart ClientInformation -Id -ClientName ClientInformationWebPart ClientInformationList : List<ClientInformation> -ClientId -Items <<Interface>> IClientInformationRepository -GetClientInformation() -GetClientInformationById(id) -Other CRUD methods BCSClientInformationRepository -GetClientInformation() -GetClientInfromationById(id) -Other CRUD methods BCS ClientInformationProxy -SomeGeneratedMethod1 -SomeGeneratedMethod2
We could change the design to this ClientIdFilterWebPart ClientInformation -Id -ClientName ClientInformationWebPart ClientInformationList : List<ClientInformation> -ClientId -Items <<Interface>> IClientInformationRepository -GetClientInformation() -GetClientInformationById(id) -Other CRUD methods WCFClientInformationRepository ClientInformationProxy -GetClientInformation() -GetClientInformationById(id) -Other CRUD methods -SomeGeneratedMethod1 -SomeGeneratedMethod2
Or even this ClientIdFilterWebPart ClientInformation -Id -ClientName ClientInformationWebPart ClientInformationList : List<ClientInformation> -ClientId -Items <<Interface>> IClientInformationRepository -GetClientInformation() -GetClientInformationById(id) -Other CRUD methods SQLClientInformationRepository -GetClientInformation() -GetClientInformationById(id) -Other CRUD methods CRM Db
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
