公司的專案都是基於b/s結構的，絕大多數操作介面都是通過網頁的形式展現在使用者面前的，頁面的美觀就成了非常重要的問題。記得去年的這個時候公司迎來了它歷史上的第乙個專職美工。同時到來的就是程式設計師與美工的合作問題。
矛盾篇：
公司以前的系統都是由程式設計師來編寫介面的，美觀與否先不必說，單從效率上講就是乙個很大的問題。大部分時間都花在了介面的編寫上，嚴重影響了專案的進展速度。美工到來以後，頁面的美觀程度和製作速度都有了很大提高，隨之而來的程式設計師與美工的配合問題又成了乙個新的問題。其中主要的問題、矛盾有以下幾點：
1． 1. 美工何時參與到專案中來
2． 2. 程式設計師不懂如何將頁面弄得美觀，美工也不懂如何向頁面中新增**（即使是使用了velocity）
3． 3. 程式設計師和美工是兩種完全不同的人，他們關心的事情也完全不同，這就導致兩種人對頁面**（html）風格的要求大相徑庭——程式設計師要得是簡單易懂，美工要得是美觀漂亮
4． 4. 程式設計師要做的是將資料展現在頁面上（使用簡單的條件、迴圈語句），美工要做的是將美麗充滿整個螢幕（程式設計師會叫道：天哪！這麼複雜，我怎麼用if、else、for來實現）
解決篇：
上面的這幾點問題和矛盾從關係上來講是層層遞進的，要乙個乙個依次解決。先來說說美工何時介入到專案中來，在公司做過的這些專案以及我聽說過的專案看，大致有以下幾種：1）先有美工製作靜態頁面，完成後程式設計師直接向頁面中新增程式**；2）程式設計師隨時和美工溝通，向美工描述頁面需求，隨要隨做；3）程式設計師自己編寫測試頁面，然後讓美工進行美化。
這3種方式可以說是個有利弊。方式1）對程式設計師來說絕對是個喜訊，它能使程式設計師最大限度的遠離那些煩人的頁面編碼，提高程式設計師工作的含金量。同時，一套完整的頁面可以展現全部業務的流程，對程式設計師開發也起到了規範的作用。但這種方式對美工的要求極高，美工要了解專案的需求，而這一般是達不到的。但可以讓了解需求的人為其講解，或是描繪出希望的頁面的樣式。這樣雖然可以彌補美工對業務了解的不足，但也確實花掉了很多時間（而且是花掉了比較重要的人物的時間，因為了解整體業務的一般都是公司的牛人，他們的時間可是一刻千金呀）。方式2）是乙個比較折中的方法，這樣做無需太多的準備就可開始編碼工作，程式設計師把握頁面內容和樣式，向美工詳細描述，美工再根據描述設計頁面，最後返回給程式設計師新增**。這個反饋的過程一般比較迅速，效果也不錯，可以達到程式設計師預期的效果，適用於專案時間要求比較緊的情況。該方式的問題在於沒有乙個形象化的完整的流程可供程式設計師參考，一切掌握在程式設計師手中，容易造成對需求的**和系統整體風格的不統一。方式3）一般用於對已有專案的美化上，對美工的要求也很高，她們需要具備在html和其他**混合體的環境下工作的能力。而且修改的效果一般不是很佳，不到萬不得已不推薦使用。
問題2.3.4.雖然表現出來的問題各不相同，但解決的方法卻很相似。首先，美工要養成一些程式設計師編碼時慣有的習慣，比如：檔案命名要有意義、html**要根據層次進行縮排等。其次，頁面**的一些細節也要注意，比如，使用居中或右對齊標籤來取代空格，必須使用空格時也要用「 」，不使用標籤，盡量使用**等。再次，如果在條件允許的情況下，美工也可以學習一下夾雜在頁面中的各種程式**，了解其語義和工作原理，這將對與程式設計師的合作起到很大的幫助的。最後，就是程式設計師要在向頁面檔案中新增**前先對頁面**做一下審核工作，在這裡並不是看美工的頁面是否美觀，而是看在原有頁面**的基礎上是否能夠使用簡單的條件、迴圈語句來顯示資料（比如，頁面布局過於複雜，不能通過簡單的迴圈來顯示所有資料），否則就需要修改頁面**直到能滿足要求為止。
一、**規劃階段
這個階段主要是對**的功能、目標受眾、內容、欄目進行規劃。這期間會經常性地和有關領導進行溝通。首先，自己一定要對**的整體規劃清清楚楚，然後要吸收別人的建議。吸收別人的建議的過程，可以認認真真地做，也可以走過場，但是有這個過程以後，別人才不會對你的規劃說三道四。
至於領導的意願，和你的規劃靠得上邊的，你一定要讓領導明白，他們的設想已經在你的規劃中被考慮進去了。
專案的大致進度，要在這個階段結束的時候確定下來。
二、後台模組劃分和版面設計
這個階段，程式設計師要和美工兵分兩路分頭行動。
後台模組劃分如果做好了，後面的效率會高一些。這個過程不能省。
版面設計，美工既要考慮**整體規劃，又要考慮大家的建議，尤其是不能忽視領導們的觀點（雖然大多數情況下領導的美術細胞少得可憐）。在這個大前提下，再兼顧美觀、合理。乙個好的美工，不僅僅能做出漂亮的頁面，還要能迎合一下客戶或者公司領導的意願，而且能和程式設計師進行溝通。
在這個階段，程式設計師和專案經理（專案負責人）要拿出乙個可操作的模組劃分方案，而美工要確定**的版面框架、美術風格，做出**首頁和二級頁面。
實際上，在第乙個階段（**規劃階段），美工就應該開始思考**的風格了。在第二個階段，則需要把比較抽象的初級設想變成具體的頁面。基本上，首頁定了，整個**的頁面就定了一大半了。
在這個階段結束的時候，要將專案的進度計畫進一步具體化。
三、資料庫設計
這項工作很重要。但是程式設計師應該知道怎麼去做。而且資料庫設計是和乙個人的理論水平、實際經驗息息相關的，不是幾句話能說明白的。大的、複雜的站點，資料庫規劃可能要用一周左右的時間，小的、簡單的站點，資料庫設計也需要2到3天。
在這個階段，美工最好別閒著，繼續完成頁面設計。要知道下乙個階段，程式設計師可就要用到美工的頁面了。最好別出現這樣的情況：程式設計師要用到某個頁面，而美工還沒有把那個頁面確定下來。
四、後台程式編碼
這個階段，程式設計師要緊張工作，會比較辛苦的。
程式設計師需要遵守的三個原則：
1、團隊合作；
2、保證進度；
3、保證質量。
美工這個時候要輔助程式設計師做頁面。這個階段美工可能比較閒，但是一定要稱職。
專案經理該和客戶或者領導溝通的時候，一定要溝通。
五、除錯、改進、頁面美化
這個階段，不多說了。專案經理和客戶、領導的溝通，仍然是很重要的。
web專案，美工和前台配合，頁面路徑訪問問題
一 美工寫頁面使用相對路徑，但後台使用專案的應用絕對路徑，訪問時會出現404或頁面亂碼的問題 目前的解決方法 在頁面中新增base標籤，指定當前頁面預設的路徑 舉個例子 html head base href head body img src images logo gray.gif body h...
編碼人員和測試人員 爭論的秘密
相信很多團隊都有這個問題 編碼人員和測試人員經常爭論。測試人員說編碼人員做的東西太爛，問題太多，缺乏規範，開發文件也沒有 編碼人員說測試人員責任心有問題，測完了還是令自己不放心 還有很多人認為 如果發布出去的軟體有問題，就是測試人員的責任 理由是 測試人員應該在發布之前把所有問題都找出來 1 為什麼...
編碼人員和測試人員 爭論的秘密
相信很多團隊都有這個問題 編碼人員和測試人員經常爭論。測試人員說編碼人員做的東西太爛，問題太多，缺乏規範，開發文件也沒有 編碼人員說測試人員責任心有問題，測完了還是令自己不放心 還有很多人認為 如果發布出去的軟體有問題，就是測試人員的責任 理由是 測試人員應該在發布之前把所有問題都找出來 1 為什麼...