这是一个创建于 1530 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近想做一款产品，搭建官网，然后我感觉有很多重复性的工作。
比如我希望为网站增加一个问答系统，又比如我希望为网站增加一个文章系统，又比如我要开发网站的账号系统，注册+登录+手机验证+邮箱发送验证+找回密码等等。
搭建完之后，我还要搭建产品的文档和帮助中心等等。
其实这些东西，你做下一款产品的时候，这种工作依然是重复的。
我也在想，这世界上，会不会还有人跟我一样，做着一样重复的工作呢？
也许你会说，搭建问答系统？网上有很多开源的问答系统啊，至于文章系统？也有很多 CMS 啊。
至于帮助中心，网上很多产品啊，语雀、gitbook，很多很多。
但你有没有发现，这些东西都很重，比如我如果引进一个问答系统，就是引进一整套的东西，文章系统，又是一整套的东西。
也就是说，我希望这些服务可以定制化、标准化、颗粒化。
最好像集装箱一样，问答系统是一个集装箱，文章系统是一个集装箱，帮助中心是一个集装箱。注册登录也是一个集装箱。
当我搭建我的网站时，我希望这些集装箱拼在一块，组合起来。节省我的效率。
比如文章系统，我可以给你提供接口，甚至是一个 UI 模块。你只需要在前台引入就行了。
后端的文章点击、点赞、文章查看量、文章的发布和修改，都是我们网站提供的。
再比如，问答系统，一个问答系统，你只需要在前端嵌入问答系统就行了。问答的数据分析，后台的统计查看，都在我们网站上进行。
这样，互联网就像是一个一个的基建工程，我们提供最底层的模块化组装服务。
你们觉得这样会不会节省很多效率？
比如我希望为网站增加一个问答系统，又比如我希望为网站增加一个文章系统，又比如我要开发网站的账号系统，注册+登录+手机验证+邮箱发送验证+找回密码等等。
搭建完之后，我还要搭建产品的文档和帮助中心等等。
其实这些东西，你做下一款产品的时候，这种工作依然是重复的。
我也在想，这世界上，会不会还有人跟我一样，做着一样重复的工作呢？
也许你会说，搭建问答系统？网上有很多开源的问答系统啊，至于文章系统？也有很多 CMS 啊。
至于帮助中心，网上很多产品啊，语雀、gitbook，很多很多。
但你有没有发现，这些东西都很重，比如我如果引进一个问答系统，就是引进一整套的东西，文章系统，又是一整套的东西。
也就是说，我希望这些服务可以定制化、标准化、颗粒化。
最好像集装箱一样，问答系统是一个集装箱，文章系统是一个集装箱，帮助中心是一个集装箱。注册登录也是一个集装箱。
当我搭建我的网站时，我希望这些集装箱拼在一块，组合起来。节省我的效率。
比如文章系统，我可以给你提供接口，甚至是一个 UI 模块。你只需要在前台引入就行了。
后端的文章点击、点赞、文章查看量、文章的发布和修改，都是我们网站提供的。
再比如，问答系统，一个问答系统，你只需要在前端嵌入问答系统就行了。问答的数据分析，后台的统计查看，都在我们网站上进行。
这样，互联网就像是一个一个的基建工程，我们提供最底层的模块化组装服务。
你们觉得这样会不会节省很多效率？
第 1 条附言 · 2020-09-14 17:18:21 +08:00
针对网友的各种疑问，统一做个总结：
1 、你这个东西不是有 wordpress 这些可以实现吗？
我吃块牛排，你给我一整头牛，没有这个必要。
这类用户没有审好题目，不做解释。
2 、你这个需求和痛点是存在的，但是为什么没有人做出来？
首先提供一个帮助中心的文档服务，不可能形成一个市场，更不可能支撑起一家公司，这些专业做这个的，就提供一整套的服务，所以就有了各种专业的知识库产品，但我上面说了，这种解决方案太重。
一个小零件和小服务不足以撑起一家公司，所以没人做，
但是我这种小零件多了，就可以形成一个可观的市场和规模了。
3 、需求多样化，你这个东西不实际。
就像论坛系统，问答系统，这种东西其实看起来需求多样，但是可以提炼出一个模型的。
比如问答，就是最简单的提问，回答，
你要定制？对不起，不会开放太多的定制功能，因为会把产品变得复杂。
如果开发文档厚得像一本书，我看你文档的时间，还不如自己动手了。
4 、那如何应对用户需求多样化这个问题？
我可以提供几个套餐给你，比如问答系统，A 方案、B 方案、C 方案，根据不同的用户群体，选择不同的方案。
如果你需要更详细化的需求和定制，抱歉，你要么选择别的产品，要么自己动手开发。
4 、我为什么把数据放你那里？你公司倒闭了我怎么办？
有时候我开发一个产品，前期只需要快速搭建原型而已，我追求的就是快，效率、验证我的想法。
我们提供数据随时导出的功能，比如你公司发展到一定程度，注册用户 20 万，我可以提供一键导出数据的功能，把 20 万的数据导出，几秒钟的时间。
所以，你不需要过分依赖于我们的服务，这种服务的理念就是微小，随时可以装卸，转移。
5 、评论里面提到了 notion，实际上我也受他这个 all in 的思想启发了。
我们写文档有专业的工具，我们写表格也有专业的工具，但是 notion 的思想就是把这些零件都拆解出来，让你随意组合。我们也是一个 all in 的思想，把这些零件一个一个打包给你，让你随意装卸。
6 、你这个是前端组件化，还是说只提供 api，或者说提供一个服务？
不局限于形式。
比如我既可以提供 api，也可以提供 UI 组件，也可以提供一个中等规模的服务组件。
比如文章系统，就是一个组件。
比如用户填了邮箱，需要一个发送验证邮件的功能，这也可以作为一个组件，提供一个 api 给你就行了。
比如你需要前端产品页的展示，我们甚至提供一套前端的 UI 组合套件给你。
7 、你这个东西不就是傻瓜化建站，或者什么别的东西？你这个东西的定位是什么？
准确的定位应该是：互联网组件服务提供商。（好像也不太准确）
不是傻瓜化，我们提供一个服务
8 、市场存在吗？需求存在吗？痛点存在吗？
你可以观察很多公司的文章系统，比如石墨文档 https://shimo.im/blog
你看他这个博客，其实就是最简单的文章查看而已。
人家肯定是自己开发的，引入一个开源的东西没必要，太重。
所以很多人觉得用户肯定有一堆个性化的需求，
实际上，目前的互联网都是简洁至上的趋势，如无必要，勿增实体。
前端也有很多标准化的组件了，比如 element 这种东西，可能你插入一个表格，就是插入一个标准的组件而已。
又看看 zoom 官网的帮助文档，人家也是自己开发的： https://www.zoomvideo.cn/download/gettingstarted/
你可以观察很多很多的公司，他们为什么要自己造轮子？当然是因为没有好的解决方案。
这世界上肯定有很多这样的公司，他们每天做着重复性的劳动，但是这种劳动还真没啥技术含量，又不得不做。
1 、你这个东西不是有 wordpress 这些可以实现吗？
我吃块牛排，你给我一整头牛，没有这个必要。
这类用户没有审好题目，不做解释。
2 、你这个需求和痛点是存在的，但是为什么没有人做出来？
首先提供一个帮助中心的文档服务，不可能形成一个市场，更不可能支撑起一家公司，这些专业做这个的，就提供一整套的服务，所以就有了各种专业的知识库产品，但我上面说了，这种解决方案太重。
一个小零件和小服务不足以撑起一家公司，所以没人做，
但是我这种小零件多了，就可以形成一个可观的市场和规模了。
3 、需求多样化，你这个东西不实际。
就像论坛系统，问答系统，这种东西其实看起来需求多样，但是可以提炼出一个模型的。
比如问答，就是最简单的提问，回答，
你要定制？对不起，不会开放太多的定制功能，因为会把产品变得复杂。
如果开发文档厚得像一本书，我看你文档的时间，还不如自己动手了。
4 、那如何应对用户需求多样化这个问题？
我可以提供几个套餐给你，比如问答系统，A 方案、B 方案、C 方案，根据不同的用户群体，选择不同的方案。
如果你需要更详细化的需求和定制，抱歉，你要么选择别的产品，要么自己动手开发。
4 、我为什么把数据放你那里？你公司倒闭了我怎么办？
有时候我开发一个产品，前期只需要快速搭建原型而已，我追求的就是快，效率、验证我的想法。
我们提供数据随时导出的功能，比如你公司发展到一定程度，注册用户 20 万，我可以提供一键导出数据的功能，把 20 万的数据导出，几秒钟的时间。
所以，你不需要过分依赖于我们的服务，这种服务的理念就是微小，随时可以装卸，转移。
5 、评论里面提到了 notion，实际上我也受他这个 all in 的思想启发了。
我们写文档有专业的工具，我们写表格也有专业的工具，但是 notion 的思想就是把这些零件都拆解出来，让你随意组合。我们也是一个 all in 的思想，把这些零件一个一个打包给你，让你随意装卸。
6 、你这个是前端组件化，还是说只提供 api，或者说提供一个服务？
不局限于形式。
比如我既可以提供 api，也可以提供 UI 组件，也可以提供一个中等规模的服务组件。
比如文章系统，就是一个组件。
比如用户填了邮箱，需要一个发送验证邮件的功能，这也可以作为一个组件，提供一个 api 给你就行了。
比如你需要前端产品页的展示，我们甚至提供一套前端的 UI 组合套件给你。
7 、你这个东西不就是傻瓜化建站，或者什么别的东西？你这个东西的定位是什么？
准确的定位应该是：互联网组件服务提供商。（好像也不太准确）
不是傻瓜化，我们提供一个服务
8 、市场存在吗？需求存在吗？痛点存在吗？
你可以观察很多公司的文章系统，比如石墨文档 https://shimo.im/blog
你看他这个博客，其实就是最简单的文章查看而已。
人家肯定是自己开发的，引入一个开源的东西没必要，太重。
所以很多人觉得用户肯定有一堆个性化的需求，
实际上，目前的互联网都是简洁至上的趋势，如无必要，勿增实体。
前端也有很多标准化的组件了，比如 element 这种东西，可能你插入一个表格，就是插入一个标准的组件而已。
又看看 zoom 官网的帮助文档，人家也是自己开发的： https://www.zoomvideo.cn/download/gettingstarted/
你可以观察很多很多的公司，他们为什么要自己造轮子？当然是因为没有好的解决方案。
这世界上肯定有很多这样的公司，他们每天做着重复性的劳动，但是这种劳动还真没啥技术含量，又不得不做。
 |
