SI 에서 일하고 있는 입장에서 공감되는 내용입니다. 여기는 전부 Service- ServiceImpl 구조이지만, 매번 생각하는 거지만 구현체가 하나뿐인 인터페이스는 필요없다는 것입니다. 인터페이스는 추상화를 통해 의존성을 끊어주려는 목적으로서 사용되어야하며, 의존성을 줄여주는것이 의미가 있으려면 구현이 여러개 존재하는 상황이어야 의미가 있으니까요.
관습적으로 인터페이스 만들고 구현체에 Impl붙이고 마는건 cglib 초창기 시대의 한계가 그냥 관습으로 온 거 이상의 의미는 전혀 없고, 굳이 인터페이스로 분리를 하면서도 Impl 달랑 붙이는건 아무리 잘 봐줘도 설계와 네이밍이 귀찮아서(...) 정도가 아닐까 생각하네요. 영상 마지막쪽도 비슷한 느낌인데, 인터페이스 설계를 잘 한다면 UserFetchable / UserSearchable 인터페이스를 분리하고 그 둘의 구현체인 UserService 뭐 이런식으로 되고 DI에서는 그 앞의 인터페이스만 주입해서 사용하는게...
Impl 접미사에 관한건, C++에서 내려온 Pimple패턴에서 비롯된 역사에 유례하지 않았나 추측합니다. C++ Pimple 패턴의 주된 목적은 현대의 Interface가 제공해주는 Polymorphism이 아니라 컴파일 시간 단축이었기에 항상 구현체와 1:1대응 되었고 그래서 무조건 -impl로 통일한 것이라 생각합니다.
지금 버전의 boot에서도 impl을 붙이는 게 컨벤션이라 생각하신다면 굉장히 잘 못 알고 계신다고 보입니다. (제가 못 봤을 수도 있긴할테니, boot 레퍼런스에 적혀있다면 공유 주시면 좋겠네요) 저는 아무리 잘 봐줘도 과거 관습의 잔재라고 보입니다. 또 네이밍 규칙을 맞추지 않으면 자동으로 매핑이 안된다 하셨는데 구현체 매핑을 의미하신 거라면 이것도 잘 못 알고 계신 것 같습니다, 이건 직접 테스트해보시기 바랍니다.
저도 영상 내용에 극히 공감합니다! 근데 Spring Data 관련 문서 Customizing Individual Repositories 부분에 이런 말이 있긴 하더라구요 The most important part of the class name that corresponds to the fragment interface is the "Impl" postfix.
impl postfix 가 spring-data 쪽에 커스텀 구현체 작성 시 변경 가능한 “기본 설정값“ 이긴 하죠, 그렇지만 이게 boot의 컨벤션이라 보는 근거라면 많이 부족해 보입니다. 그리고 추가 댓글 달아주신 분들도 감사하지만, 비꼬는 댓글은 자제 부탁드립니다.
구현클래스가 하나뿐이라도 인터페이스와 구현클래스를 나누지 안는다면 이미 공개된 클래스를 변경하기 어려워지기 때문에 인터페이스 분리는 필요하지 않을까 생각해요. 이때 이름이 애매하니까 관습적으로 Impl를 사용하게 되는거 같습니다. 해당 클래스의 api가 호출하는 곳에 대한 권한이 있다면 인터페이스를 뒤늦게 만들수있지만 그렇지 않는 경우는 Interface로 public한 동작을 정의하고 구현 클래스는 숨겨야 추후 안전하다 보니 많이 쓰이는 관용이 되지 않았나 생각합니다 !
interface 와 impl 1:1로 구성하고 함수 또한 1:1로 구성하고 결국 모두 노출시키는 방식이라면 말하신 공개된 클래스 변경의 이점이나, 추후 안전?하다는 느낌의 효과는 전혀 없을 것 같습니다. 애초에 인터페이스가 유명무실한 상태이니까요. 결국 구현에서 인터페이스가 추출 되는 방식이 아니라 무지성 1:1 인터페이스, 1:1 함수 매핑 이런 무의미한 관습이 문제라고 봅니다. 의도적으로 구현체를 숨기는 것을 적절히 활용한다면 impl 자체를 postfix로 쓰는건 오히려 문제가 적을 수 있긴합니다, 다만 이 사례보다는 위의 습관적 1:1이 대부분으로 보이더라구요.
jpa querydsl을 쓰는 경우 repository는 interface를 강제로 쓰고 있네요. 이것만 해도 interface의 method를 수정하면, repositoryImpl을 수정해야 해서 손이 많이 가는 것 같네요. service는 굳이 역할과 구현을 나눌 일이 없을 것 같아서, 그냥 구체 클래스로 썼습니다.
@@도도새-j3z 어려운 문제입니다만, 상당히 높은 확률로 `클린코드 책과 같이 수정하는걸 의미` 하지 않을 겁니다! 리펙토링은 정해진 것도 끝도 없는 작업 중 하나 같습니다. 그런 관점에서 `클린코드 책` 이나 외부의 기준에 흔들리시면 주화입마에 빠질 가능성이 상당히 높아집니다. 오히려 저는 이렇게 생각해보시길 권장드립니다. - 다른 동료가 내가 작성한 코드를 읽을 때 직관적인가? - 다른 동료가 내가 작성한 코드를 수정 할때 직관적인가? - 지금 구조가 추후 +@ 기능을 붙히려고 할 때 수정하기 어려운가? - 한달 뒤에도 내가 이 코드를 보고 빠르게 다시 이해 할 수 있는가? - 지금 현재 회사의 비즈니스 상황에서 리펙토링에 시간을 어느정도 쓰는게 맞는가? 요런 관점 정도로 고민 해보시면 좋을 것 같습니다, 대부분 회사에서는 개발로 예술을 하는게 아니고 비즈니스를 하는 것 이기에 고민해보시고 작게 작게 꾸준히 리팩토링 하시면서 현실적이고 `지속 성장 가능성` 을 열어두는 `적정 리팩토링` 의 감을 잡아나가시면 좋을 것 같습니다. -- 추가로 제가 안 좋다고 보는 것 중 하나는 `리팩토링 시간` 을 별도로 잡고 쓰는 것 입니다. 리팩토링은 꾸준히 작게 작게 계~속 일어나야하는 행위라고 생각합니다. 도움이 되셨으면 좋겠네요!
저도 하나의 구현체만 있는데 인터페이스 사용에 대해서는 오버 엔지니어링인 것더라고요. 이와 관련된 자료들을 찾아보니 테스트에 용이하다는 주장에 대해서는 어떻게 생각하시나요? 예를 들어, Repository가 주입된 특정 클래스를 테스트한다고 가정하면 DB 로직이 들어있는 구현체 RepositoryImpl 대신 더미 데이터가 있는 FakeRepository를 주입해 자유롭게 테스트를 할 수 있다고 합니다. 보통 TDD를 지향하는 프로젝트 쪽에서 사용하는 것 같더라고요 아직 저는 무엇이 좋고 좋지 않은지 잘 모르겠더라고요
물론 인터페이스으로 작성되어있으면 테스트 시 용이하다는 부분은 맞다고 생각합니다. 실제로 이점이 있습니다. 다만 '테스트'를 위해서 '인터페이스'를 만드는 것은 과한 작업이라고 생각합니다. (주객전도 느낌입니다) 그래서 실제로 구현체를 mock 처리하여 테스트를 작성해도 완전히 만족스럽진 못하지만 현실적 테스트에는 무리가 없다는 생각입니다.
아키텍쳐 설계에 관해 경험이 없으실까요. 설계 먼저하면 당연히 service에 해당하는 interface가 먼저 도출될 수 밖에 없을 겁니다. AA가 잘 설계했다면 그렇게 될거고요. MVC기반 or 스프링기반 전자정부 프레임워크 쓰는 곳들에서는 저렇게 하는게 기능 단위로 코드를 응집해두는게 편리해서 그럴겁니다. 관습적으로 해오고 있어서 새로운 프로젝트에서도 하기는 힘들 듯 해요. 소규모 프로젝트나 필요시 해볼 법하고.. 또 막상 SeviceImpl 같은 구현체를 다양하게 쓸만한 케이스가 있나 따져보면 없기도 하네요. 굳이 쓴다면 아마 기술을 쓰기 위한 구현이 되어 오버엔지니어링이 되지 않을까하는 생각이 드네요
설계 경험이 없을리가요ㅎㅎ 오히려 아키텍처 설계랍시고 설계를 먼저 도출한다는 것과, interface로 만 설계한다는 관점도 별로라고 생각합니다. 그렇게 설계한답시고 시간 까먹고, 제대로 된 설계를 보여주고, 정상적으로 구현까지 하는 사람을 본 적이 없어서요. 애초에 소프트웨어를 성장시키는 관점으로 접근하는 게 아니라, 그럴듯하게 보이는 '설계'란 키워드로 접근한다는 것 자체가 제대로 된 추상화나 올바른 인터페이스 추출을 해낼 수 없는 방식으로 보입니다. (몇몇 경우에는 예외가 될 수 있다 생각하긴 하나 99%는 잘못된 케이스인 것 같습니다) MVC 기반의 문제는 아니라고 보이고, '전자정부 표준프레임워크'의 악습이 남아있는 SI 시장이라면 슬프지만 용인해 줄 수 있는 것 같습니다. 말씀하신 아키텍처 설계 방식이나 아키텍트니 그런 이상한 것들이 통용되는 있는 시장이니까요, 그 부분은 저도 경험해 봤었지만 여전히 안타까울 뿐이네요. 어쨌든 한 번 생각해 보실 거리가 된 것 같으니 다행이네요.
@@geminikims 저도 한편으로는 악습인가?로 생각해봤다가, 사이트의 기능이 단순하고 그런만큼 각 기능의 구분이 명확이 나눠지는 것들이 많아서 그럴수도 있겠구나 했습니다. 댓글 서두에 말씀하신 부분 저도 많이 봤습니다. 하지만 반면교사로 삼기 위해서 아 저때는 어떤 상황이었을까 무슨 이유로 이렇게 만들었을까 하고 하나라도 케이스스터디 한다는 마음이 스스로에게 도움이 될 듯 싶습니다. 누군가 제시한 아키텍쳐들도 너무 기다아니다로 판단하는 것보다 부분부분 어떤 상황에 적용할 수 있을까 그래서 어떻게 변형해서 사용할 수 있을까를 고민하는게 낫고요. 올바른 인터페이스를 추출해낼 수 없는 방식으로 보이는게 99프로는 잘못된 케이스라는건 무슨 자신감이신거죠.. 하고픈 말이 많지만, 설계 경험을 더더더더더 많이 개인적으로도 프로젝트로도 많이 쌓아보시면 알게될거란 말로 줄일 수 밖에 없겠네요…
케바케에 대해서 고민하는 건 당연히 해야 할 일이죠, 다만 더 현실적인 설계, 적정 설계와 성급한 설계의 문제에 대해서 경계하고 설계 말고 훨씬 더 많은 실무 경험해 보시면 좋겠다 생각이 드네요. 회사의 자산과 팀 동료들이 계속 지켜나가고 성장 시켜야하는 건 설계 보다는 구현입니다. (또는 구현에 의해 성장되서 나온 설계입니다) 그 측면에서 아키텍처 설계니 인터페이스 기반 설계니 이런 부분이 중요하다고 주장하는 파를 봤을땐 구현 중심적인 실무 경험이 부족하다 느껴지네요. 저도 아키텍트니 아키텍처 설계니 이 부분에 더 말할 것이 많지만 서로 상황도 다르고 케바케가 있긴하니 의미없는 대화는 그만해도 될 것 같습니다
SI 에서 일하고 있는 입장에서 공감되는 내용입니다. 여기는 전부 Service- ServiceImpl 구조이지만, 매번 생각하는 거지만 구현체가 하나뿐인 인터페이스는 필요없다는 것입니다. 인터페이스는 추상화를 통해 의존성을 끊어주려는 목적으로서 사용되어야하며, 의존성을 줄여주는것이 의미가 있으려면 구현이 여러개 존재하는 상황이어야 의미가 있으니까요.
공감 감사드립니다 :D
좋은 영상 정말 감사합니다! 항상 잘 보고 있습니다.
봐주셔서 감사합니다!
오늘도 좋은 영상 감사합니다😊
봐주셔서 감사합니다!
사실 뭐 말이 impl이지 usecase 등도 동일하게 1:1 대칭되는 구조 자체를 두는 것이 별로라는 얘기로 이해가 되네요. 잘 봤습니당 :)
맞습니다 정확히는 생각과 의도 없이 무지성 1:1 구조는 고민해볼 필요가 있다는겁니다! 봐주셔서 감사합니다!
실무하는 데에 너무 많은 도움 됩니다. 매번 잘 보고 있어요 감사합니다
도움이 되었다면 다행이네요! 봐주셔서 감사합니다!
매우 공감합니다. 유행따라 무지성 impl 반복한거 보면 화가납니다
공감 감사합니다! 유행이라고 부르기도 뭐할 정도로 과거의 잔재 수준이라 더욱 그렇죠..😅
관습적으로 인터페이스 만들고 구현체에 Impl붙이고 마는건 cglib 초창기 시대의 한계가 그냥 관습으로 온 거 이상의 의미는 전혀 없고, 굳이 인터페이스로 분리를 하면서도 Impl 달랑 붙이는건 아무리 잘 봐줘도 설계와 네이밍이 귀찮아서(...) 정도가 아닐까 생각하네요. 영상 마지막쪽도 비슷한 느낌인데, 인터페이스 설계를 잘 한다면 UserFetchable / UserSearchable 인터페이스를 분리하고 그 둘의 구현체인 UserService 뭐 이런식으로 되고 DI에서는 그 앞의 인터페이스만 주입해서 사용하는게...
DI 사용 부분까지 100% 공감합니다😄😄
DI에서는 그 앞의 인터페이스만 주입한다는 게 어떤 의미인지 설명 부탁드려도 될까요? 잘 이해되지 않아서요.
@user-qi3fy6em3f 빈 주입시 구현 클래스명을 표기하는게아니라 인터패이스 명을 표기한다는 의미입니다.
생성자 주입을 받는다면 참조를 클래스가 아닌 인터페이스로 한다는 것이에요
@@geminikims 아ㅎㅎ 제가 문맥 이해를 못했네요. 감사합니다!
Impl 접미사에 관한건, C++에서 내려온 Pimple패턴에서 비롯된 역사에 유례하지 않았나 추측합니다. C++ Pimple 패턴의 주된 목적은 현대의 Interface가 제공해주는 Polymorphism이 아니라 컴파일 시간 단축이었기에 항상 구현체와 1:1대응 되었고 그래서 무조건 -impl로 통일한 것이라 생각합니다.
impl 자체는 굳이 유래를 찾지 않아도 명명자체의 직관성은 있는 편 같아요, 활용이 더 잘되면 좋겠단 생각이드네요 :) 댓글 감사합니다.
좋은 영상 감사합니다 :)
아키텍쳐가 변한다면 많은 것들이 변해야 된다고 생각하는데요.( 좋은 설계는 많이 변하지 않나요 ?? )
그렇다면 변화에 두려움을 갖지 않는게 좋을까요. 아니면 많은 변화들에 대한 부지런함을 갖는게 좋을까요
변화는 언제나 올 수 있기 때문에 두려워하면 안 되는 것 같습니다. 너무 멀리 말고 적절히 가까운 최소한의 변화를 예측해 보려 노력하고 변화에 대해 어떻게 대응할지 상상/고민도 해보고 여러모로 부지런함을 갖는 게 좋을 것 같습니다.
봐주셔서 감사합니다!
Springboot에서는 impl을 붙이는게 일종의 컨벤션화가 되어 있는데.. 네이밍 규칙을 맞추지 않으면 자동으로 매핑되지 않는 부분들도 존재하고...
동의하기도 동의하지 않기도 어려운 주제이네요 잘봤습니다
지금 버전의 boot에서도 impl을 붙이는 게 컨벤션이라 생각하신다면 굉장히 잘 못 알고 계신다고 보입니다. (제가 못 봤을 수도 있긴할테니, boot 레퍼런스에 적혀있다면 공유 주시면 좋겠네요)
저는 아무리 잘 봐줘도 과거 관습의 잔재라고 보입니다.
또 네이밍 규칙을 맞추지 않으면 자동으로 매핑이 안된다 하셨는데 구현체 매핑을 의미하신 거라면 이것도 잘 못 알고 계신 것 같습니다, 이건 직접 테스트해보시기 바랍니다.
누가 컨벤션이라고 한건지 참..
처음부터 다시 배우세요
Spring Data JPA의 경우, 사용자 정의 인터페이스의 구현체를 작성할때, Impl을 붙여주어야 매핑이 정상적으로 이뤄지는 상황을 예시로 들어 설명해주신 것 같습니다.
별개로 윗 분, 조금 공격적인 어투이신 것 같습니다..
저도 영상 내용에 극히 공감합니다! 근데 Spring Data 관련 문서 Customizing Individual Repositories 부분에 이런 말이 있긴 하더라구요
The most important part of the class name that corresponds to the fragment interface is the "Impl" postfix.
impl postfix 가 spring-data 쪽에 커스텀 구현체 작성 시 변경 가능한 “기본 설정값“ 이긴 하죠, 그렇지만 이게 boot의 컨벤션이라 보는 근거라면 많이 부족해 보입니다.
그리고 추가 댓글 달아주신 분들도 감사하지만, 비꼬는 댓글은 자제 부탁드립니다.
구현클래스가 하나뿐이라도 인터페이스와 구현클래스를 나누지 안는다면 이미 공개된 클래스를 변경하기 어려워지기 때문에 인터페이스 분리는 필요하지 않을까 생각해요. 이때 이름이 애매하니까 관습적으로 Impl를 사용하게 되는거 같습니다.
해당 클래스의 api가 호출하는 곳에 대한 권한이 있다면 인터페이스를 뒤늦게 만들수있지만 그렇지 않는 경우는 Interface로 public한 동작을 정의하고 구현 클래스는 숨겨야 추후 안전하다 보니 많이 쓰이는 관용이 되지 않았나 생각합니다 !
interface 와 impl 1:1로 구성하고 함수 또한 1:1로 구성하고 결국 모두 노출시키는 방식이라면 말하신 공개된 클래스 변경의 이점이나, 추후 안전?하다는 느낌의 효과는 전혀 없을 것 같습니다.
애초에 인터페이스가 유명무실한 상태이니까요.
결국 구현에서 인터페이스가 추출 되는 방식이 아니라 무지성 1:1 인터페이스, 1:1 함수 매핑 이런 무의미한 관습이 문제라고 봅니다.
의도적으로 구현체를 숨기는 것을 적절히 활용한다면 impl 자체를 postfix로 쓰는건 오히려 문제가 적을 수 있긴합니다, 다만 이 사례보다는 위의 습관적 1:1이 대부분으로 보이더라구요.
jpa querydsl을 쓰는 경우 repository는 interface를 강제로 쓰고 있네요. 이것만 해도 interface의 method를 수정하면, repositoryImpl을 수정해야 해서 손이 많이 가는 것 같네요. service는 굳이 역할과 구현을 나눌 일이 없을 것 같아서, 그냥 구체 클래스로 썼습니다.
결국은 타당한 이유가 있다면 허용 가능 한 것 같습니다 :D
ㅋㅋ... 맞아요. 서비스를 인터페이스로 잡고, 구현하는건 실제로 이득이 거의 없습니다.
특별히 인터페이스로 잡아야 할 상황이 아니라면, 낭비입니다.
공감합니다😃 결국은 필요에 의해 움직이는 방식이 항상 효과적이고 효율적인 것 같습니다!
프로젝트에서 쓰면서도 오히려 불편하더라구요 분기의 개념 및 기능의 보장보다 기술의 사용의 느낌이 강해서 실무자분 생각이 궁금했는데 감사합니다!!!
봐주셔서 감사합니다!
@@geminikims 혹시 리펙토링에 대해 궁금한데 프로젝트 끝난 이후에 회사에서 신입에게 바라는 리펙토링의 범위가 어떤걸까요..?? 클린코드 책과 같이 수정하는걸 의미하는 걸까요..? 도통 감이 안잡혀서 여쭤봅니다!!!
@@도도새-j3z 어려운 문제입니다만, 상당히 높은 확률로 `클린코드 책과 같이 수정하는걸 의미` 하지 않을 겁니다!
리펙토링은 정해진 것도 끝도 없는 작업 중 하나 같습니다.
그런 관점에서 `클린코드 책` 이나 외부의 기준에 흔들리시면 주화입마에 빠질 가능성이 상당히 높아집니다.
오히려 저는 이렇게 생각해보시길 권장드립니다.
- 다른 동료가 내가 작성한 코드를 읽을 때 직관적인가?
- 다른 동료가 내가 작성한 코드를 수정 할때 직관적인가?
- 지금 구조가 추후 +@ 기능을 붙히려고 할 때 수정하기 어려운가?
- 한달 뒤에도 내가 이 코드를 보고 빠르게 다시 이해 할 수 있는가?
- 지금 현재 회사의 비즈니스 상황에서 리펙토링에 시간을 어느정도 쓰는게 맞는가?
요런 관점 정도로 고민 해보시면 좋을 것 같습니다, 대부분 회사에서는 개발로 예술을 하는게 아니고 비즈니스를 하는 것 이기에
고민해보시고 작게 작게 꾸준히 리팩토링 하시면서 현실적이고 `지속 성장 가능성` 을 열어두는 `적정 리팩토링` 의 감을 잡아나가시면 좋을 것 같습니다.
--
추가로 제가 안 좋다고 보는 것 중 하나는 `리팩토링 시간` 을 별도로 잡고 쓰는 것 입니다.
리팩토링은 꾸준히 작게 작게 계~속 일어나야하는 행위라고 생각합니다.
도움이 되셨으면 좋겠네요!
영상에서 사용하시는 메모 앱 이름 알 수 있을까요?
서브라임 텍스트입니다!
저도 하나의 구현체만 있는데 인터페이스 사용에 대해서는 오버 엔지니어링인 것더라고요.
이와 관련된 자료들을 찾아보니 테스트에 용이하다는 주장에 대해서는 어떻게 생각하시나요?
예를 들어, Repository가 주입된 특정 클래스를 테스트한다고 가정하면
DB 로직이 들어있는 구현체 RepositoryImpl 대신 더미 데이터가 있는 FakeRepository를 주입해 자유롭게 테스트를 할 수 있다고 합니다.
보통 TDD를 지향하는 프로젝트 쪽에서 사용하는 것 같더라고요
아직 저는 무엇이 좋고 좋지 않은지 잘 모르겠더라고요
물론 인터페이스으로 작성되어있으면 테스트 시 용이하다는 부분은 맞다고 생각합니다.
실제로 이점이 있습니다.
다만 '테스트'를 위해서 '인터페이스'를 만드는 것은 과한 작업이라고 생각합니다. (주객전도 느낌입니다)
그래서 실제로 구현체를 mock 처리하여 테스트를 작성해도 완전히 만족스럽진 못하지만 현실적 테스트에는 무리가 없다는 생각입니다.
확실히 테스트만을 위한 이유만이면 근거가 불충분하네요
감사합니다. 영상과 댓글에 설명해주신 부분을 고려하며 인터페이스 사용하겠습니다!
아키텍쳐 설계에 관해 경험이 없으실까요.
설계 먼저하면 당연히 service에 해당하는 interface가 먼저 도출될 수 밖에 없을 겁니다. AA가 잘 설계했다면 그렇게 될거고요.
MVC기반 or 스프링기반 전자정부 프레임워크 쓰는 곳들에서는 저렇게 하는게 기능 단위로 코드를 응집해두는게 편리해서 그럴겁니다. 관습적으로 해오고 있어서 새로운 프로젝트에서도 하기는 힘들 듯 해요.
소규모 프로젝트나 필요시 해볼 법하고.. 또 막상 SeviceImpl 같은 구현체를 다양하게 쓸만한 케이스가 있나 따져보면 없기도 하네요. 굳이 쓴다면 아마 기술을 쓰기 위한 구현이 되어 오버엔지니어링이 되지 않을까하는 생각이 드네요
설계 경험이 없을리가요ㅎㅎ
오히려 아키텍처 설계랍시고 설계를 먼저 도출한다는 것과, interface로 만 설계한다는 관점도 별로라고 생각합니다.
그렇게 설계한답시고 시간 까먹고, 제대로 된 설계를 보여주고, 정상적으로 구현까지 하는 사람을 본 적이 없어서요.
애초에 소프트웨어를 성장시키는 관점으로 접근하는 게 아니라, 그럴듯하게 보이는 '설계'란 키워드로 접근한다는 것 자체가 제대로 된 추상화나 올바른 인터페이스 추출을 해낼 수 없는 방식으로 보입니다.
(몇몇 경우에는 예외가 될 수 있다 생각하긴 하나 99%는 잘못된 케이스인 것 같습니다)
MVC 기반의 문제는 아니라고 보이고, '전자정부 표준프레임워크'의 악습이 남아있는 SI 시장이라면 슬프지만 용인해 줄 수 있는 것 같습니다.
말씀하신 아키텍처 설계 방식이나 아키텍트니 그런 이상한 것들이 통용되는 있는 시장이니까요, 그 부분은 저도 경험해 봤었지만 여전히 안타까울 뿐이네요.
어쨌든 한 번 생각해 보실 거리가 된 것 같으니 다행이네요.
@@geminikims 저도 한편으로는 악습인가?로 생각해봤다가, 사이트의 기능이 단순하고 그런만큼 각 기능의 구분이 명확이 나눠지는 것들이 많아서 그럴수도 있겠구나 했습니다.
댓글 서두에 말씀하신 부분 저도 많이 봤습니다. 하지만 반면교사로 삼기 위해서 아 저때는 어떤 상황이었을까 무슨 이유로 이렇게 만들었을까 하고 하나라도 케이스스터디 한다는 마음이 스스로에게 도움이 될 듯 싶습니다.
누군가 제시한 아키텍쳐들도 너무 기다아니다로 판단하는 것보다 부분부분 어떤 상황에 적용할 수 있을까 그래서 어떻게 변형해서 사용할 수 있을까를 고민하는게 낫고요.
올바른 인터페이스를 추출해낼 수 없는 방식으로 보이는게 99프로는 잘못된 케이스라는건 무슨 자신감이신거죠..
하고픈 말이 많지만, 설계 경험을 더더더더더 많이 개인적으로도 프로젝트로도 많이 쌓아보시면 알게될거란 말로 줄일 수 밖에 없겠네요…
케바케에 대해서 고민하는 건 당연히 해야 할 일이죠, 다만 더 현실적인 설계, 적정 설계와 성급한 설계의 문제에 대해서 경계하고 설계 말고 훨씬 더 많은 실무 경험해 보시면 좋겠다 생각이 드네요.
회사의 자산과 팀 동료들이 계속 지켜나가고 성장 시켜야하는 건 설계 보다는 구현입니다.
(또는 구현에 의해 성장되서 나온 설계입니다)
그 측면에서 아키텍처 설계니 인터페이스 기반 설계니 이런 부분이 중요하다고 주장하는 파를 봤을땐 구현 중심적인 실무 경험이 부족하다 느껴지네요.
저도 아키텍트니 아키텍처 설계니 이 부분에 더 말할 것이 많지만 서로 상황도 다르고 케바케가 있긴하니 의미없는 대화는 그만해도 될 것 같습니다
100번 생각해봐도 I접두사 인터페이스 네이밍을 쓰는 닷넷형식의 네이밍 도입이 시급함..
Impl.. 겁나구림
저는 둘 다 아쉽다 생각이지만, 그래도 굳이 고르라면 Impl보단 I가 나을 것 같네요 :D