프론트엔드 코드를 유지보수에 용이하게 짜는 방법에 대한 조언이 필요합니다.

안녕하세요. 정말 멋진 고민을 하고계신것 같아서 비록 직무가 다름에도 같은 고민을 하고있는 백엔드 엔지니어로써 감히 의견을 달아보려고 합니다. 먼저 SOLID와 디자인패턴에 대해 공부하시는건 좋은 생각이라고 생각됩니다. 하지만 이론만 봤을때 바로 응용하기는 어려운 부분인것 같습니다. 저도 먼저 기획자분이나 추가로 개발할사항에 대한 요구사항이 들어왔을때 개발기간중 가장 시간이 많이 소요 되는 부분은 로직에 대한 설계라고 생각됩니다. 제가 명쾌하게 해답을 드릴 수는 없지만 지금 질문자분께서 드신 생각을 꾸준히 유지한 채로 새로운 요구사항이 들어왔을때 "이 새로운 요구사항이 추가됨으로써 기존 로직에 대한 영향력이 있을까?" 또는 "만약 너무 응용된 것이 이닌 비슷한 요구사항이 추가된다면 지금 작성한 코드를 재사용해서 풀어낼수 있을까?" 라는 고민을 시작으로 업무를 진행하신다면 질문자문께 도움이 되지 않을까 싶습니다. 누구나 처음부터 완벽한코드를 작성할 수는 없습니다. 저도 처음 작성한 코드와 이것저것 공부하고나서 과거에 작성한 코드를 다시 살펴보면 아쉬운 점이나 더 좋게 응용할 수있는 코드가 많이 보이던것 같아요. 이것에 대해선 It 관련 서적중 리팩토링이나 클린코드와 같은 서적을 통해 같이 고민해보시면 좋을 것 같습니다. 인프런같은 곳에도 코드에 대한 강의가 있으니 강의를 보며 참고하시는 것도 좋은 방법이 될것 같습니다. 그리고 너무 미래에 확장될 기능에 대해서 고려하시는건 큰 도움이 안될 수 있습니다. 코드에 대해 확장 가능성이 있어 디자인 패턴을 적용하거나 하는 방식은 중요하지만, 어떤 업무에 대해 큰 기능이 추가 될 수 있으니 어떤 로직이든 열어두어야지 하는 방식은 좋지 않을 수 있습니다. 모순적으로 생각 될 수 있으나 간단하게 생각한다면 어떤 로직에 대해서 수평적인 기능은 열어두되 수직적으로 큰 기능이 추가될 가능성의 고민엔 너무 큰 비중을 하지 않으셔도 괜찮을것 같습니다. 이건 제가 읽었던 책의 내용중 하나를 정리한 내용입니다. '우리는 너무 먼 미래는 내다볼 수 없고, 정면에서 벗어난 곳일수록 더 어둡다. '예언'과 같은 작업은 경험에 기반한 추측을 벗어난 무모한 억측이다.' 라는 내용이 있었습니다. 먼저 질문자분께서 고민하시는 SOLID와 디자인패턴을 공부하시고 추가적으로 책에 관심있다면 앞서 말씀드린 클린코드나 리팩토링에 대해서도 같이 보시면 도움이 되실것 같습니다 :)

프론트 개발시 디자인 패턴이나 SOLID 적용을 위해서 고민 하시는군요. 정확히 어떤 상황에 처해 계신지 가늠해보기는 어렵지만 공통으로 고민해볼 수 있는 방법은 각 케이스를 다르게 처리하지 않고 최대한 같은 인터페이스로 처리하게 하려는 노력이 필요할 것 같아요. 사실 객체 지향에서 다루고 있는 인터페이스를 통한 추상화를 자바스크립트 에서는 같은 입력과 출력을 가지는 함수 혹은 같은 함수 시그니처를 가지는 객체 같은 방법을 써서 수행하거든요. 입출력 인터페이스를 통일시켜 보시면 어떤 형태로든 재사용성을 높일 수 있는 방법이 보일 것 같아요. 함수형태로든, 커스텀 hook 형태로든요. 그리고 너무 많은 고민을 해가며 매우 유연한 설계를 하기 보다는 적당한 유연성을 가지도록 설계하시는게 개발속도 측면에서 좋습니다. 매우 유연하게 설계했는데, 막상 작업 하려니 불편하게 되는 상황도 자주 발생 하거든요. 더 복잡해지기도 하구요. 요구사항이 늘어날 때 뭔가 반복되는 느낌이 든다면, 현재 구조를 리팩토링 하시는 방법으로 작업하시는게 좋을 것 같아요. 결론: - 함수 혹은 결제 수단의 인터페이스를 통일시킨다. - 공통으로 사용할 수 있는 hook을 만들어본다. - 너무 막연히 최고의 유연성을 추구하지 말 것. 컴퍼넌트 설계에 대한 내용은 아래 링크들에서 많은 아이디어를 얻었어요. - https://toss.im/slash-21/sessions/3-3 - https://www.youtube.com/watch?v=HYgKBvLr49c&t=7s