1
svipchao 2020-09-14 04:25:37 +08:00 via Android
fastadmin?
|
 |
2
Trim21 2020-09-14 04:33:13 +08:00
django app （）
|
 |
3
yhhsuf 2020-09-14 04:40:26 +08:00
如果不介意客制化...后端 Django app, 前端 React Component?
|
 |
4
falcon05 2020-09-14 04:42:33 +08:00 via iPhone
WordPress，装相应的插件就有了
|
 |
5
milu2003516968 OP @falcon05 可能你们都没理解我的意思，我希望提供一种类似微服务的东西，只是提供服务，接口，跟语言无关。
比如你说 wordpress，那么等于局限了我的语言就是 php，而且我必须装一个 wordpress 的东西。这个东西很庞大的。 而我的环境是 nodejs 。 |
|
6
milu2003516968 OP 而且，你们有没有看见 zoom 的官网，帮助中心其实也是自己造的，如果有轮子，他为什么要自己造呢？
https://www.zoomvideo.cn/download/gettingstarted/ 我如果自己搭建，估计也是自己造的，因为我要引入别的东西，会很庞大。每家公司都有这种东西的，我看见很多都是自己造的，而不是第三方的东西。是他们喜欢自己造吗？恰恰是因为没有好的解决方案。 |
|
7
milu2003516968 OP 还有很多公司的新闻中心，blog 文章，有时候就是需要简单的功能而已。如果引入一个博客系统，太累赘了。有的时候，我就需要一个服务，就是一个 api 接口，让我展示在前端而已，后端的东西全部打包成一个服务就可以了。
我观察了很多的公司的网站，其实都是自己开发的居多，如果有现成的解决方案，他们为什么要自己造呢？ |
|
8
milu2003516968 OP  1
再来说说注册登录这个东西，账号系统，包括微信登录，手机验证。邮件发送，找回密码。
如果有一家公司能提供一整套的解决方案，我只需要调用 api 接口，那也是大大提升效率的。而且这些东西每家公司需求都差不多，是可以做成一个标准的服务组件的。 |
|
9
milu2003516968 OP 总结起来，这些东西如果目前有一家公司能够提供一套方案给我，可能我半个月的工期，直接缩短成 3 天就完成了，而且成本大大降低。
|
 |
