<h1 id="principles-in-refactoring"><a aria-hidden="true" class="anchor-heading icon-link" href="#principles-in-refactoring"></a>Principles In Refactoring</h1>
<h2 id="chapter-2"><a aria-hidden="true" class="anchor-heading icon-link" href="#chapter-2"></a>Chapter 2</h2>
<hr>
<ul>
<li>Refactoring is for when i need to understand the code base
<ul>
<li>If the code is a hot mess but i dont need to interact with it beyond treating it like an API black box then i can ignore the code for now. It's when i need to care that i refactor</li>
<li>If the code is easier to re-write than refactor that is also a valid edge case to not refactor</li>
</ul>
</li>
<li>Client boundries can get in the way such as the published public interface
<ul>
<li>If we want people to avoid using the <code>circum()</code> function in favor of the <code>circumference()</code> function then like the example in <a href="/DevLog/notes/8wahjk2o9ebw21gsdjt8862">124 Change Function Declaration</a> leave the old declaration as a pass through with a deprecation warning and phase out over time. This is just the cost and fact of life for public interfaces and code ownership boundries.</li>
</ul>
</li>
<li>reduce the complexity of large branch feature merges with things like feature toggles to turn off "in-progress" work that is unable to be broken into smaller parts in a <a href="/DevLog/notes/aer25byo6srulq7i050vz16">CI CD</a> environment.</li>
</ul>
<hr>

Principles In Refactoring


The hyperfixated rabbit hole diving knowledge base that is my brain looking at technology.
