저는 개인적으로 OOP 의 꽃이 추상화 & 상속 이라고 생각하고, 최대한 클래스들을 추상화 하려고
노력하는데, 팀원들은 그게 아닌가봅니다.
예를들어
레포시터리 패턴을 사용해도 굳이 이렇게 써야하냐고, 물론 꼭 사용해야 하는건 아니지만…
혹은 공통된 기능이나, 인터페이스를 사용해 추상화 할수 있는건 왠만하면 유지보수를 위해 하려는 편인데,
팀원들은 그게 조금 복잡한가봅니다.
이런경우 어떻게 해결해 나가는게 좋을까요…
주먹구구식으로 이게 옳다 무조건 좋다라고 밀고가는건 성격상 아닌것같고,
팀원과 좋은 의사소통을 위한 고견 부탁드리겠습니다.
그점에 있어 저는 한번도 설득에 성공해본적은 없는것 같네요
서열로 지위로 우위에 있을때 상대방이 제말을 어쩔수 없이 들을 상황이거나
상사가 Roll을 정해 너가 구조 아키텍쳐 짜서 팀원에게 전파해 정하지 않는 이상
솔직히 추상화 상속이 답이라는것 약간만 공부하면 알수있는데 그걸 납득 못하는쪽이
스스로 자기가 부족하다는걸 깨달을 때까지 기다릴수 밖에요
상속이 많다 불만이면 의존성이나 AOC 도 가야 하는데 그걸 하나하나 설득할려면
지칠듯 싶네요
돈으로 해결 불가능한 일은 거의 없습니다.
불만이 나오지 못하도록 먹을 것을 제공하세요
혹시 몇 단계(?)까지 상속을 사용하고 계신지 알 수 있을까요?
그럴 경우 대부분 상속의 상속(2단계)까지가 설득의 한계였던거 같아요 ㅋㅋㅋ
로직이 없는 데이터 모델 같은 경우는 상속의 상속의 상속 (3단계)도 가능한 것 같은데…
사실 정답은 없는 것 같습니다.
저 개인적으로는 위의 글에서 이야기하는 것과 비슷한 결에서 몇 가지 factor를 고려해보시면 좋겠다는 의견을 드려봅니다.
소프트웨어를 잘 만드는 것도 중요하지만, 결국 소프트웨어가 지속성있게 개발이 되려면 같이 일하는 팀원들과의 합이 잘 맞아야 하는 것도 있습니다.
그래서 기술적인 디테일과 함께, 같이 일하는 사람들과 "지속 가능한 업무 환경"을 만드는 것도 같이 고민이 이루어져야 하지 않을까 생각합니다. 혹은 반대로, 채용 관점에서 지금 개발하시는 코드 스타일이나 개발 기술 철학에 동의할 가능성이 높은 사람들을 중심으로 채용 기준이나 Job Description을 설계하시는 것이 꼭 필요하다고 봅니다.
모델은 대부분 1단계였고,
컨트롤러나 레포같은것도 깊어야 2단계였습니다.
3단계 이상이면 저도 어느정도 이해가 될텐데
2단계에서 너무 많다고 해서 할말이 없었네요…
이 스레드의 주제는 C# 언어에 대한 직접적인 질문은 아니라고 생각하여, "모두의 Q&A"로 카테고리를 변경했습니다.
팀원 분들의 주장 처럼 상속(Inheritance) 구조로 인해 복잡하다고 느껴 진다면
과연 현재 구조가 상속 관계로 처리 하는 것이 맞을까 다시 한번 고민 해 보시는 것도 좋습니다.
상속은 명확한 is - a 관계인 경우에 사용하는 것이 좋지,
그렇지 않은 경우 부모, 자식 관계의 결합도가 높아지기에 한 곳이 수정되면 그 파생되는 모든 곳을 수정해야 하는 단점이 존재 합니다. (이를 복잡하다고 표현하지요)
따라서 구조를 다시 한번 검토해 보시고 상속(Inheritance) 보다는 합성(Composition) 으로 구조를 다시 설계 하는것이 정답일 수 있습니다.
합성을 사용하면 부모 자식 결합도가 사라져 추가 요구사항 기능을 구현할때 적어도 부모 클래스나 파생되는 클래스 구조를 수정할 필요가 없어 사이드 이펙트 오류도 최소화 할 수 있습니다.
추상화에 대한 같은 책을 보고 팀원끼리 생각을 나눠 보는 것은 어떨까요?
그러다보면 좀 맞춰질 것도 같습니다.
서로 다른 경험과 지식수준의 차이에서 오는 문제일 거라고 생각해서, 방향을 맞추기 위해 공개된 정보를 함께 열람하고 생각을 조율하는게 좋을 것 같다는 생각입니다.
물론 공신력이 있는 자료일 수록 더욱 좋을 것 같습니다.
그리고 개발 기술적인 것도 있지만, 평소에도 이런저런 소통으로 나의 생각을 전달해주면 더욱 좋을 것 같습니다.
개발자의 코드 스타일은 평소의 라이프스타일과도 어느정도 일치된다는 생각이 있기 때문입니다.
Repository 패턴이 영속화층의 추상으로써 매우 편리한 개념이지만, 사용법이 조금이라도 달라지면 매우 복잡한 로직이 되어버린다
라고 하는 군요
함 읽어 보시소
@ aroooong님 의견에 한표 던집니다.
스스로 깨닫는 것만큼 확실한 것이 없습니다.
아무리 진수성찬을 차려줘도 떠먹는 건 직접 해야죠…
설득 안되면 사실 답 찾기 어렵습니다.
시간을 두고 추상화에 대해 조금씩 자주 은근슬쩍 노출(?)시켜준다면
어라? 이거 편하네? 가독성 좋네?
이런 반응이 생기길 기대하는 수 밖에 없을 것 같아요.
강하게 밀어부칠수록 부정 반응도 강하게 나올 수가 있으니까요…ㅎㅎ
힘내셔요 
팀의 색깔이 FE 쪽이라면, 객체 지향 개념은 사실 맞지 않을 수 있습니다.
객체라는 개념 자체가 단순화, 간략화(추상화)를 토대로 하고 있고, 상속은 체계화/통일화를 위한 것입니다.
비록, 피상적 정의를 통해 구현을 뒤로 미룬다하더라도, 정형성은 피할 수 없습니다. 이 정형성은 디테일이 중요한 디자인의 영역에서는 굴레처럼 느껴질 수 있습니다. (그래서 Xaml 이 디자이너들에게 인기가 없나 봅니다. ^^)
로직 쪽이고, 객체 지향 언어를 사용하면서도 기본적인 상속을 기피한다는 것은 분명 문제가 있습니다.
그런데, 프로젝트의 구조는 소프트웨어 설계론을 따르고 있는데, 인력의 배치는 그렇지 않은 것은 아닌지요?
어떤 설계론이든, 각 레이어의 사이의 관계는 공급자와 소비자이고, 피상적 정의(abstract, interface)가 힘을 발휘할 곳은 공급자와 소비자의 경계선입니다.
즉, 협업 당사자들이 공급자와 소비자로 서로 반대 입장일 때, 피상적 정의를 통해 가시적 효익을 누릴 수 있습니다.
이 경계선을 피상적으로 정의하는 것은 표준화된 통신 단자를 쓰는 것과 같습니다.
우리가 이더넷 통신의 표준 단자로 RJ45 잭을 사용하고 있는 것처럼 말이죠.
그런데 한 사람에게 몇 개의 레이어를 할당시켜 놓고, 연결점을 꼭 갖추라고 말하는 것은 마치,
"공유기 안쪽의 통신선도 납땜하지 말고, RJ45로 연결할 것"을 강요하는 것과 같을 수 있습니다.
“케이스 안에서 남땜하든 뭘 하든 님이 뭔 상관?” 이라는 1차적 거부감이 쉽게 유발될 수 있습니다.
연결점을 피상적으로 정의하는게 옳은가 아닌가에 대한 논의 이전에, 현재의 자원으로 감당할 수 있는 일인가에 대한 고민을 먼저 해보시는 건 어떨까합니다.
설령 자원이 충분하다고 하더라도, 아래의 질문에 스스로 답변을 해보신 후에, 그 답변을 바탕으로 팀원을 설득해보시는 것도 좋을 듯합니다.
IRepository 의 구현을 론칭 이후에 바꿔 본 적이 있는가?
유지보수가 아니라, DB=> 파일, API=>DB 등, 새로운 실물 저장소를 위한 구현체 변경.
DbContext 를 IRepository로 감싸 놓고, 론칭 이후에 DbContext를 바꿔 본 적이 있는가?
이런 것의 대부분은 기술 전략을 짜눈 CTO같은 역할이 없어서인 경우가 많더라구요.
@rkttu 님 말처럼 정답은 없고 상황에 따라 장단점은 있습니다.
해서 명확한 팀의 기준을 두고, 그 기준에 유리한걸 계속 선택하게끔 해야하는거 같아요. 단순하게요.
그리고 그 기준을 어떤 것으로 할것이냐가 리더의 역할 같습니다.
예: ‘우리 비즈니스는 속도만이 생명이니, 무조건 컴퓨팅 속도를 올리자. 심지어 기계 기준에서 연산 많이 안하도록‘