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
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
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
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.
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.
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.
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.
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) Q : Why Projects fail? A : UNCONTROLLED COMPLEXITY
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
“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.
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
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
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.
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.
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.
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).
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".
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.
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/
hiteshdroid
odan611
freshdaz
yoshiki0705
masayoshimaezawa
isaoshimizu
kazu_kichi_67
izumii19
hiranabe
murabayashi
tooppoo
takafumisu2uk1
kozotaira
codingconduct
reverentgeek
bryan
holman
bkeepers
sachag
iamctodd
csswizardry
raygrieselhuber
skipperchong
minecr
lynnandtonic
![Hitesh Das (HD) Android Chapter Lead OLX Group [email protected] +91-9015225032](https://files.speakerdeck.com/presentations/ad4f8db55b9240b6b801d8936bf8c898/slide_54.jpg){kind=link}
