唔、這算是我某種觀察日記(？)，就是那種、一直都沒有發現，然後，突然間看 doc 有感而發然後就突然發現的那種東西。對… 這次的靈感是從 karma 來著的，關於 api。

karma 是…？

karma 是幾年前出現，可以協助前端測試的一個…工具。當時使用的原因是，因為從 phantomjs 、 jasmine 、 然後自己的 code 這些都要自己接起來，然後還有 spec ，一想到就覺得累了。發現這工具的時候覺得很棒，他都接好了、身為使用者只需要把自己想要的 config 補上就可以結束這回合了。

我的觀察

甜蜜期

如同前述、一個把所有東西都兜好好的工具來說，免去自己需要設定、是一件很棒的事情。也因為這樣、用了很久、很久、很久。

痛苦的開始

因為他真的什摸都包了、尼要 coffee 、 coverage 、連 ie launcher 、 不想要 jasmine 、 想換成 mocha 、 qunit 都有，但正因為什摸都有了、就是痛苦的開始….。

前端的各種 framework 蓬勃發展，各種管理 dependancy 的方式、越來越多的 js framework ，karma 都有辦法幫尼包進去，這結果造成的是：

1. 越來越多、越來越複雜的設定。
2. 一不小心就會踩到各種陷阱卡，nodejs 升不上去、只能用某個(自己所需的) package 版本。
3. 然後、覺得測試跑起來越來越慢了。

這其實都是可以想像到的，一個大型的 project 發展到後來，是必然發生的事情。

拆拆拆

為了應付各種需求，甚至因為一些存在已久、也許有些 code 升級的代價過大，新舊問題等等，存活這摸久的 karma 顯然、成為一種讓人痛苦的存在。在比較新的版本、 karma 有了一個重大的變革 – 拆。

他不再把某些 dependancy 跟他的主體包裝的很好，而是由使用的人去管理他需要的版本。提供 interface 但不保證使用的某版本接上後會發生什摸樣的事情，大概是這樣。這一定程度上的緩解了各種版本造成的問題、但另一個衍生問題是，因為拆得更細了、所以… 設定上就更繁瑣了這樣。

一些小經驗

過去、曾有一段瘋狂的開發經驗，有 n 個人對於一個功能有 n 種微妙的要求。舉個雖然不是真實案例、不過、大概就是這樣的例子…。

關於排序…(以下的小括號表示本人。)

A 要求：我的都是數字、但不確定有多少。

B 要求：我的都是字串、但有 utf8。(數字固定嗎？) 嗯、固定。

C 要求：我要排序、但我不知道我會有什摸樣的輸入。 (…) 座標也可以排序嗎？ (…)

在同一個功能、但要符合各種參數(？)，或者微妙的差異下、很瘋狂的收斂，只用同一個 function name 然後做意義上一樣、但過程完全不同的事情~，啊、這好像叫做泛型的樣子。寫得好、那很棒，可是一旦走黑到底、就有點像是 java 在各種平台上都可以運作、但效能很差一樣。而更慘的是、因為要符合各種情況、不只是需要的判斷很多、也會需要很多的 option 設定，或者根據某些特定條件只會有某些設定可以使用等等…。

某方面跟 karma 一開始類似，覺得這樣的偷懶好棒、好方便，但後續的維護跟效能還有設定上都是很大的困擾。特別是在後來、開始認真的跟各種 ui 接觸的情形下，這種狀況的出現更頻繁了。因為大家設計的 layout 都不一樣，使用的 tag 不一樣，像是大家都很愛用的 slides 、 carousel 也有各種版本，而這是因為…. 設計出來的長相不一樣。

為了因應這樣的需求、目前設計的 plugin 基本上都是放棄 render (裝死不處理？)，只寫邏輯、功能…，可以用 es6 的就用 extends ， 不能用的就用設 custom event ，反正就是不處理 render 就是了。一定程度上更自由、但是我也不知道這樣好不好。因為更自由代表著、可能會有更任性的需求、但更大的可能是，根據要求改變後根本感覺不出前後差別…(改心酸的意思)

結論

對於如何設計 api 讓各個使用的人包含維護的人都可以更安心、更開心，是一件很困難的事情。(<– 根本廢話~ XD) 我只能說、現在對於這樣的要求，因為曾經有的各種瘋狂的實驗、漸漸的心中也有一把尺。但是、我想說的是，對於很多的願望清單，像是一個按鈕就這也可以那也沒問題的願望，不如期待什摸時候可以用腦波做各種事情的時代吧！