<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Refactorización on Karpoke - Just Another Blog</title><link>http://karpoke.ignaciocano.com/tags/refactorizaci%C3%B3n/</link><description>Recent content in Refactorización on Karpoke - Just Another Blog</description><generator>Hugo -- 0.159.0</generator><language>es</language><lastBuildDate>Wed, 07 Dec 2016 20:57:00 +0100</lastBuildDate><atom:link href="http://karpoke.ignaciocano.com/tags/refactorizaci%C3%B3n/index.xml" rel="self" type="application/rss+xml"/><item><title>Undebt: how we refactored 3 million lines of code</title><link>http://karpoke.ignaciocano.com/2016/12/07/undebt-how-we-refactored-3-million-lines-of-code/</link><pubDate>Wed, 07 Dec 2016 20:57:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2016/12/07/undebt-how-we-refactored-3-million-lines-of-code/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Peter Seibel wrote that to maximize engineering effectiveness, “Let a
thousand flowers bloom. Then rip 999 of them out by the roots.” Flowers,
in how the metaphor applies to us, are code patterns — the myriad different
functions, classes, styles, and idioms that developers use when writing
code. At first, new flowers are welcome — maybe the new pattern seems
easier to use, more scalable, more efficient, or more suited to some
particular task than the old.&lt;/p&gt;</description></item></channel></rss>