A lab around the principles and practices for writing maintainable code (2019)
Download as PPTX, PDF4 likes471 views
The document outlines best practices for software architecture and coding, emphasizing principles such as component isolation, traceability, and the importance of clear naming conventions. It encourages the use of automated tests, continuous refactoring, and focused commits while providing guidelines for structuring code and conducting reviews. Various design patterns and principles, including dependency inversion and encapsulation, are highlighted to promote high-quality, maintainable code.
A lab around the principles and practices for writing maintainable code (2019)
- 1. Dennis Doomen | @ddoomen | Aviva Solutions | The Continuous Improver
- 7. Isolated Can I do this without affecting anything else? Testable Is it doing what it is supposed to do? Traceable Why did we do this? Readable What does it try do and how? Discoverable Where is this done?
- 9. Application
- 11. Application Component ComponentComponent Component Component Component Component Component Component Component Component Component Component
- 12. Application Functional Slice Functional Slice Functional Slice Functional Slice Composition Architectural boundaries protected by PR expert review Each component owns/exposes its reference data Does not depend on anything except for curated shared APIs Owns schema and storage (may use shared database abstraction) DRY within component, not outside May use an internal container Event Sourcing & CQRS are component- specific concerns Does not touch other components ’ data directly Shared Services Connects the components and serves as anti- corruption layer Only services you really think should not be duplicated Designed according to Dependency Inversion Principle Covers front-end and back- end Component is the scope of unit & integration tests Align folder structure with boundaries Defines the contracts for the host as well as any services it exposes
- 14. No generic interfaces Hide the “internals” Composition over inheritance Avoid inheritance Small and focused interfaces Or delegates Avoid bi- directional relationships Design Patterns “name” a common solution Internal/private by default First-class collections and primitives
- 17. Long method Not immediately clear what it does Magic character Deeply nested “ifs” Single entry, single exit Static mutable state Magic key Multiple dots Magic keys Single entry, single exit No idea what to do if this fails Encapsulates concerns
- 19. Too much coupling? Clear algorithm (Still) static mutable state Name captures the purpose Same level of abstraction Methods ordered by execution (a.k.a. reads like a book)
- 20. Magic string? Should never happen, but is a valid path Because type is obvious
- 21. Captures what it tries to accomplish Captures what it does
- 22. Pretty clear, right? Not so clear on Github Pull Requests Jetbrains Rider / Resharper to the rescue
- 23. Superfluous documentation Nice, but a bit too much for a private method? The name is clear enough, isn’t it?
- 24. using (var scope = new AssertionScope()) var depth = GetDepthOfObjectGraph(); var displayValue = GetDisplayValueOf(context); var valueString = GetDisplayValueOf(context); var dataType = row.GetColumnType(columnIndex); var searchColumnsSql = BuildSearchColumnsSql(Columns); var results = RunSearchQuery(searchColumnsSql); var indexInSpan = 0; var longIndexInSpan = 1; Use explicit type if type is relevant What kind of results? Did the author consider the maximum size? Use explicit type if type is relevant var
- 25. Too many fields?
- 26. Too many fields?
- 28. Well-named and discoverable UTC? Local? Random? Where is this coming from?
- 31. Unstructured Manual Testing User Interface Tests HTTP Tests Integration Tests Unit Tests Any structured tests should be automated Generic code is tested separately “Unit” = (architectural) boundary Do not accept unstable UI tests Only for UI scenarios we can’t cover with integration tests. Only for non-UI scenarios we can’t cover with integration tests.
- 32. Application Functional Slice Functional Slice Functional Slice Functional Slice Composition Shared Services
- 33. Hide what’s not important Show what is important Only if you can’t make them clear otherwise Use in-line literals Crystal-clear cause… …and effect Names that explain the expected functional behavior But be careful with base-classes !DRY
- 35. git checkout master git cob my-branch git save git amend git amend git undo git commit –m “Some functional change” git commit –m “Refactor something” git commit –m “Deprecate something” git commit –-fixup “Some functional change” git rebase –i master
- 37. // SMELL a smell code description // REFACTOR an idea for refactoring // NOTE a comment explaining a part of the code
- 44. Quality Definition of Done Work Breakdown Design Log Small PRs Focused Commits Continuous Refactoring Review Speed Review by non- team member Productivity Natural Cause of Refactoring Review Thoroughness Traceability Clean Source Control History Knowledge Sharing Tech Meetings Red Hot Developer Readable Code Good Unit Tests
- 45. Dennis Doomen @ddoomen Dennis Doomen | @ddoomen | The Continuous Improver
Editor's Notes
- #38: Understand the context of when a tool, practice or principle applies and when not. Don't reject it because of misuse (e.g. IoC, OR/M, DRY, TDD).
- #40: Understand the context of when a tool, practice or principle applies and when not. Don't reject it because of misuse (e.g. IoC, OR/M, DRY, TDD).
- #42: Understand the context of when a tool, practice or principle applies and when not. Don't reject it because of misuse (e.g. IoC, OR/M, DRY, TDD).