비전문가에게 리팩토링을 어떻게 설명합니까?

기술이 아닌 사람 (일반적으로 PHB 또는 고객)에게 리팩토링 (및 기술 부채)을 설명하는 방법은 무엇입니까? ( " 눈에 띄는 차이 가 없는데 한 달 동안 작업 비용이 듭니까 ?!")

업데이트 지금까지 모든 답변에 감사드립니다.이 목록은 적절한 사람들을 지적 할 수있는 몇 가지 유용한 유사점을 제공 할 것이라고 생각합니다 (PHB에 대한 참조를 편집하는 것이 현명 할 수 있습니다!)

큰 홈 시어터가 있고 물건을 추가하면 천천히 그러나 확실하게 큰 쥐가 뒤쪽에 둥지를 틀고 있습니다.

종종 부품을 교체하는 경우 종종 모든 부품을 교정 할 가치가 있습니다.

물론, 그렇게하면 이전에 작동하던 것이 시작했을 때보 다 더 잘 작동하지 않지만 다시 엉망으로 만들면 상황이 훨씬 쉬워 질 것입니다.

어쨌든 PHB 또는 고객이 이미 익숙한 일부 주제 영역 (예 : 자동차 또는 건설 등)과 유사한 비교를하는 것이 가장 좋습니다.

리팩토링은 모든 것이 깔끔하게 들어갈 때까지 여행 가방을 다시 포장하는 과정과 같습니다. 때때로, 그 과정에서, 왜 그렇게 많은 정크를 거기에서 얻으려고했는지 궁금해합니다.

기술 부채의 개념은 필요하지 않기 때문에 설명하지 않겠습니다. 대신 리팩토링에 초점을 맞추십시오. "더 나은"또는 "향상된"것이 아닌 프로그램 디자인을 변경하는 것이 아니라 변경해야 할 변경을 수용 할 수 있도록 변경하는 것입니다.

자동차 비유가 적합 할 수 있습니다. 자동차에 에어컨을 추가해야하지만 원래는 자동차 용으로 설계되지 않았습니다. 이상한 L 자형 에어 컨디셔너를 만들어야 할뿐만 아니라 다른 것들을 먼저 옮기고 환기 시스템을 바꿔야합니다.

또한 새로운 기능을 수용 할 때 리팩토링하는 것이 더 나은 전략이라고 생각합니다. 그렇지 않으면 "더 나은"것처럼 보이는 디자인으로 디자인을 변경할 수 있지만 실제로는 다음 기능 추가와 관련된 환경에는 적합하지 않을 수 있습니다.

나는 기술 부채라는 용어를 사용하고 그들이 이해하는 것 – 기업 부채와 직접 관련이 있습니다. 기술 부채는 대출을받는 것과 같습니다. 당신은 그것에 관심을 지불합니다. 예를 들어, 새로운 공장을 건설하고 직접 지불하거나 대출을받을 수 있습니다. 대출을 받으면 실제로 장기적으로 더 많은 비용을 지불하지만 조건이 맞으면 재정적으로 의미 가 있습니다 .

그러나 그러한 대출에 대해 25 %의이자를 지불하는 경우 지속 불가능한 입장에 처하게됩니다. 기술 부채와 동일합니다. 때로는 기술적 부채를지는 것이 합리적입니다. 그러나이자가 너무 높아서 지불해야 할 시점이 있습니다. 일부 기술 부채는 주택 융자와 같으며 일부는 신용 카드 부채와 같습니다. 응급 상황에서 신용 카드 부채는 중요하고 귀중한 자산입니다. 그러나 현명하게 사용하지 않으면 은행 (또는 원하는 경우 가구)이 파손될 수도 있습니다.

또 다른 예 : 마케팅 메일 한도에 $ 10,000를 지불하여 향후 더 많은 매출을 올릴 수 있습니다. 당신은 "판매 부채"를 지불하고 있습니다. 이것은 장기 지불에 따른 비용입니다. 이것을 코드 조각을 리팩토링하여 돈을 "지출"하려는 이유와 동일시하십시오. 두 경우 모두 즉각적인 보상은 없지만 향후 더 나은 성능을 위해 스스로를 설정하고 있습니다.