10
jin7 2020-09-14 05:24:27 +08:00
除非世界上只有一种语言 一种框架
|
|
11
milu2003516968 OP 1
之前想搞一个帮助中心，产品文档的东西，我发现这个 https://www.vuepress.cn/config/ 东西还挺好用，然后花了几个晚，看人家的教程配置，然后又是部署在服务器上面。我就想，这种东西，难道就没有人做成一个服务吗？
文章在后台发布和修改，前端只需要引入就行了。很难吗？我为什么要花几个晚上去研究这些配置和代码，光一个侧边栏都搞得我火大。 而且如今有语雀啊这些乱七八糟的知识库，可是我为什么就用不上呢？这些东西都太庞大了，而且我还要跳到人家的网站去才行，各种体验非常不好。 所以，有类似需求的人肯定不止我一个人。我看到大多数公司都是自己搭建的多。 |
|
12
milu2003516968 OP @jin7 api 跟语言框架是没关系的。我现在前端也只是调用了后端的 api 而已，这个后端可以是 nodejs，或者 php，都没关系的。现在前端和后端普遍都是互相分离的。
|
 |
13
tydl 2020-09-14 06:39:08 +08:00 via Android
@milu2003516968 微信 qq 集成登录
|
 |
14
nvkou 2020-09-14 07:37:26 +08:00 via Android
开源 SSO ～开箱即用的用户管理，权限管理
firebsse ～开箱即用的移动推送 各种云数据库～开箱即用的数据库 即使是 WordPress 都有 API 可以调用的啊。不是只能 php 渲染 |
|
15
milu2003516968 OP @tydl 不是这个东西，我要表达的不是这个东西。
|
|
16
milu2003516968 OP @nvkou 不是这个东西，我要表达的不是这个东西
|
 |
