기술 부채에 관한 이 기사 에는 다음을 포함하여 몇 가지 좋은 점이 있습니다.

"기술적 인 문제"에 대한 작업은 이야기에 의해 주도 될 때 가장 효과적입니다. 코드베이스는 어느 곳에서나 작업이 필요할 수 있지만 사용자가 직면 한 이유로 코드를 처리 할 경우에만 지불해야합니다. 어떤 멍청한 부분을 지나치려는 이야기가 없다면, 그 작업은 크게 낭비됩니다.

따라서 나는 평소와 같이 이야기를 취하는 방법을 선호하지만 아마도 그보다 더 적은 수의 스카우트 규칙을 따르는 것을 선호합니다. 다시 말해, 이야기가 우리를 이끄는 곳마다 더 많은 테스트를 작성하고 더 적극적으로 리팩토링합시다.

이 방법에는 적어도 다음과 같은 장점이 있습니다.

• 이야기의 "가장 현명한"흐름을 유지;
• 모든 팀 재능의 도움을 제공합니다.
• 전체 팀이 코드를 깨끗하게 유지하는 방법을 배울 수 있도록합니다.
• 필요한 곳에 정확하게 개선에 중점을 둡니다.
• "필요한"개선을 낭비하지 않습니다.

코드 품질이 장기 생산성에 매우 큰 영향을 미치는 것을 보았으므로 기술 부채를 처리해야한다고 생각합니다. 위의 게시물이 의미가 있다고 생각하지만 마지막 두 가지 점에 대해서는 잘 모르겠습니다. 기술 스토리가 사용자 스토리와 관련이없는 경우에도 기술적 부채를 청소하여 얻을 수있는 실제 이점을 찾는 데 관심이 있습니다.

코드베이스를 정리하고 기술적 부채를 없애면 어떤 긍정적 인 이점이 있습니까? 작업을 수행하기 위해 어떤 방법을 사용 했습니까?

나는 당신에게 내 경험에서 하나의 예를 줄 수 있습니다.

약 10 년에서 12 년 전에 회사를 떠나는 개발자 팀으로부터 응용 프로그램을 물려 받았습니다. 이 시스템은 자체 개발 한 대규모 미들웨어 보고서 생성 시스템이었습니다. 매주 밤마다 실행되었으며 Fortune 500 대 기업의 임원을위한 약 24 개의 Excel 보고서가 생성되었습니다. 내가 물려 받았을 때, 달리는 데 약 5-6 시간이 걸렸으며 주어진 주중에는 적어도 2 박은 실패 할 것입니다.

나는이 엉망진창을받는 행복한 야영자가 아니었다.

처음에 나의 계획은 출혈을 멈추고 실패의 주요 원인을 해결하는 것이었다. 코드베이스에 익숙해지면 리팩토링하고 안정성과 성능을 추가 할 수있는 곳을 찾기 시작했습니다. 약 2 년 동안 시스템을 많이 변경했습니다. 우리는 2 년 전에이 시스템을 폐기했으며이 시점에서 전체 프로세스를 실행하는 데 45 분이 걸렸으며 몇 년 동안 아무런 문제도 발생하지 않았습니다.

기술 부채를 갚기 위해 많은 노력을 기울 였지만 그만한 가치가있었습니다. 한밤중에 시스템이 고장 나서 전화를받지 않는 것이 좋았습니다. monring에서 사무실에 와서 로그에서 좋은 소식 만 보았습니다.

(제외. 몇 년 후 나는이 시스템의 주요 개발자 중 한 명을 만났다. 그는 어떻게 지내고 있는지 물어 보았고 나는 그 시스템이 얼마나 나빴는지 말해주었습니다. 그가 떠난 후 지원하기 위해 소수의 사람들이 더 잘 해내 길 바랐습니다).

