这是一个创建于 2446 天前的主题，其中的信息可能已经有所发展或是发生改变。
转眼间，做业务系统的软件开发已有十个年头，从刚开始的激情满满，到周而复始地一个接一个的做项目，虽然竭尽全力将一些常用的代码或模式封装到框架中，但依然感觉到了无尽的重复，而正是这无尽的重复在逐渐的吞噬着我的工作热情。
我意识到，虽然我热爱软件研发，但目前的业务系统软件研发模式，让大家深陷在沼泽中，逐渐没有了生活。
如果我们做过一件事情之后，我们能够将我们已做过的事情（如已编写过的代码）提取到框架中，供更多的人去调用，而不是重复发明轮子；如果能够将我们在项目中已获得的经验固化为平台中的一个能力，然后为平台用户赋能，这样每个人的起点都是站在巨人的肩膀上。如果能够形成这样的机制，则我们的工作内容将不会再出现大大减少无聊和冗余的重复，并且会极大的提供工作质量和效率，出现全新的软件研发模式。
这样技术前提下的软件研发模式，也能极大的促进业务系统的高速发展，因为开发一个软件的周期大大降低，甚至能够做到实时反馈，业务专家不用再在提出一个认为很简单的需求，却在一个月之后看到与预期相差甚远的功能。而是可以边提需求、边开发、边确认。
于是，我辞掉了工作，着手搭建这样的一个平台，并完全开源，也希望能吸纳各方面的人才参与。
平台名字叫 BlockLang, 也就是块语言，使用这个“块状的语言”像摆积木一样拼装出业务系统。
BlockLang 相信“每个人都可按照自己的需求，拼装出称心的软件”。
BlockLang 致力于打造一朵“百花齐放、百鸟争鸣”的软件云，实现软件定义软件。
告别传统的业务系统开发模式，人人都能高效率的拼装出高质量的业务系统。
BlockLang 是一个开源项目
诚邀志同道合的编程手艺人加入（ QQ 群 619312757 ），一起开启业务系统研发新模式。
第 1 条附言 2019-04-23 17:56:55 +08:00
0.1.0 发布说明
很激动，终于完成了第一个小版本 0.1.0 的开发。
在规划 Block Lang 的开发路线时，我们意识到：
- BlockLang 的开发是一个漫长的过程，要做好打持久战的准备；
- 保持增量开发，让大家尽早看到一个完整的可使用的平台；
- 始终以社区的思路和姿态运营，即使社区中只有我一个开发。
因此 0.1.0 版本立足于贯通软件的研发生命周期，已完成以下功能：
- 创建空项目
- 发布空项目
- 安装空项目
- 用户登录和注销
0.1.0 版本共创建了三个项目：
blocklang.com存 blocklang 平台代码；blocklang-template存项目的模板代码；blocklang-installer是项目安装器，用于在用户主机上部署软件。
后续开发中，会按月规划开发路线，于每个月第四周的星期二发布。
0.1.1 版本重点是添加版本控制功能。
最后，分享一个心得。
- 如果将现在的研发模式称为
编程式，则 blocklang 平台提供的研发模式可称为拼装式。 - 拼装式和编程式不是完全互斥的概念，拼装式是充分建立在编程式的基础上的，是在软件工程范畴对编程式的提升。
- 而拼装式主要聚焦于业务层面，希望能提供一种新思路来快速响应变化。
真诚欢迎大家的关注和意见。在交流时以充分表述清楚意图为优先，不要太顾忌我的感受！
第 2 条附言 2019-05-16 10:58:19 +08:00
0.2.0 发布说明
欢迎您了解 Block Lang 0.2.0 发布的功能。此版本增加三个功能：
- 在项目中创建空页面
- 在项目中创建分组
- 使用版本控制系统管理新创建的页面
 | 1 airyland 2019-04-20 23:14:59 +08:00  1 网站一片空白？ |
 | 3 binghe 2019-04-21 03:30:12 +08:00 via Android 1 感觉这个和我前两年提出的问题有些类似。我当时说的是后台业务系统可以像大部分 CMS 一样，可以在后台自定义“模块”，自定义“字段”等功能。 |
 | 4 xiaotuzi 2019-04-21 07:26:25 +08:00 via iPhone 1 手机打开一片空白 |
 | 7 xiaohulu OP @xiaotuzi 您用的是华为浏览器吧。原本不打算支持 ie11，没想到华为浏览器上也显示不出来了。华为浏览器和 ie11 不会是一个内核吧。 |
 | 10 ParallelMao 2019-04-21 21:59:29 +08:00 1 面对简单的业务需求，如果想要做成类似这种动态的模式，个人认为最简单的办法是后端服务提供简单的 restful api （针对某个业务实体的增删改查操作），前台搭建一个类似 GraphQL API 的服务，通过定义 查询语言来实现业务逻辑。这一点楼主所做的块语言也可以解决。 但是当遇到更加复杂的业务场景，不同实体之间的联系错综复杂，是及其难以用类似上面那种模式解决的。首先抽象业务这个事情在面对复杂业务时本身就很难，即便是一个非常固定的需求，更何况其实需求也是在不断变化的。其次各种组件（实体）进行互相依赖之后，性能优化，问题定位啥的问题也会变得复杂起来。最重要的是，不同开发同学的对软件的理解是不同的，一个事情，可能 A 抽象出来的结果和 B 抽象出来的结果完全不同，再加上后期可能无限变动，每次变动都需要将抽象修改为最合理的方式，其实这个成本也还是蛮大的。这种情况下个人认为很难去通过这种自动化的方式很好地解决。 所以我目前的经历来看，软件开发完全通过底层实体的拼装实现上似乎可行，但潜在的风险和成本太高了其实不是很适合使用。 |
| 11 xiaohulu OP @ParallelMao 感谢您的回复，很中肯。每次变动，带来的成本的确是很高的，不管是编程式，还是拼装式。为了应对变化，编程式中抽象出了各种模式，封装出各种框架，但业务层面的变动成本依然很高。拼装式某种程度上能降低变动的成本，但的确正如您所言，这就需要更加通用和合理的抽象，也就是做组件的成本是提高了，同时也可以模仿 rust 语言的强检查的编译器机制，在拼装的过程中引入相对全面的检查。 所以，我的理解，就如封装变化点一样，我们将变动的成本封装到了组件了，从而降低业务层面的变动成本。 我的理解也许还不够成熟，不过，您说的这些风险如果不解决，则拼装式也是真的很难推广开来。不过我也尝试着琢磨方案。 也期待您的宝贵经验 ：） |
 | 12 YrX12138 2019-04-23 10:49:32 +08:00 收藏一下。 |
Select Language