<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Testability on Kaan's Blog</title><link>https://kaanbardak.com/tags/testability/</link><description>Recent content in Testability on Kaan's Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 30 May 2013 15:17:27 +0000</lastBuildDate><atom:link href="https://kaanbardak.com/tags/testability/rss.xml" rel="self" type="application/rss+xml"/><item><title>The Interface Segregation Principle (ISP) with explicit interface implementation</title><link>https://kaanbardak.com/posts/the-interface-segregation-principle-isp-with-explicit-interface-implementation/</link><pubDate>Thu, 30 May 2013 15:17:27 +0000</pubDate><guid>https://kaanbardak.com/posts/the-interface-segregation-principle-isp-with-explicit-interface-implementation/</guid><description>&lt;p&gt;The project I am currently working on is a product development project. Our daily work is to add features (or fixing bugs) to our code base which has been around for over 10 years, this is why I’ve been encountering legacy code daily. As one might imagine, when the &lt;strong&gt;maintainability and testability&lt;/strong&gt; of a project of this caliber is low-prioritized, refactoring becomes near impossible after a point. There are of course exceptions to this, some subsystems do renew themselves periodically, lucky for them!&lt;/p&gt;</description></item></channel></rss>