17
richangfan 2020-09-14 07:51:31 +08:00
那就是系统本来就有的功能，只是没开启。你到管理后台一开启，好像真的添加了一个模板似的
|
 |
18
zoikhemlab 2020-09-14 08:09:40 +08:00
你的意思是纯靠 api，各种服务只暴露相应的出口就行对吧？
|
 |
19
renmu123 2020-09-14 08:12:49 +08:00 via Android
你先问问产品经理同不同意🐶
|
 |
20
blless 2020-09-14 08:15:50 +08:00 via Android
阿里好像有搞一个 ice 不知道是不是楼主想要的
|
 |
21
goinghugh 2020-09-14 08:20:33 +08:00 3
如果你只是简单的使用某种功能，这种标准的还是比较容易做的。但是一般情况下，每个公司都有自己的需求，比如账号系统，假如现在有第三方的账号系统，账号体系可能是大而全，也可能是小而精，大而全的时候你简单的使用，会引入很多你不需要的东西到系统中，如果小而精，那又各种不满足，需要你自己理解源码进行二次开发，这样并不会减少太多的工作量。并且需求不是静态的，明天提了一个新的需求让你实现，团队面对一堆“外部系统”估计也是头大的。并且大而全和小而精的定义不是有绝对的界限，而是根据每个人的需要来定义的
|
|
22
milu2003516968 OP @zoikhemlab 也不全是。比如文章系统，你可以提供一些简单的组件，把文章列出来，比如热门文章、图文并排，或者纯文字列出来。这些可以通过提供 vue 组件的方式，成本应该不算高。又比如问答什么的，也是类似。总之，又有前端，又有后端。
|
|
23
milu2003516968 OP @blless 飞冰，感觉又不是。他只是一个前端组件而已。
|
|
24
milu2003516968 OP @goinghugh 第三方存储必要的数据就行了，你需要扩展的数据，自己本地数据库另外开一个就行，好像丝毫不受影响。
|
 |
25
TomVista 2020-09-14 08:58:20 +08:00
假设你的程序一直活着,
你这个思路会导致技术成本无限拔高,最终不可维护, 然后重构,你这程序怕是没人能够从一个个黑箱中重构出来 |
 |
26
libasten 2020-09-14 09:04:33 +08:00
阿里云有个服务商，叫“速成美站”，是给一些中小企业建官网用的。
我有个朋友购买了那个服务之后，还是不会弄网站，让我帮忙看看，我折腾了好久，感觉就是和楼主说的一样，搭积木做网站，产品系统（竟然支持电商），文章系统，登录模块啥的。 不过这些搭起来也不轻松。 |
 |
27
woodensail 2020-09-14 09:20:15 +08:00
你说的是 serverless 化的组件吧？其实现在很多啊，比如各大地图服务商的地图组件，比如某些第三方评价组件之类的。都不需要开发者部署服务，直接注册个账号后充钱，然后再页面里面引入组件即可。
但是这么搞的一般都是大型组件，比如上面提到的地图，如果是小组件，一个页面里面几十个不同公司的组件，风格完全不一样，那真不是一般的丑。 当然另一种做法就是只用接口，自己做 ui，这个就是目前很常用的做法了，第三方客服，第三方 im，第三方直播系统。这写东西各大云服务商都有卖，是很主流的做法。 |
 |
28
lower 2020-09-14 09:31:10 +08:00
我为啥要把数据放在你的服务器上？
|
 |
29
levn 2020-09-14 09:38:24 +08:00 1
表面上是重复的，实际上是多样的。
|
 |
30
tabris17 2020-09-14 09:40:35 +08:00 1
这些服务只是看上去一样而已，即便是非常普通的评论功能，也会有千奇百怪的需求在里面
|
 |
31
zavieryip 2020-09-14 09:51:01 +08:00
纠正一个说法,节省的是时间,提高的是效率
只能说太过于理想化了 从反面来说,假设完全按照你说的那样做,那你的产品倒闭了,我公司也跟着倒闭吗 |
 |
32
securityCoding 2020-09-14 09:58:50 +08:00
楼主的意思是 把模块 api 标准化,前端需要调整后端直接引入一套 sdk 即可
|
 |
33
zhw2590582 2020-09-14 10:04:55 +08:00
那我不是要失业了
|
 |
