使用 .NET WinForm 开发所见即所得的 IDE 开发环境，实现不写代码直接生成应用程序

GitHub：https://github.com/iccb1013/Sheng.Winform.IDE

SailingEase WinForm Framework WinForm开发框架开发手册：http://docs.shengxunwei.com/Home/Browser/sewinformfw/

 

直接切入正题，这是我09年到11年左右业余时间编写的项目，最初的想法很简单，作一个能拖拖拽拽就直接生成应用程序的工具，不用写代码，把能想到的业务操做所有封装起来，经过配置的方式把这些业务操做组织起来运行。

项目的核心功能已经基本实现，但12年以后我基本中止了这方面的开发，如今翻出来在这里写出来想和你们交流一下。

 

鉴于篇幅和精力的缘由，请原谅我这篇博文对于技术实现的具体细节谈的不是不少，只能算是一个概述。对业务的说明也很少，我想你们都是技术流，应该一看就明白。

写这个项目的时间是五六年前，如今回过头去看，有不少不足之处，设计上的，技术上的都有，加上当时技术力有限，不足之处还请指正，谢谢。

后续是否会写一个系列的博文详细的分析讲解实现方法，我暂时也没有想好，主要是没有太多时间，我如今基本又回到了当初天天只睡四五个小时的状态。

若是此篇博文有点儿价值，给个推荐呗 ^_^ 

 

项目使用了 .Net Framework 3.5 开发，分为两大块： IDE 和 运行时（解析器）

IDE中开发的项目在打包后生成 zip 格式的包，解析器经过读取 zip 包实时解析运行，有点相似中间语言的概念，但我这里生成的 zip 包中主要以 xml 文件为主，经过 xml 文件对项目的 UI，业务，数据结构 进行描述。

 

到此能够看出，运行时自己并不必定是 .Net 或 WinForm 的，而是可使用任何平台或语言实现，只要读取 zip 文件和 xml 文件并解析便可。

事实上我本身实现的默认运行时也不是 WinForm，而是用了 Silverlight。

 

再简单说说 IDE 的设计思路，几个主要的设计目标以下：

 

1.像 Visual Studio 同样

　　有可视化的环境，拖拖拽拽界面就出来了。

2.模块化设计

　　功能模块所有独立，解耦，以插件的形式存在于主程序（宿主）中。

2.不要写代码，业务经过界面，向导进行配置

　　拖一个按钮上去，想要单击时作一件事情，就先把按钮拖上去，而后设置这个按钮的事件序列，配置对应的事件。

3.把事件这个概念抽象并封装起来

　　如“保存数据”这个事件，配置好数据的来源，如窗体上的数据，或系统数据，再配置好要保存的目标，某种数据实体，便可，这个事件被添加到某个事件序列，如按钮的单击事件序列中，项目被运行时解析时，就会按钮这个逻辑执行。

4.对数据操做要有必定的自由度

　　除了基本的向导式配置之外，要能知足特殊需求，好比支持自定义 sql 语句。可是自定义 sql 语句怎样与数据源，目标交互呢？我设计了一种简单的表达方法，如 UPDATE FROM [User] SET [Name] = {FormElement.txtName} WHERE [Id]={System.UserId}

5.对数据库数据表的操做怎样交互

　　就是将其抽象为“数据实体”，数据实体也在 IDE 中由用户本身定义，定义的过程相似于 SqlServer，定义好数据实体之后，在 IDE 中进行设计时，经过数据实体来抽象对数据库、表的操做，在打包项目时，能够根据定义的数据实体，生成多种数据库，如 SqlServer，Mysql 等。

6.资源文件的管理

　　在项目中必然要引用到外部资源，这部分外部资源，怎样引入，管理，打包呢？我在 IDE 中设计了独立的资源管理器，在 IDE 中设计 UI 时，经过资源管理器引用资源，打包时，将资源打包到 zip 文件中。

7.打包前的静态编译检查

