【ITBEAR】上一篇文章作者分享了自己要独自研发一款产品，接下来就是工具的选择。本文分享了作者对工具选择的思考，供各位参考。
在上一篇文章里，我说明了我选择独自研发产品的原因。为此，我必须选择一个适合我完成这个目标的工具。正统的研发工具，已经被我过滤掉了，我确实没有那么多时间再次将自己训练成一个符合这个时代要求的全栈工程师。所以我会在低代码平台范围内进行寻找，寻找一个可以真正自由创作的平台。自由是我的主要指标，虽然我选择低代码，但不想成为研发工程师眼里的“LOW”代码。
选择的过程，我就不具体描述了，上篇文章我已经描述过。最终我选择了一款平台，我就是基于这款平台进行开发的。不过我觉得，我个人选择什么并不重要，真正想和大家交流的，是我为什么要选择这款平台。
01 为什么选择它 1. 部署
首先，我不太想把时间和成本花在租赁云服务以及部署应用这些事情上，对我来说这并非重要的工作，但会花费我不少时间和成本。所以我得选择一款在线的研发工具，研发结束可以直接发布成为SaaS应用，它满足了这个要求，省了我不少时间。
另外还有一点是我意料之外的，我在平台创建了自己的租户以后，开发的任意应用，居然是可以被其他租户申请的，这就意味着我自己的租户其实是我个人的空间，而我的成果可以被其他租户看到并使用，这正是我需要的。
2. 应用研发自由度
正如我前面说的，对于低代码研发工具，我最看重的就是自由度，那些一上来就介绍表单设计、流程设计的平台，我会直接Pass掉；不能自由的配置前端交互界面的平台，我也会Pass掉；最关键的一点，对于不能进行数据处理和业务逻辑的编排的平台，我会Pass掉，一款软件产品，业务逻辑处理是核心，如果这里不能自由的配置，我就只是在一个大一点的笼子里浪费时间。最后，我自己做过JAVA后端研发，因此如果一定要我写代码，我也可以接受，但必须好集成，并且足够自由，零代码最好，这样就省了我自己还要部署后端环境的麻烦。
目前我选用的这款工具做了MVC的拆分，没有强调表单的概念，而是沿用了“模型”的概念，当然这里的模型指的是数据存储模型，可以完全自定义数据结构，这一点为后续的自由度打下了一个不错的基础。在前端交互的开发功能中，平台提供了完全自由的画布，我可以从布局开始构建我的交互界面，谁说要看数据就一定是先打开一个列表了？谁说表单页面就一定得弹窗了？既然我是产品经理，那么操作界面一定得按我的设计呈现。当然，这是我初见的感受，后面我还得仔细分析这款工具的极限在哪，以及有哪些限制。
最让我满意的，应该是这款工具用来编写后端逻辑的部分，看起来它是冲着零代码的方向去做的，所有的业务逻辑都使用左侧的独立组件按照步骤执行来组成，说实话，我现在并不能搞清楚这些组件的详细用法，也不确定是否真的靠这些就可以组装出我需要的业务逻辑，但这种设计思路是一种比较方便扩展的结构，产品可以通过不断的丰富这些组件来满足需求，大胆假设一下，后面开放让用户自己写一些代码做一些自己专有的组件，也不是不可以，这样就非常Nice了。
所以，从我接触这款工具开始，就觉得，这种设计是可持续迭代的，哪怕这款产品后面停止迭代了，但这些和我并没有什么关系，我可是产品经理啊，只要证明这个方向是有潜力的，我自己找甲方资源，自己设计再做一款，也不是不可以，所以我会重点体验这款产品的应用开发功能，看看有哪些可取之处，以及有哪些也许会存在的致命缺陷。
3. 费用
选择这款工具，当然也是因为它免费。我看了一下详细规则，每个租户5个用户以内是永久免费的。对于真正要使用的企业来说，5个用户是无法大面积使用的，但对于我这种个人开发者来说，也只会有我一个账号。这种对于开发者永久免费的策略我认为是正确的，毕竟一款工具，要想发挥其价值，还得有人来使用，对于哪些限时免费或者在功能上对免费用户进行阉割的产品，我是真的爱不起来，倒不是我不愿意付钱，而是这种工具，想要掌握，必然会花不少时间，我平时也是有工作的，有时间了就来研究一下，也许免费周期就这么晃过去了，在我还不确认这款工具是否合适的时候，怎么有信心付费使用。
02 后续打算做什么
说实话，选择工具这一步是最困难的，得踩不少的坑，这个阶段花费的时间，是不一定有收获的。既然目前我认为这款工具是值得一试的，我就会好好的体验一下，所以后面我会开始尝试用这平台开发一个简单的应用，同时也评估一下这款工具是否真的足够自由。
如果这款工具可以承载我想要做的事情，我会开始在这个平台上开发真正属于我自己的产品，对于无法完全按照自己的想法实现产品的工作状态，我已经逐渐失去激情了，希望这次我的运气足够好，可以找到一个不错的玩具。
根据平台规则，我仍然不打算在文章里宣传这款工具的任何信息，各位也可以关注后我面的体验文章，相信每个人都会对这款工具有自己的判断。
题图来自Pixabay，基于CC0协议
该文观点仅代表作者本人，平台仅提供信息存储空间服务
