깨진 창문을 수리하지 않는 것이 언제 가능합니까?

깨진 창과 관련하여 리팩토링이 향후 활동에 가장 적합한 시간이 있습니까?

예를 들어, 기존 내부 시스템에 일부 새로운 기능을 추가하는 프로젝트가 지금까지 시스템에서 작동하지 않았으며 작업 할 수있는 짧은 시간이 지정된 팀에 할당 된 경우- 이 시나리오에서 마감 시한을 맞추기 위해 기존 코드에 대한 주요 리팩토링을 연기합니까?

리팩토링은 진행중인 프로세스 여야합니다. 여전히 약간 불완전한 작동 및 테스트 구현으로 요구 사항을 충족시키는 것만으로는 충분하지 않습니다.

"작동하게하고 더 잘 작동하게하십시오" .

나는 그 인용문을 어디에서 읽었는지 기억할 수 없지만 이것이 리팩토링을 잘 적용하는 열쇠이며, 그렇지 않으면 그것을 전문가가 아닌 것으로 계산합니다.

지속적인 리팩토링은 요리하는 동안 유출 물을 닦아내고 식사를 마친 후 설거지를 청소하는 것과 같습니다. 대상 리팩토링은 더러운 부엌을 찾는 것과 같지만 더러운 유리를 씻을 시간이 있습니다. 당신은 오히려 더러워진 부엌에서 살기를 원하십니까?

