我參與過的產品回顧

前幾天跟同事聊天的時候回頭看過當時在學校開發的電臺
如今多是無人維護, 並且 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 應用是怎麼作的, 我只是說架構上... 按這個想前邊幾年對編程的理解, 在一年當中漸漸被推翻了確實情理之中..