나는 대상 청중이 누구에게나 이야기 할 때 "xxxx 빚"이라는 용어를 유추로 사용하는 경향이 있습니다. 예를 들어, 운영 부채-이제 우리는 잘 작동하는 인쇄기이지만 하루 (또는 일주일) 동안 생산을 중단하고 새 기계로 업그레이드하면 출력을 25 % 늘릴 수 있습니다.

편집- 여기 에 또 다른 걸릴

봄 청소.

집을 개조하고 있지 않습니다. 방금 물건을 옮기고 먼지를 제거하고 있습니다. 더 이상 사용하지 않거나 더 이상 필요하지 않은 것을 버릴 수도 있습니다. 하지만 당신은 아무것도 추가하지 않습니다.

" 마우스 트랩을 사용해 본 적이 있습니까? 새로운 기능을 고수하고, 인터페이스를 변경하고, 버그를 수정하면 코드가 그렇게 보일 수 있습니다. 많은 자본을 소비해야 할 시점이 있습니다 (시간과 노력) , 비용이 많이들 것입니다.) 모든 움직이는 부품이 각각의 새로운 변경 또는 추가와 함께 잘 작동하는지 확인하거나 대신 디자인을 리팩토링하기 위해 시간을 따로 설정하여 변경할 때마다 관리해야하는 움직이는 부품이 줄어 듭니다. 수 것 리팩터링은 어떤 혜택이없는 것을, 최종 사용자의 관점에서,하지만 이점은 새로운 기능이 후 리팩터링을 추가 할 때마다 발생합니다.이 과정이 빠르고, 적은 버그를 소개하고, 그 후 저렴, 리팩토링 된 코드가 전반적으로 더 효율적이라는 것은 말할 것도 없습니다.

왜 우리가 처음에 Mouse Trap처럼 보이게했는지 궁금 할 것입니다.

• 때때로 무언가를 지금 당장 얻는다는 것은 단지 "작동하게"하기 위해 우아함과 효율성을 희생해야한다는 것을 의미합니다.
• 프로그래머가 자주 변경함에 따라 사용 가능한 언어 기능 및 기타 기술. 때로는 새로운 기능으로 인해 움직이는 6 개의 부품이 번거롭지 않게 대체 될 수 있습니다.
• 종종, 특징 C를 특징 A 및 B에 추가 할 때, 우리는 B가 결국 제거되고 D가 추가 될 것이라는 것을 모릅니다. C를 달성하는 한 가지 방법은 B와는 잘 작동하지만 D에서는 잘 작동하지 않을 수 있습니다.

더 나은 마우스 트랩을 구축하기 위해 끊임없이 돌아가서 복잡성을 줄이고 장소를 간소화해야합니다. 많은 기능을 갖춘 소프트웨어와 진정한 고품질 소프트웨어를 갖는 것의 차이점입니다. "

이것은 홈 시어터 비유의 약간 더 그래픽적인 버전입니다.

새로운 어플라이언스 (일명 새로운 기능)를 하나 더 추가하려면 어딘가에 설치할 수 있습니다.

다른 어플라이언스를 추가하려는 경우 확장 리드를 구매하면 시간이 좀 걸립니다.

그러나 추가 할 때마다 솔루션을 찾기가 더 어려워집니다. 그리고 당신은 자신을 노출하고 위험 ¹ 화재 [일명 버그]의, 당신은 아마도 주까지 모든 방법을 확대 할 수있는 벽에 새로운 소켓을 넣어 사람을 지불하는 거액을 꺼내해야합니다 회로 보드 또는 그 이상.

¹ PHB가 잘 이해하지 못하는 또 다른 점 : "만 일어날 수 있다면 걱정할 것이 무엇입니까?"

리팩토링-의류 캐비닛 / 도구 서랍을 구성하는 것과 같습니다.

• 옷 / 도구를 모두 버리지 마십시오.

• 당신은 그들이 결코 무질서해서는 안된다고 주장 할 수 있습니다. 그러나 그들은 그렇습니다.

코드처럼. 특히 시간이 지남에 따라 성장함에 따라.

그리고 당신이 그것을 청소하지 않으면, 당신은 당신이 항상 좋아하지만 찾을 수없는 사랑하는 티셔츠 또는 렌치에 무슨 일이 있었는지 궁금해 할 것입니다!

