---

以下嘴砲，加減參考就好。

個人建議是自己先弄出一個基本雛形，
讓人可以簡單的直接套用或修改。

大前提是讓別人可以用現在一半以下的力氣達到相同效果，
要學的也盡可能少 (都包好給人直接執行或抄)。

新工具 (測試/版控/相依性) 就看看能不能用命令操作，
能就自己把環境弄好，把命令包好，
讓其他人可以直接執行某些你給的 script 就收工。
(ex 輸入 project path 就自動做完以下

1. 架設環境。
2. 練習並摸熟操作方式/命令。
3. 將過去專案需要的功能寫成可單鍵/一個命令執行的 script。
4. 將 3 的 script 做到可在任一機器上執行。
5. 準備好任何誤用 (誤刪/誤 commit/拉錯 lib/etc) 情形下的解決方案。

然後只要把 script 公開讓人取用，
有人想用就用，沒人想用可以自己用，
然後假設那真的很有用但除了你沒其他人用的話，
你做事應該就會有別人 N 倍的效率，
有助於你爬到能主導的位置或幾年後以戰功/能力跳槽。


新語法就寫個 sample 分 A B 兩組，
 A 用目前語法，B 用新語法，然後分析利弊得失，
寫成文章公開給人存取並提供完整可執行專案。

這部份有幾點要注意/實行：
1. 語法整理
    前面 ${} 像 jQuery 雖然有點 XD，
    但不是全無道理，依字型/大小等確實可能增加辨識的麻煩，
    那再考慮是否以 noconflict 把 jQuery 換個變數名與 $ 區分，
    能不能簡單的 replace 所有檔案。

2. 功能確認
    原本用的 tag 是不是有哪些特別功能，
    例如會存資料到 Request/Session Scope，
    或者有親子/連動等功能或特性，
    要換有沒有辦法全換掉？
    或者能不能整理出一套相對單純而好記好用的 pattern？
    例如什麼 case 用 EL，什麼時候用 tag，
    如何組合，有什麼原則或要注意的地方等等。

3. 還是功能確認
    假設某些 case 你發現 EL 超好用，
    那麼假設不用 EL 只用目前的東西，
    目前的用法有其它改進空間嗎？
    這部份要花 3 倍的時間去做，
    例如原本花 2 小時研究發現 EL 超好用，
    那就花 6 小時研究不用 EL 的話最好能做到如何，
    要比較兩個東西就要把它們都發揮到淋漓盡至，
    這是要向別人推銷之前的基本禮貌。

這樣推成當然好，推不成你也學了不少更有本錢跳槽。

※ 引述《dream1124 (全新開始)》之銘言：
43
:  那是不是以後專案都不可能引入新工具了?
:  結果他竟然很誠懇的說: "對, 確實是不太想導入其他工具!"
:  我了解他是不想唬弄我才會很直接的說,
:  但回去以後越想越氣, 怎麼連這麼小的事情都說不給一點彈性, 方便, 與進步呢?
:  實在是有些不爽, 很想找機會跟前輩上面的人反應這個問題,
:  或是在個人例行報告的會議裡面向同部門的人反應我的心聲和想法,
:  可是直覺又告訴我這樣也許效果不會好, 又會有些可能的副作用,
:  因此上來請問大家一下, 若是你, 會怎麼做呢?
:  謝謝大家

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.164.150.185
※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1400332177.A.692.html