Facts
웹 개발 팀 프로젝트를 진행하면서 댓글 CRUD를 맡아서 진행하였다. 기존에 완강했던 웹 개발 종합반 강의를 참고해서 작성, 조회, 삭제까지는 금방 구현했지만 수정하는 데에 시간이 오래 걸렸다. 테스트 페이지를 하나 만들어서 빈 페이지에 댓글이 작성, 조회, 수정, 삭제 되는 것을 확인 후에 만든 웹 페이지에 연결했는데, 이 과정에서 각 게시글의 post id를 기반으로 작성한 댓글을 작성, 조회, 수정, 삭제가 되도록 해야 해서 post_id 를 post 모델에서 생성된 id를 참조하도록 변경했다. 이 변경 과정에서 코드를 다시 고치는 데에 시간이 오래 걸렸고 결과적으로는 수정 기능은 끝까지 구현해내지 못했다.
Feelings
처음 시작했을 때는 기존 웹종 강의와 비슷한 기능이었기 때문에 단계를 잘 밟아가면 해낼 수 있겠다는 생각을 했다. 하지만 단계가 달라지니 새 코드를 짜는 것과 다름이 없어 이내 막막해지기도 했고, 조급해지기도 했다. 전체적으로 부족한 시간과 혼자 헤쳐나가는 느낌 때문에 힘들었던 점이 컸다.
Findings
우선 테스트 페이지를 만들어서 댓글 CRUD를 구현하는 것도 좋지만 기본적으로 완성이 되어야 하니 처음부터 최종 게시판 형태에 연결을 하고자 했다면 더 일이 빨리 끝났을 수도 있겠다는 생각을 했다. 단계가 늘어갈수록 에러 발생 확률이 높아지는.. 당연함. 변수가 늘어나니까.
코드를 적용할 때도 검색해서 적용할 때 잘 모르면서 적용하다보면 꼭 그 부분에서 에러가 나게 되는 것 같다. 시간이 급하지 않았다면 코드를 하나씩 뜯어보면서 검색해가면서 할 수 있었겠지만.. 자바스크립트와 foreign key를 모델에 불러오는 데에서 특히 시행착오를 많이 겪었다. 각 옵션이 어떤 것인지 확실하게 알지 못하고 적용하다보니 YR 튜터님과 코드를 고쳐나갈 때 딱 긴가민가 했던 부분들이 에러의 원인이었다는 것을 알고 무작정 검색한 코드를 적용하는 것의 폐해를 정확히 이해했다.
깃허브 사용도 항상 혼자 푼 코드카타 add & commit & push 만 해보다가 clone과 pull을 써보게 된 점까지는 좋았으나 pull request를 하거나 충돌이 일어나지는 않아서 이 점은 다소 아쉽다. 한 편으로는 다행이지만. 깃허브에 익숙해졌다고 생각했는데 막상 써보니까 쓰던 기능만 쓰고 있어서 아직 능숙해지려면 멀었다는 생각이 들었다.
Future
하다보니 어찌저찌 웹 페이지의 형태가 갖춰지고 기능들이 작동하는 것을 보면서 앞으로 '진짜 홈페이지' 형태를 갖춰 나의 웹 페이지를 만들어보아야겠다는 생각을 했다. 어쨌거나 나는 일부의 기능만 구현해보았기 때문에 아직 JS도 잘 모르겠고 (물론 이건 프론트엔드지만) 데이터베이스의 작동도 어렴풋이만 파악한 것 같아 더 많은 구현을 수행해보아야 할 것 같다. 또 깃허브는 KW 튜터님 말씀대로 계정을 하나 더 만들어서 일부러 충돌을 일으켜보아도 좋을 것 같다.
