기술 부채를 줄이려면 어떻게 비용을 지불해야합니까?

현재 기술적으로 복잡한 제품이 거의없는 소규모 회사에서 일하고 있습니다. 나는 그들 중 하나의 유일한 개발자입니다. 약 1 년 전, 레거시 버전의 제품을 구입하여 "지원"하기 시작했습니다.

고객은 새로운 기능, 비즈니스 가치 및 기타 유형에 대해서만 이야기합니다. 문제는 코드가 C #이지만 코드가 매우 절차 적이라는 것입니다. 추상화는 없으며 클래스는 Visual Studio에서 필요한 경우에만 사용됩니다 (예 : 양식). 이 클래스의 구현은 정말 끔찍하며 코드를 유지하기가 정말 어렵습니다.

올해 내내 리팩토링에 시간을 보냅니다. 최신 버전에는 꽤 추상화가 있습니다. 여러 구성 요소를 처음부터 다시 구현해야했으며 이러한 구성 요소에 새로운 기능을 추가하거나 동작을 변경하는 것이 다른 구성 요소보다 훨씬 쉽다고 생각합니다.

문제는, 나는 내 자신의 시간을 보낸다는 것입니다. 나는 결과를 정말 좋아하지만 하루 12 시간 일하는 것을 좋아하지 않습니다. 비슷한 상황에 가본 적이 있습니까? 어떻게해야합니까? 이미 토론을 시도했지만 여전히 성공하지 못했습니다.

레거시 코드를 많이 변경해야하는 새로운 기능을 구현하기로 결정한 순간이 무섭습니다. 고객에게 충격을 줄 수 있습니다.이 아이콘을 변경하는 데 8 시간이 필요한 이유는 무엇입니까? 고객은 코드에 변경해야 할 500 자리가 있는지 신경 쓰지 않습니다. 그리고이 500 곳을 먼저 찾아야합니다.

어떤 아이디어?

1 단계 : 무급 초과 근무를 중단하십시오.

1 년 동안 고객과 관리자를 교육하여 현재 개발 속도가 예상되는 것임을 믿었습니다. 이것이 왜 "단순한"일이 하루 종일 걸릴 수 있는지 이해하지 못하는 이유의 일부입니다. 그들을 인질로 잡고 프로젝트를 다치게 할 필요는 없습니다. 그러나 기대치가 너무 높으며 마감 시간 전에 다른 개발자 또는 더 많은 시간이 필요하다는 것을 설명해야합니다. 초과 근무를하지 않은 채 근무하고 있으며 그렇게하지 않을 계획이라고 관리자에게 구체적으로 언급하십시오. 9 시간으로 줄이더라도 차이가 나타납니다. 관리자가 왜 업무를 수행하지 않는지 묻는다면, 이것이 사실 일 것이라고 경고 할 수 있다는 사실을 지적 할 수 있습니다.

2 단계 : 메모 작성

일을 할 시간이 없다고해서 일이 끝났을 때 더 쉽게 할 수 없다는 것을 의미하지는 않습니다. 코드 수정에 대한 아이디어를 기록하고 회의에서 다른 사람들이 귀하의 우려를 인식 할 수 있도록하십시오. 결국 당신은 느린 패치를 치게 될 것입니다. 이 시간이 다가 오면 코드 섹션을 한 번 보지 않았기 때문에 이미 말리지 않고해야 할 일에 대한 몇 가지 기본 아이디어가 이미있을 것입니다.

... 코드는 실제로 유지하기가 어렵습니다.

이것이 경영진의 길입니다. 버그를 수정하고 새로운 기능을 추가하는 데 드는 비용이 코드를 리팩토링하고 다시 작성하는 것보다 크다는 것을 설명하십시오.