정리가 완료되지 않은 코드를 유지해야 할 때 코드 정리의 이점이 가장 눈에 띄는 것은 내 경험이었습니다. 정리가 완료되면 변경 사항은 코드를 읽고 변경해야 할 하나 또는 두 곳을 찾아서 거기에서 나가는 것으로 구성됩니다. 정리가 완료되지 않은 경우 코드를 두 번 읽고 작성자 (때로는 나)가 코드를 작성할 때 생각한 것을 파악하는 초기 단계를 추가하십시오.

기술 부채를 제거하면 기술 지원이 줄어들고 개선을위한 더 나은 기반이 만들어집니다

항상

내가 한 경험은 이전 고용주에서 사이트 실적 팀을 관리 할 때였습니다. 매일 밤, 1 시간에서 2 시간 동안 팀이 모니터링하는 웹 사이트는 사이트의 봇 스크래핑 정보로 인해 허용 가능한 성능 임계 값 아래로 떨어질 것입니다. 팀이이 문제를 해결하기 위해 취한 조치는 수동 관리자 시스템에 로그인하고 문제를 일으킨 IP 주소를 차단하는 것으로 구성되었습니다. 말할 것도없이, 이것은 매일 밤 거의 한 팀의 수면 시간을 요했다. 나는 무슨 일이 일어 났는지 알았고 며칠 동안 전화 BlackBerry가 자신의 상태를 파악하고 팀원들에게 휴식을 취하기 위해 며칠 동안 직접 가져 갔다.

며칠 후, 나는 단순히 팀의 비즈니스 소유자에게 가서 봇이 사이트의 성능에 영향을 미치는 훨씬 더 어려운 시간을 갖도록 자동화 된 차단 시스템을 구현하지 않으면 우리는 잃어 버릴 것임을 알려 피로와 소진으로 인해 모든 팀원이 아닌 경우도 있습니다. 그들은 동의했고 우리는 밤에 잠을 자도록하는 시스템을 구현했습니다. 비즈니스 소유자는 며칠 또는 일주일의 개발 비용이 새로운 엔지니어의 채용 / 훈련 비용과 비교하여 최소라는 것을 이해했습니다.

마지막 두 가지 점에 대해 : 나는 그의 원래 게시물 에서 설명한대로 그것이 어디에서 왔는지 이해합니다 .

아니면 일부 개발자가 이러한 기술적 문제를 해결하도록 재 할당 할 수 있습니까? 팀의 나머지는 사용자 중심의 작업을 계속합니까? 이것은 팀 속도에 영향을 줄 수 있지만 무엇입니까?

"그렇다"는 의미 : 제품 소유자와 다른 비즈니스 측 사람들은 불행 해집니다. 그리고 엄마가 불행하면 모두가 불행합니다.

그러나해야 할 일과 할 수있는 일 사이의 경계는 매우 모호합니다. 사용자 인터페이스는 매우 광범위하며 성능 및 오류 발생을 포함합니다. 그러나 어떤 경우에는 성능 저하와 오류 발생의 근본적인 문제가 코드의 깊이에 있습니다. 그의 말로 말하자면 : 이야기는 주름진 영역을 통과하지 않을 수도 있지만, 그 주름진 영역은 옆의 정리 된 경로에서 이야기를 공격하는 불쾌한 것들을 숨길 수 있습니다.

전반적인 성능에 영향을 미치지 않는 것은 정리하기에는 흥미롭지 않지만 이러한 점의 영향을 매우 신중하게 평가해야합니다. 종종 그들은 상당히 실질적인 간접적 영향을 미칩니다.

기술 부채를 상환 한 결과 기업이받을 수있는 가장 큰 혜택은 복리이자를 피하는 것입니다. 아래 블로그 항목에는 기술 부채로 인한 원금이 5 년 만에 1 억 6 천만 달러에서 4 억 4 천만 달러로 어떻게 변했는지를 보여주는 예가 있습니다. 그 정도의 부채를 처리하는 데 전념하는 전임 프로그래머가 필요합니다. 의사 결정자들에게 관점을 제시하는 데 도움이 될 것입니다!

에서 blog.acrowire.com .