|
前些时间在与一位朋友交流简道云时提到过一个观点：能用插件时，不要用云函数，能用公式时不要用插件，能堆字段时不要用公式，能基于简道云实现的，就不要依赖外部。
朋友有点儿惊讶，他说没想到像你这样经常分享技术的，会这样说。
以“上手”为始，以“撒手”为终
这样的观点起源于什么呢？大体是，近两年来，在和多位朋友沟通交流时，逐渐形成的，有些朋友使用简道云已经很多年，单看现在使用的系统，已基本比较全面，一个表单中可能已经是经过多次迭代，以更便于满足业务需求，而同时也带来一个较明显的问题，除了开发者外，其他人不太容易去接手或维护。
形象点儿说，这就像是一道菜，一道菜有很多种做法，讲究的，可能还得吊个底汤，你就比如说，开水白菜，看似简单，较起真来，却是一个技术活儿，那有没有简单些的做法呢？搞个汤包、搞个预制菜可否？再简单些，咱真的就是开水白菜。这样，其他人接手的话，不就容易了吗！只要不影响根本上的功能。
通俗点儿说，以“上手”为始，以“撒手”为终。
之前曾写过一个“三阶九段”，用来概括简道云应用水平。
初阶段位
一段：堆字段，基本的表单搭建
二段：套公式，套用已有的公式
三段：表套表，多表间相互调用
中阶段位
四段：子表单，灵活使用子表单
五段：写公式，用公式解决问题
六段：善规划，灵活使用各资源
高阶段位
七段：重体验，能注重用户体验
八段：拓场景，能拓展实用场景
九段：承未来，能以未来为起点
不用当真，只是为了便于评估，来做个参照，其实就拿日常应用来说，简道云，对技术的需求并没有那么高。
稳迭代、拓场景、起架构
相比于以上，多年使用后，系统面临着整体迭代，这可能是一个较紧迫、较棘手的问题，是继续在原有的系统上“堆”，还是开始着手考虑“迭代”，个人的建议是“稳迭代、拓场景、起架构”，要不真就应了那张图，一个bug平衡了另一个bug。
迭代这个事儿不易，过去还只是给跑着的汽车换轮子，现在这就是在跑着的车上换车，“稳”着些好，半年，一年都可以，甚至再长些时间也没关系，重要的是得有这个意识。
首先，需要保证迭代的过程是稳定可靠的，不能因为迭代而影响到系统的正常使用，可以最小化系统颗粒度，每次只是小的迭代，确保每一次都是可控的，避免出现不可预期的问题。
其次，需要拓展系统的应用场景，过去，也许因为一些原因，有些业务没有纳入进来，现在可以求证后让更广泛的业务需求融入进来，这样不仅可以不断提高系统的价值，也可以提高公司整体的工作效率。
最后，需要考虑系统的整体架构，确保系统的可扩展性和可维护性，以及让整个系统与公司的数字化变得更为可规划、更为可预期，甚至于有条件的话，让系统不再依赖于个体的某个特定的人。
捅天窗、砸地板、拆门框
在公司里，整简道云这事儿，说简单也简单，说不易也不易，更多的可能还不是技术问题，层级、岗位、思维等等，这些都是需要考虑的问题，说是一个小社会，一点儿也不夸张，整到一定程度，就一定会是管理思维与企业文化的变革，不同的是，这个过程，有些公司是温和，而有些就不一定了。
在那次与朋友沟通中，还提到过一个“砸地板”的概念，怎么理解呢？
完整的是“捅天窗、砸地板、拆门框”，有时候，做的久了，会觉得在可控或说可折腾的范围内，已经到天花板了，无论是因为自己的层级、岗位，还是技术，亦或是环境，过去也没想明白这个问题，直到那次聊天时，从嘴里说出“砸地板”这三个字。
是有颗粒度的，集团、公司、部门、岗位、业务、流程、节点，这些都是颗粒度，上捅、下砸、左右拆，这都是打破当前颗粒度的方式，总会有一种方式适合当下的自己，总会有一种方式适合去呈现价值。
最后，来一个总结吧！
技术是一种探索、是一种兴趣、是一种精进，但绝不可以让技术成为一个系统的唯一依赖。
更多内容：
更多沟通交流可添加微信（zmlnow）
添加时请备注：简道云
| 