"코드 유지 관리" 라고 말하고 싶습니다 . 비 기술적 인 사람이 친숙하고 비 기술적 인 세계관에 맞는 단어를 사용하는 것이 중요합니다. 비전문가 (고객)가 응용 프로그램 유지 관리에 익숙한 경우 코드 유지 관리 및 응용 프로그램 유지 관리를 쉽게 수행 할 수 있습니다. 동일하지 않더라도 여기서 최종 고객은 개발자이거나 시스템을 유지 관리하는 사람들이라고 설명 할 수 있습니다.

고객이 필요로하는 경우 처음부터 자동차를 맞춤화하는 것을 전문으로하는 자동차 정비공이라고 가정 해보십시오. 자신의 초대형 리무진에 항상 새롭고 반짝이는 것을 넣을 때마다 가게에 돌아 오는이 고객이 있습니다.

멋진 사운드 시스템이 설치되면 전선을 통과시키고 올바르게 연결하는 작업을 부지런히 수행하십시오. 그는 하루 후에 외출하고 평소처럼 행복하고 잘 지불합니다.

다음 달에 그는 다시 오지만 이번에는 본격적인 홈 시어터를 설치하고 싶어합니다. 다시 한 번, 당신은 리무진에 들어갑니다. 전문가이기 때문에 사운드 시스템을 다시 방문하고 자동차 주변의 와이어를 연결하기위한 튜브 시스템을 설치하여 유지 관리를 더 쉽게 만듭니다. 이 방법으로 전선을 보호하고 빼기 쉽고 더 추가해야 할 경우에도 쉽게 수행 할 수 있습니다. 따라서 오래된 전선을 벗기고 튜브를 설치 한 다음 사운드 시스템과 시네마 용 추가 전선을 통과시켜 모두 닫으면 완료됩니다.

고객이 기존 사운드 시스템을 교체하도록 요청하지 않았다는 사실을 알고 교체 및 튜브 비용의 일부를 긁어 냈습니다. 그러나 당신은 여전히 ​​거래에서 돈을 버는 것입니다. 당신이 처음했던 것처럼 시스템을 함께 던져 버린 것만 큼은 아닙니다.

한 달 후 그는 돌아와서 이번에는 조명 시스템을 원하고 이전 주에 이전 스피커를 손상시킨 새로운 스피커를 원합니다.

모든 것을 깔끔하고 깔끔하게 유지했기 때문에 튜브를 통해 새로운 조명 와이어를 빠르게 작동시키고 시스템을 설치하고 스피커를 교체 할 수 있습니다. 그러나 이번에는 당신이 훨씬 더 빨리 끝났으며, 리팩토링 은 게임에서 당신을 계속 유지함으로써 지불했습니다.

완벽하게 좋은 전선을 리핑하고이 여분의 튜브를 모두 설치 한 것에 대해 당신을 비 웃었던 경쟁자는 여전히 그의 고객 만족을 위해 고군분투하고 있습니다. 물론 그는 대부분의 시간보다 빨리 끝났지 만 시간이 지남에 따라 고객은 점점 더 지연되고 작업의 전반적인 품질이 저하되고 있다고 불평합니다.

이를 살펴보면 비즈니스에 머무를뿐만 아니라 최고의 총을 목표로하는 목표는 고객의 요구를 충족시키기 위해하는 일과 삶의 질을 향상시키기 위해하는 일의 균형을 유지하는 것입니다. 고객이 두 가지 모두를 지불하는 경우는 드물기 때문에 면밀히 관리해야합니다. 2 배의 비용으로도 사전에 능동적으로 행동함으로써 유지 관리 비용을 생산성의 안정적인 비율로 유지할 수 있습니다.

소프트웨어는 고객과 관리자가 효과를 느끼기 전에 프로그래머가 디지털 덕트 테이프로 아주 오랫동안 재생할 수 있다는 점을 제외하면 동일합니다. 불행히도 그 당시에는 일을 다시 수행하는 비용은 존재하는 덕트 테이프의 양과 상기 덕트 테이프의 평균 수명과 관련하여 기하 급수적으로 증가합니다.