34
Rxianbei 2020-09-14 10:08:25 +08:00 via Android
技术上确实可以做到，但那就需要集装箱的提供商绝对可靠，能应对各个国家地区不同的法律并作出调整，比如谷歌就不行。
同时需要提供商有较好的服务延续性，不能说砍就砍，比如微软就不行。 同时需要提供商有很好的信用，比如中国企业基本都不行。 |
 |
35
across 2020-09-14 10:11:21 +08:00
搜“无代码快速开发平台”
|
 |
36
NilXuan 2020-09-14 10:17:45 +08:00
我认为这件事是有价值的，至少可以减少重复工作；当然，能不能提高效率，得看产品自身是否简单好用；如果使用产品的难度高于自己搭建项目，就得不偿失了；
它的难点在于保证产品的扩展性和可维护性，感觉这需要很厉害的产品经理来洞察需求以及很厉害的架构师设计系统架构； 至于对外服务，既可以提供解决系统成品，将系统交由客户自行部署；也可以提供托管服务，甚至可以提供维护升级服务； 楼主如果有兴趣尝试玩一玩，记得带上我，hh ； |
 |
37
ipwx 2020-09-14 10:28:25 +08:00
CMS 做的最好的就是 Wordpress 。大部分需求用 Wordpress + 插件 + 你自己开发就能解决。。。但你又不愿意用 PHP，那你要么自己每次动手开发整个系统，要么再花十年做个 NodeJS 版的 Wordpress 。
|
 |
38
taowen 2020-09-14 10:45:31 +08:00 1
组装的难度在于切分模块。切分得太碎了，模块之间就会有很多的互动，从而丧失切分模块的目标
* 你无法独立理解每个模块。因为模块组装起来会的行为，不是每个单个模块行为的简单加和 * 你无法在多个项目之间对模块进行独立复用，因为任何一个模块都会牵扯出一大堆关联的模块 我举了很多具体的业务场景来说明这样的困境 https://github.com/taowen/modularization-examples |
 |
39
charlie21 2020-09-14 10:55:40 +08:00 1
|
 |
40
danhahaha 2020-09-14 11:00:36 +08:00
码农就是码头搬运工人，集装箱普及的时候，就是码农失业的时候，希望不要有这样的集装箱
|
 |
41
wysnylc 2020-09-14 11:02:12 +08:00 1
软件工程的前辈是建筑工程
建筑工程中有模版化,但是只有临时住房使用而且扩展麻烦唯一好处是可重复利用和迅速移动.但是虚拟世界重复利用和移动就一瞬间的事 所以建筑工程几千年没解决的事情,你说软件工程这百来年的发展怎么做到? |
 |
42
dzdh 2020-09-14 11:05:32 +08:00
learncloud?
|
 |
43
cmdOptionKana 2020-09-14 11:12:58 +08:00 1
集装箱一样组装，前提是：需求像集装箱组装一样简单。
而 web 开发，如果需要开发，目的就是与众不同，要有新东西新玩法。 比如，你要把 V2EX 的前端抄过去，很简单，前端入门的人拿来练手就可以抄过去。但这样的网站没有特色，做不成大事。难点在于 V2EX 当初自己自创的这个，与当时其他网站都不同的表现方式，包含了极大量原创的概念，几乎每一个“零件”都是定制的。 你再看看最近发展良好的笔记网站 Notion，如果它用集装箱一样简单的方式，用现有的其他网站的“零件”去拼凑，就不可能做出自己的特色。而 Notion 的成功，正因为它包含了极大量原创的概念，几乎每一个“零件”都是定制的。 |
 |
44
hazardous 2020-09-14 11:26:03 +08:00
这不是 PaaS 么，只不过传统的 PaaS 提供的是 API 接口，而楼主需要的是连页面模块都提供了，用时候页面上只要嵌入一个远程模块就可以了，数据也是保存在服务提供商那儿的。
感觉就用户认证麻烦了点，如果有很多类似的服务器提供者，那必然没有统一的用户认证系统，每个服务都要去各自的提供商去验证，如果使用某一个服务提供者提供的多个服务，那用户认证简单了，但是跟 SaaS 就没什么不同了。 |
 |
45
jaylee4869 2020-09-14 11:38:02 +08:00
你的想法很危险。会让大量平凡码农失业（逃
|
 |
46
GreyYang 2020-09-14 11:45:07 +08:00 1
复杂度不会消失,只会转移. 如果你的基础设施封装了大量复杂度且配置少, 方便集成使用, 就会不太灵活, 例如需要对一个问答系统的某一个方面进行一个定制, 可能无法实现, 这样的基础设施功能受限; 如果你的基础设施配置灵活, 各种定制定制接口丰富, 那么复杂度实际还暴露在用户侧, 配置搭建所需要的专业性和时间精力就会大大增加. 这是一个比较棘手的问题. 具体可以参考 No Code 和 Low Code 词条相关背景.
|
 |
