[ToyProject] '오늘옷때' 시연

[시연 영상] - 소리 x

bandicam 2023-01-16 09-16-01-392.mp4

13.87MB

 

 

 

 

---

[관련 시연 PPT]

https://www.canva.com/design/DAFVQjKcUn8/WV4rCd65-d5x0o01yy-N8Q/view?utm_content=DAFVQjKcUn8&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton 

 

 

 

 

 

---

[마무리 및 회고]

이번 프로젝트는 스프링을 배우기 전 JSP를 마무리하면서 진행된 프로젝트이다. 

 

느낀점

1. 막막함

• 배운 것만으로 웹 사이트를 구현하기엔 부족한 부분이 너무 많았다. 특히, CSS 적인 것이 매우 부족했는데 이점을 보충하기 위해 따로 부트스트랩을 공부한 뒤 적용 시켜 보았다. 5일이란 짧은 기간에 모든 것을 손수 만들기엔 힘들 것이라 판단하여 기반이 되는 템플릿을 복사한 후 여러 템플릿을 참고하며 하나의 프로젝트 안으로 흡수 시켰다.

2. 이게 되네

• 처음 써보는 CSS와 처음 접해보는 공공 API는 막막했지만 하루 이틀이 지나니 윤곽이 나오고 적용이 가능했다. 기본적인 CRUD는 당연히 구현이 가능했는데, 멋진 CSS를 입히니 예상보다 꽤 괜찮은 퀄리티의 웹사이트를 만들 수 있었다.

3. 성취감

• 아마 처음 코딩을 시작한 사람들은 공감할 것이다. "Hello World!"를 콘솔창에 띄우는 짜릿함을!! 그때와 비슷한 짜릿함이었다. 막막했던 처음을 지나고 웹 창에 처음 띄울 때, 사람들에게 내 프로젝트를 공개할 때의 성취감은 내가 앞으로 코딩을 하는 길에 중요한 원동력이 될 것 같다.

4. 기대감

• JSP는 스프링에 비해 불편한 점과 구현이 힘든 점이 많다. 현재 스프링을 배우는 시점에서 당시 JSP 코드를 뜯어보면, 1줄이면 될 것이 JSP에서는 10줄이 넘어가기도 한다. 그리고, 여러 연계 프로그램을 통해(ajax, dependency 등등) 토이프로젝트보다 더 나은 웹사이트를 만들 수 있다는 것에 기대감을 가진다.

보안사항

1. 요구사항을 상세하게 구성해야 한다.

• 이전 포스팅에서 요구사항 분석을 만들어봤는데 도움이 되는 부분이 많았다. 파트를 나누고 전체적인 약속을 정하고, 우선순위를 나눈 덕에 프로젝트가 수월하게 진행 될 수 있었다. 
• 하지만, 처음 만들어본 요구사항인 만큼 부족한 부분도 여럿 있었다.
  • 약속을 상세히 구체화 하지 않았다.
    • JSP를 구성할때 파일 이름을 정하는 방식을 따로 표기하지 않았다. 그래서 JSP 파일의 이름이 중구난방이었고, 추후에 파일들의 이름을 틀리는 자잘한 실수를 하게 됐다. 
  • 예정에 없던 것을 구현할 때 분석을 하지 않았다.
    • 요구사항에는 게시판을 만드는 것이 계획에 없었다. 그렇기 때문에 게시판의 기능여부 // 사용자 관점에서의 게시판 분석 // 등의 고민을 하지않고 바로 만들게 됐다. 설계도가 없는 게시판은 같은 CRUD를 구현하는 것이지만 시간이 배로 걸렸고, 기능 또한 정립이 제대로 되지 않았다. 
    • 예정에 없던 것을 구현할 때도 충분한 회의를 거쳐야 할 것이고, 요구사항 분석을 다시 구성하는 것이 필수 일 것 같다. 즉, 요구사항 분석이 프로젝트 초창기에만 진행되는 것이 아닌 중반 후반기에도 계속 수정되야 한다.

2. 임무분담을 확실하게 나눌 것

• 이번 프로젝트는 '나'는 주로 프론트 적 요소와 DB 및 전체적인 기반 작성(DAO//DTO 구성)을 맡았고, 다른 조원은 백엔드 적 요소를 맡았다. 분담이 잘된 만큼 조원이 백엔드적 기능을 구현하면 CSS를 입히고, 기능을 추가하는 것이 수월했다. 덕분에 다른 조에 비해 빠르게 만들게 되었고, 게시판까지 추가 구현을 할 수 있었다.
• 다음 프로젝트 혹은 현업에서는 팀원이 4명~10명 20명이 될 수 있을 것이다. 이렇게 많은 사람들과 협업을 하게 될때 임무분담을 확실하게 나눠 효율적인 프로젝트를 진행할 수 있어야 할 것이다.

3. 수정사항이 있을 경우 빠른 공유 필수

• DB 반영 쿼리문을 수정하고 백엔드 파트인 조원에게 알리는 것을 깜박한 적이 있었다. 같은 공간안에 있을때는 "이거이거 수정됐어요" 라고 바로바로 말할 수 있으나, 주말에 작업하다보니 메신저를 보내는 것을 잊은 것이다. 공유받지 못한 조원은 이전 쿼리문으로 백엔드 작업을 진행했고, 추후에 완성됐을 때 내가 원했던 쿼리대로 나오지 않아 당황했었다.
• 이처럼, 수정사항이 있을 경우 "어디어디 수정 완료"와 같은 것을 프로젝트보드 or 단톡방에 바로바로 알릴 필요가 있다. 

4. 총괄 임무자의 필요성

• 전체적인 구성을 알고 백엔드와 프론트엔드를 모두 융화시킬 수 있는 총괄 임무자가 필요할 것 같다. 앞으로 프로젝트에서 각자 특화된 파트를 프로젝트에서 맡게 될 것 이다. 내 파트에는 전문간 처럼 알 수 있겠지만 다른 파트는 까막눈일 수 있다. 
• 즉, 나무를 보는 인원들이 아닌 숲을 볼 수 있는 인원이 다른 인원들을 종합하고 다시 지시내리는 총괄 업무를 맡는다면, 프로젝트가 수월하게 굴러갈 것이다.

5.깃허브 마스터하기

• 3번과 이어지는 내용이다. 깃허브로 내용을 공유한다면 어느부분이 수정되었는지 바로 알 수 있다. 만약 깃허브를 자유롭게 사용할 줄 알았다면 3번과 같은 일이 발생하지 않았을 것이다.