따라서 시스템을 계속 리팩토링하는 것이 중요합니다. 종종 경험을 통해 똑같은 일을하는 더 효율적인 새로운 방법을 보여 주거나 유사한 기능을 결합하고 중복을 악용 할 수 있습니다. 이것이 우리가 시스템을 간결하고 의미있게 유지하는 방법입니다. 시간은 수요를 충족시키기 위해 시스템을 지속적으로 리팩토링하면 유지 보수에 투입되는 양을 제어함으로써 생산성을 일정하게 유지할 것임을 보여줄 것입니다.

덕트 테이프를 배치하면 차선의 시스템을 운반하는 비용으로 생산성이 순간적으로 향상됩니다. 시스템의 다른 측면을 해칠 때 즉각적인 생산성을 선호 할 때마다 기술 부채가 발생합니다. 차용 자본에 대한이자가 차용 시간이 빨리 유지 보수를 더 많이 발생시키고 시스템 취약성을 증가시켜 팀이 생성보다는 유지 보수에 추가 자원을 소비하게하므로 부채 비유는 좋습니다. 차입이 계속 줄어들지 않으면 대부분의 자원은이자 상환에 사용되어 개선이 거의 이루어지지 않습니다. 기술 부채는 대부분의 자원이 시스템을 연삭 상태로 유지하여 가능한 다른 모든 개선 사항을 중단시키는 데까지 기술 자원을 낭비합니다.

따라서 궁극적으로 문제는 우리가해야하거나하지 말아야하는 것이 아니라 관리자와 고객이 디지털 덕트 테이프를 사용하여 인위적으로 부풀린 생산성 수치에 의존 할 수 있다고 생각하는 것이 윤리적입니다. 어떤 사람들은 그것이 사업 결정이라고 생각하지만, 솔직히 이것은 관리자가 이해하지 못하기 때문에 그렇게 결정됩니다. 결국 누군가는 리팩토링을 많이하거나 새로운 시스템으로 마이그레이션하여 부채를 지불해야합니다. 프로그래머, 시스템 유지 보수를 유지하는 것은 궁극적으로 우리에게는 작업의 본질적인 부분이기 때문에 리팩토링을 요구할 필요가 없습니다.이를 이해하지 못하면 소프트웨어 엔지니어링이 무엇인지 이해하지 못합니다. 이것은 이미 중요한 부채가 발생한 시스템이 있고이 부채를 상환하려면 지불 인의 결정이 필요하다는 것을 알았습니다. 당신의 직업은 그러한 상황이 최소한 차용을 멈추기 위해 당신의 역할을하는 것입니다. 이 부채가 발생했습니다미국은 아마도 우리가 더 잘 알지 못했기 때문에 그것을하라는 압력을 받았기 때문에 여전히이 빚을졌으며, 빚을 이해하지 못하도록 빚을 건 사람들은 종종 그것을 제대로 관리 할 수 ​​없습니다.

여기 당신의 소프트웨어가 다 있습니다. 당신이 그것을 좋아하기를 바랍니다 .... 그런데, 난 신용 카드를 최대한 사용했습니다.

리팩토링의 요점은 설계를 단순화하고 비 효율성을 제거하는 것입니다. 이를 통해 버그를 쉽게 수정하고 향후 새로운 기능을 추가 할 수 있습니다.

디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 코드를 가능한 한 영리하게 작성하면 정의에 따라 코드를 디버깅하기에 충분하지 않습니다.

코드에 새로운 기능을 계속 추가하면 리팩토링이 빠르게 비용을 지불합니다. 오류율이 낮고 디버깅 속도가 빠르고 수정이 빠릅니다.

소프트웨어 작성은 큰 논픽션 책이나 백과 사전을 작성하는 것과 매우 유사합니다.

첫 번째 초안은 항상 짜증납니다. 항상 재구성하고, 필요하지 않은 섹션을 제거하고, 전체적으로 일관된 스타일을 보장함으로써 항상 향상 될 수 있습니다.

수정해야 할 때마다 가장 간단한 작업은 새 섹션을 추가하고 몇 단어를 변경하는 것입니다. 그러나 개정 내용이 쌓이면 책의 구성이 사라지기 시작합니다. 따라서 추가 재구성 단계를 거쳐야합니다. 그렇지 않으면 책이 말도 안되는 혼란이됩니다.

