我参与过的产品回顾

前几天跟同事聊天的时候回头看过当时在学校开发的电台
如今多是无人维护, 并且 API 在外网估计屏蔽了, 因此仍是当时的样子
我最近关于 FRP 的图形编程比较多, 偶然回想到当时不少错误的认识
我以为挺有意思, 因此想写一篇文章感慨一下,
文章的重点是, 当时对事物好多的理解, 随着深刻领域已经改变甚至固化

Feel Radio

http://feel.zjut.com/

Feel 电台我记得当时由于新老交接, 社团的前端出现了空白
我当时参加的是服务器部, 但后来一直学作交互界面, 就补上去了

电台断断续续可能有好几个月, 好像是大四开始时接的, 记不清了
页面上主要是加载 DJ 和节目, 而后调用播放器, 另外控制下主题
我前端决定用 Ajax 加载全部数据, 作 DOM 操做控制播放的
后来后端开发没跟上, 临上线决定你们帮忙开始批量转 JSON
用静态的 Nignx 服务器匆忙上线了, 解决了问题, 可是 bug 很多
后来才有加上 PHP 后台管理, 后台用了框架, 界面显得比前端还成熟

这对我来讲是一次实践的很好的机会, 由于我立刻了解到了其中那么多问题
好比说当时有人文学院合做, 可是两位同窗不多碰面, 只是给了一稿设计
电台的同窗我去问了需求, 我厚了时间才弄明白作 DJ, 但是他们对网站界面没想法
界面有视觉传达部门的同窗, 可是主要是海报设计, 网页限制她们不了解
前端只有我, 并且我常常由于技术难以实现考虑对设计进行更改
后端负责的同窗实习去了, 并且没投入多少时间, 后来还换人等等

更致命的是没有人能作协调, 而我和 zarzen 前先后后拉人商量意见都对不上
后来无奈了找你们一块儿在我屏幕上看初稿, 结果快有十我的秩序都乱了
由于主要的工做是在前端, 因此结尾赶进度时候界面细节几乎都在我临时决定了
后期的维护由于我开始实习也没怎么跟上, 后边不知道是谁接手
代码质量考虑到是我第一个实际项目, 对维护的考虑也很欠缺, 不过页面很简单

我后来 xuld 商量到这个事情, 他说精弘就是缺产品经理的
包括跟在实习的公司作对比, 也彻底是缺乏那么能主导整个项目的人
我挺遗憾的是呆在精弘这段经历没有人领路, 第一个项目的经历很是低效
并且我至今都没接触过外包, 外界对于网页有什么样的需求我并不清楚
我也缺乏接触实际当中非技术的人们对网页有什么期待

呆在精弘的时间里我常常翘课, 大把的时间本身去接触大量的网站
并且有时间和资源我能反复重装 Linux, 不断在网上刷新闻追踪最新技术
精弘的技术氛围也是我对技术社区最初的印象, 就是一堆能随口扯 Linux 的人
服务器部分的会议和分享给了我基础的维护服务器的经验, 只是我没走那条路

TickTick

https://ticktick.com/

最开始同窗跟我聊工做我仍是有压力的, 只是仗着社区活跃给本身留点退路
不过由于第一家面试的公司就是作的单页面应用, 我没怎么抗拒就去了
第一家公司的印象, 站立会议, 密集的任务管理, 不成功但一直不停尝试的分享等等
当时的感想已经有文章追述, 下面只是说技术方面个人接受程度

我只是了解过但没真实用过 Backbone, 而 TickTick 是一个很是大的 Backbone 项目
最初工做都是修复其中的 Bug, 靠着对 Chrome DevTools 的熟悉程度勉强跟上了
我从前接触的都是 jQuery, 并且也没有理解 Backbone MVP 那种模块化开发的思想
View 部分其实挺简单, 然而 Model 与 Server 之间关系让我费了很多力气

另外麻烦的地方是复杂的 View 的开发, 我遇到第一个技术上难点是 RRule 控件的开发
其实我以为老板对界面效果要求太高, 甚至超出了 Backbone 控制状态的能力
固然直接的问题是个人技术和经验, 我在作复杂的状态切换的模块上花了很是多的时间
而这也让我直接将注意力转到了 Angular 上边, 关心 MVVM 方面的方案
另外是多个 View 对单一的 Model 的监听和操做问题, 也让我体会到 Backbone 的弱点

另外大的大概还有整个项目切换了 Browserify 又切换到 RequireJS 才稳定下来
以及 CDN 经过 md5 部署的问题, 即使在后面的经历当中也是难点
此外在 TickTick 遇到的大量是业务逻辑上的问题, 大型的前端 MVC 恐怕避免不掉
我所以对于 Chrome JavaScript 调试的便利性极为赞扬, 至今不习惯 Firefox 调试
不过对总体架构我依然感到很是无力, 主界面的性能优化我也无力解决

另外一方面因为工做压力, 我本来差劲的交流能力, 还有作事的条理性改善不少
我还参与过很多前端面试, 当时以为有单页面经验的人太少很不理想
如今看来我对于他人技能增加的速度是毫无经验, 不少预判也都是肤浅的
可是有一点我依然坚持, 单页面不是成熟的技术方案, 缺乏明确的 MVC 经验是不行的
并且公司当时项目推动很是有力, 没那么多时间作各类试验

Today

http://today.ai/

是我到 Teambition 时跟着寸志作的, 数据层没有以前 TickTick 那么重的 Java 架构的味道
并且对 Backbone 的使用也娴熟很多, 我对于 Collection 的理解慢慢清晰起来
由于项目是用 CoffeeScript, 对我来讲轻松很多, 由于我我的项目用的都是 CoffeeScript
中间另外比较明显的是 Teambition 的开发习惯花了一些时间拾起来

