For any project that is critical to the business, it’s important to do ‘Modern Architecture Reviews’. Being an architect is fun, you get to design the system, do ongoing code reviews, and play the bad ass. It is even more fun when using modern cool tools.
Follow these steps to achieve a 'Modern Architecture Review'. See how performing an architecture review on a big project, no longer needs to be daunting. Read about the 1st steps, then check to see if you’re following SOLID principles, then drill in and find patterns and anti-patterns. Use Visual Studio to help the process with architecture tools, code smell tools, and the great Visual Studio Code Review tools.
These steps enable you to attend to the code that needs the most attention. Finally, create PBI's to make sure they get fixed in the next Sprint.
Want to drive business value with IT Transformation? Check SSW's Strategic Architecture consulting page.
Often an incorrect process is the main source of problems. Developers should be able to focus on what is important for the project rather than getting stuck on things that cause them to spin their wheels.
When writing a large scale enterprise application you want to make sure you only have to write it once. Choosing the right software architecture for your system is crucial for its long term success and maintainability. The right software architecture will allow your software application will scale too meet new requirements. Choosing the wrong software architecture can turn adding new features and maintaining your code into an increasingly frustrating exercise in futility.
It's amazing how often you can't simply Clone a repository (aka "Get Latest") and compile it.
A good developer makes it clear how to get a new project, compile it and run it.
There are 2 main parts to any application. The UI which is what the customer can see and provide feedback on, and the underlying code which they really can't know if it is healthy or not.
Therefore it is important to conduct a 'test please' on the internal code and architecture of the application.
Ideally conduct a small 'Code + Architecture Review' for every Sprint. Assuming a 2 week Sprint, schedule a 4 hour (2 architects x 2 hours) review.
There are a few styles of documentation:
Have you ever opened a promising project, only to be lost because the README was unclear? It's a frustrating experience and causes you to quickly give up.
Crafting a README is not a one-size-fits-all endeavor. The content that makes a README truly great varies significantly depending on who the audience is and what type of project you're showcasing.
A README can often be a potential contributor's first impression of your project. It communicates the project's vision, how to contribute to the project and places where people can donate and installation instructions.
A good architecture diagram (aka cloud architecture diagram or system architecture diagram) gives a great overview of your project. An architecture diagram lets you see at a glance what the overall structure of the solution is.
This is useful for gaining an understanding of how the system fits together, how it flows, and what it does. It also helps to easily show which components can be improved due to updated or better components (or improved architectural guidelines).
The technologies and design patterns form the architecture that is usually the stuff that is hard to change.
A pattern allows using a few words to a dev and he knows exactly what coding pattern you mean.
ALM is about refining the work processes.
In Agile development, both the terms "Spike" and "Proof of Concept (PoC)" are used to address uncertainty or gather information, but they are applied in slightly different contexts.
- Do you evaluate the processes?
- Do you know how to choose the best software architecture for your system?
- Project setup - Do you know the importance of the initial developer experience?
- Do you conduct an architecture review every few Sprints?
- Do you make awesome documentation?
- Do you have an awesome README?
- Do you use README templates?
- Do you have an architecture diagram?
- Do you document the technologies, design patterns and ALM processes?
- Do you know when to use the term SPIKE (Agile) or PoC (proof of concept)?”
- Do you look at the architecture of JavaScript projects?
- Do you generate dependency graphs?
- Do you know how to laser in on the smelliest code?
- Do you know the common Design Principles? (Part 1)
- Do you know the common Design Principles? (Part 2 - Example)
- Do you use unique DTOs per use case?
- Do you know the common Design Patterns?
- Do you use the Dependency Injection design pattern?
- Do you code against interfaces?
- Do you look for GRASP Patterns?
- Code - Can you read code down across?
- Do you start reading code?
- Do you use a ‘Precision Mocker’ like NSubstitute instead of a ‘Monster Mocker’ like Microsoft Fakes?
- Do you have opportunities to convert use Linq to entities?
- Do you look for opportunities to use Linq?
- Do you use the repository pattern for data access?
- Do you look for large strings in code?
- Do you decide on the level of the verboseness? E.g. ternary operators
- Do you review the code comments?
- Do you use the best Code Analysis tools?
- Do you use the best trace logging library?
- Do you look for Code Coverage?
- Do you use the Kent Beck philosophy?
- Do you know what a container is?
- Do you know the best dependency injection container?
- Do you know what to do about ASP.NET Core default dependency injection?
- Do you use subdomains instead of virtual directories?
- Do you use the best middle tier .NET libraries?
- Do you use the best Web UI libraries?
- Do you use your IOC container to Inject Dependencies – and not as a singleton container
- Do you know the importance of paying back Technical Debt?
- Do you practice the "Just Enough Refactoring" when adding new features?
- Do you use the Well-Architected Framework?
- Do you know the different ways to modernize your application?
- Microservices - Do you break down your apps?
- Tech Debt - Do you avoid 'clever' code?
- Do you use Co-Creation Patterns?
- Do you use Co-Authored Commits?
- Project setup - Do you containerize your dev environment?
- Git - Do you know how to avoid large PRs?
- Pull Request - Do you do over the shoulder reviews?
- Do you use Architectural Decision Records (ADRs)?
- Do you use prefixes to improve code review communication?
- Do you use MassTransit to build reliable distributed applications?
- Do you know how to choose the right multi-tenancy model?