　　相似于咱们在 Visual Studio 中写程序，编译时若是有错误就会出现警告或错误提示。在这个 IDE 中，也必须有一样的功能。当引用的数据实体被删除，数据项不存在，引用的资源文件不存在，以及事件配置中一些问题出现时，可以实时，并在打包项目时指出这些错误的具体位置。

8.支持嵌入脚本

　　可以在事件序列中添加自定义脚本，支持在运行时动态解析或者调用某种脚本语言。此功能有所设计，但并未开发。

9.支持插件

　　此处插件支持指的是 IDE 层面可以支持插件，相似 Visaul Studio 或者 Eclipse 的插件机制，我当时使用的是 .NET 管线技术（很冷门），实现了相关DEMO，可是没有集成到IDE中。

10.IDE界面支持多国语言

　　目前IDE完整支持多国语言，全部文本均使用了资源，可是我没有直接使用资源文件，而是将其强类型化了，具体实现方式下文详述。

 

在设计开发这个 IDE 的早期，我并无给本身设定如此详细的目标，如今写其实更多的是回顾和总结。

 

 

在这个项目中，大量使用了 GDI+ 绘图，说复杂，给你调用的接口也就那么多，说简单，用 GDI+ 本身写一个功能完备的 WinForm 控件，分分钟教你从新作人。在这个项目中，几乎全部的界面元素都是我本身用 GDI+ 绘制的，使用的第三方控件很少。后面我会写一些这方面的感想。

 

下面罗列一些技术难点和主要功能点，有些细节可能没有试着作过都不会意识到那是个问题。

 

1.工具栏按钮/右键菜单的状态控制

　　就是控制状态栏上按钮可用不可用，可见不可见，绝大多数时候这不是个问题，可是做为一个 IDE，工具栏上的各类按钮很是多，且按钮的状态和当前设计器中的选中元素个数，选中元素类型，甚至选中元素自身的状态等等相关，还有些按钮是特定控件或元素提供的，怎样统一控制这些按钮的状态？

黄色背景部分是动态挂载上去的，状态的控制在后文中说明。

 

此处右键菜单指的是窗体设计器中的右键菜单，在窗体设计器中，右键菜单比较复杂，不一样控件的右键菜单有所不一样，有共通的项目，有特殊的项目，以及状态是否是灰掉可能和控件自己的某些因素有关，但右键菜单自己是不可能经过处于设计状态的控件自身提供的，因此此处如何把控件特有的菜单项挂载上去，又怎样控制它们的状态？注意设计器自己和用来设计的控件是解耦合的。

注意这个例子，右键 DataGrid 产生的右键菜单中存在“添加列” 和“编辑列”两个特殊的项目。

此处当我选中 DataGrid 时，属性网格下方也会出现这两个项目，这里先提一个关键概念，叫作“谓词”，这是一个 DesignSurface 中的概念，后文再详述。

 

此处实际上我实现了一个独立的菜单（包括工具栏项目）的管理器，并不是直接建立 MenuItem 之类的实例去使用，这个管理器也是独立于业务进行设计的，对菜单项的各类状态，行为都进行了抽象与封装。在管理器层面统一调度这些菜单项，经过必定的机制使菜单项的状态与业务状态关联起来，不容许外部代码直接修改菜单项的状态，整套机制自己，与菜单项在UI层面的实现也是无关解耦的，最终生成可见菜单项时，才会生成特定的控件，如 MenuItem，也能够换成其它任何菜单项控件，不影响管理器的功能与逻辑。

我记得当时我研究了几个IDE的设计细节，包括  Visual Studio，应该都采用了相似的机制，好吧我认可是我研究以后借鉴了它们的机制。

这个问题我放在首位，是我意识到这个问题在大型软件中，真的是个很大的问题，我如今参与开发的一款电气化CAD软件中，就存在这个问题，可是他们早期并未意识到这个问题，也谈不上能很好的解决，几千个菜单项，工具栏按钮项，直接硬编码，对他们的状态控制也谈不上成体系，就是粗暴的硬编码，如今的维护，修改，调整都异常痛苦。

 

