周报 2022W39：开发恶习的教训与个人知识库进展
一如既往，今天也是早上 7 点 20 分之前到达了公司，只为了下班时不用打电话叫别人挪车。为抢不会被其他车挡住的车位，大家也是卷到飞起！
还好这持续了几个月的日子终于暂时告别——摇到了下个季度的公司内部车位。一个萝卜一个坑，正常来说不会被其他车挡住了，晚上可以安心睡觉了！
来到办公室后，补充下前几天日志中的缺失事项，突然想起这搁置了有段时间的「周报」，想想还是继续捡起来写吧，尽量坚持！
工作事宜
规则引擎标准化
这半个来月我基本都在支持规则引擎标准化的几个新模块的开发（按照优先级排序）：空间管理、规则组管理以及数据项管理。
空间管理本身没啥难度也不那么复杂，但因其包含了权限控制，与后端联调时总发现问题，反复测试花了不少时间；并且空间与管理员管理相关页面使用了原来没有的交互形式，写新的视图部件也耗费了一些时间。
相对来说，规则组管理是最简单最省时的了——非常常规的 CRUD，交互也是已经有的，在 Handie 的支撑下，几十行配置代码就完成了全功能——无脑，省心！
数据项管理真的是让我吃饭都觉得不香了……看上去就是常规的 CRUD，但是它的坑在于新增与编辑数据的表单！
我是在立项进入开发之后插入支援的，没参加过需求评审什么的，本来就对在这个系统里「数据项」到底是啥就不懂，询问明白之后，产品的交互图又过于抽象，让我一头雾水：
这个系统没有设计师参与，实际呈现形式全凭想象……经过讨论，确定左侧是树，右侧是表单。
由于被 Handie 的便利性惯坏了，上手之后在实现需求时就放弃了认真思考，本能地直接去写配置拼装页面。然而这回碰壁了，因为一开始的没想清楚，实现时交互形式来回改了好几次，浪费了大量时间进去，搞得我都要 emo 了！
一开始做左右结构，但右侧表单的值在 Handie 的机制下怎么同步到左侧树里没弄好，后来改成了对话框；为了尽量还原产品上的设计，第二天又稍微换了个方式实现了左右结构，当然还是在 Handie 的机制下：
其中，红框部分是最外层的表单对话框视图，绿框部分是展示为树的 children
字段，蓝框部分则是表单对话框视图中内嵌的用于新增/编辑数据项/字段信息的表单视图。
由于数据项配置信息的前后端数据结构不一致，前端是有父节点标记的平铺数组，而后端是树形结构，故而在前后端交互时需要分别进行正反向转换。
在界面中交互时的数据流为——
最外层的表单对话框将数据项配置信息下发到配置树字段；配置树字段在初始化及字段值发生变动时构造展示用的树形数据结构；树节点在新增/编辑时将对应信息经由外层表单传给内嵌表单，点击「保存」按钮后再由外层表单更新数据项配置信息。
可简单总结为：配置树字段负责展示；内嵌表单用于编辑；外层表单主要起到桥接作用。
煎熬了几天后，周一终于将这让我寝食难安的东西给完结掉了！之后的几天不再焦虑，回到了往日放松的状态，按照设计师的要求把登录页和切换空间的布局与交互做了些修改。
那几天我之所以很焦虑很煎熬，并不是因为它难它复杂，而是由于我的疏忽而导致多投入了很多时间在这本不难且没那么复杂的事情上！
总之，我要铭记这次教训，纠正自己的不良习惯——
很常规的 CRUD 可以无脑地去写 Handie 配置，但要对不是已经存在的交互形式持有警觉，一定要先去思考，想明白了各种流程再动手写代码！能去写设计文档更好。
在写代码时不要边写边调试，先试图进入心流状态地一门心思把逻辑、视图结构等都按照思路写好，之后再在浏览器中预览调试并调整细节。
确定 Q4 OKR
部门在 Q4 对小组的划分又进行了调整，将合并起来的「基础工具支撑组」又拆回了「知识中心组」和「平台工具组」。
名义上我是属于知识中心组的，但之前看到平台工具组的规划内容时比较好奇和感兴趣，就事先跟那个组的负责人打招呼说开头脑风暴会的时候叫上我。
国庆假期回来就是 Q4 了，因此在假前各小组都要将 Q4 的 OKR 敲定。
最近一段时间，我有个期望部门所有系统在产品层面上能够统一透出的想法，就是不是散装的「XX 平台」、「XX 中心」、「XX 系统」之类，而是以部门为名义的「数据智能工作台」。
有此想法的原因大致如下：
- 散装形式有碍于形象、品牌建设，使用户分散，不利于形成内心归属感和推广传播；
- 每个系统的功能较少，给人一种单薄的感觉，现有复杂度不需要切割成多个；
- 各系统的用户、权限体系分裂，应该有个一致的「账户中心」。
根据这个想法的性质，在平台工具组的头脑风暴会上提出更合适。以我对团队情况的了解，我的想法极有可能不会被采纳，但还是要说，在他们脑中留下个印象，没准哪天时机一到会被提上日程呢！
在同时参与了知识中心组和平台工具组的头脑风暴会之后，发现明显平台工具组涉及到前端的事情更多，然而总共三个前端中的两人在知识中心组，到时我应该会将主要精力投入到平台工具组中，即便名义上我不是平台工具组的。
还记得上个月我在前端群中立了个 flag——
平台工具组在 Q4 的工作重心所在的那个应用还未引入 Handie，是提高 Handie 在团队前端项目中的覆盖率的大好机会——这也是我考虑将精力主要投入在平台工具组的原因之一！
除此之外，我个人想要在 Q4 封装出囊括部门内前端项目常用的运行时配置、逻辑、交互模式等的团队定制 Handie starter，届时每个前端业务项目实际上就是在包含部门特色的通用 Handie starter 的基础上构建的项目专有交互及 Handie 配置集合。
个人事项
个人知识库
如果说我的个人网站是个人知识库的公开对外部分，那日志、周报、笔记等就是非公开且仅供自己查看的——是的，之前曾经公开对外的周报、笔记早已变为不公开了。
可是，有时会出于协作等原因想要临时地共享非公开内容给别人看，这可咋办？为了解决这个问题，前半个月实现了公开共享与需密码访问的简易版受限共享。
这里会有个定位边界的问题——「公开共享」与「公开对外」的区别是什么？
我目前的定位是——创作类的、发布后基本不会修改的算作「公开对外内容」；非创作类的、未完成的创作类的、极易变动的是「非公开内容」，想要较为长久公开的话就是「公开共享内容」。
就像这个周报，它本身是非公开内容，但我想临时地或者长久地共享出去让别人看到，那我就可以根据需要用受限或公开的方式共享出去。
昨天午饭时间在想该把自己的个人知识库相关的东西打包成什么品牌比较好——该叫什么名字。起名是个头疼的事情，尤其是好不容易想到个，一查已经被占用了！
在想名字时，突然灵光乍现，想到了前段时间了解到的「诺斯替主义」。其英文「Gnosticism」来自于表示「知识」的「gnosis」——就叫这个好了！
可当我在 GitHub 和 NPM 上一查，都被占用了！这时使出我的惯用招式，利用谐音替换字母一一尝试，结果无论是「gnosys」还是「knosis」都已被注册……
在我想用「knosys」做垂死挣扎时，虽然 GitHub 已被占用，但 NPM 是可以的！于是立刻在 NPM 上用「knosys」注册了组织，而 GitHub 上则在后面加上较为常见的「io」——「knosysio」。
代码相关的已经搞定，我就想查下互联网上是否已经存在同名的域名——还真有！是澳大利亚的一家上市公司……假如日后我的这个有名气了，不知会不会出现什么法律上的纠纷？也许我操心得太早了……
「knosys」只用于网址、文件（夹）名等的拼写，给人看时则写作「KnoSys」。
事不宜迟，我快速地复制粘贴出 KnoSys 的官网，毕竟它是我的开源软件体系中除「反混沌战线联盟」之外的「互联网自由宣言」阵营的第一个落地项目！
现在想想，「KnoSys」这个名字真的挺好的——不仅读音与「gnosis」一致，可以按「知识」、「灵知」理解；还能看成是「knowledge」与「system」的结合，取「知识体系」或「知识系统」之义。
妙哉，妙哉！
认知多元化
从上周开始，周末自不用说，工作日基本每天下班后在吃晚饭时都会通过投影仪看上那么一两期「大问题Dialectic」的视频。
它是一个与哲学相关的频道，但内容不是单纯的哲普，而是像圆桌会议一样针对某个问题搬出多个古今欧美哲学家的观点看法。
这不仅让我更了解那些听过的、未听过的哲学家的名字及其主张，达到了哲普的效果；还通过对比的方式使我能够一时间看到不同哲学家的多种看法，令我更加确信自己的观点：
- 没有什么思想理论是绝对的，比如绝对的正确、绝对的优势，能够自洽的就是好的；
- 有关意识的、思想的就是主观的，脑中所认知的只是事物的现象材料，并未触及本质，别拿「客观」来说事儿；
- 主流的未必且很可能不是正确的，对主流的倾向性也是一种迷信。
只要他人的观点主张能够自洽，就可以接受，借之完善自己的思想理论体系。