[인터넷프로그래밍] 프로젝트 DUKJOB 회고
[인터넷프로그래밍]
11/11 ~ 12/11(발표일)
장고 웹 개발 약 3주~ 한 달 동안의 팀프로젝트가 종료되었다.
0. 팀장의 역할
1. UI/UX의 차이
심사위원의 피드백 중 UI는 깔끔하나, UX를 고려하지 못했다는 평이 있었다.
나는 실제로 외관상의 인터페이스 디자인과 사용자 경험을 분리하여 고려하지 않았다.
UX/UI 디자인의 차이점은 무엇일까요?
UX 디자인은 '사용자 경험 디자인' 이라는 용어를 말하며,
UI는 '사용자 인터페이스 디자인'을 나타냅니다.
UI와 UX의 차이를 체감했으며, 이젠 단순히 돌아가는(잘 작동하는) 프로그램에서 나아가 그 본질과 유의함에 신경을 써야겠다는 생각을 하게 되었다.
2. 왜?
'왜 그렇게 구현해? 굳이 그렇게 한 이유가 뭐야?' 라는 질문을 스스로에게 던지며 구현해야겠다는 생각이 들었다. 나는 평소에도 "왜"라는 질문을 잘 던지는 인간이지만, 여태 개발에 있어서는 완성도를 기대하기보다 완성이 되기만 하면 된다는 마인드가 강했다. 그래서 "왜"라고 질문하기보다 일단 작동하는 기능부터 만들어왔다. 내 수준에는 그게 옳은 방향이라고 생각했었다. 그러나, 이젠 그럴 시기가 지난 것 같다. 평소의 나처럼 개발에 있어서도 구현의 당위성을 입증할 수 있게끔 생각하며 개발하자. 그래야 결과물에 대한 질문을 받았을 때도 잘 대답할 수 있다.
3. 모델 테이블 설계
최적의 테이블 설계는 무엇이었을까? 사실 scrap 테이블을 중간테이블로 따로 구현했는데, 그냥 user 모델에 post.pk를 외래키로 가져와서 enum값으로 저장해 스크랩 여부를 확인하는 필드를 만드는 편이 나았을 것 같다. 애초에 scrap 테이블이 pk, user.pk, post.pk 구성이라 디비에 저장될 때도 모양새가 이상했다... 만들고서 보니 이딴 테이블을 왜 만들었지 싶은... 모델에 대한 이해도가 부족한 것 같다. 스크랩 내역을 불러올 때도 user.pk, post.pk가 동시 일치하는 객체가 있는지 확인하고 불러왔으며 여러모로 코드도 길어지고 불필요한 함수 때문에 views.py는 길어지고 불편했다. 이래서 설계가 중요하다고 하는구나!
+)12/18
다시 생각해보니 아직도 스크랩을 설계하는 가장 좋은 방법이 뭐였을지 모르겠다. 우리야 테스트용 웹개발이나 다름없으니 어떻게 설계하든 큰 차이가 없었지만, 실제 설계에서 테이블 분리를 어떻게 하는 게 좋았을지 그 기준을 모르겠다. erd cloud에서 당근마켓 클론 설계한 것을 보니 우리와 같은 방식이던데 이게 맞는 걸까?