2.窗体设计器

　　最初我是本身用 GDI+ 写了一个简单的设计器模型，支持拖拽，绘制，动态对齐等等功能，可是越日后越复杂，好比绘制一个 DataGrid，你不能光是一个框框，你要本身去绘制它的列，列头，若是要绘制一个图片框，你就要本身去绘制它的图片内容，要考虑图片的缩放方式等等细节，若是要一条道走到黑彻底本身实现，成本将很是高昂。

先看看早期直接使用 GDI+ 实现的效果：

 

下面是直接使用微软 DesignSurface 效果：

和 Visual Studio 效果同样，不过这里须要注意的是 DesignSurface 仅仅也只是提供了基本的窗体设计能力（图中右侧部分），比我上面GDI+本身写的功能多不了多少，可是不用本身绘制控件的外观，其它辅助功能都是须要自行开发的。

这里要注意的一点是窗体设计器中 容许被设计 的控件 们，是与设计器自己，与IDE解耦的，是彻底独立实现的，后期添加新控件，修改控件都与IDE无关，这个地方的难点毅然是解耦合，各类解耦合。

左侧的属性列表是自行开发的，.Net Framework 中确实提供了 PropertyGrid 控件，可是对于高阶开发此处并不适用，有不少制限，下文详述。

 

 

3.工具箱

　　工具箱自己是独立实现的，不依赖其所处的窗体设计器，同时它自身所承载的控件，也是动态载入的，后期容许第三方插件挂载控件到工具箱中。

　　这个地方须要注意的很少，一个是动态载入控件，另外一个就是在和窗体设计器交互的时候，好比我拖一个控件到设计器上，这里是须要对接 DesignSurface 的。

 

4.属性网格（PropertyGrid）

.Net Framework 中提供了 PropertyGrid 控件，能够实现对对象实例的属性编辑功能，可是难于扩展与自定义，我此处须要个性化定制的地方比较多，因此选择本身实现一个。

主要实现了如下功能

1）对于单个对象实例，列出它的属性（Property，下同），以及属性的值，若是属性值与默认值不一样，可以粗体显示。

2）对于特殊的属性，提供对应的扩展编辑器，如颜色属性，在点击后应该提供一个颜色选择器。且这些扩展编辑器，是与属性网格自己解偶的。

3）若是同时设置了多个不一样类型（Type）的对象实例，例如在窗体设计器中框选了多个控件，这个场景就复杂一些了；首先获得这些对象实例的类型（Type），抽取共通的属性，属性网格中仅显示共通属性，对于某个属性的值，若是全部对象实例的值是相同的，则显示，若是有所不一样，则留空不显示。在设置了某个属性的值以后，可以将新值设置到这些对象实例中。

 

 

5.撤销重作引擎

这里能够用的上“引擎”二字，由于确实比较复杂，咱们先将这个问题简化，能够简单理解为对“对象”属性变化的跟踪，能够撤销这些变化，也能够重作这些变化，能够任意步骤的操做。

涉及到的问题和知识点不少，在 IDE 里对象状态的变化又被抽象为具体的“操做”，以及这些操做又要和设计器进行联动，有必定难度。

UI上的效果是直接使用 GDI+ 自定义的一个列表，并非很复杂，其它可以直观看的界面UI很少，主要是代码了。

 

6.事件及事件编辑器

上文中提到，要将经常使用的操做（事件）都封装起来，经过配置的方式来运行，大方向好像并不复杂，可是，怎么作呢？首先事件自己的抽象要独立，要与窗体设计解耦合，其次“事件”的定义应该容许由第三方插件扩展，甚至“触发时机”也应该容许由第三方插件进行扩展。以一个最简单的按钮为例：

