Agile practitioners talk about Test Driven Development(TDD), so do lot of developers who care about their code quality and workability. And I once upon a time, not so long ago managed to read about TDD. The crux of TDD as… Read More ›
Why is the legacy code is the way it is?
What is legacy code?
At the start of the post I tried to get some definition for the term: “legacy”. (we wish if the noun was true! but indirectly they are one of the reasons for our pay). The adjective definition is somewhat closer to our “legacy code”.
Legacy code is something:
that has been written previously ( may be years old or even months, may be written by another developer or by the same developer) and continues to work just well to satisfy the customer needs.
that is being written as I am writing this post (and it is something which evolves to a legacy code stature in no time) and just enough to implement the requirements.
Book Review: Essential Skills for the Agile Developer
This book does justice to its title and subtitle- it clearly tells you the basic design principles to write good code which is easy to read, debug and extend. At first glance the title may seem misleading as it uses the word “Agile Developer” but there isn’t much specific to agile in the book, though familiarity with terms like Scrum or Kanaban or TDD would be an added advantage.
SOLID- Liskov Substitution Principle
Liskov Substitution principle (LSP) states that, Methods that use references to the base classes must be able to use the objects of the derived classes without knowing it This principle was written by Barbara Liskov in 1988. The idea here… Read More ›
SOLID- Open Closed Principle
Open Closed Principle (OCP) states that, Software entities (Classes, modules, functions) should be OPEN for EXTENSION, CLOSED for MODIFICATION. Lets try to reflect on the above statement- software entities once written shouldn’t be modified to add new functionality, instead one… Read More ›
SOLID- Single Responsibility Principle
The Single Responsibility principle (SRP) states that: There should never be more than one reason for a class to change. We can relate the “reason to change” to “the responsibility of the class”. So each responsibility would be an axis… Read More ›