ADG, New Delhi Nov 7 2020 : Progressing towards a responsible Software Craftsmanship

Transcript

1. Progress towards responsible Software Craftsmanship Hitesh Das Webinar . ADG, New Delhi . Saturday, 7th Nov 2020
2. Introduction
3. What is Software Craftsmanship?
4. “Software craftsmanship is an approach to software development that emphasizes the coding skills of the software developers. It is a response by software developers to the perceived ills of the mainstream software industry, including the prioritization of financial concerns over developer accountability.” Software craftsmanship Book by Pete McBreen
5. “Software Craftsmanship is about professionalism in software development ”
6. Introduction Why is it the need of the hour ?
7. - Reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. Like monetary debt, if not repaid, it can accumulate interest, making it hard to implement changes later on. TEC H N IC A L
8. • Business pressures • Lack of process or understanding • Tightly-coupled components • Lack of collaboration • Delayed refactoring • Lack of knowledge • Lack of ownership • Poor technological leadership What Causes Technical Debt?
9. “The Last minute changes” … and finally
10. The Design Trade Off Line Axiom
11. “This raises the question of where that line is. Even with people who accept the design stamina hypothesis there is substantial, and important, differences over where the payoff line sits. I take the view that it's much lower than most people think: usually weeks not months. But again this can only be a judgment call.” - Martin Flower
12. Introduction Why is it the need of the hour? How to progress?
13. The Four Dimensions Of Quality
14. Not only working software, but also well-crafted software Provides a clear-cut direction on product quality in terms of design and code quality. It goes beyond that to cover several aspects of product quality that are necessary for any product to be valued as well-crafted by end users as well as maintainers.
15. Not only responding to change, but also steadily adding value All about delivering business value. The quality of how a project team steadily adds value by delivering the most valuable features on time is more important than responding to change and establishing a comfort factor. Aim to ensure new code is maintainable (well crafted). Remember the 4th Quadrant of Tech Debt.
16. Not only individuals and interactions, but also a community of professionals Summons the need to build the culture of knowledge communities or communities of professionals. When we limit ourselves to “individuals and interactions,” we tend to limit our contributions as well as learning opportunities. When we become part of knowledge communities, we open up immense opportunities for sharing as well as learning. Sharing and learning are very critical to improve professional quality.
17. Not only customer collaboration, but also productive partnerships Enables us to think in terms of engagement or relational quality. Customer collaboration cannot be confined to ensuring success at the project level. It has to be extended further to cultivate productive partnerships. That is the way to ensure engagement quality.
18. Introduction Why is it the need of the hour? How to progress? Who can help?
19. Application Architecture
20. Why Is It So Important? Architecture is a primary element in the design and planning phase of software development. A software project without architecture can be compared to building without foundations - the bigger the building, the more problems this will cause.
21. We often see an approach without architecture as faster. However, very soon it turns out to be a dead end. Often it is too late to add architecture or patterns to such code. Along with the increase of size and complexity of the project, these problems accumulate. Courtesy : The Agile Samurai (Book) Q : Why Projects fail? A : UNCONTROLLED COMPLEXITY
22. Overview of Common Software Architecture Patterns
23. - Layered Architecture - Event Driven Architecture - Microservice Architecture
24. Layered architecture The advantage of a layered architecture is the separation of concerns, which means that each layer can focus solely on its role. This makes it: • Maintainable • Testable • Easy to assign separate "roles" • Easy to update and enhance layers separately
25. Layered architecture Cons • Source code can turn into a “big ball of mud” if it is unorganized and the modules don’t have clear roles or relationships. • Much of the code can be devoted to passing data through layers without using any logic. • Layer isolation, which is an important goal for the architecture, can also make it hard to understand the architecture without understanding every module. • Coders can skip past layers to create tight coupling and produce a logical mess full of complex interdependencies. • Monolithic development is often unavoidable, which means small changes can require a complete redeployment of the application.
26. Ideal for • New applications that need to be built quickly • Enterprise or business applications that need to mirror traditional IT departments and processes • Teams with inexperienced developers who don’t understand other architectures yet • Applications requiring strict maintainability and testability standards
27. Event Driven architecture Many programs spend most of their time waiting for something to happen (basically an event). This is especially true for systems that work directly with humans. Event-driven architectures: • Are easily adaptable to complex, often chaotic environments • Scale easily • Are easily extendable when new event types appear
28. Event Driven architecture
29. Event Driven architecture Cons • Testing Complexity if the modules can affect each other. While individual modules can be tested independently, the interactions between them can only be tested in a fully functioning system. • Error handling can be difficult to structure, especially when several modules must handle the same events. • When modules fail, the central unit must have a backup plan. • Messaging overhead can slow down processing speed, especially when the central unit must buffer messages that arrive in bursts. • Developing a systemwide data structure for events can be complex when the events have very different needs. • Maintaining a transaction-based mechanism for consistency(ACID) is difficult because the modules are so decoupled and independent.
30. Ideal for • Asynchronous systems with unidirectional data flow. • Applications where the individual data blocks interact with only a few of the many modules. • User interfaces.
31. Service Oriented Architecture The Service Oriented/Microservice/Microkernel architecture pattern is useful when your software system or product contains many integration points to external entities. This architecture pattern can be identified as a plug-in based pattern and it consists of two main components, the core system and plug-in components.
32. Service Oriented Architecture
33. Service Oriented Architecture Platform Independence Easier to Test, More Reliable Ability to Reuse Codes Parallel Development Scalability
34. Service Oriented Architecture Cons Items that need to be analyzed include contract versioning, internal plug-in registries, plug-in granularity, and the wide choices available for plug-in connectivity. Requires a thorough analysis of the design before implementation.
35. Ideal for It can react to changes in plug-in modules while minimizing changes to the core system. Unlike layered architecture, having plug-in modules means it is easier to deploy thereby minimizing downtime. Testing also is easier as individual modules can be tested in isolation. It can perform well due to customizing the application to only include features that are needed (On Demand).
36. So Which Architecture to choose from? “It depends”
37. - Cost - Time to Market - Number of users (current and future) - Level of independence (Integration with other systems) Motivation while choosing the architecture
38. We should not build fighter jets to buy groceries from the mart on the opposite road
40. Minimal Complexity Ease of Maintenance Loose Coupling High Cohesion
41. One of the most crucial features of a good architecture is Responsibility Layer Separation. Defining The Bounded Context reduces the extent of errors.
42. Key Principles
43. SOLID Principles S - Single Responsibility Principle (SRP) O - Open Closed Principle (OCP) L - Liskov Substitution Principle (LSP) I - Interface Segregation Principle (ISP) D - Dependency Inversion Principle (DIP)
44. DRY – Don’t Repeat Yourself "Every piece of knowledge or logic must have a single, unambiguous representation within a system." - Divide your system into pieces. Divide your code and logic into smaller reusable units and use that code by calling it where you want. - Don't write lengthy methods, but divide logic and try to use the existing piece in your method. Less code is always good :)
45. KISS – Keep it Simple Stupid - Keep coding simple and straightforward. - Keep your methods small. Each method should never be more than 40-50 lines. - Each method should only solve one small problem, not many use cases. - If you have a lot of conditions in the method, break these out into smaller methods. Easier to read and maintain. - It can help find bugs a lot faster
46. YAGNI – You Aren’t Going to Need It - Often used generally in agile software teams. - It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".
47. Key Practices
48. Pair Programming Dont!
49. Practicing Dojo Katas
50. Test Driven Development(TDD) Two schools of thought "Mockist" TDD makes you a bit more flexible in what you can test. “Classical” TDD makes your tests a bit less brittle because they tend to look more at the input/vs output instead of looking at the actual implementation. When doing mockist unit testing I seem to have more tests break when changing the implementation in comparison to the later.
51. Classic School Triangulation Test Driven Development(TDD)
52. As an aspiring Software Craftsman, • We should together raise the bar of professional software development by practicing it. • And help others to learn the craft. Let’s take the oath … http://manifesto.softwarecraftsmanship.org/
53. References http://blog.cleancoder.com/ https://techbeacon.com/ http://manifesto.softwarecraftsmanship.org/ https://www.netguru.com/blog https://er.yuvayana.org/quality-software-attributes- characteristics-of-good-software-products/ https://www.mindtree.com/about/resources/manifes to-software-craftsmanship-and-four-dimensions-qual ity https://martinfowler.com/ https://agilemanifesto.org/
54. Thank you
55. Hitesh Das (HD) Android Chapter Lead OLX Group hitesh.das@olx.com +91-9015225032 @hiteshdas1912 @hiteshdas Let’s connect - - -