iT邦幫忙

10

過去的笨蛋跟未來的聰明人

聊我對 JS 一路以來學習的感想。
我注意到 JS 是從表單開始的,當初 2005 年我接案做網站系統時,

注意到一個問題是很多日期選單其實都是月份用 select 選項放 1~12 ,日期放 1~31,
這樣就會導致可能視覺上出現 2/31 這種根本不存在的選項。

另外就是像是清單型的資料,為什麼不能按個鈕就增加一行,而非得要重新整理網頁,
然後自己一一處理重新整理時欄位的重新置入,反應又慢又難寫。

我就覺得這樣的 UI 很蠢,所以就想說有沒有辦法,
能夠按照不同月份判斷不同月份的日期或是動態的新增欄位,

後來發現在 client(browser side) 上能夠對 html 做操作的,
就只有 JavaScript ,所以就試著用 JS 寫了一些類似這樣的小功能。

當初學 JavaScript 並沒有什麼特別的想法,
事實上我當時的語言背景是一年的 Java,會一點點 vb6 ,也就只有這樣。

很多人學語言時,都會考慮到這個語言紅不紅、好不好用、好不好學,
而我純粹就是因為"我需要" 所以我學他,而這也是為什麼我能專心致志的運用 JS。

早期寫 JS 的人是很孤獨的,因為你跟別人講 JS 人家都會覺得那就是網頁特效,
但是特效不夠炫的基本上也吸引不了人家注意力。

然後很多人都覺得 JS 要考慮跨瀏覽器議題很難寫、沒有好的 debugger tool ,
但其實你寫熟了就知道跨瀏覽器議題其實有一些基本的經驗法則的,
debugger tool 從有 mozilla firefox with firebug 、
IE8 開始有開發者工具之後,就已經好很多了。

而且就算是 IE6 , Microsoft script editor 也能做 JS breakpoint ,
只怕很多人根本沒聽過沒用過。XD

最糟糕的是這個技能在履歷上的能見度非常低,零零總總加起來就變成喜歡寫 JS 的人是笨蛋。



因為因緣際會的關係寫了不少年 web ,喜歡做一些貼心的細節,
一項是我設計網站的思維,怎麼樣可以讓使用者更覺得有趣的作法是我在追求的。

很早就把 fade in , fade out 、ajax 這類的作法應用進專案,
當然也不是說有用這些作法就是好,有時候也會做得太過花俏。

以我個性如果持續性的在寫網頁 html ,但卻沒有接觸 JavaScript ,
會是很匪夷所思的事情,因為做一件事情本來就應該試著把它做得更好。

我是覺得去學自己需要的東西,如果你在寫 web ,現階段瞭解 JS 對你是好的,
如果你不是再寫 web ,是不是需要學這個看起來好像很紅得語言,那也未必。

@學習過程跟困難

一開始學習 JS 的時候,我通常是遇到一個問題,
然後得用 JS 去解決,於是就開始一直找參考資料。

一開始碰到比較大的問題是 Dom 物件的清單跟 JS 屬性的對應,
因為對 html/dom 本身的瞭解不夠,當時主要是參考 w3cschool 的網站資料做對照。
(雖然後來是發現 w3cschool 上面也會有瑕疵的小問題,
但是就當時來講已經算是很不錯的參考資料。)

像是
http://www.w3schools.com/TAGS/tag\_img.asp
或是
http://www.w3schools.com/jsref/dom\_obj\_style.asp

有這種屬性表其實蠻不錯得,可以知道自己能做什麼事。

當然這過程中也是要一直學 CSS 相關的,一開始我們寫 JS ,
可以說是學 HTML 跟 CSS 比寫 JS 來得多。

@瀏覽器相容性議題

其實現在回頭想想,瀏覽器相容性議題只要有養成開兩個 browser 測試的習慣,
基本上是不太會困擾我們的,只有想偷懶或是跟著唸的工程師會一直抱怨。

其實我們常常都只是偷酸 IE ,但是是酸好玩的,誰叫他們不做自動更新機制...
現在誰還叫我 support IE6 我就殺了他。(咦,不是說好不抱怨瀏覽器嗎)

記憶中當時比較明顯的問題就是 padding 判定 issue (IE6)、zoom:1 (IE6) 、event binding 的不一致 (IE*),什麼 CSS3 跟 HTML5 因為當年根本就還沒有瀏覽器(連 chrome 都還沒出現),所以也就沒什麼現在那麼複雜的相容性的問題。

然後 IE6 JS 引擎真的很慢,但是做的事情反正也沒現在多,就當時應該算是夠用了。