데스크톱 컴퓨터를 예로 들어 보겠습니다. 타워, 모니터, 키보드, 마우스, 프린터, 스캐너 및 스피커가 있습니다. 궁극적으로 원하는 것은 멋진 책상입니다. 맹목적으로 연결하면 몇 분 후에 모든 것이 원하는 방식으로 설정됩니다. 글쎄 ... 거의 원하는대로.

하루 후에 스피커의 밸런스를 변경하면 실수로 왼쪽 및 오른쪽 스피커를 잘못된 영역에 놓았으므로 위치를 바꾸고 싶습니다. 하지만 아뇨! 꼬인 끈으로 된 정글이 있습니다. 스피커 이동을 계속하면 마우스 코드가 연결되고 마우스가 스피커와 함께 드래그됩니다. 또한 키보드에는 느슨 함이 없습니다. 책상에서 무릎 위로 키보드를 옮길 수있었습니다.

마우스와 키보드를 뽑았다가 다시 삽입하면 모든 것이 고정됩니다. 그러나 이것은 향후 재구성 및 향후 추가에 도움이되지 않습니다. 또한 정글을 통해 마우스와 키보드 코드를 짜는 것은 번거 롭습니다.

더 나은 해결책은 모든 코드를 다시 연결하여 각 코드가 다른 코드를 방해하지 않는 깔끔한 방법으로 다시 연결하는 것입니다. 이제 미래의 변화는 쉽고 계속 쉽습니다. 당신은 나중에 큰 이익을 위해 약간의 선불 투자합니다.

핵심은 원래 솔루션이 대부분 작동했다는 것입니다. 그것은 리팩토링에 관한 것입니다 : 그것은 처음부터 작동하지만, 미래의 변화를 쉽게하기 위해 (스피커 이동) 이미 존재하는 방법을 변경해야합니다.

그것은 전날 밤에 거칠고 미친 파티 후에 집안을 청소하는 것과 같습니다.

거실이 완전히 쓰레기라고 가정 해 봅시다. 집은 여전히 ​​집이고 거실은 여전히 ​​거실입니다. 그것은 작동하지만 그것이 될 수있는 방식이 아닙니다. 혼란을 쳐다 본 후에는 청소가 필요하다는 것을 알게됩니다.

쓰레기를 포장하기 시작합니다. 벌써 좋아 보인다 따라서 방을 둘러보고 가구를 똑바로 세우기로 결정합니다. 한 조각을 다시 넣은 다음 다음 조각을 넣습니다. 와우, 방은 정말 좋아 보인다. 당신은 자랑 스럽습니다.

여동생이 들어 와서 방이 쓰레기처럼 보이면 책장을 고치고 카펫을 진공 청소기로 청소해야합니다. 그녀가 옳아. 방은 정말 좋아 보인다.

주변을 둘러보고 창 높이가 모두 같은 높이에 있으면 훨씬 더 잘 보일 것입니다. 끝난. 와우, 방은 훌륭하다.

코드를 같은 방식으로 취급하십시오.

쉬운!

예를 들어 보자 ... 모두가 인생에서 사랑하는 사람에게 편지를 썼습니다. 편지에서 우리는 일반적으로 작곡에도 관심을 기울이기 때문에 사랑하는 사람이어야합니다.

그래서, 당신은 당신의 텍스트를 가지고 있습니다 ... 의미는 어느 쪽이든 통과하지만 당신은 모든 것이 멋지게 들리기를 원합니다 ! 권리?

리팩토링, 같은 것 ... 같은 정보 조각, 다소 작지만 구성이 더 좋습니다. 그리고 아마도 독자가 더 잘 검토하게 될 것입니다.

또 다른 예-잡지 기사 쓰기. 두 작가는 둘 다 "그들의 물건"을 알고 있지만, 유일한 차이점은 하나는 "쓰기 방법"을 알고 다른 하나는 그가 이와 같은 답변에서 쓰는 법을 배운 것입니다.

누구의 기사를 기억하십니까?

극장을 짓는 것과 같이 실제 세계의 것들과의 모든 비유는 끔찍합니다.