看上去和普通编程中的事件机制没什么区别，是的，咱们要作的是对其基本机制进行抽象化。例如：

1）触发时机应该与事件寄主解耦，甚至容许第三方插件挂载触发时机。

2）事件序列应该与触发时机解耦，事件序列中的事件定义，应该与以上机制解耦，甚至容许第三方插件扩展。

 

看看项目中实现的效果：

咱们就以“为窗体元素加载数据”这个事件为例，看看如今的事件编辑器大概是什么模样。

这个事件支持“关联数据实体方式”和“执行 SQL 方式”。

切换到数据实体界面中，选一个数据实体，而后设置相关的数据项。

这里就能够配置事件在执行时，从哪里取得数据，咱们指定了从 用户 这个数据实体中选择数据，同时指定了一个条件，就是 用户的 Id 要等于 指定文本框中的值。

除了使用界面元素中的值做为条件，还可使用系统数据，如：

 

对于选择特定的用户，好比这个 Id 怎样获取呢？只要在加载数据时，把 Id 绑定到一个隐藏的文本框中就能够了，加载数据时，能够读取它的值。

而后切换到载入界面

在载入界面中，指定个人数据取出来之后，加载到界面的哪些元素中。

咱们上文提到，但愿对数据的操做有必定的自由度，那么在事件编辑器中，就容许直接定义 sql 语句，或者说 sql 语句的模板。

切换到 sql 界面后，首先能够经过 获取 sql 按钮自动根据前面的配置生成 sql，而后在此基础上进行调整，修改。

在 sql 编辑器中，能够经过 {Provider.Source} 的方式访问数据。

支持语法着色，支持智能提示。

目前实现了两种 Provider，FormElement （窗体元素）和 System （系统），在智能提示中支持递进的提示。

