Recro Webinar Nov 28, 2020 : Progressing towards responsible Software Craftsmanship

Transcript

1. Progressing towards responsible Software Craftsmanship Hitesh Das Webinar . Recro . Saturday, 28th Nov 2020
2. Introduction
3. Software Craftsmanship is about professionalism in software development
4. Introduction Why is it the need of the hour ?
5. Why do software projects continue to fail? - Poor Planning? - Poor Requirements? - Poor Management? UNCONTROLLED COMPLEXITY
6. TECHNICAL DEBT Defects No Reuse Rewrites Afraid to Change Increase Development times
7. “Software Change is inevitable”
8. Introduction Why is it the need of the hour? Building the Craftsman Mindset
9. The Manifesto The Four Dimensions Of Quality
10. Not only working software, but also well-crafted software - Write code supported with tests - Code should speak the Business Language. - Simple Design (≠ No Design)
11. Not only responding to change, but also steadily adding value - Code we write should be Testable - It should be Extendable for incremental value addition - Refactor for optimization THE BOY SCOUTS HAVE A RULE: “Always leave the campground cleaner than you found it.”
12. Not only individuals and interactions, but also a community of professionals - Share/Mentor Knowledge - Discuss and propose Ideas - Share Success & Failures - Community engagements. Inspire and ignite the same passion with peers.
13. Not only customer collaboration, but also productive partnerships - Must help our clients. - Must say “NO” for client’s benefit. - Cultivate productive. partnerships. - Find a way to ensure engagement quality.
14. Introduction Why is it the need of the hour? Building the Craftsman Mindset How to progress?
15. Application Architecture
16. 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.
17. 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)
18. Minimal Complexity Ease of Maintenance Loose Coupling High Cohesion Characteristics of good design
19. We should not build fighter jets to buy groceries from the mart on the opposite road
21. Overview of Common Software Architecture Patterns
22. - Layered Architecture - Event Driven Architecture - Microservice Architecture
23. 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. 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
26. Event Driven architecture
27. 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. Microservices are an approach to software architecture, where the product is split into decoupled components that interact with each other via APIs, ensuring the continuity of product performance.
28. Service Oriented Architecture
29. Service Oriented Architecture Platform Independence Easier to Test, More Reliable Ability to Reuse Codes Parallel Development Scalability Most often consider adopting microservices for a product that has been in production for quite some time and has become too bulky to be updated and maintained as a monolith. By splitting it to decoupled microservices, the developers want to: Improve the system resilience, as any part of the product can be rebooted separately. Decrease the development complexity, as many functions can be isolated to reduce the number of obligatory interactions. Shorten the time-to-market for new features, as developing a new version of a smaller module is faster than updating the product as a whole.
30. - Cost - Time to Market - Number of users (current and future) - Level of independence (Integration with other systems) Motivation while choosing the architecture
31. Key Principles
32. 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)
33. 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 :)
34. 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
35. 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".
36. Key Practices
37. Pair Programming Dont!
38. Practicing Dojo Katas
39. Demo TDD/Dojo Kata
40. The Triangulation Test Driven Development(TDD) TDD is primarily a developer's tool to help create well-written unit of code (function, class, or module) that correctly performs a set of operations
41. Given When Then
42. ... If you want to develop software with pride and professionalism; love what you do and do it with excellence; and build a career with autonomy, mastery, and purpose, it starts with the recognition that you are a craftsman. Once you embrace this powerful mindset, you can achieve unprecedented levels of technical excellence and customer satisfaction.” -- The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso
43. 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/
44. Thank you
45. Hitesh Das (HD) Progressing towards a Software Craftsman Medium hitesh.das@olx.com +91-9015225032 @hiteshdas1912 @hiteshdas - - -