예를 들어, 현재 코드를 사용하여 새로운 기능을 추가하는 데 2 ​​주가 소요되고 유지 관리하는 데 상당한 시간이 소요되는 경우 (예 : 주 1 일), 일주일의 리팩토링을 사용하면 개발을 1/2에서 완료 할 수 있음을 보여줍니다 몇 주 동안 유지 보수를 한 달 (1 일 이하)로 줄입니다. 이 수치는 단기 비용이 있더라도 현재하고있는 일이 중장기 적으로 비용 효율적이라는 것을 보여줍니다.

회사는 지금 돈을 쓰는 것을 좋아하지 않지만 잠재적 이점이 훨씬 더 크다는 것을 알게 될 것입니다. 즉, 더 적은 시간에 더 많은 코드를 생산적으로 생산할 수 있고 그 코드의 품질이 더 좋아질 것입니다.

보이 스카우트 규칙 적용 : 코드를 만질 때마다 코드를 약간 깔끔하게 유지하십시오 (즉 기술 부채가 적음).

귀하가 제공 한 모든 추정치에서이 작업을 수행 할 시간을 허용하십시오. 그러면 마술처럼 시간이지나면서 기술 부채가 사라지고 그에 대한 대가를 치르게됩니다.

이 접근법은 기술 부채에 대한 시간을 명시 적으로 (따라서 고객 / 관리자에게 설득력을 부여) 시도하는 것보다 훨씬 쉽습니다. 그것은 당신에게 훨씬 더 전문적인 느낌과 "잘된 일"을 제공합니다. 그리고 마지막으로, 고객과 관리자는 어떻게 된지 잘 모르더라도 장기적으로 감사 할 것입니다.

이것은 유지 보수 프로그래밍의 슬픈 현실입니다. 유지 관리 대상으로 고착되어 있고 청구서를 지불하는 사람이 자신이 혜택없이 변경 한 것으로 간주하는 것에 대해 지불하기를 원하지 않는 경우 이러한 변경은 완료되지 않는 경향이 있습니다.

이러한 변경에 자금을 지원하려는 경우 가장 간단한 업데이트를 위해 변경해야하는 모든 장소를 기록하십시오. 약간의 변경 후에는 해당 로그를 관리자와상의하십시오. 문서화 할 수 있다면 지갑 끈을 가진 사람이 장기적으로 실제로 코드를 정리하는 것이 실제로 저렴하다는 것을 깨닫게 될 가능성이 있습니다.

이 제품을 판매 할 가능성이 높을수록이 제품을 더 오래 사용할 것으로 예상됩니다. 또한 제품 고장으로 고객에게 홍보 문제가 발생하거나 고객 비용이 발생하는 경우 승률도 증가합니다.

이를 막고 가능한 것을 배우고 유지 보수를 줄이면서 다른 위치로 넘어갑니다.

제품을 리팩토링하고 개선하는 것이 회사에 어떻게 도움이되는지 경영진에게 보여 주어야합니다.

고객은 코드가 작동하는 한 코드가 아름답거나 추악한 지 신경 쓰지 않을 것입니다. 경영진은 고객에게 이미 지불 한 요금이 잘못 설계되고 제대로 구현되지 않았다고 설명하기를 열망하지 않습니다. 동시에 경영진은 제품을 눈에 띄는 (청구 가능한) 방식으로 개선시키지 않는 개발 시간 비용을 간절히 원치 않을 것입니다.

제안한 변경 사항이 회사에 도움이 될 것이라고 경영진에게 확신시켜야합니다.

