적합한 소프트웨어 설계(design)를 위해서는 기술 요소에 대한 구체적인 지식과 함께 사용자 요구 사항에 대한 깊은 이해가 필요하다. 1
예전에 경험한 일이 떠오른다. 대량 데이터 조회 화면에서 페이징(paging) 고려는 흔한 일이다. 구체적인 사항에 대해서는 고객에 앞서 UI 개발 전문가가 예제를 보여주고 선택하게 했다. 그리고 나니 고객은 적극적으로 의견을 피력했다. 주관식보다는 객관식이 답하기에 좋은 법이니까. 두 가지 사항을 결정했다.
여하튼 이러한 예외적인 사용자 입력에 대해 정상적인 페이지를 보여줄 수 있도록 코드 수정이 필요했다. 개발자가 작성하는 화면 스크립트, 서버 코드, 연동을 처리하는 공통 코드(혹은 프레임워크) 세 곳 중에서 가장 영향이 적은 방안을 택해야 한다. 아쉽게도 화면 스크립트는 수정은 막을 수 있었지만, 서버 코드 수정은 피할 수 없었다. 공통 코드가 로직 대부분을 감싸고 있기에 변화를 줄일 수는 있었지만...
예전에 경험한 일이 떠오른다. 대량 데이터 조회 화면에서 페이징(paging) 고려는 흔한 일이다. 구체적인 사항에 대해서는 고객에 앞서 UI 개발 전문가가 예제를 보여주고 선택하게 했다. 그리고 나니 고객은 적극적으로 의견을 피력했다. 주관식보다는 객관식이 답하기에 좋은 법이니까. 두 가지 사항을 결정했다.
- 페이지로 나누어진 그리드(list) 하위에 이동할 페이지가 숫자로 나타나는 형태 선택2
- 그리드 상단에 콤보(drop-down list)를 부착하여 한 페이지에 보일 데이터 건수를 선택하게 함
- 하나는 데이터 수정(입력, 삭제 포함) 후에 돌아가는 페이지와 커서 위치다.
- 두 번째는 데이터 건수 선정 후에 페이지 이동을 함께 반영할 때 처리를 어찌 하느냐 문제다.
여하튼 이러한 예외적인 사용자 입력에 대해 정상적인 페이지를 보여줄 수 있도록 코드 수정이 필요했다. 개발자가 작성하는 화면 스크립트, 서버 코드, 연동을 처리하는 공통 코드(혹은 프레임워크) 세 곳 중에서 가장 영향이 적은 방안을 택해야 한다. 아쉽게도 화면 스크립트는 수정은 막을 수 있었지만, 서버 코드 수정은 피할 수 없었다. 공통 코드가 로직 대부분을 감싸고 있기에 변화를 줄일 수는 있었지만...
- 마침, 비슷한 논지의 글을 읽었다. '너도 나도 그렇게 폼나고 상위의 일을 했을 때, 디테일이 살아있는 디자인이 나올 수 있냐는 질문을 던집니다.' 출처: 누끼마녀와 아웃소싱 [본문으로]
- 화살표 클릭이나 페이지 직접 입력 등을 배제 [본문으로]
