후덜덜 아이패드에서 작성하다가 사진찾으러 나가갔다가 와보니 글 쓰던거 다 날라갔네...
기획에대해...
거두 절미하고,
sns 는 단순해 보이지만, 한페이지 안에 많은 개발요소가 존재하기 때문에 기획 단계에서 세심한 배려가 필요하다. 그렇지 않으면 개발자가 자칫 구현해야할 기능을 오해하거나 심지어 개발을 안해버릴수도 있다.
실전에서 문제가 발생한 사례로,
기획자가 나름 디테일하게 정의하는 과정에 초안은 심플했지만,
갈수록 디테일을 추가하다보니 처음 30장이던 기획서가 거의 세배가 되어버렸다.
게다가 기능이 여기저기 엉키다 보니 1페이지에서 못다 기술한 내용이 40, 50 페이지에 나오기도하고
이정도는 예측하겠지 하고, 생략하거나, 카피앤 페이스트로 넘겨버린 뒷페이지에서 혼동을 발생하기도 했다.
내 생각은 이렇다.
큰 기획페이지를 보여주고, 디테일한 기능이 있다면 체크 표시를 해주고 인덱싱을 했더라면 좋았을 것같다.
아래 캡쳐를 예로들어서,
1, 2 는 바보가 아닌 이상 누구나 예상할 수 있다.
3, 4, 5 는 별것 아닌것 같아서 기획자로 기능이 있다고 표시까진 해주지만 사실 개발자 입장에서는 의외로 생각할게 많은 기능이다. 생각이 많이 필요하다는 것은, 성능, 구조 즉 아키텍처와 직결된다.
6,7 은 정말 자세히 명기해주지 않으면 개발자가 모르거나 잘못구현할수 있는 기능이다.
그것도 몰랐냐고 하면 할말없구... ㅋㅋ 난 몰랐으니까능...
A 의 경우도 저런 기능이 있다는 표시만 해놓으면 개발자는 참으로 난감하다.
아키텍처 얘기로 넘어가보자.
3번의 좋아요를 얘로 들어보자.
sns 라는건 개인대 개인의 이슈 드리븐이다. (이건 그냥 내 표현이다.)
기존의 게시판 개발로 생각한다면 굳이 개발할 수 없지는 않겠지만, 역시 뭔가 찜찜하다.
a가 b한테 좋아요를 했는데 관계형 db의 좋아요 테이블에 넣었다 뺐다 해야 할까?
내가 했던 프로젝트에서는 유저 폴더에 파일을 떨구기로 했다 (내 아이디어는 아니었다)
정확히는 좋아요는 아니었고, 알람이나 공지가 왔을 때 그리 하기로 했다.
그러다보니 회원마다의 폴더 생성하는 메카니즘이 회원 가입 시점에 들어가야 했고, 관련 정보를 가져올때 db와 폴더를 같이 조합해야하는 조회 매카니즘이 필요했다. 이건 바른걸까?
내가 처음 제안했던 방식은 회원별 이슈테이블이었다.
똑같이 회원 가입 시점에 회원고유 테이블 생성 메카니즘이 필요했고, 조회시 관련내용을 조합하는 메카니즘이 필요하게된다. 하지만, db-파일 조합 메카니즘과, db-db 조합 메카니즘... 둘중에 후자가 좀더 낫지 않을까?
내가 가장 하고싶은 이야기는 윗부분이다.
그외에 필요했던 몊가지 아키텍처를 붙여본다.
- 데이터 비동기 로딩 처리 (요즘 뭐 많이하는...)
- html 과 js 바인딩 (jstl 없는 바인딩)
- ui 어플리케이션과 api 어플리케이션 분리
- java web restful service
-node.js 로 알람, 채팅 실시간 양방향 처리
이정도...
다음에는 아키텍처 그림 몇장을 넣어볼까한다.
댓글 없음:
댓글 쓰기