- 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.”
professionals - Share/Mentor Knowledge - Discuss and propose Ideas - Share Success & Failures - Community engagements. Inspire and ignite the same passion with peers.
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.
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)
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
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
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.
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.
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 :)
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
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".
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
hiteshdroid
freshdaz
shotatsuge
askul
ueponx
you
masayoshimaezawa
sugupoko
yoshiki0705
taka_aki
estie
laysakura
seike460
skipperchong
khoart
joshbly
inesmontani
bermonpainter
tammyeverts
moore
aleyda
mfonobong
sabderemane
rabernat
jmmastey
![Hitesh Das (HD) Progressing towards a Software Craftsman Medium [email protected]](https://files.speakerdeck.com/presentations/112c74c5bff34c0687a15228521825b6/slide_44.jpg){kind=link}