• 더 나은 아키텍처를 사용하면 새로운 기능을 더 빨리 추가 할 수 있음을 보여줍니다.
• 현재 경로를 계속 따라 가면 스스로 구석에 그려 질 것이라고 설명한다.
• 현재 시스템에서 매우 비싸지 만 더 나은 디자인으로 간단하고 저렴한 변경의 예를 제시하십시오.
• 레거시 코드를 유지하고 판매 가능한 기능을 추가하는 데 소요되는 시간을 추적하십시오. -기존 및 미래 고객들에게 기존 시스템은 꽤 훌륭하지만 현대화 된 새로운 아키텍처는 많은 새로운 개선, 안정성 개선 등을 허용 할 것이라고 설명합니다.
• 제안한 변경과 관련된 위험을 완화하십시오. 관리자는 위험을 피할 수 있으며 기존 시스템에 대한 변경 사항은 본질적으로 위험 해 보입니다.
  • 비용 및 이익에 따라 다양한 구성 요소의 현대화를 우선시하고 경영진이 우선 순위에 동의하는지 확인하십시오.
  • 현대화 된 구성 요소가 나머지 레거시 코드와 호환되는지 확인하려면 단위 테스트를 사용하십시오.
• 현대화 노력의 진행 상황을 추적하십시오. 합리적으로 최대한 빨리 혜택을 보여 주지만,해야 할 일이 더 많다는 사실을 모든 사람들에게 상기 시키십시오.

당신은 그것을 알지 못하지만 Johnny Cash는 리팩토링 운동을 예측하고 기존의 큰 코드베이스를 리팩토링하는 가장 좋은 방법에 대한 노래를 썼습니다.

물론 그는 자동차의 은유로 그것을 감싸서 청중이 그것을 이해할 수 있도록해야했습니다.

"한 번에 한 조각"-Johnny Cash

변경이 "수행되어야" 하고 장기적으로 앞서 나갈 때까지 고객에게 청구 할 수있는 것 같습니다 .

코드 정리가 즐거우면 (적어도 조금하는 것처럼 보입니다) 계속 진행하고 코드를 작성하지 마십시오. 그것은 당신, 당신의 회사 또는 다른 고객에게 좋은 일이 아닙니다.

경영진과 고객과 함께 일하는 모든 사람이 코드가 최선의 형태가 아니므로 정보에 근거한 결정을 내릴 수 있음을 알아야합니다. 코드를 소유한다고해서 비즈니스 결정을 내려야한다는 의미는 아닙니다. 코드의 문제점을 모르면 작업을 수행 할 수 없습니다.

클라이언트의 응용 프로그램에 기술 부채가 있지만, 약간의 할인이 부과 될 수 있습니다. 그들은 이것을 알지 못했을 수도 있지만, 가장 낮은 입찰가를 취할 때 발생합니다.

기능 변경에 대해 전체 가격을 지불할지 아니면 변경하지 않고 결정해야하는지 결정해야합니다. 그들의 선택입니다. 그들이 결정을 내리거나 무료로 계속 일하도록 할 수 있습니다. 수행 한 정리 작업을 언급하고 언급 한 작업에 대해 약간의 할인을 제공 할 수 있습니다. 다시, 그것은 그들의 선택입니다.

내가 이것에 접근하는 방법은 상사에게 기술 부채의 개념을 설명하는 것부터 시작합니다. 결론은 비즈니스 관점에서 접근하십시오. 새로운 기능을 요청할 때마다 제품에 축적 된 기술적 부채가 효율성에 영향을 미치므로이 부채로 인해 각 기능에 약간의 추가 비용이 발생합니다.

그들이 당신이 말하는 것을 이해하고 나면 기술 부채를 줄이기 위해 약간의 시간 동안 협상하십시오. 우리 회사에서는 기술 부채 삭감 작업을 위해 각 개발자 시간의 10 %를 청원하는 데 합리적으로 성공했습니다.

이 작업을 위해 시간을 따로 떼어 놓은 후에는 실제로 사용하십시오 (시간을 초과하여 10 % 이상 작업하지 마십시오-총을 고수하십시오). 기술 부채 항목의 카탈로그를 작성하고 우선 순위를 정하고 조각을 시작하십시오. 한 번에 한 입씩 코끼리를 먹어야합니다.

더 나은 도구를 고려하는 것을 잊지 마십시오. Resharper는 Visual Studio에 연결하는 훌륭한 리팩토링 도구입니다.