@ 多層事件

單一事件的處理寫久了,就會開始碰到多重事件的處理,事件跟事件的層層套疊,
開始網站的頁面層次變得複雜,但是到了這一步,現在我會希望回頭問問自己。

這個頁面變得這麼複雜對使用者來講負擔不會太大嗎?
每個地方連點兩下都可以編輯真的是使用者要得嗎?
到處都有功能,會不會讓使用者搞不清楚一個功能到底要去哪找。It worth to think.

到現在,我知道多層事件的處理有許多技巧,像是 pub-sub 觀念、
像 namespace 加上 delegate 觀念,該怎麼做 template 等。

但即使你有技巧能更優雅的做這件事情,一樣節省不了他的複雜度。

好的程式碼可以讓你減少犯錯、讓你容易看清楚清楚程式的結構,
沒有程式碼可以減低程式的複雜度

假設你程式就是要做一百件事,這一百件事不會因為你最後寫成一行或一百行而變多或變少,
所以寫下任何程式碼之前,想想複雜度這回事,然後想想你是否已經決定付出這個代價。

@ 資料管理

因為你頁面上總是會有很多動態處裡的資料,你多少會需要 cache 一些 models 在你的頁面上,
像是編輯、處理中的清單啦或是頁面上有的一些資料啦,

需要不斷更新的一些頁面資料區塊,都可能需要你對目前的資料做儲存、fetch、update 等,
而且不同區塊的資料可能會有一些彼此互相參考的需要。

這時候你要面臨的最大的問題是因為疏忽造成的記憶體管理問題,還有資料過期造成的問題,
有些被快取的資料不是資料庫裡最新的資料,這會是個大問題。

而且你得跟後端充分的合作將你需要得資料請後端送到前端,
或是跟他們協商你應該送什麼資料給後端,

擁有"資料"傳輸的觀念也是前端人該點的技能。

@ 跨服務整合

寫到後面你可能還會需要煩惱一些跨服務的整合,像是 google map 、Facebook api 之類的,
這些都需要跟服務商的系統打交道,有時可說是毫無道理跟規則可言。

===============

其實 JS 本身是一個很簡單的語言,
上面說得複雜度其實都是頁面操作邏輯的複雜度轉換來的,
也就是說如果你的功能不複雜,你的 JS 就可以寫得很簡單。

你會覺得 JS 是很複雜,其實是你要做的功能很複雜。

近年來網站系統有複雜化的傾向,不管大小網站都是,
很有些人太技術狂熱喜歡把簡單的事情用很複雜的方式做,
很多時候我們真的應該回頭想想這些功能,是否有值得用這麼複雜的方式去打造的價值。

當然也很有一些中型或大型系統是真的需要運用大量前端技巧去打造的,
但目前很遺憾的是台灣由於過去產業斷層,蠻缺少能夠自由運用前端經驗的工匠,

即使現在慢慢能有前端的職缺,卻仍然是出現找不到技能完備的人。

我認為理想的前端是應該同時具有前後端一定經驗,
又願意花時間在 JS/css/html 上,這樣才能夠達到最好的發揮。

也因為這樣,一個好的前端工程師的培養動輒需要好幾年,而以台灣產業環境過去又無法給前端一個溫床,
不重視前端且後端職缺普遍比前端待遇好、受重視,開發者因為後端待遇較高就轉往後端就職,
然後這些好的工程師又會因為某些迷思從後端轉往管理職,導致連後端圈自己都很難以技術深研,
就更不用說再轉回前端來完成前端 F2E 所該走得路徑了。

目前資深 F2E 多是本身就是持續在 web 上開發,且有需要一直運用到 JS 的人。

相信接下來不管 mobile web ,web 也好,甚至是新的 epub 市場也好,
html 這個簡易而且許多人會得樣板、UI 語言,短時間內看起來是屹立不搖的狀態,

相信 JS 這個前端語言還能夠有一定程度的興盛。

只是台灣的產業是不是已經承認前端本身就已經足夠豐富到成為一個職缺與產業的問題。

不過他們不承認也不行,因為今年我至少聽到幾十家公司說他們想徵前端,
但完全找不到能用的人,而這完全就是過去這幾年忽視這技能所種下的歷史共業。

文末回顧一下標題,在過去有人說學 JS 是笨蛋,而現在很多人覺得學 JS 是聰明人,
但是那些都不重要,重要得是你想要做什麼事、當什麼樣的人。

在過去我樂於當笨蛋,在現在我也不排斥當聰明人,
但別人怎麼說別人怎麼看,其實還是比不上自己想要做什麼來得重要。