코드가 작동하면 코드를 리팩터링하여 가능한 최상의 구현을 보장 할 수 있습니다. 익숙한 작업을 수행하는 경우 최상의 코드를 처음 구현하는 것일 수 있지만 작업을 다시 확인하려면 시간이 조금 걸립니다. 코드를 개선 할 수있는 것처럼 보이는 경우 리팩토링하여 코드가 최대한 간결하고 깨끗해야합니다. 즉, 기술 부채가 줄어들고 다음에 코드를 처리해야 할 때 쉽게 읽고 리팩토링 할 수 있습니다. 이것은 TDD mantra "Red-Green-Refactor"의 핵심 가치입니다. TDD에서 주로 복제를 제거하기 위해 리팩터링하는 경우에는 리팩터링 될 수있는 다른 클래스 (예 : 큰 클래스, 긴 메소드,

자신이 주요 재 설계에 직면 한 경우, 특히 일정에서 시간이 매우 부족한 경우 잠시 중단 할 수 있습니다. 그러나 이것은 코드의 기능이 손상되지 않으며 구현이 요구 사항을 계속 충족시킬 수 있다는 것입니다. 이런 상황은 드물게 발생하며 계속 진행하면서 계속 리팩토링하는 경우 상황이 더 드물게 유지되도록 도울 수 있습니다. 그러나 더 중요한 것은 중요한 변경 사항을 너무 오래 남겨 둘 위험이 없다는 것입니다. 그렇지 않으면 나중에 훨씬 더 많은 작업 부하가 발생하여 수정 비용이 훨씬 많이 들거나 결국 더 많은 비용이 발생할 수 있습니다 프로젝트 실패.

많은 사람들이 리팩토링 과 리엔지니어링에 대한 정의를 혼동하는 경향이 있다는 인상을받습니다 . 이 두 용어는 매우 다른 상황을 관리하기위한 전략을 설명합니다. 리엔지니어링하려는 경우 시스템의 동작을 변경할 수있는 과감한 변화를 약속합니다. 이로 인해 일부 테스트가 무효화되고 새로운 테스트가 필요합니다. 리팩터링 할 때 시스템이 계속 정확하게 작동하는지 확인 합니다변경하기 전과 동일하지만 코드 수명이 길고 시간이 지남에 따라 유지 관리가 더 쉬워 질 것입니다. 당신은 코드를 "포주"하지 않고, 실패의 위험을 줄이고, 코드가 작업하기에 즐거움을주고 전문적인 표준을 유지할 수 있도록 깨끗한 ​​코드의 전문적인 표준에 전념하고 있습니다. .

깨진 창문 비유로 돌아가서, 창문을 깨면 바로 수리해야합니다. 창이 파손 된 것을 눈치 채지 못한 경우, 창문을 깨진 상태로두면 비용을 결정해야합니다. 이제 앞의 두 문장을 반복하지만 창 대신 버그 를 대체하십시오.. 결국 다른 전략이 필요합니다. 코딩 할 때 버그를 생성 한 경우 즉시 수정하거나 변경 사항에 재 엔지니어링 노력이 필요한지 확인하고 문제를 해결하는 것이 가장 좋은시기에 대한 상업적 결정을 내립니다. 따라서 문제를 해결하기 위해 리팩터링하지 않고 문제를 쉽게 찾아서 수정할 수 있도록 리팩터링합니다. 코드가 얼마나 놀랍다 고 생각하든 상관 없습니다. 복잡한 시스템에는 항상 시간이 지남에 따라 처리해야하는 문제가 있습니다. 이것이 기술적 부채의 전부이며, 코드를 구현할 때 리팩토링이 지속적인 프로세스가 필요한 이유 이며, 임의의 미래를 위해 남겨 두지 않아야합니다.

간단히 말해, 마감시 간을 만들기 위해 코드의 주요 변경 사항을 연기하는 것은 드물지만 대답은 리팩토링을 일상적인 구현 작업과 무관하게 연습으로 취급하는 것이 일반적 관례로 간주되어서는 안됩니다. 코드 기반에 익숙하지 않은 팀은 이러한 상황에서 구현할 수있는만큼 단순하고 깔끔한 구현을 피하기위한 옵션으로 사용 된 적이 없습니다.

일부 개발자들은 실제로 "타이타닉의 데크 의자를 재배치"할 때 "깨진 창문 고정"이라고 말합니다. 작동하지만 후각을 상하게하는 리팩토링 코드는 비교적 쉽습니다. 사용자에게 새로운 기능을 추가하거나 앱을보다 유용하게 사용하는 대신 이러한 종류의 작업을 계속 수행하는 경우 (최적화는 앱을 더 빠르게 실행하는 것이 좋습니다. 다른) 아마도 당신은 너무 정리하고 있습니다. 정리가 나쁜 것이 아니라 개발을 위해 개발 비용을 지불하고 있기 때문입니다. 그들은 깨지기 쉽고 읽기 어려운, 잘 설계되지 않은 솔루션을 원치 않지만, 세련되고 아름다운 반 솔루션을 원하지 않습니다.

"가려고"간단한 일을해야 할 때, 또는 다른 팀이 문제가 실제로 결함인지 또는 결정을 기다리는지를 알려줄 때까지 정리하십시오. 많은 기회가있을 것입니다. 전체 응용 프로그램을 앞으로 나아갈 수있는 기회가 있다면 모든 것이 부서지기 시작했다고 느끼지 않으면 그것을 가져 가십시오. 아마하지 않았습니다. 리팩토링 할 기회가 생길 것입니다. 걱정할 필요가 없습니다.

질문의 후반부로 되돌아 가기 위해 짧은 타임 라인에 직면 한 기능을 추가하는 스프린트는 "리팩토링을하지 않고 시간이 없다"고 말하는 것은 잘못된 것입니다. "6 주가 지났고 사용자와 똑같아 보인다는 것을 알고 있지만이 깨진 창은 실제로 수정해야했습니다."라고 말하는 것도 잘못입니다. 모든 프로젝트에서 발생하는 간격에 리팩토링을 적용하십시오. 프로젝트의 목표를 달성하는 대가로 정리하는 데 피난하지 마십시오.

비즈니스 관점에서 리팩토링은 투기 투자이며, 시간과 노력 (돈)을 투자하여 향후 언젠가 더 많은 시간과 노력 (돈)을 절약 할 수 있기를 바랍니다.

리팩토링을위한 노력이 furture에서 얼마나 많은 비용을 절감 할 수 있는지에 대한 논쟁에 들어 가지 않고 (여기서 의미있는 토론을하기에는 너무 많은 변수에 의존합니다) 그것을 떠나는 비용의 지금은 지금하는 비용을 초과합니다.

furture의 가격이 얼마인지 모를 경우를 제외하고는 쉽습니다. 또한 투자 수익, 위험 관리 (브랜드 가치, 법적 책임, 보험 가능 vs 비보험 위험), 운영 비용 등과 같은 모든 일반적인 재무 계획 아이디어를 고려해야합니다.

대부분의 경우 리팩토링시기를 결정하는 것이 비즈니스를 운영하는 사람들에게 맡기는 것이 가장 좋습니다. 이 포럼에서 발성 된 많은 포스터에도 불구하고, 관리자는 일반적으로 프로그래머보다 비즈니스 운영에 대해 더 많이 알고 있습니다. 그들은 주주에 대한 수익을 극대화하는 것을 포함하여 더 큰 그림을 염두에두고 있습니다. 깨지지 않은 것을 고치는 것이 이것에 기여하는 경우는 거의 없으며, 코드도 예외는 아닙니다.

편집 : 중요한 인프라의 유지 관리 일정에 대한 흥미로운 기사를 읽었습니다. 요점은 운동이 필요할 때 수리하기 위해 일상적인 유지 관리 (리 팩터)와 거리를 두는 것입니다 (버그 수정). 주요 차이점은 모니터링 수준입니다. 예를 들어, 원자력 발전소는 상세하게 모니터링하고 "파손"상태이지만 고장이 발생하기 전에 수정합니다. 발견 된 것은 유지 보수 계획에 고정하는 데 비용이 많이들뿐만 아니라 유지 보수 프로그램으로 인한 중단으로 인해 신뢰성이 떨어집니다. 측정을 통해서만 알 수있는 소프트웨어에 대해서도 비슷한 아이디어가 필요합니다.

수정으로 인한 비즈니스 손상이 수정하지 않은 것보다 큰 경우 허용됩니다.

이것이 발생하는 상황은 다음과 같습니다.

• 수정하는 데 필요한 시간 때문에 마감일 또는 비즈니스 기회를 놓칠 수있는 곳
• 코드 조각이 (정품 적으로) 매우 짧은 시간 단위로 폐기되도록 예정되어 있으므로 리팩토링하면 거의 이점이 없습니다.

이러한 상황이 발생합니다. 상업적 상황은 종종 협상 기회가 지났을 때 충족되어야하는 인공적인 마감일과 시간 구성 요소가있는 요구 사항 (예 : 특정 날짜-존재합니다.

비결은 이러한 상황을 파악하고 올바르게 평가하는 것입니다. 은퇴 예정인 코드는 종종 몇 년 동안 계속 될 것입니다. 인공 마감일을 충족해야 할 수도 있지만 다른 방식으로 충족 될 수도 있습니다 (예 : 최종 릴리스 버전을 나중에 완료하지 않아도 소프트웨어를 지정된 날짜에 제시, 데모 및 "시작"할 수 있음).

이런 종류의 것들이 제시되면 열린 마음으로 접근해야하지만 항상 그것이 나타나는지 물어보십시오. 가정이 현실적인가? 비표준 코드를 배송하지 않고 목표를 달성하는 또 다른 방법이 있습니까? 사용 가능한 시간을 가장 잘 사용하지 못하면 어떻게합니까?

그리고 항상 좋은 대안이 없다면 언제 해결할 수 있습니까?

거의, 거의, 거의 항상해야하기 때문에 경우 가 아닌 경우 .

관리자가 기술 부채 를 쌓기로 결정한 경우 . 예를 들어 초기 고객에게 초기 프로토 타입을 제공하여 초기 피드백을 받기를 원하는 경우 결정하는 것은 공정한 결정입니다.

신용을 요구하는 것과 같은 방식으로 생각할 수 있습니다. X에 단기적으로 투자하고 장기적으로 지불하기 위해 돈을 빌려도 괜찮습니까? 결정적인 대답은 없으며, 조직의 이익을 위해 최선을 다하거나 (예 : 현재 고객의 기대를 충족시키기 위해) 무책임하게 수행하면 재앙이 될 수 있습니다.

모든 것이 우선 순위로 귀결되며 경영진은 "우선 작업"을 수행하고 새로운 기능을 구현하며 고객의 기대에 부응하는 것이 최우선 순위이지만, 깨진 창을 떠날 때마다 그 최우선 순위가 느려집니다. 더 어렵고 더 많은 자원 투자가 필요합니다. 또한 99 %의 시간은 새로운 기능 개발을 중단하고 "코드베이스 수정"에 모든 노력을 집중시키는 것이 불가능합니다.

결론적으로, 대출을 요청하는 것이 허용되는 것처럼 깨진 창문을 남겨 두는 것이 허용됩니다. 단지 당신이 정말로, 미래에 지불해야한다는 것을 기억하십시오. 그리고 앞으로는 시간이 현재보다 훨씬 크지 않을 것입니다.

일반적으로 가능한 경우 수정해야합니다. 유지 보수에 소요되는 시간을 막을 수 있습니다. 그러나 일부 야만적 인 비 민첩한 관행은 작동하는 한 현 상태를 유지하는 경향이 있습니다. 일부 관리자는이 변경으로 인한 "예기치 않은 영향"을 두려워합니다.

필자는 리팩토링을 수행하는 경우 제대로 작동하고 (최적화에 의해서만 손상되었지만 기능이 아닌) 작동하는 경우에만 그대로 두는 것이 좋습니다. 그러나 가능한 한 빨리 수정해야합니다.

기능에 의해 끊어지고 새로운 기능에 의존하는 경우 최대한 빨리 수정하는 것이 가장 좋습니다.

대부분의 프로그래머는 고용주를 위해 돈을 버는 사업을하고 있습니다. 리팩토링은 언제해야합니까? 리팩토링은 다른 프로젝트에 소비되지 않은 시간과이 프로젝트에서 미래에 절약 된 시간입니다.

가치가 있는지 여부는 대부분 관리자에게 달려 있습니다.

프로그래머는 비즈니스 측에 기술 부채의 정도를 알려 주어야 정보에 입각 한 결정을 내릴 수 있습니다. 더 빨리 시장에 출시해야 할 필요성이 코드의 위험을 능가하는 경우 선택의 여지가 없습니다. 현금 흐름의 부족은 많은 기술적 결정에 우선합니다.

비 기술적 관점에서 일부 문제를 해결하려면 연장 된 시간을 지적하여 버그를 수정하고 새로운 기능을 추가하십시오. 경영진에 판매 및 마케팅 배경이있는 경우이를 이해할 수 있습니다. 고객에게 이러한 일이 더 오래 걸릴 것이라고 말하는 것을 싫어합니다.

팀 확장에 ​​대해 생각하고 있다면 주니어 개발자를 고용하기에 좋은시기입니다. 이 경우 테스트 범위는 큰 구세주가 될 것입니다. 그들은 문서를 읽는 것보다 더 많은 것을 배우게 될 것입니다.

이 시나리오에서 기한을 지키기 위해 기존 코드에 대한 주요 리팩토링을 연기하는 것이 정당화 될 수 있습니까?

• 무언가가 깨지면 대부분 그렇지 않습니다. 부분적으로 작동하는 브레이크가 장착 된 자동차를 운전하지 않습니까? (제 시간에 어딘가에 가지 않을 위험이 브레이크 고장으로 인해 충돌의 위험보다 큰 경우가 아니라면) 이상적인 솔루션과는 거리가 멀지 만 불행히도 발생합니다.

그러나 작업 코드 리팩토링에 대해 이야기하고 있다면 다음을 고려할 것입니다.

• 수석 개발자 나 기술 책임자에게 달려 있다면 소프트웨어를 출시하지 않을 것입니다. 우리는 항상 리팩토링하고 완벽주의를 위해 노력합니다.

• 리팩토링이 비즈니스 수익성에 부정적인 영향을 미치면 일정을 재조정해야합니다.

• 비즈니스에서 특정 날짜까지 특정 기능을 제공하겠다고 약속 한 경우 나중에 리팩터링해야합니다. Red Nose Day 자선 단체를 생각해보십시오. 매년 24 시간 또는 48 시간 동안 기부금을 모을 수 있습니다. 그들이 시간 간격에서 기부금을받는 것을 막을 수 있다고 생각되면 코드베이스를 리팩터링 할 방법이 없습니다. 또한 깨진 창문이 있지만 기부를받는 능력에 영향을 미치지 않으면 리팩터링하지 않기로 결정할 가능성이 높습니다.

• 당신은 항상 무언가를하는 더 좋은 방법을 찾을 것입니다. 자연스러운 과정이며 선을 그리는 것이 매우 중요합니다.

리팩토링에 대한 귀하의 질문에 대한 답변으로 "예"라고 대답합니다. 위의 답변에서 다른 사람이 지적한 것처럼 리팩토링은 진행중인 프로세스이며 때로는 이미 작동하는 코드를 다시 작성 해야하는 전술 및 비즈니스 결정이 있습니다 (아마도 klugey 방식).

"깨진 창"에 관하여 : 저는 약 10 년 전에 소프트웨어 개발과 관련하여이 용어를 처음 들었습니다. 그러나 당시에는 부서진 단위 테스트 허용을 설명하는 데 사용되었습니다 . 이것은 사람들이 부서진 단위 테스트를 고치지 않는 유혹을 가지고있는 시나리오를 설명하는 것이 었습니다. 깨진 테스트를 수정하는 대신 어떤 인터페이스가 "실패해도 괜찮은지"기억하는 것이 더 편리하기 때문입니다 (인터페이스 또는 요구 사항으로 인해서 올바르게 중단됨) 예를 들어 변경).

깨진 단위 테스트에 깨진 창 은유를 적용하는 것이 더 적합하며 소프트웨어 환경에서 "깨진 창"을 허용하는 위험에 대해 더 잘 설명합니다. 내 의견으로는, 깨진 단위 테스트 (창이 깨진 상태)에 대해 이야기했다면 대답은 결코 괜찮지 않을 것입니다 . (우리가 결코 말할 수없는 정도로 ...)

실제로 고장난 경우 수정해야합니다.

하지만 정말 고장 났나요? 당신은 단순히 "예쁘지 않은"을 깨진 것과 동일시하지 않습니까?

스타일이 마음에 들지 않거나 나중에 문제가 발생할 것이라고 생각하기 때문에 작업 코드를 리팩터링하기 전에 "sunk value"계산을 적용해야합니다.

지난 주에 작성한 코드를 리팩토링하기 위해 비용을들이는 시간은 지난 주에 코드를 작성하는 데 소요 된 시간이며 코드가 실질적으로 개선되는지는 신경 쓰지 않아도됩니다.

단위 테스트를 거친 코드 리팩토링. 이제 다시 작성하지 않아도되며 지금까지 수행 한 모든 테스트를 다시 정의하고 다시 실행해야하므로 비용이 많이 들기 시작합니다.

프로덕션으로 이동 한 코드 리팩토링. 더 많은 테스트를 수행하고 사용자에게 배포하고 이전 릴리스와 같이 작동하지 않는 것을 제공 할 위험이 있습니다. 계속하기 전에 이것을 정당화하고 큰 상사와 함께 정리해야합니다.

한동안 제작에있어 여러 릴리스 및 버그 수정을 거친 리팩터링 코드. 소프트웨어가 작동을 멈출 것임을 알지 못하면 거기에 가지 마십시오!

마감 시한이 비즈니스에서 가장 중요한 것은 저의 경험이었습니다. 실제로 누가 응용 프로그램을 사용할 지에 달려 있습니다. 제 경우에는 휴대폰 OS 소프트웨어를위한 것이 었습니다. 마감일을 놓치면 판매 목표를 놓치고 주가가 떨어졌습니다.

우리는 상속받은 코드를 볼 때 많은 WTF 순간을 보았으며 분명히 변경해야했습니다. 그러나이 코드는 '단순히'(비동기성에 대한 이해가 부족한) 방식으로 작동했기 때문에 경영진이 실제로 리팩토링을 허용하는 한편 뛰어난 약속이 전달되도록하는 동기는 없었습니다. 우리가 모호한 경우를 통해 쉽게 스스로를 깰 수는 있지만 버그를 '거칠게'볼 때까지는 아무것도 바꿀 수 없었습니다. 나는 한 번에 약 10k 줄의 코드를 리팩토링하여 버려야했습니다. 테스트에 필요한 시간과 다른 사람들의 검토 등을 정당화 할 수 없었습니다.