토픽광장자유게시판

물론 범용으로 개발되어 배포되는 자료의 한계일 수도 있습니다. 여러 환경에 만족하도록 고려한다는게 쉽지는 않겠죠.

 

그런데 그런 것이 아닌 그냥 개발자의 신념이나 주관에 의해서 결정된 것이 간혹 사용자들이 사용함에 있어하 불편 또는 한계를 만들어 내는 경우가 있습니다.

 

 

page.png

 

 

지면의 상황에 따라 목록수를 줄이고 페이지 수를 늘려 제공하는 list 의 총량은 그대로 유지하고 싶은 경우가 있습니다.

 

그런데 제가 사용하는 위젯의 경우 페이지를 1,2,3 페이지에서만 고르게 되어있습니다.

 

왜일까요??

목록의 수를 많이 가져오는 것을 개발자분이 방지해주고 싶은 것은 아니었을 겁니다.

 

개인적으로 페이지를 구분해서 출력하는 페이지 수를 굳이 제한해서 제공해야 하는 이유를 찾지 못했습니다. 성능의 이슈도 발견해 내지 못했구요. 저희는 페이지 수를 좀더 선택할 수 있도록 추가해 줬습니다.

 

이 사례를 제가 잘못 이해하는 것은 아닐지 라는 조심스러운 생각도 들더군요. 뭔가 이유가 있어서 그런 것을 제가 이해하지 못하고 오해하는 것 일수도...

 

지금 사례와 비슷한 사용자로서 원치하는 제한이 되어 있는 경우가 종종 있어 이런 생각이 들었습니다.

물론 저는 저희 사이트에 맞게 수정해서 사용하려는 성향이 강한 운영자 이다 보니 이런 생각을 하고 있는지도 모르겠네요.

글쓴이 웹지기

profile
^ ^
Atachment
첨부 1
  • profile
    기진곰 2018.07.04 12:38:21

    너무 많이 가져오면 성능에 매우 안 좋습니다.

    저 위젯은 글쓴이 이름이 나오지 않아서 그나마 괜찮겠지만, 글쓴이 정보가 들어가면 회원정보 확장 애드온, 포인트 레벨 아이콘 애드온 등이 전체 글 수만큼 루프를 돌려버립니다. 글쓴이 이름이 없어도 모바일 표시 애드온처럼 글 수만큼 루프 돌리는 애드온이 꽤 많습니다.

    3페이지 가져오던 것을 5페이지 가져온다고 큰 문제가 생기지는 않지만, 무제한으로 풀어주면 100페이지로 설정해 놓고 그 위젯 느리다고 툴툴거리는 사용자가 나올 수도 있겠지요. 잘 튜닝된 서버가 아니라면, 그리고 오브젝트 캐시가 없다면... 페이지수를 늘려서 설정을 저장하는 순간 아예 접속이 불가능할 정도로 심하게 느려질 수도 있어요. 성능과 안정성을 보장할 수 있는 범위 내에서만 기능을 제공하는 것은 개발자 입장에서는 현명한 판단인 것 같습니다.

  • 웹지기 글쓴이 2018.07.04 12:53:13
    저는 페이지만 그렇게 하는 것이 이상해 보입니다. 1페이지에 많은 목록수도 문제가 될 겁니다.

    그런데 페이지를 제한하는 것은 곱하기가 되기 때문에 개발자가 그걸 미리 막아준다는건 좀 오버로 다가옵니다.

    성능을 고려해서 쓰는건 사용자가 고려해야죠.

    그런 논리라면 목록수 자체도 제한해서 만들어야 할 것 같습니다.
  • 기진곰 2018.07.04 12:57:16
    @웹지기
    목록수가 너무 많으면 바로 눈에 띄니까 현실적으로 수십 개 이상 불러오는 사람이 드물지만, 페이지수는 별 생각 없이 큰 값을 입력해 놓기 쉽지요. (실제로 서버 튜닝하다가 발견한 사례입니다... ㅡ.ㅡ)

    물론 말씀하신 위젯 같은 경우는 성능에 대한 고려보다는 그냥 제한해 놓은 것 같습니다.
  • 웹지기 글쓴이 2018.07.04 13:14:52
    @기진곰
    네. 맞습니다. 지금 주신 댓글이 핵심을 담고 있습니다. 제가 하고 싶은 이야기는 그냥 제한해 놓는게 속편하다 라는 식의 제한은 옳지 않다는 것이죠.

    목록수 너무 많은 욕심을 내는 케이스를 제가 이야기 해본다면
    y축에 스크롤을 많들어내는 이유가 이 욕심 때문입니다. 페이지수와 다를게 없죠. 거기에 목록수를 말씀하신 비현실적인 숫자를 시도하는 사람이 나오겠죠.

    이거 막자고 목록수를 제한하는건 쉽지 않은 이야기죠.

    페이지수도 마찬가지인데 개발자분마다 다른 생각이시지만 이렇게 1,2,3 중에 고르는 것을 선택하는 건 개발자의 신념이 들어간 것으로 보여집니다.

    목록수,페이지수 에 대한 성능이슈를 방지하려는 무언가를 하고 싶다면 옵션값을 입력 받는 곳에서 고지가 있으면 더 좋다고 봅니다.

    그리고 이 값을 제한하고 싶다면 일정 수 이상은 입력이 안되게 한다던지의 과도한 부분을 막아주고 나머지는 정상적인 사고를 가진 운영자라는 가설로 운영자에게 맡겨야 한다고 봅니다.

    말씀 하셨듯이 "그냥 제한해 놓은 것 같습니다." 의 결과가
    오히려 목록수를 많이 줄이고 정보 제공량은 원하는 사람에게는 충분히 제공하고자 하는(결과적으로는 성능은 똑같은) 의도를 가진 대부분의 운영자들이 이부분에서 한번쯤 왜 이렇게 해놓았지? 라는 의문을 가지게 된다는 것이죠.

    기진곰님의 이야기와 제 이야기가 크게 다르지 않다는 것은 저도 공감하고 아마 기진곰님도 공감하실 수 있을 것 같습니다.
  • profile
    YJSoft 2018.07.04 21:22:07

    깊게 생각하실 필요 없습니다. 신념 같은게 담긴게 아니라, 그냥 "이쯤이면 충분하겠지"란 생각에서 그이상을 대응해서 개발하지 않은 것일 뿐입니다.

  • profile
    엔데벨 2018.07.05 03:21:02
    YJSoft 님 말씀이 정답인것 같습니다ㅋㅋㅋ

    개발자의 신념을 언급한다면 수치를 한정적으로 제한하는게 아니라, 오히려 수치를 양껏 설정할 수 있도록 하고, 입력된 수치가 적용되어도 버벅거리지 않도록 최적화까지 잘 해서 배포하겠죠.

    제가 보기엔 그냥 귀찮아서(...) 적당하다고 생각되는 수치를 지정해 둔 것 같습니다.
    많이 사용해도 5페이지 정도고, 대부분은 3페이지로 설정되어 있기 때문에 그정도 수치를 적당하다 판단한것 같구요,
    저 위젯의 작동방식은 모르겠지만, 입력받고, 큰 값이 들어갈걸 고려해서 최적화도 빡세게 해야하고....

    그냥 귀찮은게 아닐까요ㅋㅋㅋㅋ
    개발자로서는 제대로 만들고 싶지만, 작업 시간 대비 얻는 이득도 적고.... 현실과 타협한 마인드...?

서버에 요청 중입니다. 잠시만 기다려 주십시오...