47
Achiii 2020-09-14 11:49:40 +08:00
想要自定义装修功能？
|
 |
48
n37r09u3 2020-09-14 11:51:43 +08:00
说的就是 headless cms 吧 CaaS
|
|
49
Achiii 2020-09-14 11:54:54 +08:00
我用过一个小程序的留言功能，同 leancloud 一起的，感觉就是特别方便
|
 |
50
abcbuzhiming 2020-09-14 11:56:16 +08:00 3
楼主，你不要以为就你一个聪明人，类似的想法早就有人想过，只是他们都复杂度打败了，非定制的组件无法应对复杂度问题，否则通用组件早就淘汰所有程序员了
|
 |
51
walsh 2020-09-14 12:02:33 +08:00
当然可以，设计一个强人工智能就实现了，更简单的，招聘几个码农
|
 |
52
hoyixi 2020-09-14 12:07:54 +08:00
其实国外已经有很多产品了，面向小白建站的。
|
 |
53
matrix67 2020-09-14 12:19:00 +08:00 8
面向特定领域的软件工具之所以让人觉得复杂，是因为这个问题本身复杂。我们把解决特定领域问题而所需的知识叫做”领域模型“(domain model)。如果我们不了解领域模型，就不能理解为什么 Photoshop 比系统自带的 Paint 复杂几千倍, 或者为什么我们需要正则表达式这种诡异的东西。我们讲的复杂与简单，都是工具设计哲学层面的。
以王垠说的 TeX 为例。写出《计算机程序设计艺术》的 Knuth 到底知不知道程序语言设计的基本原则我们可以不加讨论。了解一点字体设计和排版的都知道，计算机排版问题是个复杂的问题。的确，软件工具的设计目标，是把复杂的问题简化。然而，大多数人不知道的是，简化问题是一个两步过程。第一步，我们需要把现实的问题映射到一个领域模型。第二步，是把这个模型简化到我们人可以处理的地步。很多时候这两步合并起来了，让我们觉得这两步好像是一步，并且认为所有的设计，都应该朝简化的方向走。这是一个对设计的错误认识。 举个非计算机领域的例子：用电饭锅煮饭非常简单，加米加水再按个按钮就行了。电饭锅的设计者的设计目标是操作简单且能完美地煮米。作为工具的设计者，它一方面需要了解大米是怎么煮熟的，另一方面需要提供给用户一个简单的按钮。TeX 作者，从一开始就不是设计一个电饭锅，而是一个精确的温控炉子。有了这个精确的温控炉子，想烧饭的可以把它封装成电饭锅，想做蛋糕的可以把它封装成蛋糕烤箱。设计电饭锅的人的设计，并不比设计精确的温控炉子的人好，或者差。设计者的初衷决定了产品的形状。Kunth 的初衷，正是设计一个可以让他人排版出任何想排版的东西的系统。也就是说，做出一个最终非常简单的，只有一个按钮的排版系统不是他的设计目标。做出一个可以高度定制的系统才是他的目标。 我感觉上面这段说的挺好。 |
 |
54
cheunjq 2020-09-14 12:35:16 +08:00
感觉这不是技术的问题，而是利益的问题
|
 |
55
shm7 2020-09-14 12:37:26 +08:00
可以啊。所以 web 开发可替代性就像这些集装箱一样。
|
 |
56
windyCity 2020-09-14 13:57:23 +08:00
@cheunjq #53 是技术的问题，也是成本的问题，模板粒度太细，太繁琐。粒度不够细，适应面就不够大，可定制性就弱。
通用的模板太难做，就算做出来，维护成本也高到不划算。不同行业，不同公司，个性化需求多到你怀疑人生。最后发现还是招程序员定制开发来的划算。 |
 |
57
azcvcza 2020-09-14 14:03:08 +08:00
前端这种那么吃用户体验的地方，套模板倒也不是不行，万一哪里需要改了，需要的工作量不比重新开发来的少
|
 |
58
springz 2020-09-14 14:09:47 +08:00
前端微服务吗？我记得有个方案，稍等我查下。
|
 |
59
v2orz 2020-09-14 14:09:53 +08:00
可能楼主说的是金蝶用友这样的？这行业里面的大部分需求都是配置组装了
|
 |
60
xianxiaobo 2020-09-14 14:10:14 +08:00
其实很多外包公司在做这个事情，如何最快的搭建开发完成网站，并满足用户多样化的需求。
但是没办法做到你想象的那么完美。 提供接口就稍微简单些，但是提供 UI 模块就难了，除非你们都用统一的前端框架，并且用统一的样式。 而且缺点就是扩展性问题，如果要扩展开发就很难。 |
 |
