Discuz!是PC互联网时代搭建社区论坛的开源系统，虽然很早就接触过Discuz，但一直没有研究过它系统设计和源码实现。直到去年开始做一个基于Discuz的移动社区项目时，才深入了解了一下Discuz。虽然最后该项目没有取得很好的发展，但是站在技术的角度，Discuz还是给了我很多启发。于此梳理下若干要点，以作备忘。        1．运营也是用户        计算机专业的教课书告诉我们软件是程序加文档。但是在互联网领域，用户在访问网站，使用APP时根本不会阅读使用手册，也压根没有什么使用手册可以看。难道互联网系统都是简单的不用看任何文档就直接会用吗？对于网民而言，确实是这样。产品经理在设计互联网产品时，会充分考虑交互设计，优化用户体验，用最直接的方式给每个小白用户他们想要的信息和服务。但是，严格地讲，网民只是互联网软件的服务对象，不是软件的真正使用者。而网站的运营人员（很多网站的运营人员就是开发者）才是互联网软件的真正使用者，他们需要去了解软件的各种功能和配置，需要了解软件的运行状态，需要处理软件运行过程中出现的各种异常情况等等。        运营是互联网软件的用户，这个认知的产生对开发者提出了新的要求：在设计和开发web系统时必须考虑运营用户。        2.为运营用户开发运营系统        既然运营也是用户，那么就需要照顾好这个用户，为他们提供便于操作的运营系统。虽然开发运营系统，会增加一些开发成本，但从长远来看，它在整个互联网系统上线后节省的运营成本会远远大于为之付出的开发成本：运营可以自行配置软件，而不用麻烦技术；某些业务需求只需点下按钮，而不用再经历改代码，测试，上线这个漫长的流程。当然运营系统不仅仅是配置系统，它是互联网软件的使用手册和控制台，软件的功能说明，各种配置，运行状态等都可以集成在运营系统中。（PS：如果想了解Discuz，建议从它的后台管理系统开始）。当运营系统成为互联网软件必不可少的组成部分后，对于开发而言，也将变得有所不同。        3.互联网软件的功能 = 开发 + 运营配置         运营系统产生之后，对开发带来最直接的变化是：产生了丰富的运营变量。这是因为，当我们开发运营系统时，就会对运营中需要配置的各种数据去设计数据结构（比如我们会为导航菜单设计一个tree的数据结构）。与使用配置文件（如xml）中kv格式的配置变量而言，这种富数据结构的运营变量给系统带来了更大的灵活性，使得系统的部分功能可以从hardcode转向运营变量来实现（比如导航菜单，页面布局）。而且随着深入实践，开发人员会越来越倾向于将功能转移到运营变量中实现，尤其是与业务紧耦合的功能，比如用户权限，颜色，图标等等。由此带来了下一个重要改变：技术与业务的解耦。        4.动静分离：技术与业务解耦         对于开发者而言，改代码是件很恐怖的事情。因为哪怕只动一个标点符号，都可能导致系统无法运行。而且一旦代码有改动，按照正规的流程都需要过测试再上线，这个成本是非常大的。所以对技术而言，我们不喜欢代码被频繁改动，我们喜欢代码是静的。但是对于业务而言，系统最好是个变形金刚，能适应业务的各种变化。网上流传的各种程序员与产品运营之间的爱恨纠葛本质上都是技术与业务的动静矛盾导致的。从根本上解决这个矛盾不太现实，但是运营变量的产生为程序员缓和这个矛盾提供了途径。         运营变量生而为运营用户设计，它对于运营而言是可变的，能按照不同的业务需求变换；但对于开发者而言，它是代码中的一个变量，在开发中是静止的。这样业务上需要变化或者可能变化的功能就可以通过运营变量来实现，而相对稳定的技术代码或者不频繁变化的业务代码（如网站logo）则可以hardcode。         随着技术和业务的不断解耦，技术和业务中的不变成分被不断沉淀，业务中的可变成分变得越来越灵活，能适应越来越多的业务场景，逐渐成为这一业务领域的通用系统。这对于开发而言，又带来一个新的启发。 5.设计和开发更通用的系统        软件工程中有一个原则叫依赖倒置，意思是，具体依赖抽象而不是抽象依赖具体（针对接口编程，而不是针对实现编程）。这个原则同样适用于系统设计：站在更高的角度去抽象具体业务问题，不要只为一个具体业务去设计系统，而是为业务领域的一般业务模型和方法论去设计和开发更通用的系统。（前提是，在排期允许的情况下，^_^）

