2023/04/13 TIL

[MultiIt Backend]

서론

어제 느낀 팀원들의 진행 속도와, 프로젝트의 이해에 대한 전반적인 부분을 챙기기 위해 전체의 이야기를 들어보려고 노력했다. 이야기 결과 전반적으로 api 설계 자체를 너무 빠르게 지나간거같아, 전체 기능에 대해 이야기하며(입개발 느낌~)  기능 로직 정리 + api 설계 느낌으로 진행하는 것이 좋다 판단하고 이 과정으로 하루 회의를 진행하였다. 조금 돌아가더라도 개인적으로는 확실히 설계를 잘 작성하고, 이해해야 그만큼 뒤의 과정 (실 개발과정, 테스트, 배포..)이 원할하고 더 좋은 퀄리티로 진행 될 수 있다 생각한다. 그렇기에 오히려 팀원 모두 우리 프로젝트에 대한 이해를 탄탄히 챙긴다 생각하고 진행하니 진짜 쉬는 시간없이 풀로 채워서 회의를 하는데도 모두 집중하며 기능 정리를 할 수 있었다. 잘 마친후 오늘은, 어제를 반성하는 마음을 담아 정처기 공부를 하고, 프로젝트 회의자체도 집중해서 좋은 방향으로 진행 됬다는게 많이 스스로 성취감을 느낄 수 있었다. 진짜 이 성취를 잊지말고 프로젝트를 잘 마치고, 곧 있을 정처기도 실기도 잘 준비해 한방에 합격할 수 있게 더 노력해야겠다!  

---

오늘 하루 진행 내용

전체 프로젝트의 기능에 대해 논리적으로 생각해보며 입개발을 위주로 정리하는데 시간을 많이 보냈다. 어제 진행했던, api 설계의 경우, 처음에 기능 정의서를 바탕으로 api를 설계하다보니,여러곳에서 사용되는 공통기능이 있는 경우 분류가 애매하다는 이야기가 나왔다. 이런걸 방지하기 위해 api는 기능이 주 우선이니, erd와 와이어프레임을 보면서 기능을 분류하는 과정을 먼저 진행했다. 그런 과정을 통해 우리가 만들고자 하는 기능 사이에서 우선적으로 모든 부분에 영향을 주는 (피드, 사용자) 엔티티와 그 관련 기능들에 대해 이야기하고 수정하는 시간을 많이 가졌다. 그 후 완성된 기능 분류서를 가지고 엑셀을 통해 api를 작성하는 것은, 가시적으로 좋지 않다 판단해 팀원들에게 postman을 통해 request와 restful하게 api를 짜는 걸 제시했고 이 의견이 받아 들여져 api 작성을 기능별로 나눠 완료하였다. (+ swagger을 사용하는 방법도 있지만 팀 단위의 작업이고, 서로 연관된 기능이 많기에 가시적으로 깔끔하고 관리가 편한 postman이 더 좋다 생각 -> 또한 우리 팀은 우선적으로 백엔드 개발에 집중할 예정이라 controller가 잘 동작하는지 확인하기 위한 도구가 필요하다 생각했고(프론트는 어느정도의 기능 구현 후 제작할 예정) 초심자에겐 swagger보다 postman이 적합하다고 생각했다.) 또한 그렇게 정규 회의 시간을 마친 후 정보처리기사 학습을 진행하였다.(현 7장까지 완료)

 

<진행 사항>

1.기능 분류서, 2. postman을 통한 api 설계 완료(response는 따로 정리 예정), 정처기 학습

---

느낀점

