-----------------------------------------------------------------------------
Writen by lwz7512 in 2006/11/8--2006/11/19
Email:rabbit69@126.com
------------------------------------------------------------------------------
part One:常规编码习惯
------------------------------------------------------------------------------------------------------
1.画布(canvas)里的元素按顺序编写
这个顺序从上到下依次是：
<canvas>
<debug/>
<splash/>
<style/>
<include/>
...
...
<resource/> or none
<dataset/>
...
...
<handler name="oninit"/>
<method/>
...
...
<view/> or <customview/>
...
...
<window/> or <modaldialog/>
...
...
</canvas>
注意：“...”表示和上面类型相同的标签声明
2.自定义组件的编写按照openlaslzo标准组件的格式编写
即按照这个顺序：
<library>
1
<include/>
...
...
<resource/>
...
...
<class>
<attribute/>
...
...
<method/> or <handler/>
...
...
<view/>
...
...
</class>
</library>
3.相同类型标签区域用注释间隔
各个代码区域都用注释符间隔开来，并标明其下面的代码类型，比如有很多方法都是放在一起了，那么可以这样表示：
<!--****** method declaration section ******-->
<method name="" .../>
...
...
<!--****** end of method declaration ******-->
当然把方法或者资源各自单独形成一个文件然后include进来也是很好的做法，因人而异。
4.同级视图命名唯一性
每个视图都要有个名字(name)，不使用id，且不能和同级路径下其他视图重名，也不能用属性名当作视图名称，如不能这样：
name="name"，x="x" ...
所有的视图引用采用name，而不用id，即采用局部变量而不是全局变量，这样是为了让引用的路径清晰可见。
5.使用绝对坐标值定位视图
每个视图尽量用绝对数值进行定位，少用绑定表达式，这样调整视图位置时也便于控制，后面还会讲到为什么少用绑定表达式。
6.引用视图采用最短路径原则 2
这样做是为了让引用更加方便，比如：一个位于深层次的视图要引用一个canvas下的视图，就用canvas.targetview，而如果它要引用同级路径的视图，就应该用parent.targetview。
7.标签严格缩进对齐
代码按照本身在canvas或者library中的层次进行严格缩进，对应的标签一定要对齐，层次高的视图在前面，层次后的视图依次向后缩进，形成阶梯状结构。
8.标签命名与变量命名原则
标签的name、方法的name、变量的name采用Java的命名习惯，即第一个字母小写，后续单词的首字母大写，例如：
createUserWin表示一个新建用户的窗口名称；getUserInfo表示获取用户信息的方法名称；userDataNode表示一个用户的数据，它是一个变量(var).
此外，类以及自定义组件的名称，即<class name="mycomponent" .../>中的mycomponent最好都用小写，这符合openlaszlo的标准组件定义规则。
9.方法编写原则
首先，方法名称要唯一，一个方法如果对于整个应用有通用性，就将其放在canvas下，或者一个单独的方法库文件中，如果它只对特定视图、组件有用，就放在视图、组件内部。此外，一个方法的长度最好不要超过50行。
10.dataset与datapointer成对使用
每一个dataset定义都应该有一个datapointer指向它来获取dataset中的数据状态，主要是ondata，并且由datapointer中的ondata事件执行组件的数据填充操作。
11.常用视图组件化
将某项完成特定功能的视图抽象成组件，这符合OOP的思想。组件使openlaslzo的应用具有模块化的特点，便于代码维护、重用，最大限度的减少总代码量和编译后的文件尺寸。
12.中文字号以12号为基准
在openlaslzo的应用中，如果canvas中定义的全局fontsize的值小于12号，那么汉字将变得很难分辩，效果很不好，建议标准字体为12个point，如果还觉得小，那再加大。
13.lzx编辑工具采用xmlspy编辑器
xmlspy是编辑xml文件的最好工具，而且天然的unicode编码，还可以自定义喜欢的代码颜色。而用IDE4laslzo编辑还需要指定编码为UTF-8，代码自动完成功能不强，回车不能跳到下一行的当前位置，毛病一大堆。对于新手还比较适合，对于老手还是手写代码比较好，不要引入schema(如果引入无法使用自定义组件)，直接在xmlspy里编写。 3
part Two:性能优化的最佳实践
------------------------------------------------------------------------------------------------------
1.dataset的请求(request)属性永远是false
只有在事件中才进行doRequest()
2.尽量少用始终绑定${}来指定视图间的位置关系
比如：<view name="myview" x="${parent.b.x}" .../>因为程序在初始化过程中要评估表达式的值，而且生成约束constraints，这样对性能产生很大影响。
3.需要数据来生成视图内容的组件尽量不用严格数据绑定
这样做是为了减少程序编译时间合减少服务期端传送过来的文件尺寸。正确的做法是将组件的datapath置为空，即定义组件的datapath=""，而在用户事件或者在datapointer中的ondata事件中用component.datapath.setPointer(this.p)中进行运行时绑定。
4.通过事件给组件填充数据
combobox、list等组件的数据只在需要时填充，通过打开窗口或者点击按钮的事件来为这些组件填充内容。只要填充了一次，下次如果数据没变，就不会再重复生成视图。
5.使用initstage="defer"
laslzo官方文档推荐使用initstage="defer"来阻止某些不是马上用到的视图的生成，而在需要的时候才complete，但本人试过，不太好掌握时机，而且会让程序变的互相耦合，效果不甚理想。
6.使用dataoption="lazy"
list组件有一个很有用的属性：dataoption="lazy"，这个属性可以使列表中的数据更新起来非常迅速，尤其是在大数据量的情况下。它的原理在于把部分视图进行了缓存，而不是全部销毁和新建，可惜tree组件对于这个属性不好使。
7.tree组件推荐使用lazytree
这是一个经过改进的tree组件，阻止了递归生成深层次节点过程，只有打开当前节点才生成下一级节点，这对大数据量的内容显示非常有用。tree组件的缺点是生成的节点速度仍然较慢，而且占用内容很大，一个有几百个节点的树完全打开的话，占用几十兆的内存，而且更新树的话会造成flashplayer报警。lazytree组件的源码如下：
<class name="steptree" extends="tree">
<!-- Turn off auto-recursion for tree. Get child nodes when tree is opened. -->
<attribute name="recurse" value="false" type="boolean"/>
<attribute name="haveChildren" value="false" type="boolean"/>
<method event="onopen" args="o"><![CDATA[
// If we already have children, don't fetch them again.
4
if (this.haveChildren) return;
if (o) {
// Now set recurse to true. This value is used in basetree's
// createChildTrees() method. See
// lps/components/base/basetree.lzx for and
// lps/components/lz/treee.lzx source code.
this.setAttribute('recurse', true);
createChildTrees();
this.setAttribute('recurse', false);
// We have child nodes.
this.setAttribute('haveChildren', true);
}
]]></method>
</class>
8.尽量降低视图的层次
尽可能的减少视图的嵌套层次，能直接放在canvas下，就不要放在其他视图里面，而且window和modaldailog应该严格的直接放在canvas里面。这样做是为了加快程序的渲染速度，并且简化编程时路径引用，方便查看代码结构。
9.尽量少用state/animator
用这些会增加内存占用和代码量，而用node的animate方法却可以轻松的控制视图运动，而且没有额外的内存占用。
10.控制单个canvas文件的代码规模
一个canvas文件代码行数最好控制在1000行以内，其中include进来的方法、资源、自定义组件的代码数目不算在内，这样做是为了获得较快的界面初始化时间，和方便的代码维护。
11.尽量采用方式solo部署
如果不需要rpc等特殊功能，建议采用solo方式部署应用，将已经写好的openlaslzo应用编译成swf文件，在html文件中包裹，这样可避免用户第一次请求lzx文件的长时间等待，也避免了服务期重起后重新编译lzx文件，还可以减少lps server部署时对服务器空间的占用(尽管才十几兆)。
12.模块化应用
将具有独立功能的应用模块单独分离出来，即用一个包含canvas的lzx文件配合其他组件来实现一个小模块，各个模块之间导航用loadURL()来完成，各个模块共享session以及后台数据，实现模块之间的通讯。
5
part Three:提高编程效率的原则
--------------------------------------------------------------------------------------------------
1.只做自己擅长的事
openlaslzo只擅长做表现层，不要奢求在界面上处理一些复杂逻辑，这些要交给后台处理。也不要用它来做类似于博客等以文字为主的应用，体现不出优势，反而体现出劣势。
2.做好自己该做的事
类似于客户端数据校验的功能，前台该做好的，就不要交给后台去判断数据是否有效，前台每次提交都要保证自己是没有问题的，和后台的结合应该是无障碍的。
3.不要过分追求效果
不要为了RIA而故意RIA，界面的过多动态效果，只会让用户眼花缭乱，而且加大了代码量，增加了性能问题，损害了用户体验，只有简单中有一点新奇、静中有动才是境界。
4.不要急于看到结果
新手往往每次写点东西都立刻编译想看到结果，这样也是情有可原，但是不能养成习惯，一般是写一段代码，比较完整了，才去看效果，所以事先的设计就显得很重要。
part Four:开发RIA过程
--------------------------------------------------------------------------------------------------
第一步 选定运行平台
以java平台为例，可以采用struts作为界面和后台服务的框架，也可以考虑采用webservice，至于webservice的性能如何，没有验证过。因为openlaslzo的编译server是基于java平台的，所以部署时仍采用java平台也是合情合理的，其他平台，比如.net、php、ROR也是可以考虑的，但是只能以solo模式部署，如果需要修改或者调整不甚方便。
第二步 项目架构设计
针对项目的要求，设计整体的技术架构，尤其是后台的架构，用什么做服务层，是否采用数据持久层，数据库采用什么等等问题，这个部分可以沿用传统web设计思想，但是还要要抽象出中间数据层，作为laszlo和后台的接口。
第三步 划分功能模块
根据项目的要求，将任务分解为几个大的部分，个别大的功能模块如果功能仍然复杂的话要继续拆分，直至每一块都是一个单独的小型应用单元，其代码量不足以影响到应用程序初始化的性能。
第四步 设计数据库结构
根据前面的任务设计数据库的表、字段及其关联关系，这部分与传统应用的数据库设计原则相同，只不过对性能的要求更高一些，所以表之间的关联尽量简单。
第五步 设计界面原型 6
根据模块划分结果，对各子模块的用户界面进行草稿设计，包括界面、窗体的内容、交互过程涉及到的各个部分，大致刻画出轮廓来。
第六步 定义前后台接口的xml文件结构(schema)
根据界面组件所需的数据内容，定义xml文件格式，后台需要根据这个格式来动态生成xml字符串，生成这个接口xml文件的应用层称为中间数据层，一个类应该只有一个公共方法来获取xml字符串。
第七步 编写业务逻辑
按照业务需要编写具体的实现，这部分和传统web应用的model是一致的，但是每次业务逻辑的执行结束要返回一个xml信息给界面，界面根据这个信息来刷新相应的视图。
第八步 界面部分的开发
这个过程可以后后台程序编写同时进行，分别由不同的开放人员完成。这个过程主要定义用户界面、交互方式、数据传递等等，这个过程需要比较真实的数据进行测试驱动的开发，这个数据可以是静态xml数据。
第九步 前后台整合
界面程序调用后台程序提供的数据源，并按照所需的参数来配置dataset的查询参数，一步步完成前后台整合。在发出请求时务必保证参数名称正确、参数值不为空。
第十步 整合子模块为系统
将各个子模块通过合理的导航方式组织起来，并组织好文件的目录结构、名称，使得各模块内容便于区分。
第十一步 美化界面
这一步需要设计人员提供设计好的背景资源，由界面开发人员加到代码中，并做UI方面的细节调整，有的需要调整代码，有的需要调整资源图片，所以这部分是设计与开发的整合过程。
第十二步 功能完整性与系统可用性测试
系统测试人员需要对软件得各项功能进行测试，而且主要对性能表现进行评估，以及界面感觉、交互体验给出结论，一般情况前期设计合理的话性能问题不会太大，但是这个问题往往不能避免，尤其是大型应用中容易出现，而且需要花大量的时间来调整性能。
第十三步 系统试运行
系统测试通过后，则部署在服务器上通过用户的实际使用情况来观察其表现，确认有无内存泄漏，无系统负荷过载，各项功能是否完整，这个阶段往往会发现一些系统的bug，以及并发访问等引起的性能问题，以便进一步完善系统。
7
-----------------------------------------------------------------------------------------
part Five 结束语
这是这篇文档的结束，相信这篇文章对初涉openlaslzo开发的朋友有所帮助，也相信许多高级openlaslzo开发者对这篇文章会有自己的看法，请你们主动提出来，很希望得到你们的反馈来修正这篇规范，如果不提出来，就说明我是正确的，如果我真是错的，那么误人子弟我可罪莫大矣。
openlaslzo的开发一直没有一个开发规范来让大家遵守，没有一个方向来让大家直行，但愿这个规范起个好的开头，引起大家对开发规范和开发模式的讨论和重视。
lwz7512 from beijing China
Nov.19.2006
Writen by lwz7512 in 2006/11/8--2006/11/19
Email:rabbit69@126.com
------------------------------------------------------------------------------
part One:常规编码习惯
------------------------------------------------------------------------------------------------------
1.画布(canvas)里的元素按顺序编写
这个顺序从上到下依次是：
<canvas>
<debug/>
<splash/>
<style/>
<include/>
...
...
<resource/> or none
<dataset/>
...
...
<handler name="oninit"/>
<method/>
...
...
<view/> or <customview/>
...
...
<window/> or <modaldialog/>
...
...
</canvas>
注意：“...”表示和上面类型相同的标签声明
2.自定义组件的编写按照openlaslzo标准组件的格式编写
即按照这个顺序：
<library>
1
<include/>
...
...
<resource/>
...
...
<class>
<attribute/>
...
...
<method/> or <handler/>
...
...
<view/>
...
...
</class>
</library>
3.相同类型标签区域用注释间隔
各个代码区域都用注释符间隔开来，并标明其下面的代码类型，比如有很多方法都是放在一起了，那么可以这样表示：
<!--****** method declaration section ******-->
<method name="" .../>
...
...
<!--****** end of method declaration ******-->
当然把方法或者资源各自单独形成一个文件然后include进来也是很好的做法，因人而异。
4.同级视图命名唯一性
每个视图都要有个名字(name)，不使用id，且不能和同级路径下其他视图重名，也不能用属性名当作视图名称，如不能这样：
name="name"，x="x" ...
所有的视图引用采用name，而不用id，即采用局部变量而不是全局变量，这样是为了让引用的路径清晰可见。
5.使用绝对坐标值定位视图
每个视图尽量用绝对数值进行定位，少用绑定表达式，这样调整视图位置时也便于控制，后面还会讲到为什么少用绑定表达式。
6.引用视图采用最短路径原则 2
这样做是为了让引用更加方便，比如：一个位于深层次的视图要引用一个canvas下的视图，就用canvas.targetview，而如果它要引用同级路径的视图，就应该用parent.targetview。
7.标签严格缩进对齐
代码按照本身在canvas或者library中的层次进行严格缩进，对应的标签一定要对齐，层次高的视图在前面，层次后的视图依次向后缩进，形成阶梯状结构。
8.标签命名与变量命名原则
标签的name、方法的name、变量的name采用Java的命名习惯，即第一个字母小写，后续单词的首字母大写，例如：
createUserWin表示一个新建用户的窗口名称；getUserInfo表示获取用户信息的方法名称；userDataNode表示一个用户的数据，它是一个变量(var).
此外，类以及自定义组件的名称，即<class name="mycomponent" .../>中的mycomponent最好都用小写，这符合openlaszlo的标准组件定义规则。
9.方法编写原则
首先，方法名称要唯一，一个方法如果对于整个应用有通用性，就将其放在canvas下，或者一个单独的方法库文件中，如果它只对特定视图、组件有用，就放在视图、组件内部。此外，一个方法的长度最好不要超过50行。
10.dataset与datapointer成对使用
每一个dataset定义都应该有一个datapointer指向它来获取dataset中的数据状态，主要是ondata，并且由datapointer中的ondata事件执行组件的数据填充操作。
11.常用视图组件化
将某项完成特定功能的视图抽象成组件，这符合OOP的思想。组件使openlaslzo的应用具有模块化的特点，便于代码维护、重用，最大限度的减少总代码量和编译后的文件尺寸。
12.中文字号以12号为基准
在openlaslzo的应用中，如果canvas中定义的全局fontsize的值小于12号，那么汉字将变得很难分辩，效果很不好，建议标准字体为12个point，如果还觉得小，那再加大。
13.lzx编辑工具采用xmlspy编辑器
xmlspy是编辑xml文件的最好工具，而且天然的unicode编码，还可以自定义喜欢的代码颜色。而用IDE4laslzo编辑还需要指定编码为UTF-8，代码自动完成功能不强，回车不能跳到下一行的当前位置，毛病一大堆。对于新手还比较适合，对于老手还是手写代码比较好，不要引入schema(如果引入无法使用自定义组件)，直接在xmlspy里编写。 3
part Two:性能优化的最佳实践
------------------------------------------------------------------------------------------------------
1.dataset的请求(request)属性永远是false
只有在事件中才进行doRequest()
2.尽量少用始终绑定${}来指定视图间的位置关系
比如：<view name="myview" x="${parent.b.x}" .../>因为程序在初始化过程中要评估表达式的值，而且生成约束constraints，这样对性能产生很大影响。
3.需要数据来生成视图内容的组件尽量不用严格数据绑定
这样做是为了减少程序编译时间合减少服务期端传送过来的文件尺寸。正确的做法是将组件的datapath置为空，即定义组件的datapath=""，而在用户事件或者在datapointer中的ondata事件中用component.datapath.setPointer(this.p)中进行运行时绑定。
4.通过事件给组件填充数据
combobox、list等组件的数据只在需要时填充，通过打开窗口或者点击按钮的事件来为这些组件填充内容。只要填充了一次，下次如果数据没变，就不会再重复生成视图。
5.使用initstage="defer"
laslzo官方文档推荐使用initstage="defer"来阻止某些不是马上用到的视图的生成，而在需要的时候才complete，但本人试过，不太好掌握时机，而且会让程序变的互相耦合，效果不甚理想。
6.使用dataoption="lazy"
list组件有一个很有用的属性：dataoption="lazy"，这个属性可以使列表中的数据更新起来非常迅速，尤其是在大数据量的情况下。它的原理在于把部分视图进行了缓存，而不是全部销毁和新建，可惜tree组件对于这个属性不好使。
7.tree组件推荐使用lazytree
这是一个经过改进的tree组件，阻止了递归生成深层次节点过程，只有打开当前节点才生成下一级节点，这对大数据量的内容显示非常有用。tree组件的缺点是生成的节点速度仍然较慢，而且占用内容很大，一个有几百个节点的树完全打开的话，占用几十兆的内存，而且更新树的话会造成flashplayer报警。lazytree组件的源码如下：
<class name="steptree" extends="tree">
<!-- Turn off auto-recursion for tree. Get child nodes when tree is opened. -->
<attribute name="recurse" value="false" type="boolean"/>
<attribute name="haveChildren" value="false" type="boolean"/>
<method event="onopen" args="o"><![CDATA[
// If we already have children, don't fetch them again.
4
if (this.haveChildren) return;
if (o) {
// Now set recurse to true. This value is used in basetree's
// createChildTrees() method. See
// lps/components/base/basetree.lzx for and
// lps/components/lz/treee.lzx source code.
this.setAttribute('recurse', true);
createChildTrees();
this.setAttribute('recurse', false);
// We have child nodes.
this.setAttribute('haveChildren', true);
}
]]></method>
</class>
8.尽量降低视图的层次
尽可能的减少视图的嵌套层次，能直接放在canvas下，就不要放在其他视图里面，而且window和modaldailog应该严格的直接放在canvas里面。这样做是为了加快程序的渲染速度，并且简化编程时路径引用，方便查看代码结构。
9.尽量少用state/animator
用这些会增加内存占用和代码量，而用node的animate方法却可以轻松的控制视图运动，而且没有额外的内存占用。
10.控制单个canvas文件的代码规模
一个canvas文件代码行数最好控制在1000行以内，其中include进来的方法、资源、自定义组件的代码数目不算在内，这样做是为了获得较快的界面初始化时间，和方便的代码维护。
11.尽量采用方式solo部署
如果不需要rpc等特殊功能，建议采用solo方式部署应用，将已经写好的openlaslzo应用编译成swf文件，在html文件中包裹，这样可避免用户第一次请求lzx文件的长时间等待，也避免了服务期重起后重新编译lzx文件，还可以减少lps server部署时对服务器空间的占用(尽管才十几兆)。
12.模块化应用
将具有独立功能的应用模块单独分离出来，即用一个包含canvas的lzx文件配合其他组件来实现一个小模块，各个模块之间导航用loadURL()来完成，各个模块共享session以及后台数据，实现模块之间的通讯。
5
part Three:提高编程效率的原则
--------------------------------------------------------------------------------------------------
1.只做自己擅长的事
openlaslzo只擅长做表现层，不要奢求在界面上处理一些复杂逻辑，这些要交给后台处理。也不要用它来做类似于博客等以文字为主的应用，体现不出优势，反而体现出劣势。
2.做好自己该做的事
类似于客户端数据校验的功能，前台该做好的，就不要交给后台去判断数据是否有效，前台每次提交都要保证自己是没有问题的，和后台的结合应该是无障碍的。
3.不要过分追求效果
不要为了RIA而故意RIA，界面的过多动态效果，只会让用户眼花缭乱，而且加大了代码量，增加了性能问题，损害了用户体验，只有简单中有一点新奇、静中有动才是境界。
4.不要急于看到结果
新手往往每次写点东西都立刻编译想看到结果，这样也是情有可原，但是不能养成习惯，一般是写一段代码，比较完整了，才去看效果，所以事先的设计就显得很重要。
part Four:开发RIA过程
--------------------------------------------------------------------------------------------------
第一步 选定运行平台
以java平台为例，可以采用struts作为界面和后台服务的框架，也可以考虑采用webservice，至于webservice的性能如何，没有验证过。因为openlaslzo的编译server是基于java平台的，所以部署时仍采用java平台也是合情合理的，其他平台，比如.net、php、ROR也是可以考虑的，但是只能以solo模式部署，如果需要修改或者调整不甚方便。
第二步 项目架构设计
针对项目的要求，设计整体的技术架构，尤其是后台的架构，用什么做服务层，是否采用数据持久层，数据库采用什么等等问题，这个部分可以沿用传统web设计思想，但是还要要抽象出中间数据层，作为laszlo和后台的接口。
第三步 划分功能模块
根据项目的要求，将任务分解为几个大的部分，个别大的功能模块如果功能仍然复杂的话要继续拆分，直至每一块都是一个单独的小型应用单元，其代码量不足以影响到应用程序初始化的性能。
第四步 设计数据库结构
根据前面的任务设计数据库的表、字段及其关联关系，这部分与传统应用的数据库设计原则相同，只不过对性能的要求更高一些，所以表之间的关联尽量简单。
第五步 设计界面原型 6
根据模块划分结果，对各子模块的用户界面进行草稿设计，包括界面、窗体的内容、交互过程涉及到的各个部分，大致刻画出轮廓来。
第六步 定义前后台接口的xml文件结构(schema)
根据界面组件所需的数据内容，定义xml文件格式，后台需要根据这个格式来动态生成xml字符串，生成这个接口xml文件的应用层称为中间数据层，一个类应该只有一个公共方法来获取xml字符串。
第七步 编写业务逻辑
按照业务需要编写具体的实现，这部分和传统web应用的model是一致的，但是每次业务逻辑的执行结束要返回一个xml信息给界面，界面根据这个信息来刷新相应的视图。
第八步 界面部分的开发
这个过程可以后后台程序编写同时进行，分别由不同的开放人员完成。这个过程主要定义用户界面、交互方式、数据传递等等，这个过程需要比较真实的数据进行测试驱动的开发，这个数据可以是静态xml数据。
第九步 前后台整合
界面程序调用后台程序提供的数据源，并按照所需的参数来配置dataset的查询参数，一步步完成前后台整合。在发出请求时务必保证参数名称正确、参数值不为空。
第十步 整合子模块为系统
将各个子模块通过合理的导航方式组织起来，并组织好文件的目录结构、名称，使得各模块内容便于区分。
第十一步 美化界面
这一步需要设计人员提供设计好的背景资源，由界面开发人员加到代码中，并做UI方面的细节调整，有的需要调整代码，有的需要调整资源图片，所以这部分是设计与开发的整合过程。
第十二步 功能完整性与系统可用性测试
系统测试人员需要对软件得各项功能进行测试，而且主要对性能表现进行评估，以及界面感觉、交互体验给出结论，一般情况前期设计合理的话性能问题不会太大，但是这个问题往往不能避免，尤其是大型应用中容易出现，而且需要花大量的时间来调整性能。
第十三步 系统试运行
系统测试通过后，则部署在服务器上通过用户的实际使用情况来观察其表现，确认有无内存泄漏，无系统负荷过载，各项功能是否完整，这个阶段往往会发现一些系统的bug，以及并发访问等引起的性能问题，以便进一步完善系统。
7
-----------------------------------------------------------------------------------------
part Five 结束语
这是这篇文档的结束，相信这篇文章对初涉openlaslzo开发的朋友有所帮助，也相信许多高级openlaslzo开发者对这篇文章会有自己的看法，请你们主动提出来，很希望得到你们的反馈来修正这篇规范，如果不提出来，就说明我是正确的，如果我真是错的，那么误人子弟我可罪莫大矣。
openlaslzo的开发一直没有一个开发规范来让大家遵守，没有一个方向来让大家直行，但愿这个规范起个好的开头，引起大家对开发规范和开发模式的讨论和重视。
lwz7512 from beijing China
Nov.19.2006
1554
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
