Re: [閒聊] (F2E)新手心情文

看板Soft_Job作者 (自立而後立人)時間12年前 (2013/11/12 11:22), 編輯推噓5(5032)
留言37則, 7人參與, 最新討論串6/6 (看更多)
※ 引述《milfin ( )》之銘言: : 分享一下個人心得 : 雖然F2E叫前端工程師沒錯,理想的狀況下,是拿到美術那邊完成的html+css, : 然後進行修改&套版,再與後端api接起來,最後讓畫面能動。 : 大概像這樣... : |----- html+css+js -----+----- php/Java/C#/RoR... -----| : 美術 F2E 後端 : 可是在實務上, : 美術不見得會切html+css,搞不好根本只有一張一張的jpg : 美術可能把設計網頁當成雜誌平面設計,呈現的效果在web上很糟 : 後端也可能Delay或是bug連發,使用者第一個看到的就是前端所以都罵F2E : 其實蠻吃力不討好的(苦笑 : 我個人認為一個好的的F2E,至少要有下面幾項能力 : 1. 美術面: 不用到獨立設計版面,但至少框架圖(mockup)要能畫出來。 : 至少美術在用的工具(PS/Ai等),不用精通,但要能改做好的檔案。 : 不要求動感十足的設計,但至少也要能四平八穩。 : 2. 網頁面: HTML + CSS + JavaScript。 : 另外除了 jQuery 之外最好多會一點 MV* 的前端架構。 : 各版本瀏覽器要如何相容,Responsive要怎麼做, : 除錯工具要怎麼用...等等。 : 3. 程式面: 視後端用的語言而定。 : 不過至少基本的CRUD要能自己兜一套出來。 : MVC常用的框架要怎麼組裝,要如何將常用功能模組化。 : JSON是什麼,Restful API 的觀念。 : 4. Server: 總要會架開發環境吧。 : 雖然常常只能拿根香蕉就是了..... : ※ 引述《t1123425 (tommax)》之銘言: : : 當初進這家公司是因為我們公司開發部的技術長想多拉攏一些程設相關的人進來, : : 雖然公司有做app和網頁, : : 但程式部分都是外包廠商的,公司主力比較偏向美編和創意 : 看上面文字,比較像是接案代工的。 : 這也代表了你現在的公司,至少美術/企畫方面可能還過的去。 : : 進公司第一個案子就是"官網", : : 而開發部的技術長就拿些他和公司內部行銷長討論的網頁初稿給我看, : 這邊就有一個問題,最後的版面是誰說了算? : 如果是行銷長一廂情願怎麼辦? : : 還大概討論了一些範例和官網要的規格,雖然自己還沒有接案子或架過網頁的經驗, : : 不過能有個練功的機會 自己覺得因該要好好把握。 : *應 : 其實到這邊,有點感覺你要變全端工程師了... : : 後來在開始上班後的三個禮拜,我把進度大概完成一半, : : 技術長也確認過ok, : : 但在一次公司的執行長要開會看官網的進度時, : : 就開始說原設計的理念跟他想的不同,要我們重新更改官網的項目。 : .....開發初期的草圖,其實就應該讓付錢的人看過。 : 因為改草圖比改程式or切好的圖簡單,也比較不會讓人想撞牆。 : : 之前在製作的時候,我本身是還沒拿到美術ui的部分, : : 唯一的參考就是技術長的初稿,所以基本上就只有純架構的部分, : : 但後來被執行長打槍,整個構思都要重改,加上公司美術那邊卡關, : : 技術長就跟我說等美術和企畫都確認定奪後才換我這邊= =)。 : 其實,你這時候可以開始想, : 如果版面完全沒有所謂的""最終版"",一直都是要你做了改做了改,你能接受嗎? : 如果這時候,後端程式又跟版面綁的很死的話,更是讓人想撞牆Orz : : 不過事情還沒結束! 執行長又丟一案子要我評估=_= : 要評估的方向是什麼? 是評估前端? 還是評估全端? : : 現在開始想是否未來在從事前端工程師這些事都會是家常便飯? : 對前端來說,不見得是。 : 對全端來說,是。 : : 另外這行通常是先有接案經驗會比較好嗎? 感覺前端要懂的東西不少。 : 要懂的東西多沒錯,但你這多太多了。 : 整體來說,先看你自己願不願意繼續撐下去。 : 這間公司能帶給你的,或許就是那些美術企畫設計的東西。 : 如果是這樣,那你自己加強程式這一塊,或許還混的下去。 : 但是如果整天空耗.....就要審慎考慮了 基本上 F2E 跟台灣許多職位(SD SA PM ..etc)一樣都有定義浮濫的問題, 不變的地方大概都是作為不同職責之間的磨合跟最後的協調者, 也就是不管整合後端也好設計也好,最後都要輔助大家一起上線的。 我今天有點忙所以不打太多 技能面肯定要有的: 1.html/css 撰寫技巧 包括視覺圖片怎麼轉換成 html 結構,css class name 命名要有章法, 基本概念大概就像這篇我講得(雖然這篇講的是更基礎的東西) http://ithelp.ithome.com.tw/question/10099132 盡量少用 inline css 跟盡量不要用 JS 直接操作 css , 而是透過 class name 去決定狀態等等等等許多武功心法。 兜 bootstrap (或 normalize) 或 reset 這種統一各瀏覽器標準的打底。 float 要記得要 clear 殺小之類的,這一塊基本上就得磨蠻久的。 2.切圖 把視覺設計圖切成小部份跟應用到 css 上, 然後要能提醒視覺設計把可能沒有考慮到的狀態在一開始補上。 (LoVe HAte 口訣在這一樣管用) 要會看狀況做 css sprite 。 3.對 JavaScript 核心元件跟相關的應用元件要熟,對 UI 效果能掌握的才多。 html5 的東西(canvas, svg, drop upload...etc) , 因為規格繁瑣又複雜,正常人沒好好摸個幾個月很難應用, 只能說不要強求,看團隊需要適時培訓夥伴比較好。 4.對 web api 相關的資料傳遞操作要有概念 a.接本站 json 要怎麼接,接外站的 jsonp 要有概念 b.傳資料往 server 傳資料極限在哪要知道 form 的 target 一定要用的很精熟, http method POST/GET 跟 Multipart 觀念一定要有, 很多招像是 fileupload 都得靠這玩。 至於前端也要能夠跟後端、視覺一起把資料欄位橋好, 開 api 真的不應該只是 F2E 的責任,應該大家一起參與。 5.以 prototype (或 mockup) 為 base 的開發模式 至於 F2E / 設計/ 後端怎麼溝通,請盡量使用 prototype 。 這部份有興趣的請參考今年年初我寫的投影片跟講題 (網站) 前端與設計如何真心合作 http://slid.es/tonyq/projectcowork_20130129 Youtube https://www.youtube.com/watch?v=tPF3pxe6XOg
6.架 server 可以不用會,這年代能幫忙搞定 apache 或其他 server 的人, 應該夠多了,F2E 不是神不用每個東西都會。XD 7.一般網站的 page flow 是前端該煩惱的。 8.至於像 angularJS/backbone 這種近 single page website, front-end 還需要在流程管理多著墨很多功力的, 一般建議找個人專責流程規劃。 (一般會讓 UX designer 進駐跟負責,此職位最好由 F2E 轉任。) -- 個人理想上 F2E 最好有半年到一年的後端經驗輔助會火候更好, 因為合作時更理解雙方問題在哪。 另外切記不要後端跟設計跟前端壁壘分明,這麼幹的團隊很多都會各據山頭水火不容, 大家共同的敵人是「決定規格猶豫不決的那個人」,而不是對方團隊。 -- Life's a struggle but beautiful. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.137.245.90 ※ 編輯: TonyQ 來自: 220.137.245.90 (11/12 11:24) ※ 編輯: TonyQ 來自: 220.137.245.90 (11/12 11:27)

