[💬] 만약 코드짤때

[익명(27.67)]

자기가 봐도 이건 너무 스파게티 코든데? 싶은 코드가 있는데 어떤식으로 최적화할지 잘 모르겠으면
찾아보면서 최적화 먼저 하고 개발을 하는게 맞을까 아니면 일단 구현은 다 시켜놓고 나중에 코드를 고치는게 나을까?

[익명(121.150)]

그러니까 기획이 중요하다는 거임. 그걸 어떻게 나중에 고치겠음

[ㅇㅇㅋ(59.7)]

나중에.. 하다가는 돌이킬 수 없게되지 않을까?

[익명(175.223)]

그걸 위해 존재하는게 인터페이스란 개념임 - dc App

[익명(175.223)]

인터페이스가 보통 배우기론 다형성 추구.. 업 캐스트.. 이런 용도로 인식하는데 말그대로 코드의 유즈케이스를 추상화하는 용도로도 강력함 - dc App

[익명(175.223)]

너가 게임에서 뷰라면 인터렉션, 컨트롤러라면 시퀀스, 모델이라면 엑세서를 설계단계에 유즈케이스를 정의 후 명확히 정의해둔다면 - dc App

[익명(175.223)]

그다음 내부에서 기능을 실제로 실행하는 비즈니스 로직은 얼마든지 리펙토링해도 외부에 노출되는 인터페이스는 일관되게 만들면 이런 유지보수 걱정이 훨씬 가벼워짐 - dc App

[H1(121.135)]

이거에 대한 예시 같은 것 좀 볼수 있음? 내가 지금 딱 이부분을 하면 코딩좀 수월해질 것 같은데

[익명(175.223)]

방법론적인거라 코드로 예시를 줘도 크게 도움이 안될거같음.. - dc App

[익명(175.223)]

기존의 C#에도 ICloneable같은 목적성이 존재하는 인터페이스가 있잖아. 먼저 너가 만들려는 컴포넌트 혹은 스크립트의 기능이랑 이게 어떤 과정으로 수행되며 외부 컴포넌트와 어떻게 교류되는지 사용예를 정의하고 그게 표면에 노출되게 구현하라는 얘기야 - dc App

[익명(175.223)]

그러면 그 과정자체가 코드가 스파게티가 되는 것을 제한하고 차후 내부의 구현을 수정해도 흐름상 외부의 연결까지 일일히 수정하는 일을 줄일 수 있다는 거지 - dc App

[익명(175.223)]

이게 익숙치 않다면 그냥 OOP 공부가 부족한거고 검색만해도 관련 정보가 많으니까 읽어보면 될듯 - dc App

[H1(39.7)]

아 그렇구나 외부 연결만 일정하면 내부를 이상하게 뜯어고쳐도 상관이 없겠구나 내가 맨날 한쪽 코드에서 뭔가 큰 변화가 일어나면 다른 코드에서 에러가 주욱 뜨면서 한참 바꿔줘야 하는 경우가 생기더라고 인터랙션 시퀀서 액세서 등을 유즈케이스 정의후 명확하게 설계해두면 이런 일을 막을 수 있다는 거지?

[H1(39.7)]

그 후에는 인터페이스로 구성된 함수들만 외부에서 호출하도록 하면 되겠네 oop나 유즈케이스에 대해서 좀 찾아보고 더 공부해볼게 진짜 고맙다!

[H1(39.7)]

근데 올렸던 글은 어디갔어 ㅠㅠ 그거 복사 안해놨는데

[익명(175.223)]

언제든 이슈는 생길 수 있고 그것을 일일히 단번에 완벽하게 만들어둔다는건 불가능하기 때문에 차라리 이런 컨벤션 습관을 들이는게 낫다는게 나의 생각.. - dc App

[익명(175.223)]

그게 익숙해지면 본인의 디자인 패턴이 되는거고.. 거시화하면 아키텍처가 될 수 있지.. - dc App