61
lio444 2020-09-14 14:12:06 +08:00
就是做成 Axure 这样的，任何人都可以做一套系统出来。可以自己根据自己需要进行修改调整。
|
|
62
springz 2020-09-14 14:12:34 +08:00
|
|
63
springz 2020-09-14 14:14:40 +08:00
感觉是类似后端微服务的概念，将一个大型系统分隔成为独立的可复用的子模块，子模块可以自由组合结合很少的业务逻辑就能快速组合成一个新的大型系统。
|
|
64
springz 2020-09-14 14:16:26 +08:00
类比的注册登录系统其实已经有人做了，国外 Auth0，国内 Authing 。
|
 |
65
JCZ2MkKb5S8ZX9pq 2020-09-14 14:18:30 +08:00
虽然这些工作是重复的，可是下一个客户来的时候，我多花 20%的力气，就多收 100%的钱了呀。
当然有可能有鲇鱼乱入，来拼价格拼服务。但具体做到实际运营的时候就会发现，做出产品的成本，是远低于运营销售推广的成本的。所以节省下来的开发费用，在总费用里可能占比并不高。 程序员的特长是做得出，做生意需要的是卖得掉。 |
|
66
springz 2020-09-14 14:18:57 +08:00
类比的帮助中心也有人做了 zendesk，这些都使用过。
|
 |
67
exc 2020-09-14 14:29:21 +08:00
我有跟楼主同样的想法，并且正在做，因为我是多项目并行开发的，这些基础构件不独立出来，会非常影响开发体验的。
|
|
68
exc 2020-09-14 14:33:18 +08:00
这些东西，有些是可以做成第三方库进行项目集成，有些需要做成第三方服务进行调用，也有些只需要设计成一个 API 就可以了，多开几个项目就能体会出来。
|
|
69
exc 2020-09-14 14:35:41 +08:00
不过楼主要求数据都在自己的网站（或某一个数据中心）上，不太好，应该给使用的人选择权。
|
 |
70
charten 2020-09-14 14:39:12 +08:00
以前 jq 一统天下的时候有，现在你也可以去巴拉 jq 的插件，很丰富，有些设计到现在都不过时...
|
 |
71
laike9m 2020-09-14 16:23:48 +08:00 via Android
dark-lang 了解一下？虽然好像不能写前端
|
 |
72
jerfoxu 2020-09-14 16:34:27 +08:00
这个想法很好，的确是有太多重复性的事情了！如果有一家工作把这个事情做的简单一些，很多公司很多岗位是完全没必要的。
|
 |
73
wgco 2020-09-14 16:45:11 +08:00
楼主是不是上次看到的说想要开发出一个根据产品画流程图就直接生成代码的哦
|
 |
74
lxk11153 2020-09-14 16:45:44 +08:00
类似第三方评论系统？这不就行了[doge]
|
 |
75
Saszr 2020-09-14 17:04:56 +08:00
永远不知道客户会提出什么需求
|
 |
76
jabin88 2020-09-14 17:22:21 +08:00
有个类似想法。语雀作为大后台。前端页面自己根据 api 自己写。可惜语雀 api 开放的比较少，只有库和文章，也就只能做一个文章发布类，我目前是做了一个 blog 。评论语雀不开放，那就没办法了。只要开放评论和 tag 接口。感觉 cms 的功能就差不多了，前端自己写，后端用语雀。
|
 |
77
xiaoxinshiwo 2020-09-14 17:31:52 +08:00
springboot-starter
|
|
78
milu2003516968 OP @jabin88 语雀我用过，直接抛弃了。还要新开一个页面跳到你网站，域名还是你的，不利于 seo 什么的。体验也不好，而且我不需要那么重的东西。我就是需要一个简单的文档，你别给我别的东西，我用不到。
|
|
79
milu2003516968 OP @zavieryip 看我补充的附言。
|
|
80
milu2003516968 OP @cmdOptionKana 关键还是你怎么定义这些零件，怎么切割每个需求制造成一个个的零件。
|
|
81
milu2003516968 OP @matrix67 你不可能满足所有人的需求，但是你可以满足某个细分领域的需求。很多个细分领域集合起来就是一个大的市场。
|
|
82
milu2003516968 OP @exc 可以随时导出数据，不会让你过分依赖我们的服务。适用于前期需要快速搭建原型或者网站的创业公司。可能我这个产品三个月半年运营不好直接就关了，这类用户不会太在意这些东西的。万一做大了，给你导出数据到你自己的网站不就完了嘛
|
|
83
milu2003516968 OP @charlie21 你说的那个项目，一看就知道不靠谱，他还找人实现出来，所以一堆人会嘲弄他的点子。
我要是说我要开发一个时光机穿梭的项目，特来找技术合伙人，肯定一群人喷我。 |
|
84
milu2003516968 OP @charlie21 而且你把我的问题跟他的归于同一个问题，那是你没有审好我这个题想表达什么。
|
 |
