代码编辑器使用ArrayList结构来存储代码行,但是ArrayList是种插入慢的方式，因为每插入一行所有元素都要后移。后来作者试图使用列表结构虽然这种结构插入方便但又存在读取慢的缺点，从而作者不得不考虑使用线形数组，在行中插入字符会得到相当高的效率，因为它只影响一个单行。但若使整个缓冲区呈线形性，则会使插入变更变的相当慢，因为缓冲数组比行数组大的多。所以最终选择了基于行的结构。
下一个面临的问题就是语法的醒目显示。首先采取的对策是将单词分割并单独分配颜色。由于内置的语法醒目显示难以改变及维护，作者最终选择了在XML中定义语法醒目显示。
虽然老大英明神武但是它面对的问题也是越来越难。
第二关：编辑器的绘图速度太慢，每次滚动文本哪怕是一行都要重新绘制整个编辑器窗口。后又被英明的老大们通过一个了解文本大小的控件来解决掉了。但是却带来个代码行只有2718的问题。该问题1年内都没被解决。
各位可以考虑产生此问题的原因。
但是以上的结构还是存在很多问题，所以作者放弃了行方式回到了文本编辑器，又通过一系列努力解决了性能问题。大家可以一起探讨下。我们在后来再来进行总结。
SD中明确的实现了XCopy部署（复制就可运行），并使软件可扩展及高灵活度。而作者使用插件（AddIn）方式来实现软件的灵活，并通过XML配置来实现XCopy的可能，从而此过程中从没有使用注册表。
下面SD的开发速度得到个质的提升，因为任何插件的开发都不影响已有功能的维护与其它功能的开发。
另外一个重要的问题是SD中使用了MVC模型。实现了视图与模型之间的通信，并可方便的切换视图。这个模型启发我们使用组件来开发，并最终导致了面向组件的决策。
SD的作者提供我们几条关于设计与重构的经验。虽然这些经验不是万能的灵丹妙药，但也确实包含了程序演变
的理念。重构规则有：
1、若不理解—个方法，则将其分解为更小部分
2、更容易理解的代码要优与性能更好的代码
3、不厌其烦地进行重构（这正是我们国内ISV的一个很大的错误，我们往往不希望在重构上浪费时间。）
4、不要想着在一天内完成所有的事情。
需求在不断变化，所以我们不要期待一劳永逸。最好先做一些简单的设计，随着时间的推移程序员水平的提高，再不断的进行重构。
5、尽可能地使用断言
6、从根本上解决问题