11/12 11:32, , 1F
另外其實也可以到 ajax 版討論 XD
11/12 11:32, 1F

11/12 11:34, , 2F
F2E 其實就是團隊的捕手,沒打出去的球要幫忙留意跟接住
11/12 11:34, 2F

11/12 13:07, , 3F
還有一個敵人是"反覆翻規格不改期限的那個人"
11/12 13:07, 3F

11/12 13:10, , 4F
這邊的"壁壘分明"感覺像是敵對?釐清工作責任是要的~是否敵
11/12 13:10, 4F

11/12 13:12, , 5F
對其實是"態度"問題~就算同樣是後端或前端~也一樣會有功能
11/12 13:12, 5F

11/12 13:13, , 6F
互相牽連的時候~對人不對事就會變成敵對~如果大家都肯先思
11/12 13:13, 6F

11/12 13:14, , 7F
前端去接部份的後端任務是ok的 後端去協助前端做部份也ok的
11/12 13:14, 7F

11/12 13:14, , 8F
前端協助 css 是ok 的。所謂的壁壘分明就是...
11/12 13:14, 8F

11/12 13:14, , 9F
考問題的核心~其實不管前、後端~都不會有敵對的問題...
11/12 13:14, 9F

11/12 13:15, , 10F
當使用者說頁面壞了只會問前端說你 ui 壞了,不去思考自己
11/12 13:15, 10F