--
這篇好像有點太心得了 哈哈哈哈,沒啥技術含量啊。將就著看。


0
ted99tw
iT邦高手 1 級 ‧ 2013-04-14 10:10:27

tony1223提到:
在過去有人說學 JS 是笨蛋,而現在很多人覺得學 JS 是聰明人

灑花 我是以前該當笨蛋時自傲地當了聰明人,現在才知道聰明人原來是個笨蛋,雖然這文看得讓人汗流浹背涕淚滿衣裳,但看完後同時也像四川人吃辣般,一個字...

<span style="font-size: 36px;"><span style="color: red;">爽~</span></span>開心

0
temo
iT邦新手 1 級 ‧ 2013-04-14 19:36:10

老手的經驗談常常能帶給新手一些啟發,並讓新手少走點彎路謝謝

就是阿~
真的是很好的分享

http://www.piece2ec.com.tw/

0
chibc
iT邦新手 3 級 ‧ 2013-04-15 11:13:40

如果沒有熱情的前輩分享,在職場或自修前進的道路一定更困難

學校目前好像教不出前端?

看更多先前的回應...收起先前的回應...

現在的學校能教出什麼?

+1 學校能教出啥?

sula3065408 iT邦研究生 1 級‧ 2013-04-17 20:10:02 檢舉

學校能教出啥? ++

ted99tw iT邦高手 1 級‧ 2013-04-17 20:42:04 檢舉

sula3065408提到:
學校能教出啥?

你,我,他...汗

總裁 iT邦好手 1 級‧ 2013-04-17 20:51:45 檢舉

還有你的妳和他的她...冷

chibc提到:
學校目前好像教不出前端

通常只有...弊端....毆飛

0
eastamis
iT邦新手 5 級 ‧ 2013-04-15 16:09:09

不用等別人教, 要用什麼自已學就可以了
在學校學東西的流程是: 教(老師教), 學, 習, 用
出來混的的流程是: 用, 習, 學, 教(找會的人教)
講白一點的說法是,

  1. 先直接用吧,
  2. 不會用時, 參考會的人怎麼用, copy & paste
  3. 真的不行就自已找方法學, 看看書也行,
  4. 再學不會只好找人來教吧
    通常有程式基礎再來寫任何程式(除了專業領域的限制外), 使用前兩招就ok了,
    這應是open source所帶給大家的好處

阿伯大...你改帳號囉?汗

0
外獅佬
iT邦大師 1 級 ‧ 2013-04-15 23:44:34

tony1223提到:
這個語言紅不紅

這只會影響到接班人的問題.....

很多古老的系統,其實運作得都很好,或許是因為單工、環境單純
但是,他們就是比現在很多系統都堅強,歷經幾十年不死。
但...逐漸凋零,只因為....新系統不支援;新人不想學,因為覺得沒前途...
cobol、foxpro、delphi、vb6....等等等的程式語言,現在一點都不紅
但是,中小企業,還有多少依賴他們生存?

依賴他們生存是因為他們沒有前進的思考跟思維,
換個角度想,有多少中小企業就抱著這些沉腐沉進去了。

金融業有多少系統是改不動而不是不想改,
有多少資訊因為這些陳腐的思維而無法公開。

前陣子跟朋友在聊到台灣證交的交易資訊公開,就聊到這件事,
大部分系統都老舊且被系統商(ex. IBM)把持,導致要翻身也不行要轉身也不行。

有些系統(諸如 POS)的確在需求沒有變更的情況下可以數十年如一日的運作,
像保齡球館的 POS 還不是都是老電腦甚至都是一堆 DOS 時代的應用程式就足夠了。

但是同樣是 POS ,也有能整合多樣代收跟各種豐富功能的 POS,
你面對什麼挑戰就需要什麼系統。

VB6 我也接觸過一兩年,他在開發上的確有它的問題,
如果真的叫大家回頭去倚賴這些語言,用兩倍的時間作一樣的事情,不是好事。

這種說法大概就跟當初一堆人抱怨文書處理軟體,
扼殺了打字工跟排版工的工作是一樣的。
(想起小時候用 PE2 跟文字格線打公文跟表格的年代。XD)

你會說這叫堅強嗎? 我會說堅強的不是這些系統,是人們不願意改變的習慣。 :P

tony1223提到:
這叫堅強嗎?

我所謂的堅強,並不是撐得久...
而是...當機、出錯機率低...這很難否認...
畢竟,單工的環境還是比較單純。

0

(想起小時候用 PE2 跟文字格線打公文跟表格的年代。XD)

還有列印控制碼

我要留言

立即登入留言