Discuz!是PC互联网时代搭建社区论坛的开源系统，虽然很早就接触过Discuz，但一直没有研究过它系统设计和源码实现。直到去年开始做一个基于Discuz的移动社区项目时，才深入了解了一下Discuz。虽然最后该项目没有取得很好的发展，但是站在技术的角度，Discuz还是给了我很多启发。于此梳理下若干要点，以作备忘。        1．运营也是用户        计算机专业的教课书告诉我们软件是程序加文档。但是在互联网领域，用户在访问网站，使用APP时根本不会阅读使用手册，也压根没有什么使用手册可以看。难道互联网系统都是简单的不用看任何文档就直接会用吗？对于网民而言，确实是这样。产品经理在设计互联网产品时，会充分考虑交互设计，优化用户体验，用最直接的方式给每个小白用户他们想要的信息和服务。但是，严格地讲，网民只是互联网软件的服务对象，不是软件的真正使用者。而网站的运营人员（很多网站的运营人员就是开发者）才是互联网软件的真正使用者，他们需要去了解软件的各种功能和配置，需要了解软件的运行状态，需要处理软件运行过程中出现的各种异常情况等等。        运营是互联网软件的用户，这个认知的产生对开发者提出了新的要求：在设计和开发web系统时必须考虑运营用户。        2.为运营用户开发运营系统        既然运营也是用户，那么就需要照顾好这个用户，为他们提供便于操作的运营系统。虽然开发运营系统，会增加一些开发成本，但从长远来看，它在整个互联网系统上线后节省的运营成本会远远大于为之付出的开发成本：运营可以自行配置软件，而不用麻烦技术；某些业务需求只需点下按钮，而不用再经历改代码，测试，上线这个漫长的流程。当然运营系统不仅仅是配置系统，它是互联网软件的使用手册和控制台，软件的功能说明，各种配置，运行状态等都可以集成在运营系统中。（PS：如果想了解Discuz，建议从它的后台管理系统开始）。当运营系统成为互联网软件必不可少的组成部分后，对于开发而言，也将变得有所不同。        3.互联网软件的功能 = 开发 + 运营配置         运营系统产生之后，对开发带来最直接的变化是：产生了丰富的运营变量。这是因为，当我们开发运营系统时，就会对运营中需要配置的各种数据去设计数据结构（比如我们会为导航菜单设计一个tree的数据结构）。与使用配置文件（如xml）中kv格式的配置变量而言，这种富数据结构的运营变量给系统带来了更大的灵活性，使得系统的部分功能可以从hardcode转向运营变量来实现（比如导航菜单，页面布局）。而且随着深入实践，开发人员会越来越倾向于将功能转移到运营变量中实现，尤其是与业务紧耦合的功能，比如用户权限，颜色，图标等等。由此带来了下一个重要改变：技术与业务的解耦。        4.动静分离：技术与业务解耦         对于开发者而言，改代码是件很恐怖的事情。因为哪怕只动一个标点符号，都可能导致系统无法运行。而且一旦代码有改动，按照正规的流程都需要过测试再上线，这个成本是非常大的。所以对技术而言，我们不喜欢代码被频繁改动，我们喜欢代码是静的。但是对于业务而言，系统最好是个变形金刚，能适应业务的各种变化。网上流传的各种程序员与产品运营之间的爱恨纠葛本质上都是技术与业务的动静矛盾导致的。从根本上解决这个矛盾不太现实，但是运营变量的产生为程序员缓和这个矛盾提供了途径。         运营变量生而为运营用户设计，它对于运营而言是可变的，能按照不同的业务需求变换；但对于开发者而言，它是代码中的一个变量，在开发中是静止的。这样业务上需要变化或者可能变化的功能就可以通过运营变量来实现，而相对稳定的技术代码或者不频繁变化的业务代码（如网站logo）则可以hardcode。         随着技术和业务的不断解耦，技术和业务中的不变成分被不断沉淀，业务中的可变成分变得越来越灵活，能适应越来越多的业务场景，逐渐成为这一业务领域的通用系统。这对于开发而言，又带来一个新的启发。 5.设计和开发更通用的系统        软件工程中有一个原则叫依赖倒置，意思是，具体依赖抽象而不是抽象依赖具体（针对接口编程，而不是针对实现编程）。这个原则同样适用于系统设计：站在更高的角度去抽象具体业务问题，不要只为一个具体业务去设计系统，而是为业务领域的一般业务模型和方法论去设计和开发更通用的系统。（前提是，在排期允许的情况下，^_^）