11/12 13:15, , 11F
api 是不是有問題的可能,不會幫忙查 log 看東西有沒有問題
11/12 13:15, 11F

11/12 13:15, , 12F
那自然就會很麻煩 雖然說前端應該都已經習慣這種事,只是還
11/12 13:15, 12F

11/12 13:15, , 13F
是要互相~XD
11/12 13:15, 13F

11/12 13:17, , 14F
這樣就是沒有拋棄自我去思考"問題的真正核心"了~久了當然
11/12 13:17, 14F

11/12 13:17, , 15F
一個問題背後不會只有一個團隊需要動,大家有這種共識就好了
11/12 13:17, 15F

11/12 13:17, , 16F
大家越做越不爽...
11/12 13:17, 16F

11/12 13:18, , 17F
我比較傾向講現象啦 畢竟很多事情我們只知道現象跟盡量調整
11/12 13:18, 17F

11/12 13:36, , 18F
我覺得 cover 要看個人,責任感強的人就會做,
11/12 13:36, 18F

11/12 13:36, , 19F
但是沒必要拿可以 cover 來要求前端
11/12 13:36, 19F

11/12 13:57, , 20F
有沒有必要是看團隊需要的
11/12 13:57, 20F

11/12 13:57, , 21F
所以就看需求、待遇、技能兜不兜的攏了
11/12 13:57, 21F
※ 編輯: TonyQ 來自: 220.137.245.90 (11/12 14:21)

11/12 23:01, , 22F
當一個案子是由全段設計師負責就沒上面對壘的問題了(被
11/12 23:01, 22F

11/12 23:01, , 23F
11/12 23:01, 23F

11/12 23:01, , 24F
全端xddddddd
11/12 23:01, 24F

11/12 23:11, , 25F
感謝前輩們精闢的見解,在團隊上的經驗恐怕是我最欠缺的
11/12 23:11, 25F

11/12 23:15, , 26F
路還很長,繼續加油吧~
11/12 23:15, 26F

11/14 14:06, , 27F
"盡量少用 inline css"這句我有意見,應該是不要用,不是少用
11/14 14:06, 27F

11/14 16:41, , 28F
Ageis 哈哈, agress with you. 不過有時候是必要的
11/14 16:41, 28F

11/14 16:41, , 29F
像顏色是動態指定的時候,你免不了要透過 js 或 html 去設定
11/14 16:41, 29F

11/14 16:42, , 30F
色碼。
11/14 16:42, 30F

11/14 16:42, , 31F
position 的問題就更不用說囉...:Q
11/14 16:42, 31F

11/15 00:17, , 32F
@TonyQ 透過 plugin/lib 那種我可以接受 e.g. hide()
11/15 00:17, 32F

11/15 00:18, , 33F
但正常情況下,99.9% 是不需要寫 inline css 的
11/15 00:18, 33F

11/15 00:22, , 34F
而"盡量"這個詞是比較模糊的,所以我會建議寫"不要用"
11/15 00:22, 34F

11/15 00:23, , 35F
當遇到特殊情況時,再 case by case 的去分析
11/15 00:23, 35F

11/15 12:39, , 36F
ok 的 , got your point.:)
11/15 12:39, 36F

11/15 22:16, , 37F
共同敵人實在是心有七七菸 XD
11/15 22:16, 37F
文章代碼(AID): #1IWPyA5- (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1IWPyA5- (Soft_Job)