|
|
@@ -310,7 +310,7 @@ code > span.in { color: #60a0b0; font-weight: bold; font-style: italic; } /* Inf
|
|
|
<li><a href="#遗留代码的来源">遗留代码的来源</a></li>
|
|
|
<li><a href="#遗留代码的问题">遗留代码的问题</a></li>
|
|
|
</ul></li>
|
|
|
-<li><a href="#如何修改代码">如何修改代码</a></li>
|
|
|
+<li><a href="#如何修改遗留代码">如何修改遗留代码</a></li>
|
|
|
<li><a href="#网站重构">网站重构</a><ul>
|
|
|
<li><a href="#速度优化">速度优化</a></li>
|
|
|
<li><a href="#功能加强">功能加强</a></li>
|
|
|
@@ -3332,6 +3332,13 @@ System.<span class="fu">out</span>.<span class="fu">println</span>(<span class="
|
|
|
<p>一种旧的方法、旧的技术、旧的计算机系统或应用程序。</p>
|
|
|
</blockquote>
|
|
|
<p>但是实际上，当你看到某个网站宣称用新的框架来替换旧的框架的时候，你应该知晓他们原有的系统是遗留系统。人们已经不想在上面工作了，很多代码也不知道是干什么的，也没有人想去深究——毕竟不是自己的代码。判断是否是遗留代码的条件很简单，维护成本是否比开发成本高很多。</p>
|
|
|
+<ul>
|
|
|
+<li>几乎无法维护</li>
|
|
|
+<li>代码遗失</li>
|
|
|
+<li>逻辑不清</li>
|
|
|
+<li>没有文档或者不够详细、看不懂</li>
|
|
|
+<li>关键点遗失</li>
|
|
|
+</ul>
|
|
|
<p>在维护这一类系统的过程中，我们可能会遇到一些原因来修改代码。如《修改代码的艺术》的一书中所说，修改软件有四大原因：</p>
|
|
|
<ul>
|
|
|
<li>增加特性</li>
|
|
|
@@ -3348,17 +3355,18 @@ System.<span class="fu">out</span>.<span class="fu">println</span>(<span class="
|
|
|
<p>什么是遗留代码？没有自动化测试的代码就是遗留代码，不管它是十年前写的，还是昨天写的。</p>
|
|
|
<h3 id="遗留代码的来源">遗留代码的来源</h3>
|
|
|
<h3 id="遗留代码的问题">遗留代码的问题</h3>
|
|
|
-<h2 id="如何修改代码">如何修改代码</h2>
|
|
|
+<h2 id="如何修改遗留代码">如何修改遗留代码</h2>
|
|
|
<blockquote>
|
|
|
<p>即使是最训练有素的开发团队，也不能保证始终编写出清晰高效的代码。</p>
|
|
|
</blockquote>
|
|
|
<p>然而，如果我们不去尝试做一些改变，这些代码就会遗留下去——成为遗留代码，再次重构掉。即使说，重构系统是不可避免的一个过程，但是在这个过程中要是能抽象中领域特定的代码、语言也是件不错的事。</p>
|
|
|
<p>So，如何开始修改代码？</p>
|
|
|
<ol type="1">
|
|
|
-<li>测试</li>
|
|
|
-<li>重构</li>
|
|
|
-<li>修改测试</li>
|
|
|
-<li>再次重构</li>
|
|
|
+<li>代码修改点</li>
|
|
|
+<li>找到测试点</li>
|
|
|
+<li>打破依赖</li>
|
|
|
+<li>编写测试</li>
|
|
|
+<li>修改并重构</li>
|
|
|
</ol>
|
|
|
<p>在有测试的情况下重构现有的代码才是安全的。而这些测试用例也是功能的体现，功能首先要得到保证了，然后才能保证一切都可以正常。</p>
|
|
|
<h2 id="网站重构">网站重构</h2>
|
Fengda HUANG