Admin 회고

#1 Admin

커뮤니케이션의 중요성과 응집도와 결합도의 중요성 사이드 이펙트 등 많은 부분을 느끼게 해준 admin 회고입니다.

 

admin 개발이 된 것을 받았을 때 기존 기획서에 있지만 누락된 요소들이 너무 많았고, 개발자는 기획자가 기획한 것을 보지 않고 개발했다는 말도 함께 들었고 client와 비교했을 때 빠르게 개발하다보니 여러 문제가 있다는 말도 함께 들었습니다.

 

그래도 관리자 입장에서 admin은 필요하기에 개발을 하다가 이런 부분은 정리하면 좋겠다 싶은 부분을 정리해보고자 글을 써봅니다.

#1 문제

Front는 서버에 저장되어 있는 모든 데이터를 요청한 후 필요한 데이터를 뽑아 사용하는 방식으로 되어 있었습니다.

ex) fetch API로 프로젝트 생성, 수정, 삭제를 모두 하고있습니다.

 

그래서 나오는 문제점은 결합도가 너무 심하게 되어 있어 백엔드 api에서 제공하는 데이터를 수정했을 경우에 사이드 이펙트가 너무 심하게 나고 있었습니다.

 

사실 admin은 기획서와 개발되어 있는 방식이 달랐고 (기획서에 존재하는 기능이 없거나, 누락된 기능들이 있었음) 기능은 되지만 사용자 입장에서 사용하기 불편한 점이 너무나 많다고 느꼈습니다.

 

최초 서버에 요청하는 Front api를 확인했을 때 요청하는 api들이 잘 정리가 되어 있어 restFul하게 잘 되어 있는 것 처럼 보였습니다.

 

 

또한 전임 개발자 분께서 실력이 신입인 저보다 좋다고 들었기 때문에 admin 구조에는 문제가 없을거라고 생각했습니다.

 

그래서 기획서에 있지만 누락된 요소들과 사용자 입장에서 불편한 요소들을 수정하고 그 부분에 초점을 맞춰 task를 분류하고 작업을 진행하려고 했습니다.

 

그러나 분류된 api는 쓰임새에 맞춰 사용하고 있지 않았고, 하나의 api를 요청할 때 마다 다양한 정보들을 가져오는 것을 확인할 수 있었습니다.

 

 

#2 문제의 대한 생각

이 방식은 현재 개발을 할 땐 편할지 몰라도 장기적인 측면으로 봤을 땐, 주먹구구식으로 개발이 되어 있다고 느껴졌습니다.

 

이렇게 정리가 되어 있지 않은 상태에서 기능을  추가하거나 삭제하면 언젠가는 문제가 생길 것이라는 생각이 들었기 때문입니다.

 

현재 admin이 갖고 있는 문제를 덮고 개발은 할 수 있지만 추후 누군가는 admin을 정리해야만 합니다.

 

처음에는 아예 갈아 엎어야 한다는 생각에 의견 전달 후, 멈추고 싶다는 생각이 강하게 들었지만 이것도 경험이라 생각하고 최대한 고칠 수 있는 부분은 고치면서 개발을 해 나가야 된다고 결론을 내렸습니다.

 

그렇지만 나중에 제가 프로젝트 구조 설계를 할 때에는 이러한 부분을 깨닫고 의사소통을 통해 제대로 된 프로젝트를 만들 수 있다는 생각을 하였습니다.

#3 이러한 문제를 방지하려면

1. 프로젝트의 컨셉(목적)을 파악하자

  - 명확한 목적이 없으면 방향을 잃기 쉽고 결국 시간이 없어 주먹구구식 개발이 될 가능성이 높아질 수 있습니다.

 

2. 기능의 용도와 쓰임새를 정확히 파악하자

  - 용도와 쓰임새를 모르면 어떤 정보가 필요하고 필요 없는지 구별할 수 없습니다.

 

3. 어느 한쪽으로 치우쳐지지 않도록 비중을 나눠야 한다.

  - 백엔드 메커니즘을 알아야 비중을 나누는데 용이할 것 같습니다. (적극적인 커뮤니케이션 !)

  - restFul한 api를 위한 노력을 하는 것이 좋을 것 같습니다.

  - pure function을 사용함으로써 코드의 복잡성을 줄여야 할 것 같습니다.

    (함수형 프로그래밍은 함수를 중심으로 side-effect가 없도록 프로그래밍 하는 것인데 여기서 말하는 함수가 pure function)

    (즉, pure function은 외부 상태에 의존적이지 않고,

     어떠한 사이드 이펙트도 발생시키지 않는 함수이며 언제 호출해도 항상 같은 input에 대해 같은 output을 반환하는 것을 말합니다.)

 

#4 배운점

1. 프론트 또는 백엔드 중 어느 한쪽으로 기능이 몰리게 되면 유지보수가 힘들어질 수 있다는 점을 알았습니다.

 

2. 코드의 결합도가 높을 때, 복잡성도 함께 높아진다는 점을 알 수 있었습니다. (유지보수에 리소스도 같이 많이 들어갑니다)

  - interface를 설계할 때, 최대한 한 모듈안에 다양한 interface가 들어가지 않도록 작성해야 한다고 생각했습니다.

 

3. admin - client - studio (각각의 프로젝트) 가 어떻게 동작될 지 이해할 수 있었습니다.

 

4. resful API의 중요성을 알 수 있었습니다.

(restFul : rest를 rest답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것은 아니지만 REST 원리를 정확히 따르는 시스템)

 ex) crud 기능을 모두 post로만 처리하는 api

 ex) route에 resource, id 외의 정보가 들어가는 경우 (/student/updateName)