85
pkoukk 2020-09-14 18:34:48 +08:00
可是现实世界中的问题不就是系统总会膨胀嘛，一个没有人用的简单系统，确实可以，可这么小也没必要模块化。
一个很多用户使用的系统，很快就会产生很多需求，需要定制化开发，模块也就不通用了。 |
 |
86
pokon548 2020-09-14 18:35:55 +08:00 via Android
你说的不就是 serverless 容器么（
推荐试试 Leabcloud （非利益相关，只是刚好觉得符合 LZ 需求 |
|
87
pokon548 2020-09-14 18:36:43 +08:00 via Android
leancloud...神奇的自动补全
|
|
88
milu2003516968 OP @pokon548 不是这个，我现在需要一个简单的博客系统，你告诉我有什么解决方案。别告诉我安装一个 wordpress 。
|
 |
89
km000 2020-09-14 19:17:17 +08:00
这个想法是很有价值的，最终还是要看执行。
|
|
90
pokon548 2020-09-14 19:26:39 +08:00 via Android
|
|
91
pokon548 2020-09-14 19:29:45 +08:00 via Android
整评论用 Valine，投票随便找个能的网站弄个 iframe 。
再插到文章模板里不是同样很香吗。就几行代码的事。 |
|
92
milu2003516968 OP @pokon548 你看我附言的第一条问答，很多人根本就没看清楚问题是什么。
wordpress，gitbook，hexo，你觉得混互联网有几个不知道这些东西呢？ |
 |
93
firefox12 2020-09-14 21:21:21 +08:00
很好的视点，的确 web 缺乏这个能力， 很多年以前，其实是有这样的发展的， 很多留言版服务商， 聊天室服务商。大家在自己的网页里面引入一个页面 就可以了。但是现在 网页的发展 耦合性越来越强了，前端自己的耦合性就很强，希望和别的页面再耦合，缺乏一个公共的对接方案。现在基本都是基于 node 模块级别的组合，还没有这种大模块的组合，我认为这是很有前途的。
至于数据的问题 绝对也是很大的问题，引入了前端 还有后端的问题。 |
|
94
milu2003516968 OP @firefox12
现在前端组件化，比如很多前端方案都是标准的组件模式了，就是一种集装箱的思想。换几年前，没有这种理念的。 还有微服务什么的，都是面向比较小的颗粒去划分模块。所以未来的服务肯定也是如此。 比如你现在想搭建一个论坛系统，不可能沿用以前 discuz 那种庞大的东西了。讲究轻和快，融入你自己的项目里面。 博客系统，不可能搭建一个 wordpress 这种东西了。如果你的应用需要十几个这样的东西，你的项目肯定十分臃肿。 所以，划分成粒度比较小的模块，反复重用，标准化，才能提高效率。 |
|
95
firefox12 2020-09-14 21:48:49 +08:00
@milu2003516968 你也知道微服务，但你知道微服务之间交互的协议是什么吗？ 关键不在于具体哪种，而是要有一种大家可以通用的。
|
 |
96
wangyzj 2020-09-15 01:08:50 +08:00
前端圈为了让前端组件化已经奋斗多年且乱的一比
你这个问题让前端们情何以堪啊 |
 |
97
Michelangelono 2020-09-15 01:55:34 +08:00 via Android
不要你觉得不行就是不行，你倒是问下客户的需求是什么
|
 |
98
wanguorui123 2020-09-15 08:41:14 +08:00 via iPhone
这就是我在设想业务组件；
业务组件包含：UI 组件 + 后端业务模块； UI 组件：包含多套 UI 布局方案，也可以做样式定制； 后端业务模块：提供标准化的 API 对接前端的 UI 组件，后端业务模块可以集成到自己的后端系统中，提供一套事件接口对接自己系统的权限验证功能，也可以重写部分方法做功能对接，业务模块也可以存在第三方 PaaS 提供商，通过统一的 OAurh 等方式授权，一次授权，所有第三 PaaS 提供的 API 都可以被 UI 组件调用； 效果：最终达到集装箱式的组装所有业务组件，根据不同客户需求，使用不同业务组件进行组装。 |
|
99
wanguorui123 2020-09-15 09:04:52 +08:00 via iPhone
我也正在验证这个设计理念
|
 |
100
tikazyq 2020-09-15 10:21:08 +08:00
楼主的意思是定义一些基本的组件（ component ），也可以叫模块（ module ）、功能（ feature ）、包（ package ）等（叫法可能不同），相当于 web 开发的最基础组成单元，然后万物都可以由这些最基础的组件进行组装，然后拼凑成一个大的 web 应用
|
Select Language