난 중소 솔루션 회사인데
애플리케이션 만들어주다가 요구사항이 이전 요구사항에 반하는 요구사항이었음.
이때 다형성이 있는 모델들을 지우게 됐는데
이러다보니 고작 클래스 하나를 확장하기 위해서 추상클래스를 만든 코드가 되어버림.
오히려 클린코드보다 난해하고 바보처럼 보이는 코드가 완성된거지.
물론 다음에 확장하기에는 좋겠지.
몇년 뒤가 될지는 모르지만..
과연 중소 솔루션 회사에서 기존의 요구사항 명세서를 기반으로
다형성을 적극적으로 사용하는게 올바른지에 대해서
좀 혼란스럽고 내가 배운 디자인 패턴에 대해서 자괴감이 느껴짐.
좋은 고민이고, 고민하는거 보니 올바른 방향으로 나아가고 있음
그래서 해답은 무엇임니가.. 이거 중소 솔루션에서도 다형성과 디자인패턴을 지향하는게 맞을가요.. 이정도로 요구사항이 바뀐 적이 처음이긴한데. 너무 바뀌다보니 코드가 바보같아져버리는 현상은..
다형성과 디자인 패턴은 도구일뿐임 지향이라는 건 답에 대한 이야기가 아니라 여러가지 방향 중 하나에 대한 이야기야
상황에 따라 맞는 답을 선택하고, 전체 구조에 최대 이득이 되는 방향으로 나아가는게 맞음
보통은 일단 그냥 개발하고 사례가 충분히 생기면 추상화 함
그럼 최대한 단일클래스로 만드는게 오히려 요구사항이 자주 바뀌는 중소솔루션 특성상 더 나을 것 같은데 단일책임원칙을 프로젝트 내 최대의 원칙으로 세워놓고 최대한 단일클래스를 사용하는게 낫겟삼..
요구사항이 자주 바뀌는데 추상화하면 좆되지 그리고 단일책임도 지키기 어려워 책임이 뭔지도 기준을 세울 수 없는 상황인거잖아?
뭔가 체계를 세우는데 너무 집착하지 말고 영역을 두가지로 나눠라 니가 통제할 수 있는 부분과 아닌 부분으로 통제할 수 있는 부분에만 체계를 적용시켜
그 경우 하드코딩과 비슷한 영역과 아닌 영역이 나뉘게 되어서 오히려 유지보수가 어렵지 않을까? 라고 생각햇는데 생각보다 흔한 일인가보네용 이거
지킬 수 있는거라도 지켜야지 그러다 모든게 망가짐
견고한 영역과 쉽게 교체되는 영역을 나누는건 개발에만 있는 방식이 아냐 칼 만드는거만 봐도 심과 날은 다름 옳고 그름의 문제가 아니라 적재적소의 문제야
이런건 경험이 중요한거라 당장 모르겠어도 계속 고민하다보면 점점 답이 명확해짐
C# 쟁이들이 쓴 코드보면 개난해한 경우 많던데. 하나 구현하는데 쓸데없는 뎊스가 2 3개 짜리도 있고
내가 본 C# 코드는 하드코딩 덩어리엿는데..
김영한도 항상말하는데 실무에서 안그럴수도 있다라고 무조건 다형성 지킨다고 서비스 클래스 하나만드는데 서비스 -서비스임플 이렇게 만드는 김치 블로그 처럼 코딩할거냐고~
요구사항 조금 변경하는 정도는 대응할 수 잇게 만들었음. 아예 정반대 요구를 해버리는 경우가 처음이라 그런것..
아예 정반대의 요구를 하는 건 그냥 다른걸로 봐야지 간혹가다 다형성이나 확장성을 어떻게든 다 확장가능한 코드로 생각하는데 그거는 같은 책임 안에서 형태가 달라지는 거고 책임이 달라지면 그냥 다른 상황이라 봐야하는 거 같은데