[💬] 게임 개발자 아무나 들어와바

[Year_of..(decay4934)]

내가 게임을 개발하고 있는데 추가하고 싶은 기능이 있거든

근데 이게 기획 근간을 좀 흔드는거라 리팩토링을 좀 크게 할 것 같은데

기존 코드 최대한 재사용하면서 버리는 코드 최소화 vs 아예 싹 뜯어고쳐서 변경사항 맞춤

님들은 어떻게 개발할것임?

[랩키(nation0672)]

리팩토링의 기본은 출력값이 동일한 상태로 구조를 뜯어고치는거지. 난 그래서 함수를 단위별로 엄청 쪼개서 이름 지어 놓은 다음에 기능 추가할 부분 확인하고 구조개선함

[Year_of_agi(decay4934)]

음 둘 중에 고르자면 최대한 재사용?

[랩키(nation0672)]

@Year_of_agi 구조만 개선할거면 동작하는건 냅둬야지.

[Year_of_agi(decay4934)]

음 비유하자면 테트리스게임을 블록 내려오는 건 유지하면서 리듬게임으로 치환하는 느낌의 변경이긴 한디

[랩키(nation0672)]

@Year_of_agi 팁을 주자면 함수를 최대한 분리해서 static 함수로 만들어보셈. 그러면 의존성이 분리 될거고 내 코드를 최대한 살리면서 버릴 부분을 찾을 수 있게됨

[Year_of_agi(decay4934)]

함수를 최대한 static함수로? 오키 고마워

[랩키(nation0672)]

@Year_of_agi 리팩토링은 커플링 제거부터 시작된다. 많이 하다보면 늘꺼야

[Year_of_agi(decay4934)]

커플링 제거.. 메모.. 고마워

[Indie 1(175.124)]

경험이지 싹다 뜯어고쳐봐

[Year_of_agi(decay4934)]

님이라면 어케할것?? 뜯어고치는 쪽으로 가려면 갈 수는 있는데 역시 좀 망설여짐 기존에 쓴 코드 아까워서

[익명(plastic4826)]

무조건 나중에쓴코드가 더 진보되어있음 귀찮고 오래걸릴뿐이지 근간을 흔든 결과로 마음에 쏙드는 결과가 나온다면 미련없이 버림

[Year_of_agi(decay4934)]

으으으으으으음.....

[디시콘쓸려고만듦(kimmsssiu)]

갈때까지 갔으면 변수 이름 하나만 바꿔도 참조 끊기는 것 부터 이미 만들어둔 DB까지 싹 다 갈아야하니까 쉽게 못 건드릴거고 싹 다 갈아도 상관없는 수준이면 처음부터 다시 만드는게 훗날 유지보수 고려하면 훨씬 나은 선택

[Year_of_agi(decay4934)]

아예 처음부터?? 으음......................

[디시콘쓸려고만듦(kimmsssiu)]

@Year_of_agi 다른 팀원이 쌓아둔 데이터들 참조 끊기거나 이미 그 구조를 기반으로 설계해둔 컨텐츠들이 무너지는게 문제면 고민 좀 해봐야겠지만, 댓글보니까 그런건 아닌 것 같고, 걍 지금 작성해둔 코드가 아깝다는 것 같은데 그 수준이면 처음부터 다시 잘 설계해서 만드는게 훨씬 나은 결과물이 나올거임

[Year_of_agi(decay4934)]

으으으으음.....................이 항아리가 아니야 해야되나

[익명(rent1081)]

먼 길이긴 했지만 조금 갈아엎은 적 있음 하고나면 만족함 - dc App

[Year_of_agi(decay4934)]

음 역시 갈아엎는게 맞나?

[뜌따이(ultimate3901)]

기존 코드는 쓸만하면 쓰는 거고, 오히려 기존 코드가 제약이되서 머리만 아파질 수도 있음 애초에 리펙토링을 크게해야겠다는 판단이 섰으면 기존 구조로는 신규 기능 커버가 불가능하다는 거지. 벽돌집에서 콘크리트집으로 바꿔야하는데 벽돌집에서 쓸만한 게 뭐 얼마나 있겠음 장난삼아 하는 말이지만 Ctrl+a+delete는 치료율 100%의 특효약이라고 말하고 다님

[Year_of_agi(decay4934)]

그정도란 말인가........

[Year_of_agi(decay4934)]

댓글 여론이 갈아엎기 강세니까 아예 처음부터 제대로 설계해보겠슴!!

[Indie 2(114.200)]

네.... 싹 다 처음부터 하시는 것을 추천합니다. 당신은 이미 정답을 알고 계셨어요!!

[Indie 3(211.200)]

쌓아온게 크지 않으면 걍 새로해

[Indie 4(122.34)]

메인 로직이라면 새로 작성하는걸로 레거시 코드가 계속 발목 잡아서 재사용안됨

[Indie 5(49.170)]

처음 구조를 만들때 자기가 만든 스케일이 있을거고 그건 자기자신이 가장 잘 알고있는데 그걸 갈아엎어야할 정도의 무언가를 추가하고자하는건 모순임. 갈아엎지 않는 선에서 그 기능을 축소하든 변화시키든해서 추가하면되고 그것조차 안되면 과감히 그기능은 추가하지말아야한다고 보고있음

[Indie 4(122.34)]

비개발자들이 이전 게임 로직 가져다가 조금만 바꿔서 빨리 만들 수 있을까 하지만 그게 더 일을 크게 만듬. 기획은 항상 바뀌거든 그걸 기존 뼈대에 확장해서 쓰겠다는 얕은 생각을 하고 개발자가 그걸 허용하는 순간 지옥문 열림

[익명(content7365)]

그건 아예 새 겜을 만들어야함. 아예 시스템이 갈아치워지는게 정상적인게 아님. 예상가능한 유저가 이런 스킬이 있음 재밌겠네 같은 기능이었다면 네 무능을 입증하는거고. 처음 기획에서 생명주기와 콜백을 체계적으로 정의내릴수 있었을텐데, 못한거면, 그건 게임 개발 이전에 기획자로써 실격이야. 협업 정신자체가 없단거니까. 프로그램에 전문적이지 못하더라도 리드 개발이나 하다못해 선임한테 묻고 상담해서 함께 생명주기를 설정했어야지. - dc App

[익명(hotkey02)]

나는 재사용 하는 편임 코드를 사이드 이펙트 최소화하는 방식으로 작성하기도하고 리팩토링도 어떤식으로 수정해야 할지 명확하면 클로드 코드 돌리면 되니까