这边就想不杭州那么忙了, 加上 Vue 是在这个时候出现的, 因而开始用 Vue
在 Vue 之间我用的模块是 Ractive.js, 而 Vue 才是完整的 MVC 层面考虑的框架
我 Vue 写了一些小的应用, 才开始感到有点写应用的感受
而这也弥补了我没能学会 Angular 的遗憾, 太多稀奇古怪的东西了

Backbone 面向对象式的臃肿的封装其实让我挺难适应的, 我的也用不起来
虽而后来我已经熟悉了用构建 Collection 构建 View, 但是思路仍是不通
Vue 对我来讲像是在开发思路上作了廓清, 定义数据, 定义模版, 定义操做, OK
特别是 Backbone 当中事件形成的架构的繁复也瞬间被条理化了
固然这中间不少仍是 Angular 的功劳, 双向绑定我已经关注了半年多

Talk

https://talk.ai/

后面不久就是参与 Talk 的前端, 由于是 Backbone, 我各类不觉得然
由于中间有次重构, 因此这算我第一个从头写的大的应用, 用的是 Backbone
对 Backbone 完整的认识也是在中间开始的, 固然 Backbone 是很是简洁的框架
也还好我有时间研究, 当时我整纠结 Vue 怎样模块化, 正好遇到了 React
React 极为灵活的模块化方案, 以及极为清晰的 Flux 架构立刻打动了我
在确认 CoffeeScript 的语法支持之后, 我很快丢掉了 Vue

React 几乎是个崭新的世界, 虽然开发上不少仍是和 MVVM 类似的
但我理解 MVVM 依然是对 DOM 作各类优化方便在 DOM 当中开发应用
而从 React 开始, DOM 就是个虚拟机, 而 jQuery 就成了汇编, MVVM 勉强对应 C
React 对 DOM 进行了抽象以后, MVC 架构的思想很是直白
随之发生的事情是瞬间可以管理的 DOM 的数量提高了一个数量级
考虑到将来 React 模块丰富, 这种遍历性将会继续提高

今年另外关于的 Polymer 也发布了更新, 模块化设计很是出色
只是由于迷信 React, 我后来也没怎么花时间到上边去了
我认为, Polymer 不如 React 的应用的抽象能力更好, 或者说更灵活
React 当中的 MVC 在 Polymer 当中并不清晰, 那可都是模块啊而不是业务逻辑
具体到应用开发我认为 Web Components 依然大步向前.. React 依然从中获取好处

随着对 React 的熟悉以及信心的提高, 我开始在项目当中引入 React
原来 Backbone 渲染复杂的消息列表的性能问题默认就解决掉了
另外是 React 容许了更多的 DOM 和更多的状态和交互的管理能力
这也是后边 Talk 搜索部分交互骤增我还能正常推动项目的技术保证
固然如今也存在 Backbone React 混合使用一些麻烦
不知道后边是否在数据层还会遇到问题, 但这确实值得花时间深刻的

超出 DOM 的 MVC

另外两个把 DOM 看成虚拟机的优秀项目一个是 Elm, 一个是 Famo.us
Elm 带来的是 FPR 多年研究成果在 HTML 当中的实现
从架构图看, React 算是深受 FPR 影响, 不过也许只是由于都是 MVC 吧
Elm 遵循 Haskell 的不可变数据, 纯函数, 强类型, 整个很特殊.. 很少说
Famo.us 带来的则是 3D 游戏开发开发领域对精致的交互界面的理解
Famo.us 对 DOM 结构从新作了思考, 为精致高性能的动画铺平了道路
不过考虑项目缺乏 React 方式的抽象, 我也只是密切关注而已

从最初 jQuery 按照交互的过程一步步渲染模版绑定事件到如今
我对于编程的理解一步步被颠覆掉了, 呈现出更多函数式的理解
以前我虽然花不少力气想学 Haskell, 但是不能写界面, 我也就不多练手的机会
实际上我没用 Haskell 写过像样的程序, 甚至认为仅限研究而已
但是从 React 开始, 我发现之前的理解慢慢被颠覆了, 就是过程式的代码
这样的代码慢慢会被声明式或者函数式的代码替代掉

举个例子, Teambition 的编译工具, 之前是用 CoffeeScript 加 Shell 脚本
后边前端修改以后, 用的是主流的工具 Grunt 和 Gulp
Grunt 基本上是声明式语法, 而 Gulp 则是函数式编程里数据流的方案
并非脚本功能差, 而是用这些办法能更专一业务逻辑,
并且很是实用主义地, 这些方案更容易把复杂的工具性代码转嫁给社区
最终工具暴露的是函数式的一些接口, 虽然深奥, 可是效果不错

相似地对于界面, React 带来的是一种更好的对 MVC 的抽象
我渐渐认为开发更须要的不是一门好的语言, 而是对应用更好的抽象
对于单页面来讲, 主要须要关心的是, 网络和浏览器环境的 IO, MVC 和业务逻辑
前边的 IO 有各类类库, 不讨论, 业务逻辑躲不掉, 不深刻. 因而剩下 MVC
我认为对于框架做者的普通开发者来讲, 基本都是按着 MVC 填业务逻辑而已
那么当有更好的 MVC 的选择, 意味着更好的实现应用的工具

要赶忙睡觉... 仓促结尾.. 固然我想说的在这一小节前面的段落说完了 上个月和 xuld 在外滩交流的时候他说我看别人代码太少.. 还说服我了 后来我在 GitHub 翻一些代码, 甚至本身代码, 感到的确, 太多东西其实不了解 并且我也不知道其余人的 MVC 应用是怎么作的, 我只是说架构上... 按这个想前边几年对编程的理解, 在一年当中渐渐被推翻了确实情理之中..