代码不是怎么想就怎么写的

我的经历

刚开始做单页面应用的时候, 我只会 jQuery, 甚至在 CoffeeScript 拼接 HTML
得到 HTML 后插入 DOM, 之后绑定事件, 事件当中继续做着这样的循环
当时的开发方式也是, 写好第一个界面, 于是按照操作的顺序一个个做下来
显然这是最直观的新手对于代码的理解了, 先做什么, 再做什么, 一步一步来

那时候每当应用像点样子, 我都会发现自己不知应该怎样维护下去了
也许是理不清楚从前的代码, 也许是不知道新功能怎样才能加进去..
后来到了公司接触到 Backbone, 思路渐渐明朗了一些,, 特别是事件代理
在 View 上做事件代理之后, 应用区分模块清晰了好多, 我学着一个个 View 去考虑问题
随之而来的还有数据监听, 用来更新 DOM 这件事情

后边我渐渐懂了原来 View 就是数据的映射, 并且都是随着数据的更新而更新的
那时我觉得眼前更加清晰了, 因为 View 可以自动更新意味着复杂度能控制住了
到了 React 我又发现前边区分不够清楚, state 也是需要区分出来的一类数据
我也学着把从前的操作尽量转化为数据, 而最终 View 能较好得仅仅作为数据的映射
最终, View 就像是 Data 的一个备份, 终于能自动完成同步了

代码的不同

从前看 Haskell, 我甚至不明白为何放弃了过程式的操作, 以至于如此难用在实战
但是从我前边的经历我逐渐感受到了非常重要的这一点, 编程和人们所想的不一样
当人们想着做一个什么东西, 首先想的成怎样怎样做, 有一条路能同向终点
而到了代码当中, 要应对的状态就不仅仅是把成功的那一件事情做到了
而是存在这大量的状态的组合, 组合的结果多到我们不可能逐一去穷尽

解决的办法也很明白, 每种状态都尝试一个模块解决, 再实现模块的组合
函数式编程中每个函数实现一个功能, 适用满足类型所有数据, 然后进行组合
在 React 当中就是 Component, 每个 Component 都对内渲染所有状态, 对应允许组合
不存在复杂状态的事物, 仅仅写个脚本, 足够完成了, 因为状态很容易被穷尽
只是到了复杂的应用当中, 状态相互交织, 写脚本时那种理解就面临颠覆

不过上边的观点, 大概也是未来达成目的而设想的一个思路, 没有想尽考虑
但是我希望可以借此说明过程式的编程是存在问题的,
同时人们思考时惯用过程式的思路, 也就有着不小的隐患在的

界面的设计

我注意到在网页的交互和界面在我开始实现之后会遇到类似的问题
我们认为用户看到的就是界面的状态, 而且可以进行任意的操作
比如点击页面里边一个按钮, 能控制界面上任意的内容, 只是为满足用户习惯如何如何
而对于程序来是, 这种思维是危险的, 任意定义操作会导致代码复杂度增长到难以控制
通常操作和对应的数据会集中在一个 Component 之内, 只是有时候会出现极端

所以我渐渐开始思考, 设计界面时就应该考虑模块化, 以便代码实现更合理
否则可能代码层面的模块化难以达成, 模块之间状态交织增加复杂度
一旦状态交织, 模块的复用性就恩格出问题, 为 bug 的产生带来了温床
而对于用户, 也许这样的界面当中元素关系不够清晰, 有那么点困惑

未来的不确定

相关的想法前边博客提到了, 就是跨 View 进行动画的问题
Material Design 里设计了不同的 View 之间渐变的交互, 粗看是很难做的
从 Web 的角度, 由于 DOM 结构限制有点困难, 也许对 Android 开发稍微好点...
总之新的设计出现, 就可能对技术形成挑战, 现有技术能否达成并不是确定的