디자이너와 프로그래머와의 사이의 코딩 논쟁 해법
페이지 정보
작성자 서방님 댓글 0건 조회 284회 작성일 07-12-18 09:20본문
항상 그런문제는 있어왔던 듯 싶습니다.
물론 전문 코더를 쓰면 좋겠지만 인건비 부담으로 인해 중소규모 웹제작사에서는
전문코더를 두기 힘들죠....
이런 문제는 결국 업무 프로세스에 대한 정립이 제대로 안돼서 나오는 문제라 봅니다.
저역시 비슷한 경험을 했었죠...
참고로 저희 회사는 기획과 디자인은 한팀을 이루고 있고
프로그램 개발은 관계사에서 파견된 전산실 요원이 담당합니다.
즉 회사가 다른 경우죠...
항상 개발자의 불만은 원칙없는 HTML 코딩이었죠.
불필요한 테그발생 복잡한 테이블 구조, 기본적인 프로그램 지식이 없는 디자이너에 대한 불만이 대부분이죠.
여하튼 HTML코딩은 디자이너가 할수 밖에 없습니다.
왜냐... 그래야만 디자이너가 원하는 레이아웃을 뽑아 낼 수 있으니 말이죠.
말그대로 이미지만 가지고 프로그래머 보고 HTML 코딩하라고 하면
문제가 발생하는건 당연하겠죠?
그래서 html 코딩 방식 자체를 메뉴얼화 시켜버렸습니다.
즉, 코딩을 하는 방법에 대한 제한을 둔것이지요.
이미지와 html 파일, 기타 플래쉬 파일등의 파일명과 확장자에 대한 정의를 내렸습니다.
예를 들어 html 파일명은 [분류명_페이지명_옵션.htm] 이런식으로요.
물론 여기 계시는 기획자분들은 이런 파일명 규칙에 대해 잘 알고 계시리라 믿습니다.
두번째는 작업방식을 규정시켰습니다.
먼저 디자이너들 중 하드코딩 지식이 부족한 디자이너들에게 외부 교육을 시켰습니다. 고용보험 환급이 되는 과정을 통해 드림위버와 홈사이트를 2개월간 교육시켰지요.
그리고 업무 프로세스를 정립했습니다.
이는 크게 신규 개발시와 유지보수 시, 두가지로 정의 했으며 신규개발시 작업 프로세스는 다음과 같이 정의했습니다.
1. 디자인작업
2. 드림위버 템플릿 제작
3. 템플릿 업로드
4. 템플릿을 기초로 프로그래머가 인클루드 파일 제작
5. 서버에 등록된 인클루드 구문을 삽인한채, 홈사이트로 컨텐츠 부분 제작
6. 코딩 완료 후 개발자에게 최종 이관
유지보수는 모두 홈사이트를 통해 테스트서버(PC 서버)에 등록하여 테스트하며
테스트 완료후 개발자가 최종적으로 테스트 서버에서 서비스 서버로 데이터를 이관합니다.
물론 테스트 서버는 매일밤 1시부터 서비스 서버의 데이터를 내려받는 관계로 두 서버의 환경 및 파일구조는 동일합니다.
세번째는 주석처리 정의입니다.
디자이너는 템플릿 생성시 테이블의 시작점과 종료점에 주석을 표기하도록 정의되어 있으며 표기 방법은 다음과 같이 합니다.
<-- ################ 주 네비게이션 테이블 시작 ################# //-->
....
<-- ################ 주 네비게이션 테이블 종료 ################# //-->
네번째 테이블 구조는 독립적으로 코딩하도록 정의합니다.
저희는 특별한 경우(너비 100%, 높이 100%가 필요한 경우)를 제외하고 페이지 전체를 두르는 테이블은 사용이 불가능하도록 정의했습니다.
크게 화면 기능상 상단 주메뉴, 중단 컨텐츠, 하단 카피라이트 부분을 분리된 테이블로 생성해야 하며 해당 테이블 내에서 컨텐츠 테이블 역시 서비스별 테이블을 분리하도록 정의했습니다.
다섯번째 html 테그 사용규정을 만들었습니다.
<TD> 테그 내에 가운데 정렬은 <TD align=center>로 하기도 하고 <TD><P align=center>로 하는 경우가 있습니다. 이런 경우 전자를 선택하여 위와 같은 방식으로 작업하도록 했습니다.
위 경우에는 드림위버에서 셀을 선택하고 프로퍼티창에서 align 설정을 잡아주면 됩나다.
즉 작업 방식을 설정해 주는 겁니다.
또한 드림위버에서 코드 옵션에서 테그와 속성명은 대문자로 속성은 소문자로 하도록 정의했습니다.
그 결과 모든 html코드는 <TD ALIGN="center"> 형식으로 돌출되도록 했습니다.
기타 이러저런한 업무 정의를 통해 디자이너를 교육시키고 이를 통해 업무를 개선하는 거 역시 기획자의 할일이라 생각합니다.
만약 기획자가 html, css, javascript 등을 상세히 알지 못한다면 이는 개발자의 도움을 통해 위와 같은 업무 정의서를 만들어 두고 이를 시행토록 한다면 필요없는 논쟁으로 인한 업무로스를 줄일 수 있으실 겁니다.
물론 이게 정답은 아닐거라 생각합니다.
디자이너들의 반발도 있을 겁니다.
작업시 너무 신경이 쓰일테니까요. 하지만 이는 작업시 작업 습관으로 만들어 지면 이후 그 디자이너는 어느 회사로 가더라도 개발자와의 호흡에 도움이 될거라 인지시켜 줄 필요성이 있습니다.
더구나 요즘 툴이 워낙 좋아져서 코딩 방식은 자신이 습관화만 한다면 원하는 정리된 코드는 자연 툴이 만들어 주니까요.
댓글목록
등록된 댓글이 없습니다.