Login  |  繁體中文
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
Tech Column 網站程式上線前需要準備的事(三)

網站程式上線前需要準備的事(三)

◎ 本文轉載自 Blog.XDite.net

第 3 件事:制定 Art/RD 都遵守的開發 convention

在傳統的開發過程中,作法多半都是:規劃 => UI/畫面設計 => 程式設計。

其實若專案規劃階段結束的早(也就是實作類似最低可行產品的概念),並非需要等待 UI/畫面設計完工,才可以進行到「套版」(程式設計)的階段。

一直以來,我都認為「套版」是一個非常不好的說法,造成了偏差的印象。因為一個網站實際上是「一整套」的「軟體」,並非是「畫面」設計的出來,程式就配合寫的出來。雙方必須都要是可以執行實作的部分才行。

程式一定要實際的「美術畫面」被設計出來才能夠被接著實作嗎?其實不是這樣的:只要有 wireframe,RD 往往就可以先行動工。

但問題來了:若雙方各自進行自己的部分,那最後要怎麼組起來?

這其實還不是最大的問題。

最大的問題,其實是 Art 切出來的「版」,多半是不能夠被「套」的。


畫面不是切得出來就能「套」

這個問題其實不能夠怪 Art,它們有的是藝術細胞,並非邏輯細胞。而:

  • 能夠熟練 Photoshop,並不代表能夠寫出良好結構的 HTML 與 CSS code。
    1. 這需要一定的經驗以及技術實力。
  • 能夠切出 HTML 與 CSS,並不代表這一份原始碼,可以被實際使用。
    1. 有一些 Art 只懂得 PSD to table,整個畫面毫無結構可言,讓人頭痛萬分。
    2. 有一些 Art 專精製作單頁的活動頁面,但 application 需要整套的 DOM 能夠重複利用,CSS 一旦被重疊使用時大爆炸。

在傳統的專案進行到「套版」階段,程式開發進度會難以掌控的其中一個原因。也是因為:RD 面對著一套爛 HTML,完全不知從何下手「套」進去。不改結構無法讓程式運作,或者程式運作效率會很低;但一改結構,就別肖想 Art 再幫你調整細部 style 和追加細節了。(東西被改的不爽情緒或原始結構被改變)

「套版」這個過程中無端被追加浪費了大量時間,這也是一個上線前的隱藏變因。

解決方法:製作一套 HTMLCSS 設計準則

多數的 application 有固定結構的 DOM。差異在於 〈div id="content"〉 〈/div〉 內的不同。至於

  • header
  • sidebar
  • warning
  • form
  • footer
  • etc…

其實多半是相同的。

與其抱怨 Art 切出來的東西不能被套,不如設計一套 general 的實際準則可以被大家遵守學習。

不僅僅是 HTML 設計規則,其實開發當中會花掉很多時間的,還包含一些常見的 CSS hack/IE hack。這些也可以被整理起來,節省開發時間(當然,現在你只要學 compass 就好)。


平行開發互動:解決多人團隊的偏好歧異問題

剛剛有一個問題我們沒有回答到:就是個人偏好如何「組合」?

比如說美術的版裡面有這樣的 DOM 〈div class="article"〉 〈/div〉,class 是 article。

但是 RD 實際的程式碼卻是 post 這樣的物件名稱。

〈% @posts.each do |post| %〉
  〈%= post.title %〉
〈% end %〉

這樣「套」起來不是很有問題嗎?如何實現所謂我說的「平行開發」?

其實 Art/RD 雙軌平行開發,才可以有效的為專案爭取到時間。

其實之前的所謂「套」,因為有完工的時間壓力,DOM 往往不能夠被更改。但是不改 DOM 又不能讓專案繼續被執行下去。

若是雙方平行開發,又有一個 deployable 的 application 讓進度透明,所有的修改和溝通調整,只是一下子的功夫(article 與 post 的不同,可以在很早期就被抓出來修掉),不但不會打亂開發節奏,反而會加速專案的進行。



You may be interested in the following articles:




OSSF Newsletter : 第 196 期 從 Copyleft 看自由開源軟體授權相容性

Category: Tech Column