https://gamasutra.com/blogs/MasonRemaley/20210628/384189/When_To_Rewrite.php

다시 쓰는 시기

좋아, 왜 안돼? :)

백스토리

그래서 프로밋 로이의 이 트윗은 최근에 많은 관심을 받았고, 정말 훌륭한 조언이라고 생각한다.

결국 많은 건축과 인프라 코드를 구축하게 되는 사람으로서, 내가 충분히 강조할 수 없는 한 가지가 있는데, 바로 가장 간단한 일을 한다는 것이다. 미래의 요구 사항을 상상하거나 잘못 정의된 잠재적 사용 사례를 지원하려고 하지 마십시오. 그것은 항상 나중에 바뀔 것이다.

초심자들은 이 충고를 듣는 데 어려움을 겪는 경향이 있다. 나는 이것이 부분적으로 많은 학교들이 여전히 반대되는 접근법을 가르치기 때문이기도 하지만 계획 자체가 매력적이기 때문이라고 생각한다. "물론, 이번에는 내 계획이 무산되지 않았지만, 다음 번에는 달라질 거야!"

이것이 좋은 조언인지 확실하지 않은 경우, 응답에 동의하는 이 주제에 대해 신뢰해야 할 몇 가지 사용자:

경험이 적은 개발자들이 미래의 요구사항/애플리케이션에 대한 설계가 순포지티브로 얼마나 드물게 나타나는지를 이해하기는 어렵다. https://t.co/lusGdzkfd3

나는 많은 계획을 세웠고, 그것은 항상 시간 낭비였고, 어쨌든 나는 큰 덩어리를 다시 써야 했다. 왜냐하면 요구사항이 바뀌었거나, 아니면 내가 코드를 쓰기 전까지 그 문제를 이해하지 못했기 때문이다.

좋아, 그럼 이제 결정됐어?

좋아

내 소릴 들어보자.

문제

그래서, 당신은 확신하고 있었군. 당신은 이 충고를 마음에 새기고, 가능한 한 단순하게 유지하는 방법의 각 단계마다 거대한 소프트웨어를 만들기 위해 떠나게 된다. 언젠가는 피할 수 없는 일이 일어날 것이다.

너는 비종교적인 변화를 만들어야 한다.

괜찮아! 결국 이런 날이 올 줄 알았잖아! 사실, 네가 계획했잖아! 하지만… 이 시나리오를 처리하는 가장 생산적인 방법은 무엇일까?

때때로, 새로운 니즈를 지원하기 위해 이미 구축한 것을 어떻게 수정할 수 있는지 쉽게 알 수 있다. 어떤 때는, 당신이 만든 것이 현재의 니즈와 너무 상충해서 처음부터 다시 쓰는 것이 더 나은 접근법처럼 보일 때도 있다.

물론 그것은 트레이드오프지만, 이 포스트에서 나는 어떤 상당한 규모의 시스템에서도 다시 시작할 가치가 있는 것은 매우 드물다고 주장하고 싶다.

여기서 문제는 몇 줄의 코드를 교체하느냐가 아니라, 어떤 방법으로 교체하느냐 하는 것이다. 원래 코드가 남아 있지 않을 때까지 시스템을 점진적으로 변경할 수 있으며, 그것은 유효한 옵션으로, 이 주장의 목적상 나는 다시 쓰기를 고려하지 않는다.

보통 처음부터 다시 쓰고 싶은 유혹은 두 가지다.

1. 이미 한 번 썼는데, 지금 가지고 있는 지식으로 다시 쓰려면 얼마나 걸릴까?
2. 네가 지금 하려고 하는 것은 네가 이미 지었던 것과 상충하고 있어, 점진적으로 변화를 만드는 것은 너무 어려울 거야!

문제는, 이 두 가지 믿음이 서로 모순된다는 거야!

당신이 짓고 있는 것이 이미 지은 것과 너무 비슷해서 다시 쓰기가 쉬울 것이라는 것이 사실이라면, 그것을 다시 쓰는 것은 의미가 없다. 만약 그것이 너무 달라서 점진적으로 그것을 수정하는 것이 까다롭다면, 다시 쓰는 것 또한 엄청난 투자가 될 것이다- 그것은 분명한 승리가 아니다.

발생할 수 있는 일

여기, 현실적으로, 대규모 재작성 중에 일어나는 경향이 있다.

일은 순조롭게 시작된다. 넌 기본적으로 이미 가지고 있던 것을 만들고 있지만, 더 깨끗하고, 기분도 좋아.

그리고 나서 문제가 시작된다. 알고 보니, 원래 하던 대로 일을 처리한 데에는 사실 좋은 이유가 많이 있었다. 그리고 당신은 그 이후로 대부분의 것들을 잊어버렸다.

네 새 디자인이 잘 안 되더라. 오, 그래, 괜찮아, 가는 대로 조절해도 돼-오, 그것도 별로 효과가 없어.

…

등등.

결국, 다시 쓰는데 많은 시간을 소비한 후에, 여러분은 기본적으로 여러분이 이미 가지고 있던 것을 다시 만들어내거나, 새로운 것을 희생하면서 기존의 문제를 해결하는 것을 하게 된다. 때로는 더 나은 시스템으로 귀결되기도 하지만, 대개 이전 구현에 대한 점진적인 변경을 통해 보다 신속하게 구축할 수 있었던 시스템이다.

당신이 결정 시간에 비용을 지불하지 않기 때문에 다시 쓰기로 결정하는 것은 쉽다. 일련의 점진적인 변화를 통해 목표를 달성하기로 결정하는 것은 어렵다. 왜냐하면 어떻게 해야 하는지에 대해 전면적으로 생각해야 하기 때문이다. 가끔은 불가능해 보이기도 하지만, 종종, 당신은 단지 그것에 대해 조금 생각할 필요가 있다.

그렇다면, 언제 다시 써야 할까?

IMO, 코드 조각이 작거나 매우 잘 캡슐화되었을 때만, 다시 쓰기의 비용이 명백해지거나, 점진적으로 변경을 시도했다가 실패한 경우.

일하는 시스템은 귀중한 자산이다. 그건 효과가 있다. 그것은 당신이 새로운 아이디어를 저렴하게 시험할 수 있게 해준다. 그것을 당연하게 여기지 마라.