所谓递进的提示是输入“{”以后自动给出 Provider，选择后进一步自动给出 Source 列表。

也能够在 “{Provider” 后输入“.” 则自动给出 Source 列表。

智能提示用起来简单方便，看起来也很简单，貌似只是一个 Popup ，实则是一个不小的坑，这个功能困惑了我好久，记得当时处处找大神请教，除了高谈阔论的就是直接告诉我不知道，有我的也研究过 SharpDeveloper，告诉我这个问题深了，后来我又去翻 SharpDeveloper 的源代码，参考了它的实现，完成以后仍是至关有成就感的。

 

对于事件序列的编辑，有两种方法，一种是在设计器中双击控件以后打开的事件序列编辑器

另外一种方法是在窗体设计器中提供了以树形方式展现的事件序列，能够直接拖动改变事件的触发时机，或其在事件序列中的位置。

 

事件在解析器中执行时，是按钮它所处事件序列中的顺序进行执行的。

 

目前实现的事件大概有十几个，基本的应用程序操做，数据交互等。

再也不一一详细说明，由于事件本事是在解耦的状况下独立实现的，IDE并不依赖他们，因此将来扩展也很容易，能够说IDE和解析器是核心引擎，而这些事件定义，只是系统中的“业务”部分。

 

7.集合编辑器

集合编辑器，就真的只是用来编辑对象集合的，支持对集合中对象实例的编辑，以及集合中元素顺序的调整，而且在与窗体设计器解耦合的基础上，与窗体设计器联动，可以从窗体设计器中的元素取得对象集合，同时与撤销/重作引擎对接，在编辑的过程当中，提供撤销/重作的支持。

这个编辑器完成以后复用性比较强，在窗体设计器中有不少地方须要对集合进行编辑，行定义，列定义，元素定义之类。

一个典型的使用场景是在窗体设计器中，对 DataGrid 的列进行编辑。

 

8.有效性检查

在窗体设计器中，可以对当前窗体中的各项设置，包含的事件进行有效性的检查。例如我在某个事件中设置了加载数据到 TextBox1 ，后来我删除了这个 TextBox1 ，那么就必须给出提示。

此处的主要难点应该在于解耦合，各类解耦合。

 

9.IDE多国语言实现

　　Visual Studio 自带的资源文件编辑器使用起来不是很方便，好比多国语言，是分开在多个资源文件编辑器窗口中编辑的，没有一一对应的显示语言文本，另外直接使用资源文件，使用的是经过 String 作参数的弱类型方式进行调用的，不能作静态编译时检查，也没法保证多语言相关编码的质量。因此这里我没有直接使用资源文件机制，而是进行了二次开发，我专门开发一个资源文件编辑器，提供一个一体化的界面同时编辑多国语言资源文件，使资源key同时和多个资源文件对应起来，同时支持导出excel，交给翻译翻译以后直接导回来，而后解析资源文件中的资源，生成一个统一的 ILanguage 接口，和不一样的语言实现，如 class Chinese:ILanguage，class English:ILanguage，调用时，直接使用接口进行强类型调用，即将 Resource.GetString("buttonText") 变换为 _language.buttonText。

　　另外一方面，实现了一种将界面文本绑定到资源的机制，这一点在 WPF 下很是方便，在 WinForm 下就要本身动手了。经过特定字符串标记资源key，在运行时自动扫描窗体或其它容器控件，经过解析这些字符串自动查找对应的资源，将其替换。

 

10.界面用户数据的验证

　　目前几乎全部的开发平台都提供了比较友好的用户输入验证方案，在 WinForm 下也有，不过并非很完善，使用起来限制比较多，功能也有限，不是很顺手。

　　我本身开发了一套用于 WinForm 的用户界面数据验证功能。举个最简单的例子，我给文本框设置一个不容许空的属性，或者设置一个正则表达式，在我调用验证方法时，就可以对它进行有效性验证。方案很是简单，只是要花点心思把它实现好，各类控件都要支持，要解耦合，验证器要支持多种不一样验证机制，验证结果如何向用户反馈等等。

　　这套验证机制也一样实如今了运行时（解析器）当中。

验证结果的反馈并不必定要用 MessageBox，能够很容易的改进为其它更友好的形式。

 

11.模块化设计

模块化，插件式的框架设计如今应该有不少现成的框架和设计方法，可是在当时，又是 WinForm 下，能够参考的资料很是少，大方向不复杂，可是作完善作细致，在当时对我来讲有至关大的难度。当时惟一能够参考的是微软的 CAB 框架，但在当时来看，CAB 就已是一个有些过期的框架了，使用起来有一些缺点和限制。

我在参考 CAB 的基础上在 WinForm 下实现了一套分解的很是细致的模块化开发框架，对软件的功能进行层层解耦，宿主程序与功能模块彻底无关，而在我业务功能的设计上，IDE中的功能也实现了彻底解耦，上文也多处提到了，窗体设计器与被设计的控件包解耦，事件机制与具体的事件定义解耦等等。

 

 

 

其它功能点

其它功能点主要是指：数据实体定义，主菜单定义，枚举定义，资源管理，以及其它小功能等，下文先作个简单展现，暂再也不作详细的说明。

 

1.欢迎界面

欢迎界面是内嵌了一个 HTML 页面，只是和 C# 代码有简单交互，例如单击连接会调用 C# 方法，并传入参数。

使用 HTML 的一个缘由是但愿欢迎界面比较漂亮，可是在 WinForm 下实现一个漂亮的，交互性强，维护性强的欢迎界面有必定难度，很浪费时间。

此处注意一个细节， URL 地址不是一个磁盘文件地址，而是一个自定义协议和路径的地址，这个须要本身实现，可是很简单。

年代久远，CSS 和图片可能遗失了，不太好看，见谅。

 

2.数据实体定义

这块相对比较简单，没有复杂功能。

发布项目时能够根据数据实体定义自动生成数据库。

 

也能够针对指定的数据实体生成脚本。

 

3.枚举定义

界面很简单，生成数据库时，根据枚举定义向枚举表插入枚举数据。

可是有一个小细节是它和窗体设计器是有对接的，它是一个数据源的 Provider，能够在设计器中把控件中的值绑定到枚举。

 

4.主菜单/工具栏定义

定义要生成的软件的主菜单和工具栏，运行时解析以后，根据本身的实现方式生成，能够是 Ribbon 的，也能够是传统的，或者其它方式。

菜单或工具栏项目支持事件，能够挂载事件序列。

 

5.资源管理

实现一个资源管理器，目前只实现了对图片资源的管理。

 

 

这里有点看点的是，我当时没有找到我以为不错缩略图控件，因而只好本身实现一个。和 Windows 资源管理器功能一致，没有须要特殊说明的地方，只是本身从头实现一个不能说很难，可是真的很麻烦。借这个地方简单讲一下这个缩略浏览器的实现，可能有些朋友对 GDI+ 不是很了解。

对于在 WinForm 下使用 GDI+ 绘制界面（本身实现一个控件），是比较原始的，想像一下给你一张白纸，和一些简单的绘图接口，画线，画圆，画矩形，其实没别的了。画一个圆角矩形？本身计算坐标系，经过画弧线和画直线画一个。显示一些文本？本身进行字体字号测量坐标系换算，若是涉及到文本换行，超长用省略号代替，都是比较麻烦的。

你要本身在 逻辑上 把握控件的不一样状态，如选中，非选中，鼠标滑过等等，和WPF下预约义的状态组不一样，WinForm 下这些状态是你要本身去把握的，状态切换时，你要本身根据状态进行重绘……

在绘制界面时，你只有一个从0,0开始的二维的平面坐标系，和它的尺寸。实现这样一个缩略图浏览器，缩略图的排版，布局，一行显示多少个，何时换行，选中非选中，鼠标框选，滚动条滚动都须要本身实现，包括鼠标框选时的框，也是须要本身用 GDI+ 绘制的，而后本身计算坐标系，判断哪些项目应该处于被选中状态。

这个控件的代码接近3000行。如今回过头去看，只以为注释不够详细。

软件中大部分本身实现的控件，都采用了相似的架构进行设计：控件自己，布局管理器，呈现器，呈现器实现，主题。

 

6.生成数据库，生成项目

这里目前并不复杂，生成数据库根据数据实体定义生成便可，生成项目目前我直接使用了项目文件，由于我目前的项目文件格式就是 zip 包，内含 xml 文件。

附带产出是实现了一个简单的比较通用的向导功能。

 

7.其它控件的美化。

从上面的截图中可以看到我使用了至关多的自定义控件，或通过美化的 WinForm 自带控件，典型的几个除了上面的缩略图控件，还有IDE上面的主菜单（效果参考了 Paint.NET）， DataGrid，从新实现的 ComboBox 等等，竟然一步一步造成了一个本身的控件包。惋惜技术更新换代突飞猛进，如今也基本用不上了。

 

IDE 部分如今回过头去看，貌似实际功能并很少，可是核心架构已经基本完整了，后续若是继续开发，基本至关于开发插件和添加新的功能包。 

其中绝大部分是从空白 class 硬写出来的，不少地方用如今的眼光去看，存在很大的过分设计问题。

 

解析器部分我是用 Silverlight 实现了一个，核心实现了，业务没有实现完整，多是我如今的机器 Silverlight 版本有问题仍是怎么回事没有运行起来，也不想去调试了，

并不复杂，只是解析 zip 包，xml文件，生成界面，事件处发时解析事件序列中的事件便可。

 

最后，若是你如今要作客户端软件，选择 WPF 吧，生产性很是高，功能很是完善与强大，若是你担忧性能问题，我想说如今已经2015年了，不是2005年，若是你在开发中遇到了性能问题或其它问题，先从自身找缘由。

专业程序员永远从自身找问题，业余程序员从平台从语言找问题。

 

后记：

最后想写一点点我的的感想与反思。我在开发这个软件的过程当中，犯了许多的错误，这些错误未必是技术上的，但都是严重错误。

首当其冲：闭门造车。活在本身的技术宅世界里，历来不去想，也不肯意去想这个东西有多少实际价值，谁会去用它，到了后来，我明明潜意识里知道这个软件没有太大市场价值，就是不肯意去想这个问题，一门心思去开发。我记得那两年我随身带的手机里，记满了关于这个软件的想法和一些问题的实现思路。我在路上想到某个解决方案或者有什么想法，就立马掏出手机记录，怕回去就会忘记。有一个冬天住的地方没有空调，很是冷，写代码一直写一直写，两个手冻青了，就本身用热水瓶子捂捂继续写，那段时间每到周末就特别高兴，由于有2个完整的工做日能够利用了，不用单纯靠晚上的时间去写，很长一段时间我天天晚上我都只能睡四五个小时，个别时候还没睡着，天就蒙蒙亮了。可是这么辛苦的意义是什么呢？我当时没有认真的思考。

第二：目标很是的不明确。看上去有目标，我要作一个什么什么样的东西，可是太宏大，太宽泛，太遥远。没有认真的考量我要的究竟是个什么，因此彻底没有详细的计划，里程碑什么都没有。

第三：缺乏与外界沟通。这个沟通除了技术，更多的是市场对技术的需求究竟是什么，若是回到当初，我会抽本身一巴掌，你睁开眼睛，走出去看看别人的世界好吗！作技术不是高新技术行业，更多的是服务业，咱们须要利用手中的技术去为他人服务，这是技术存在的意义。

第四：不懂快速迭代，最小可用集。这个概念如今应该你们都知道了，在当年好像并非很流行，也可能和我长期作企业级开发有关系，项目周期都很是长。作产品若是不懂得快速迭代是很是危险的，最小可用集就是只要达到最低可用的限度，就立马拿出去见人，固然范围能够是有限的。根据 真正 用户的反馈，快速调整。这个提及来简单，技术人员作起来很容易失控，我作这款软件，就是花了大量的时间精力去研究技术方面的问题，以致于在某些方面挖的很是深，可是这个东西和个人 大目标 其实没有必然关系，无论技术好很差，差一点就差一点，先作出东西来，先用起来，功能先实现，业务先转起来，论证了这东西基本的可行性，再经过迭代去优化。

第五：作东西尽可能不要藏着掖着。没意义，藏着掖着无非怕别人剽窃了本身的创意，想法，这个先不论创意想法有多大实际价值，就算你的想法真的很厉害，若是你没有其它门槛，别人看了就会抄去，那你这个东西必定是会出问题的。门槛这么低，怎么就你想到了？别算别人确实一时没想到，你没有其它门槛，被抄了是早晚的事情，藏着掖着没有用。作了东西就要勇敢拿出来和人交流，正面的就吸纳，负面的就多反思本身。

第六：开发这个软件的过程当中，我看完了《人月神话》，《代码大全》，《设计模式》，和其它一些不是那么有名的书籍，一半以上 SharpDeveloper 源代码。不少是在地铁，长途车，火车里看的，当时好像没有平板，有一次在火车上抱着笔记本电脑看《设计模式》，被旁边妹子主动搭讪：“你是程序员吧”，想像一下，绿皮车，一堆人…… 上面讲的几本书我推荐有时间就看一看，特别特别是《代码大全》，必定要看。个人体会是若是没有目标，没有目的的看书学习，很难深切领会，很容易泛泛而谈，我当时看这些书大部分缘由是被逼的，由于我老是遇到我搞不定的问题，我必须去寻求解决方案，好比设计模式，我当时也是被逼急了，有结构上的问题搞不定，就处处查资料，看书，一边看一边带着目的的去想，这样行不行，那样行不行，这样成长确实比较快。