간단한 취미생활 뿐만 아니라 전공과 관련된 학습 역시 수업, 개인적인
공부를 통해 의문을 해소하기 힘든 경우가 많다. 취미 생활의 경우, 교내에
동아리라는 시스템이 있지만, 가볍게 배우고 취미생활을 즐기고 싶은 학생은
한 학기 동안 꾸준한 참여를 요구하는 동아리가 부담으로 다가 올 수도 있다.
또한 학교에서는 학습능력 증진, 유대감 등을 목적으로 튜터링 프로그램을
진행하고 있다. 그러나 현재 학교에서 진행하는 튜터링은 기간, 인원이
제한적이며, 한정된 부분에서만 진행이 가능하다.
위의 생각에서 비롯되어 교내 학생들이 자유롭게 이용하고 참여 할 수 있는
멘토링 플랫폼을 제작 하기로 마음을 먹었다.
추가로 본인 역시 복수전공을 하면서 공부하는데 어려웠던 경험이 떠올라서
해당 아이디어에 대해 긍정적으로 받아들이며 열심히 회의 했던 기억이 난다.
프로젝트가 6월 13일 학술제를 끝으로 마무리되었다.
처음 회의 때는 나름 부푼 꿈을 가지고 '이것도 구현하자 이렇게 하자' 라고
말을 했었지만, 프로젝트가 진행 될수록 실력의 부족함과 처음 해보는
협업 프로젝트의 한계에 부딪혔다. 결국 줄이고 줄여서 '반드시 이건 구현하자'
했던 핵심 기능만을 구현했다.
혼자서 토이프로젝트를 할 때와는 다르게, 사소한 것 하나까지 모두 의논이 되어야 하고, 모두가 인지를 하고 있어야 한다는걸 크게 깨닫고, 어렵다는 것을 느꼈다.
깃허브 브랜치라는 기능을 처음으로 제대로 써보기도 하고, 나만 알아보는 코드가 아닌, 협업이기에 늘 가지고 있던 나름의 철학인 ‘가독성 좋은 코드’에 대해 한 번 더 고민하고 이를 실천하고자 노력 했으나 쉽지 않았다.
스프링 프레임워크를 이전에 간단히 경험만 해본 정도였고, 프로젝트에 적용 해본 것은 처음이었다. 다양한 라이브러리를 사용하고 오류등을 경험하며 공식문서 뿐만 아니라 여러 블로그 등을 통해 해결하는 능력을 기를 수 있게 된 점이 가장 뿌듯하다.
마지막으로, 개발 공부에 대한 방향성 고민이 많았는데, 프로젝트를 경험하며 기술을 경험하고 공부하며, 그와 관련된 다른 기술을 공부 할 게 생기는 것을 보며 방향을 잡을 수 있게 되었다.
TDD 하지 못한것
프로젝트 극초반에는 나름의 테스트 코드도 작성하며 진행 했던것 같은데, 시간이 지날수록 시간이 부족하다는 핑계를 대며 테스트코드는 생각도 못하고 무작정 코드 작성을 진행했다. 결국 오류가 나고 고치며 시간을 쏟아 붓는건 매한가지였다. 다음 프로젝트를 할 때는 꼭 테스트 주도 개발을 해볼 것이다.
중복된 코드가 많다.
개발을 혼자서 진행하는게 아니다보니 다른 팀원의 코드를 가져다 쓸 때 같은
코드를 계속해서 복붙하게 되었다. 코드의 길이도 길어지고 가독성이 떨어졌다.
Annotaion에 대해 공부하고 적용하기
디자인패턴에 대해 공부하고 도입하기
지저분한 URL 체계
아무래도 소통이 부족하여 발생된 현상 같다. 기능 구현을 하며 URL은 어떻게
할 것인지 충분한 회의를 거쳤어야 했는데, 하지 못해 지저분한 URL이 나왔다.
ex ) /metoring/room//{room_id}/mentor/posts/view/{id}
URL 체계를 그려보고 RESTful 하게 개발 하기