AdminBoard 라이브러리 만들기 - 1

들어가기 전에

기존에 OurBoard 라는 이름의 라이브러리를 만들어보면서 연습한 적이 있습니다.

간단히 OurBoard 라이브러리에 대해 설명을 드리자면 Django의 admin 라이브러리의 역할을 해주는 Spring용 admin 라이브러리라고 생각하시면 됩니다.

여러가지의 효용성을 이 라이브러리를 만들면서 높이고 싶었는데

- Django를 Spring보다 먼저 시작하는 이유는 배움의 시작이 더 쉽기 때문이 아닐까?

- Java보다는 Python을 익히면서 개발하는 것이 좀 더 편하기 때문이지 않을까?

- Django에서는 admin을 통해서 데이터베이스의 데이터를 조회하거나 확인하고, 기본적인 CRUD, Sorting, Filtering 을 제공
해주다보니 대시보드를 따로 개발자가 만들지 않아도 되서 편리하겠다.

- SQL을 잘 모르는 마케터, 기획자에게는 데이터를 확인하고 시각화할 때 유용하게 사용할 수 있겠다.

 

이러한 생각을 통해 OurBoard 라이브러리를 제작하게 된 것 같습니다.

허나 라이브러리를 만드는 자체가 어려움이 많았습니다. 라이브러리를 만들면서 가장 처음 생각이 든 것은 일단 죽이 되든 밥이 되든 개발을 해서 결과를 내보자 라는 생각이었습니다. 허나 개발을 하면서, 개발을 하고 나서 든 생각이 아래의 생각들입니다.

 

- Spring으로 기본적인 웹을 만드는 것이 아닌 다른 개발자가 사용할 수 있도록 개발을 해야 하다보니 Bean이 중복되는 문제점을 어떻게 해결해야 될까?

- 어떤 기능들만을 Public으로 풀어줘야 할까?

- 기존에 사용하던 라이브러리에는 Lombok을 잘 사용하지 않는 것 같은데.. Builder Pattern도 잘 사용하지 않는 것 같은데 Lombok의 @Builder 를 사용하면 안될까?

- EnableAdminBoard 를 통해서 Reflection에 필요한 package의 경로를 가져올 때 문제가 될 것 같은데.. 만약 멀티모듈이라 package의 경로를 여러개 등록해야하는 경우에는 어떻게 처리해야될까? 현재 로직에는 Bean의 목록을 가져와 첫번째 Bean의 package 경로를 등록했는데 이거 무조건 문제가 생길 것 같은데..

- 처음의 컨셉은 DriverManager를 통해 DB Connection 객체를 가져온 뒤에 쿼리를 날림으로써 기능을 만들고자 했는데 DB Connection 객체를 언제 해제하고 언제 연결을 해야할지 (메모리 관점) 고민이 되었고, 이후에 Reflection을 통해서 개발(리팩토링)을 했는데 이 또한 예외적인 상황이 많더라... (JpaRepository에만 한정되는 문제, Entity에 annotation들이 기존에 붙어져 있는 경우 예외없이 해결이 될 것인가?)

- 라이브러리의 용량이 너무 큰데.. 이걸 줄일 수 있는 방법이 있을까?

- 오픈소스의 기능으로서 역할을 하려면 다른 개발자들이 쉽게 확인할 수 있는 가독성이 높은 코드로 개발이 되어야 했는데 너무 더러운(스파게티) 코드처럼 덕지덕지 개발이 된 것 같다... 기능개발에만 포커스를 두어서...

 

 

"    다시 만들자!    "

 

 

 

네엡..! 기존의 라이브러리를 리팩토링 하면서 다시 구현을 해보기로 했습니다.

위에서 고려할 사항들, 고민했던 사항들을 생각하면서 개발을 할 생각입니다.

한번 연습은 해보았으니 다시 한번 개발해 보는 것으로 결론을 내리게 되었습니다.

 

 

1. 개발 고려 사항

이번에 다시 라이브러리를 만들면서 고려할 사항입니다.

물론 모든 부분들을 다 지키기는 힘들 수 있습니다. 놓치는 경우도 생길 수 있고요! 허나 개발 고려 사항을 작성하면서 개발하는 동안 이 사항들을 생각하면서 최대한 지킬 수 있도록 개발을 할 예정입니다.

 

1.1 사용자(라이브러리를 사용하는 개발자) 관점

• Method와 Class의 이름을 직관적으로 지어보자.
• 대시보드 특성상 보여주고 싶지 않은 데이터, 또는 설명이 필요하니 annotation을 통해 적극적으로 내용을 담을 수 있도록 제공하자.
• 라이브러리의 용량을 최대한 가볍게 만들어보자.
• 개발자가 이 라이브러리를 쓰기 위해 준비하는 과정에서 작성하는 코드의 양을 최대한으로 줄이자.

 

1.2 사용자(라이브러리를 사용하는 기획자, 마케터) 관점

• 대시보드에서 사용할 수 있는 기능들의 권한을 설정할 수 있도록 하자.
• 일단 UI의 가독성을 높이자. -> 개발자 특성상... 제대로된 UI를 구성하지는 못하더라도 사용하는데 불편함이 없을 정도는 만들자.
• 데이터를 불러오고 변경하는 시간을 줄이자.

 

1.3 같이 개발하는 개발자 관점

• 코드를 일단 가독성 있게 구성하자.
• 문서화를 하자.

 

 

2. 개발 준비

2.1 멀티모듈

멀티모듈을 적용해 볼 생각입니다. 멀티모듈을 적용하는 이유는 기존의 라이브러리를 개발하는 과정에서 많은 패키지들이 분산되어있다는 점과 개발을 하면서 패키징이 제대로 되지 않아 개발의 능률이 떨어졌습니다.

멀티모듈을 적용할 생각이고 모듈은 아래의 항목으로 구성할 생각입니다.

• admin-board-core 
  • Domain 
  • Repository
  • Site : 외부 개발자가 사용할 때 생성하는 Class가 정의되어 있습니다.
• admin-board-view
  • 화면을 담당하는 모듈입니다.
  • Controller
  • HTML, CSS, JS -> Vue.js
• admin-board-api
  • api가 naming에 들어가있지만 솔직한 역할은 Internal API 역할을 합니다. View에서 event가 발생했을 시 호출되는 API가 있는 모듈입니다.
  • Controller
  • Service
• admin-board-commons
  • 모든 모듈에서 사용이 되는 모듈입니다. (의존성 없이)
  • Exception
  • Log

 

2.2 사용 라이브러리

기본적으로 AOP, Web으로 기본적인 프로젝트를 구성할 예정입니다.

웬만해서 의부모듈 사용을 자제함으로써 의존성을 줄여보자 라는 생각입니다.

 

2.3 배포 툴

JitPack 사용 예정입니다.