서버 입장에선 무조건 enum인데 모바일에선 하위 버전과 최신 버전이 공존할 수 있어서, API 상 ENUM 코드에 대한 하위 호환을 유지해주는게 까다롭더라구요. "API 응답 ENUM은 바뀔 수 있으니 항상 하위호환을 고려하세요!"라고 항상 요청하기에도 팀이 자체가 다르거나, 상황에 따라 하위호환이 어려운 상황도 생깁니다. 마지막에 말씀 해주셨듯이 무조건 뭐가 좋다기보단 상황에 따라 유연하게 선택하는게 맞는 듯 해요. 둘 다 애매하다면 DB에 코드를 정의 해두고 이를 Enum으로 변환해서 사용하는 것도 방법 일 듯 합니다. (대신 하위 버전용으로 Enum.UNKNOWN 처리를 추가한다거나) 항상 좋은 영상 감사합니다.
프로젝트 할때마다 팀내 의견이 갈리는 이슈입니다. ㅎㅎ 저는 개인적으로 enum파인데 코드로 관리되니 배포 민감성이 있죠. 요즘은 서버가 가볍게 관리되니 빌드 배포가 빈번하면 enum인데 빌드 배포가 무거우면 db로 가야죠.. db로 가면 문서화는 필수입니다. Common이라는 명명은 프로그램 짤때 최대한 피해야죠. 모든 것을 만족하는 결과는 없습니다. Common이 비대해지면 시간이 지나 분해하기도 어렵고 관리도 까다롭죠. 반면 enum은 복잡해지면 enum을 묶어서 다루거나 패키지 수준에서 분리한다면 복잡성은 관리가능한 수준으로 덜어진다고 봅니다.
공통코드 쓰는건 보통 운영자(백오피스 사용자)가 필요시 개발팀 배포요청없이 기능변경의 유용함은 있겠으니 프로젝트마다 사용방식은 그러려니 하겠습니다. 다만 개발자 입장에선 이넘으로 관리하는게 더 좋은거같아여 ㅠ 근데 공통코드와 이넘을 동시에 쓰는 케이스는 어떻게 생각하시나요? 여기같은 경우가 그리 되있는데. 공통코드변경시마다 이넘도 바꿔야하며, 심지어 어떤 이넘은 공통코드랑 매칭이 안 되는 경우처럼 따로국밥 사례들이 생겨서 이게 좀 힘드네요 ㅠ
@nonon9418 님이 적어주신 것 같은 상황을 말합니다 :D 추상적으로 자주 쓰는 표현인데 처음엔 common 으로 깔끔하게 시작했지만 잡다한 것들이 다 common 에 들어와서 A를 고치면 B가 터지고 B를 고치면 C가 터지는 그런 우울한 상황을 상상하며 쓰는 표현입니다 :D
저는 가급적 공통 모듈을 만들지는 않습니다! 로깅 같은 경우는 기능 모듈로써 분리하는 편이고, Exception 이나 에러는 최대한 그 모듈에서 순수하게 제공하려합니다 (물론 공통의 니즈가 있을 순 있으나, 공통 자체의 범위를 전역으로 잘 안두는 것 같습니다) 그치만 정말 정말 비대해지거나 특정 상황이 있다면 만들 수 있다고 생각합니다! 대략 이런 스타일 입니다 :D github.com/team-dodn/spring-boot-kotlin-template
안녕하세요! 저 댓글을 달았던 사람압니다. 저같은 경우에는 반대로 ENUM 사용으로 유동적으로 대처할 수 없는 상황이어서 당시 많이 답답한 마음에 '무조건' 이라는 표현을 쓴거 같네요! 사실 무조건은 없다고 생각합니다 ㅎㅎ.. 타입 안정성이나, IDE 의 지원을 받을 수 있고, 말씀하신대로 변화가 거의 없다면 ENUM 은 매우 유용하지만 수정시 배포를 해야한다는 단점도 크게 느껴지는거 같아요... 좋은 의견 감사히 잘들었습니다!
서버 입장에선 무조건 enum인데 모바일에선 하위 버전과 최신 버전이 공존할 수 있어서, API 상 ENUM 코드에 대한 하위 호환을 유지해주는게 까다롭더라구요.
"API 응답 ENUM은 바뀔 수 있으니 항상 하위호환을 고려하세요!"라고 항상 요청하기에도 팀이 자체가 다르거나, 상황에 따라 하위호환이 어려운 상황도 생깁니다.
마지막에 말씀 해주셨듯이 무조건 뭐가 좋다기보단 상황에 따라 유연하게 선택하는게 맞는 듯 해요.
둘 다 애매하다면 DB에 코드를 정의 해두고 이를 Enum으로 변환해서 사용하는 것도 방법 일 듯 합니다. (대신 하위 버전용으로 Enum.UNKNOWN 처리를 추가한다거나)
항상 좋은 영상 감사합니다.
공감합니다:D 봐주셔서 감사합니다!
common이 진짜 '공통'으로 쓰이는거면 좋은데 프로젝트 커지고 사람 바뀌어가고 하다보면 공통이 아니라 '전역'의 느낌이 강해지더라고요. static을 대신해서 더 많으 쓰게 변질되더라고요.
맞습니다 :(
Enum 이 가져다주는 타입안정성은 절대 포기할수 없죠
맞습니다ㅎㅎ enum 절대 지켜!
하하 항상 좋은 영상 감사함니다
봐주셔서 감사합니다!😃
프로젝트 할때마다 팀내 의견이 갈리는 이슈입니다. ㅎㅎ 저는 개인적으로 enum파인데 코드로 관리되니 배포 민감성이 있죠. 요즘은 서버가 가볍게 관리되니 빌드 배포가 빈번하면 enum인데 빌드 배포가 무거우면 db로 가야죠.. db로 가면 문서화는 필수입니다. Common이라는 명명은 프로그램 짤때 최대한 피해야죠. 모든 것을 만족하는 결과는 없습니다. Common이 비대해지면 시간이 지나 분해하기도 어렵고 관리도 까다롭죠. 반면 enum은 복잡해지면 enum을 묶어서 다루거나 패키지 수준에서 분리한다면 복잡성은 관리가능한 수준으로 덜어진다고 봅니다.
맞습니다 제일 중요한건 상황을 제대로 이해하고 적절한 선택을 하는 것이죠!
공통코드 값 나중에 아무도 못건드리고 가비지 엄청 쌓입니다..
공통 코드가 망한 경우가 상당한 레거시죠 ㅠㅠ
공통코드 쓰는건 보통 운영자(백오피스 사용자)가 필요시 개발팀 배포요청없이 기능변경의 유용함은 있겠으니 프로젝트마다 사용방식은 그러려니 하겠습니다. 다만 개발자 입장에선 이넘으로 관리하는게 더 좋은거같아여 ㅠ
근데 공통코드와 이넘을 동시에 쓰는 케이스는 어떻게 생각하시나요?
여기같은 경우가 그리 되있는데.
공통코드변경시마다 이넘도 바꿔야하며, 심지어 어떤 이넘은 공통코드랑 매칭이 안 되는 경우처럼 따로국밥 사례들이 생겨서 이게 좀 힘드네요 ㅠ
제 경험에서도 공통코드 테이블이랑 enum 을 같이 동기화해서 쓰는 방식은 경험이 너무 안좋았습니다 ㅜ 그래서 가급적 안하는게 좋다고 생각하고, 레거시가 그렇다면 개선하는게 좋다고 생각합니다!
디비데이터랑 enum 싱크안맞아서 장애낸 기억이 ㅜㅜ 그이후로는 enum값 추가시 한번더 생각하고 합니다 😂
사실 그 둘이 의존성이 있는 구조가 상당히 안 좋은 구조 같습니다ㅜㅜ 저도 그 구조가 있을땐 신규입사자 올 때마다 그 패턴 장애가 났던 것 같아요ㅜㅜ
Common의 저주가 뭔가요?
Common이 점점 비대해지며 제 역할을 하지 못하게 되는 상황을 말씀하신 것 같습니다
@nonon9418 님이 적어주신 것 같은 상황을 말합니다 :D
추상적으로 자주 쓰는 표현인데 처음엔 common 으로 깔끔하게 시작했지만 잡다한 것들이 다 common 에 들어와서 A를 고치면 B가 터지고 B를 고치면 C가 터지는 그런 우울한 상황을 상상하며 쓰는 표현입니다 :D
자료구조 알고리즘은 어떻게 공부해야 하나요?
일전에 비슷한 내용을 영상으로 한 적이 있는데 어떤 영상인지는 모르겠네요! 실무 진행하면서 병행 학습 하는게 좋다고 봅니다!
코드레벨에서 분기 의존이 있다면
enum이 맞고
코드테이블이 맞다고 생각
상황에 따른 적절한 선택이 중요한 것 같습니다!
Enum == 속이뻥
😁😁😁
common 코드는 아닌데 공통 역할을 수행하는 모듈의 경우는 어떻게 생각하시나요? 예를들어 exception 이나 로그 등을 정의한 모듈일 경우도 따로 공통 역할을 하는 모듈을 안두시는지 궁금합니다
저는 가급적 공통 모듈을 만들지는 않습니다!
로깅 같은 경우는 기능 모듈로써 분리하는 편이고, Exception 이나 에러는 최대한 그 모듈에서 순수하게 제공하려합니다
(물론 공통의 니즈가 있을 순 있으나, 공통 자체의 범위를 전역으로 잘 안두는 것 같습니다)
그치만 정말 정말 비대해지거나 특정 상황이 있다면 만들 수 있다고 생각합니다!
대략 이런 스타일 입니다 :D
github.com/team-dodn/spring-boot-kotlin-template
한번 얘기해볼만한 주제 같아서 추후에 영상으로 얘기해보겠습니다
이슈 : github.com/geminiKim/dev-practice/issues/95
이런 세세한 습관을 배울 수 있는 곳은 정말 독보적인거 같습니다 :)
좋게 봐주셔서 감사합니다!😄 도움이 된다면 다행이에요!
안녕하세요! 저 댓글을 달았던 사람압니다. 저같은 경우에는 반대로 ENUM 사용으로 유동적으로 대처할 수 없는 상황이어서 당시 많이 답답한 마음에 '무조건' 이라는 표현을 쓴거 같네요! 사실 무조건은 없다고 생각합니다 ㅎㅎ.. 타입 안정성이나, IDE 의 지원을 받을 수 있고, 말씀하신대로 변화가 거의 없다면 ENUM 은 매우 유용하지만 수정시 배포를 해야한다는 단점도 크게 느껴지는거 같아요... 좋은 의견 감사히 잘들었습니다!
Enum을 사용하면 타입세이프하기 때문에 컴파일 단계에 걸러낼수 있는게 많은반면 말씀하신 형태가 되면 유연할수 있지만 항상 런타임에서만 걸러낼수 있을것 같아요.
결국 취사선택하기 나름일것 같습니다
좋은 질문 감사드립니다! :D
장단점이 있으니 적절히 사용하는게 답 같아요!
Enum 안배우면 할아버지가 Enum~~ 한다!
어익후...! 다들 망태 할아버지 조심!!