오늘은 소통의 중요성을 한번 더 느꼈다. 확실히 어제 생각했던 스스로 부족했던 점을 보완하기 위해, 실제로 다시 기능 분류 및 api 설계를 다시 진행했고 그 과정안에서 팀원들에게 한 부분이 끝날 때마다 현재 진행 속도나, 이야기하고 있는 기능들의 이해정도에대해 계속 체크하였다. 그렇게 먼저 우선적으로 대화를 이끌고 물어보고, 서로 의견을 공유하다보니 서로 다르다 생각한 부분이나, 기능에 대해 어떤식으로 구현해야 될지 감이 안잡히던 부분을 어느정도 파악할 수 있게 되었다고  한번 더 회의하고 지나간것이 도움이 되었다는 전반적인 팀원들의 의견을 들을 수 있었다. 이를 보고 나는 아무리 프로젝트를 진행 시, 이런 설계 부분에서 속도가 빠르더라도, 실질적으로 팀원 모두가 전체적인 설계된 내용을 이해하고 파악해야지 실제 개발 진행 단계에서 각자 자신이 맡은 모듈을 잘 개발하고, 전체적으로 그 모듈들을 통합했을때  잘 연결이 되 실질적으로 서비스들이 잘 동작될 수 있겠다는 생각도 들었다.(이 부분은 실제 개발이 진행된 후 한번 더 느껴보고.. 내 생각이 확신으로 변할 수 있을 듯?) 또한 진짜 이건 좀 신기했던게 정처기 필기를 볼때 공부했던 부분들이 그냥 이런 지식이구나 하고 넘어갔는데, 실제 프로젝트 개발을 위한 설계를 진행하다보니 생각보다 관련 지식들이 많이 사용되는 것 같았다. 또한 

실기를 준비하며 복습 및 추가 공부를 하며, 다이어그램이나, ui 작성 및 다양한 부분에서 프로젝트에 도움이 될만한 정보도 많이 얻을 수 있었다. 이를 통해 이론을 실제 프로젝트에 잘 적용하면, 좋은 설계 및 개발이 가능하다는 것을 느끼고, 이론이라고 외운 후 넘어가는 것이 아닌 이론과 연관된 실습이나, 실제 활용 방법들을 생각해 학습하는 것으로 방향을 잡는 것이 더욱 큰 학습효과를 얻을 것 같다고 생각도 들었다. (-> 이를 적용하기 위해, 이론에 대해 학습하고 관련된 부분을 실습하는 = [jpa 이론 학습 및 정리-> jpa를 통한 간단한 게시판 프로젝트] 방향으로 나의 공부 방향을 정해볼까 생각함 )

마지막으로 실제 api를 작성하며 restful한 api에 대한 표준 방식? 과 예시를 찾아보며 최대한 restful api를 지향하며 작성하다보니  이런 api 작성의 중요성에 대해 느낄 수 있었다.

---

배운점

프로젝트안의 진행 속도도 물론 중요하지만 그보다 추후의 전체 서비스 로직의 연결과(모듈 통합 후), 개발 과정에서의 안정적인 흐름을 위해서는 같은 서비스를 개발하는 팀원 전체의 우리 프로젝트의 전체적인 로직을 이해하는 것의 중요성에 대해 배울 수 있었다. (만약 이런 설계 과정에서 잘 파악하지 못하면, 추후 개발 및 테스트 때 에러로 인해 처음부터 다시 모든걸 진행해야 할 수 도 있음..)  또한 RESTful API에 규칙, 예시, 사용이유 등 전반적인 부분 대해 좀 많이 배울 수 있었다. 

 

---

+ 개념 & 용어 

* RESTful API : REST를 기반으로 만들어진 API

REST : 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미

REST API(REST의 원리를 따르는 API) 설계 예시

1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.

    ex) http://cutecatjyu-coding/Running/              -> BAD

          http://cutecatjyu-coding/run/                      -> GOOD

2. 마지막에 슬래시 (/)를 포함하지 않는다.

    ex) http://cutecatjyu-coding/test/                     -> BAD

          http://cutecatjyu-coding/test                      -> GOOD

3. 언더바 대신 하이폰을 사용한다.

    ex) http://cutecatjyu-coding/test_code            -> BAD

          http://cutecatjyu-coding/test-code             -> GOOD

4.  파일확장자는 URI에 포함하지 않는다.

    ex) http://cutecatjyu-coding/image.jpg            -> BAD

          http://cutecatjyu-coding/image                  -> GOOD

5. 행위를 포함하지 않는다.

    ex) http://cutecatjyu-coding/delete-post/1        -> BAD

          http://cutecatjyu-coding/post/1                   -> GOOD  (Method - DELETE)

 

즉 RESTFUL이란 REST의 원리를 따르는 시스템을 의미

-> 하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아니다.  

       REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며

       모든 CRUD 기능을 POST로 처리 하는 API

       혹은 URI 규칙을 올바르게 지키지 않은 API는 

       REST API의 설계 규칙을 올바르게 지키지 못한 시스템은

       REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있다.