리팩토링 코드는 ... 리팩토링 코드와 같다고 설명해야합니다. 물리적 아날로그가 아닌 방식으로 소프트웨어를 변경할 수 있습니다. 일이 점점 더 복잡 해짐에 따라 코드베이스의 크고 작은 부분을 리액터 (또는 원하는대로 다시 실행)하여 복잡하지 않고 복잡성을 계속 증가시킬 수 있어야합니다.

왜 우리는 리팩토링합니까? 리팩토링되지 않은 코드는 유지 및 변경하는 데 분당 비용이 더 많이 들고 결국 더 문제가되기 때문입니다.

리팩토링에서 흥미로운 점은 코드베이스를 다시 실행하지만 최소한 처음부터 기능은 동일하게 유지된다는 것입니다.

리팩토링은 무언가를 정리하고 물건을 '숙박'하기위한 새로운 장소를 제공하는 것과 같습니다

쉽고 간단하며 많은 시간이 소요될 수 있습니다. 때때로 나는 그 사람 X를 추가하여 X가 엄청난 혼란을 겪었고 그것을 정리해야합니다.

나는 여기서 아무도 언급하지 않은 또 다른 예를 생각했다.

방정식을 재정렬 할 때 의미를 바꾸지 않고 더 읽기 쉽고 사용하기 쉽도록 '주변을 움직입니다' .

그들에게 간단한 수학 방정식을 줘. 예를 들면 다음과 같습니다.

어느 것이 더 간단합니까?

y = x + x

또는

y = 2x

리팩토링은 간단한 수학 방정식 대신 알고리즘을 사용한다는 점을 제외하고는 비슷한 개념입니다. 주요 아이디어는 동일한 결과를 얻을 수 있기 때문에 두 가지 방식으로 전환 할 수 있다는 것입니다.

수행 할 수있는 가장 간단한 리팩토링은 이름을 바꾸는 것입니다.

doX() { ... }
{
   doX()
}

의미가 무엇인지 알지 못하기 때문에 doX라고하는 것을 원하지 않기 때문에 이름을 좀 더 설명이 필요한 다른 이름으로 바꾸고 사용했던 곳을 대체합니다.

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

이렇게하면 사람들이 애플리케이션을 이해하고 수정하는 시간이 줄어들 기 때문에 문제 나 개선이있을 때 나중에 비용을 절약 할 수 있습니다. 추가 비용을 절감 하기 위해 사용중인 언어에 따라 자동으로이 작업을 수행 하는 무료 도구가 있습니다. 이러한 도구는 또한 제한적이지 않으며 라이센스를 직접 사용하는 경우 별도의 승인없이 별도의 조치를 취해야합니다.

그림은 천 단어를 말합니다. 예를 들어 리팩토링에는 두 가지 사용 사례가 있습니다.

• 일이 제대로 완료되지 않은 경우 :

• 일이 지루할 때 :

참고 문헌

• xkcd : 좋은 코드

• xkcd : 시간 가치가 있습니까?

리팩토링 에서 주어진 답변을 고려하고 기술이 아닌 사람에게 설명하지 마십시오. 리팩토링은 다음에 대해 알 필요가없는 기술 활동입니다.

물론 많은 사람들이 품질에 따라 결정되지만 일정에 따라 더 많이 결정한다고 말합니다. 이 경우 더 논란의 여지가있는 조언을합니다 : 말하지 마십시오!

파괴적인가? 나는 그렇게 생각하지 않습니다. 소프트웨어 개발자는 전문가입니다. 우리의 임무는 가능한 한 빨리 효과적인 소프트웨어를 만드는 것입니다. … 일정 중심의 관리자는 내가 할 수있는 가장 빠른 방법을 원합니다. 내가하는 일은 내 사업이다. 가장 빠른 방법은 리팩토링하는 것입니다. 따라서 리팩터링합니다.

(리팩토링, Martin Fowler, 2000, 61 쪽)

물론 리팩토링 이외의 작업을 한 달 동안 보내면 효과가 없지만 어쨌든 일반적으로 나쁜 생각이라고 생각합니다. 현재 또는 다음 작업을 쉽게하는 데 필요한 정도로 리팩터링하는 것이 훨씬 좋습니다. 또는 방금 작업 한 코드를 정리합니다.