경영진이 기술 부채를 처리하도록 설득하려면 어떻게해야합니까?

이것은 개발자와 작업 할 때 자주 묻는 질문입니다. 지금까지 4 개 회사에서 근무했으며 코드를 깨끗하게 유지하고 소프트웨어 앱의 향후 진행을 방해하는 기술적 부채를 다루는 데 관심이 없다는 것을 알게되었습니다. 예를 들어, 내가 일한 첫 번째 회사는 MySQL과 같은 것을 사용하지 않고 처음부터 데이터베이스를 작성했으며 응용 프로그램을 리팩토링하거나 확장 할 때 팀을 위해 지옥을 만들었습니다. 나는 매니저가 계획을 논의 할 때 항상 정직하고 명확하게 노력했지만, 경영진은 이미 존재하는 문제를 해결하는 데 관심이없는 것 같으며 팀 사기에 미치는 영향을 보는 것이 끔찍합니다.

이 문제를 해결하는 가장 좋은 방법에 대한 당신의 생각은 무엇입니까? 내가 본 것은 사람들이 짐을 싸고 떠나는 것입니다. 회사는 개발자들이 들어오고 나 가면서 코드를 더 나쁘게 만드는 회전문이되었습니다. 기술 부채 정리에 관심을 갖기 위해 경영진에게 어떻게 전달 합니까?

이 문제를 논의하기 위해 상사를 만났을 때, 나는 모든 추정에 리팩토링을 포함시켜야한다고 말했다. 그는 그것이 생각하고 싶은 문제가 아니라고 말했다. 대신 처리해야합니다.

이것은 일반적으로 경영진이 생각하고 싶은 문제가 아닙니다. 그들은 엔지니어가 아닙니다. 이것을 모든 추정치의 무언의 일부로 만들면 기술 부채가 줄어드는 것을 알 수 있습니다.

그래도 완벽하지는 않습니다. 신용 카드 부채와 같은 기술 부채는 고객을 더 빨리 유치하고 경쟁 업체보다 빠르게 시장 점유율을 확보하기위한 투자입니다. 신용 관리와 마찬가지로 제대로 관리하면 성공할 수 있습니다.

간디가 히틀러와 같은 사람과 그의 전술이 효과가 있는지 물었을 때와 같이 말했다. 그는 "어려울 것"이라고 말했다. 그러나 나는 그 대답이 실제로 "아니오"라는 공정한 주장이 있다고 생각합니다. 슬프게도, 당신이하려는 일을 할 수 있다고 생각하지 않습니다. 비관적이지 않고 정직하려고합니다.

나에게 문제는 관리자가 설득력이 필요하다는 것이 아니다. 더 나은 사람들은 이미 관리하지 않으면 부채가 살인자가 될 수 있다는 것을 이미 알고 있습니다. 그러나 그들이 이해하든 아니든, 훌륭한 관리자인지 나쁜지에 상관없이 그들은 모두 배달해야 할 압력에 직면하며, 배달은 날짜에 대해 상사에 의해 판단됩니다. 품질이 매우 나쁘거나 개발자의 잘못이거나 품질이 매우 우수한 경우에만 품질이 중요합니다. 품질은 "충분히 우수"해야합니다.

나는 경영진이 엔지니어링과 매우 다르게 생각한다는 것을 이해하는 몇 안되는 사람 중 하나이기 때문에 Renesis가 그의 답변에서 말한 것을 좋아한다고 생각합니다. 그리고 우리 모두는 고객과 품질에 초점을 맞추지 않고 회사의 발전이 날짜 중심적이고 프로젝트 관리가되는 것을 보았다고 생각합니다. 이 말은 애플 컴퓨터 나 아이디 소프트웨어와 같이 "완료되면 끝날 것"이라고 말하는 용기가있는 전형적인 회사가 아니라 전형적인 회사를 의미합니다. 그 접근 방식을 취하십시오).

품질 우선 접근 방식을 취하는 기업은 무엇입니까? 맞습니다. 영업 사원, 마케팅 담당자, 프로젝트 관리자 또는 회계사가 아닌 엔지니어가 운영합니다. HP, Apple, id, Google, Microsoft 및 IBM을 생각하십시오. 세일즈맨이 확실히 역할을 했음에도 불구하고 세일즈맨이 아닌 엔지니어에 의해 시작되고 성공했습니다. 많은 사람들이 Microsoft가 품질과 관련하여 논쟁을 벌일 것이라고 확신합니다. 그리고 그 중에서 내리막 길을 갔던 사람들은 엔지니어링 중심의 리더십에서 벗어났습니다. 그러나 변화하는 시간에 적응하지 못하고 자신의 성장을 관리 할 수 ​​없기 때문에 결국 실패한 많은 기술 회사가 있기 때문에 그 진술에는 많은 주장이 있습니다. 저는 엔지니어링 기반 리더십을 이러한 실패의 원인으로 보지 않습니다. 누군가 개발자 나 회계사와 무관 한 기술 및 비즈니스 통찰력 문제. 그러나 일반적으로 엔지니어링이 구성 요소 인 회사에 도움이되는 엄격한 책임과 규율에 대한 엔지니어링에 전념하고 있다고 생각합니다.

진지하게 둘러보세요. IT 리더십이 매우 부족합니다. 초점은 항상 비용과 시간에 중점을 두지 만 충분히 좋은 품질에는 거의 초점이 없습니다. IT 리더는 더 이상 CEO에게 거의보고하지 않으며 이제는 항상 CFO입니다. IT는 생산 지원을 고수하고 있으며 혁신적 가치의 중대한 변화가 아니라 더 작고 소화 가능하며 측정 가능한 덩어리에 중점을 둔 프로젝트 관리자에게 점점 더 주목을 받고 있습니다. 큰 그림을 보려면 거기에 있어야합니다).

이 게시물에 너무 오래 걸리는 것이 유감 스럽지만 결국에는 기술 부채에 대한 경영진의 관리 방법에 대한 귀하의 질문이 기존의 리더를 변경하는 것이 아니라 올바른 리더를 찾는 것으로 종종 더 잘 해결 될 것이라고 생각합니다. Renesis가 말한 것처럼 표준 사상가들에게 기술 부채를 설명한다는 것은 돈과 비용에 초점을 바꾸는 것을 의미합니다. 당신이 성공하더라도 회사의 최고 리더가 그것을 구입 한 경우에만 중요합니다. 중간 관리자가 옳은 일을하도록 설득하면 아마 해고 될 것입니다.

가장 먼저 할 일은 표현을 바꾸는 것입니다. 이를 "기술 부채"라고 부르면 경영진은 실제로 바이러스와 유사한 경우 일종의 투자가 가능하다는 생각을 갖게됩니다. (나는 기술 부채 의 Dave Ramsey 와 같습니다 .)

그것이 지불되지 않는 것을 허용하는 것은 볼 수 없거나 쉽게 정량화 할 수없는 막대한 비용이 따른다.

관리를 위해 다음과 같은 문제를 나열하십시오.

• 새로운 기능 견적은 필요한 것보다 훨씬 높습니다. 아니면 불가능합니다.
• 나쁜 코드는 더 나쁜 코드를 생성합니다
• 개발자가 항상 수정하더라도 버그 목록이 커짐
• 팀 구성원 (이 자체에 설명 된대로 문제가 있음을 보여줄 수 떠나 이 우수한 답변 )

저의 경영진은 기술 부채를 해결하기 위해 진지한 노력을하기 시작했습니다. 기술 부채는 제가 여기서 일하는 것을 좋아하는 이유 중 하나입니다.

내가 견적을 요청하고, 나는 특정 기술 부채 문제를 처리하지 않은 경우 시간이 저장 될 수 있었다 때마다 나는에 압력을 유지하는 한 가지 방법은, 내가 포함 내 추정에 그 . 예를 들어, " 이 버그는 추적하는데 2-3 일이 걸리지 만, 대기열에있는이 두 가지 다른 '우선 순위'버그를 이미 해결했다면 아마도 1 개 미만일 것입니다. " 이에 대한 답변은 진행 중에 다른 것들을 수정하는 것입니다.

또한 업무의 개선 부분을 고려하고 너무 혼란스럽지 않으면 진행하면서 다른 답변에 동의합니다. 현재 진행중인 작업은 매우 잘못 설계된 코드를 추가하는 것입니다. 일치하는 새 코드를 작성하여 혼란에 빠지기보다는 일반적인 기능을 통합하는 데 약간의 시간을 소비하므로 패킷을 보내는 것은 15 줄의 약간 수정 된 복사 및 반복을 반복하는 대신 한 줄의 함수 호출이됩니다. 상용구 붙여 넣기.

나는 그것이 길 아래로 일부 관리자의 정신을 더 구할 것이라는 사실을 알고 있습니다. 나는 오늘 그 관리자이기 때문에 알고 있습니다. 그러나 나는 또한이 기능을 가져 와서 지금 디버깅하는 내 자신의 현재 작업을 가속화 할 것이라고 생각합니다.

내가 과거에 사용하고 다시해야 할 또 다른 기술 은 컴파일하거나 긴 테스트를 기다리거나 속도를 변경해야 할 때 다운 타임 동안 리팩토링 DVCS 분기를 별도의 작업 트리 에 유지하는 것입니다. 버그에 탔을 때 조금. 때때로 상류에서 합류하여 너무 멀리 분기하지 않는 한, 최소한의 노력으로 변경 사항을 리팩토링하는 데 원하는 시간이 걸릴 수 있습니다. 하루 15 분 여기 저기 실제로 시간이 지남에 따라 더해질 수 있습니다.

신용 카드 비유를 시도 할 수 있습니다. 그들에게 "당신은 오랜 기간 동안 무급 신용 카드 명세서를 떠나 편안하게 생각하세요?"

관리자는 비용과 이점을 이해하지만 일반적으로 개발자가 사용하는 기술 용어는 아닙니다. "기술 부채"라는 용어는 이미 이러한 의사 소통 장벽을 극복하기 위해 고안되었지만 더 명확하게 설명해야 할 수도 있습니다. 대부분의 관리자는 기한이 지난 신용 카드 결제가 끔찍한 이자율로 성장하여 미지급 상태로 두는 것이 아프다 는 사실을 잘 알고 있습니다 (자체 경험에서 비롯됨). 이는 소프트웨어 엔트로피와 관련된 문제의 심각성을 얻는 데 도움이 될 수 있습니다.

그러나 이것이 설득력이 없다면 사실적인 증거를 수집하고 계산을 시도하십시오. 예를 들어 회사를 떠나는 직원을 대체하기 위해 하드 현금과 시간 손실로 회사에 드는 비용은 얼마입니까?

아무도 (행운이 있더라도) 작동하는 것으로 대체하는 돈을주지 않을 것입니다.

당신이 할 수있는 일은 그것을 더 많은 일로 대체하는 것을 제안하는 것입니다. 즉, 기술 부채 서비스를 업그레이드에 묶어 즉각적이고 실질적인 비즈니스 이익을 가져옵니다.

물론 당신은 그것에 대해 공개해야합니다. 우리는 여기서 새로운 프로젝트를 "몰래 들여다"는 것이 아닙니다.

나는 다른 쪽, 개발자가 다루기가 더 어렵다는 것을 안다. 기본적으로 이것은 다음과 같이 요약됩니다. 일부 개발자의 경우 코드가 최상의 코드인지 확인하는 것은 전문적인 자부심의 문제입니다. 다른 사람들에게는 이것은 또 다른 일이며 목표는 빨리 끝내고 집으로 돌아가는 것입니다.

확실한 설득력은 그 상황을 변화시키지 않으며, 필수 코드 품질 표준을 도입하면 9-5 명의 개발자가 시스템을 작동하는 방법을 찾을 수 있지만 전담 개발자는 필연적으로 전체 절차에 의해 화가납니다. 개발자를 목표로 삼지는 않지만 개발자 X는 규칙을 준수해야하지만 Y는 원하는 것을 수행 할 수 있다고 말할 수는 없습니다.

작동하지만 여전히 매우 실망스러운 것은 더 헌신적이고 지식이 풍부한 개발자가 코드베이스를 감독하는 것입니다. 아마도 기존의 것을 정리하고 정리하는 것 사이의 좋은 균형을 이루는 것입니다.

사실, 많은 기업에서, 특히 현재의 경제 상황을 고려할 때, 매 시간마다 누군가에게 청구되어야합니다.

아니면 빨리 내려갑니다 .

기존 클라이언트가 리팩토링 비용을 기꺼이 지불하지 않는 한, 성능이나 기능이 크게 업그레이드되지 않은 경우에는 거의 불가능합니다. 그런 다음 이전 코드베이스에서는 발생하지 않습니다. 클라이언트가 많은 포켓을 가지고 있다면 새로운 프로젝트의 예산으로 몰아 넣을 수 있지만 리팩토링에서 API를 변경할 필요가 없다면 이전 프로젝트에는 쓸모가 없으며 회사가 두 개의 코드베이스를 지원하는 상황에서 더 많은 두통과 비용이 발생합니다.

엔지니어는 오래된 코드를 리팩토링하고 싶습니다. 더 이상 사용되지 않거나 더 이상 사용되지 않을 때마다 더 이상 목적에 맞지 않습니다. 그러나 내가 일했던 모든 회사의 내 MD가 "누가 지불 할 것인가?"

나는 항상 갈 때 정리하려고합니다. 코드가 깨끗해질 때까지 완료되지 않습니다. 기술적 부채의 문제는 대부분의 사람들이 그것을 이해하지 못한다는 것입니다. 그것을 해결하는 가장 좋은 방법은 그것을 축적하지 않는 것입니다. 관리자가 문제 해결 방법을 결정하도록 개발자를 신뢰하는 경우 모든 프로그래밍 작업의 일부로 코드 위생을 만들 수 있습니다. 불량 코드를 확인하지 않으면 부채가 누적되지 않습니다. 보이 스카우트 규칙을 준수하면 (항상 코드를 찾은 것보다 깨끗하게 유지) 기존 부채가 천천히 사라집니다.

기능을 구현하는 것과 별개의 작업으로 리팩토링을 볼 수 없습니다. 그것은 그것의 필수적인 부분입니다.

비 기술적 인 관리자를 상대하는 경우 토론을 이해하는 용어로 표현할 수 있으면 도움이됩니다. 기술 부채를 갚기 위해 소비 한 작업에 대한 긍정적 인 ROI를위한 현실적인 사례를 구성 할 수 있다면 어딘가에있을 수 있습니다. 그 연습은 상황에 따라 다르지만 예는 다음과 같습니다.

개발자가 프로덕션 문제에 대한 지원을 돕는 데 얼마나 많은 시간을 소비했는지 분석 한 다음 오래된 코드를 수정하면 A. 지원 문제의 수를 줄이고 B. 개발로 이관하지 않고도 문제를 쉽게 해결할 수 있도록 지원합니다. C. 개발 문제가 발생할 때 개발에 소요되는 시간을 줄입니다. 개발자가 지원 작업을 수행하지 않아도 비용을 절감 할 수 있습니다. 또한 개발자가 지원을 수행하는 데 소비하는 시간당 "더블 웜"이 발생한다는 점을 지적하십시오. 개발자에게 지원을 요청하는 데 비용을 지불 할뿐만 아니라 개발자가 수행 할 수있는 작업의 기회 비용 (새 기능 추가 등)을 태우고 있기 때문입니다. .)

예, 일부 숫자는 부두 / 연기 및 거울이 될 것입니다 ... 괜찮아요, 관리의 더러운 비밀은 그들이 던지는 숫자의 대부분이 총 BS 라는 것을 알고 있다는 것입니다. 겉으로는 구체적으로 작동하므로 머리에 넣을 수 있으므로 전투 기회가 있습니다.

기술 부채에 대한 설명이 끝나면 경영진은이를 갚아야합니다.

쓰레기로 가득 찬 매우 더러운 부엌이 있다고 상상해보십시오. 식사를 준비하기 전에 먼저 1 시간 동안 청소를해야합니다. 그리고 당신이 먹고 싶을 때마다 그렇습니다. 또한 식사를 준비 할 때 쓰레기가 식사에 빠지지 않도록 특히주의해야합니다.

부엌은 당신의 코드이고, 식사는 당신의 제품이며, 식사는 당신의 제품을 판매합니다.

안전한 단위 테스트없이 변경 사항이 구현 될 때까지 더 오래 기다릴 수 있다면 회사에 문제가있는 것입니다.

원래 제품 및 비즈니스 사례와 관련하여 지금은 저에게 더 중요한 일을하기 위해 그 돈을 사용할 수 없다는 매우 설득력있는 주장이어야합니다. 좋든 싫든 경영진이나 고객이 비용을 지불하고 있기 때문에 고객에게 납득할 수 있도록 판매 할 수 있어야합니다.

이것을 고객으로서 자신을 포지셔닝하기 위해 바꾸어 보자. 좋은 역할 놀이.

냉장고를 구입했다고 가정 해 봅시다. 또한 Acme Corp에서 정상적으로 작동하는 1000 달러짜리 냉장고를 구입하거나 외부에서 동일하게 보였지만 동일한 기술 사양을 가지지 만 내부 구조가 깨끗해 유지 보수 비용이 저렴한 Acme Deluxe 냉장고의 2000 달러짜리 냉장고를 구입할 수 있습니다.

고객으로서 어느 쪽을 구매 하시겠습니까?

그리고 Acme Deluxe의 엔지니어는 무엇이 더 나은 대답이라고 생각합니까?

" 기술 부채 "는 경영진에게 필요로 보이지 않을 수 있으므로 까다로운 주제가 될 수 있습니다. 이 질문은 회사에 "여기서 우리는 기술 부채 문제를 해결하기 위해 X % 시간이 걸리고 있습니다. 비슷한. 거기에는 자율성에 대한 주장이 있지만, 그렇지 않으면 경영진이 다소 위험한 영역 인 일부 결과를 볼 때까지 얼마나 오랫동안 궁금해 할 수 있기 때문에 기간도 있습니다.

그러나 첫 번째 요점은이 문제를 문제로보고 있는지 여부입니다. 시력이 좋지 않은 사람이 안경에 대해 전혀 모르고 어떤 종류의 변화를 줄 수 있다면, 안과 검사가 왜 가치가 있는지 이해하는 방법은 무엇입니까? 주제가 다소 기술적이며 불행히도 쉽게 정량화되지 않는 동일한 아이디어입니다.

당신은 그것에 대해 불평을 중지해야합니다.

이유는 다음과 같습니다.

1. 1 년 이상 소프트웨어를 사용할 계획이 없습니다.
2. 그들의 계획이 나중에 그것을 버릴 것이라면 그것을 조정하는 것은 시간 낭비입니다.
3. 지금 수정해야 할 실제 문제가 있습니다.
4. 프로그래머는 항상 재미 있지는 않지만 유지 관리를 다루는 법을 배워야합니다.
5. 해야 할 일을 더 잘 안다고 불평하는 것은 거만하다-다른 사람이 결정을 내린다면, 당신은 그것에 대해 행복해야한다
6. 그들은 어쨌든 좋은 코드를 작성하도록 당신을 믿습니다.

가장 좋은 방법은 다음과 같습니다.

1. 그들이 당신에게 새로운 일을 줄 때, 주어진 시간에 가능한 한 그것을 구현하려고 노력하십시오.
2. 처음부터 완벽하게 작성하십시오. 나중에 변경해야하는 경우 처음으로 실수를하고 변경이 항상 잘못된 방향으로 진행됩니다. 실수를 할 때 프로그래머에게는 학습의 기회입니다.
3. 추가 시간을 요구하지 마십시오. 알 수없는 마감일이 있습니다.

기존 시스템을 재 작성 / 교체 또는 업그레이드하기 위해 프로젝트에 참여한 적이 없습니다.

이것들은 성공적으로 완료하기 가장 어려운 프로젝트 중 일부입니다. 당신이 겪게 될 몇 가지 문제는 다음과 같습니다.

1. 비즈니스 규칙은 제 시간에 없어집니다.
2. 문서와 구현이 완전히 맞지 않습니다.
3. 사용자가 기능으로 보는 버그로 표시되는 것
4. 반대로 많은 "기능"은 사용자가 결함으로 간주합니다.
5. 당신은 사용자를 사지 않을 것입니다-그들은 당신의 "사실 발견"을 "멍청한 질문을하는 대단하다"로 간주하고, 테스트 노력을 시간 낭비로 간주하고, 새로운 기능을 추가하여 프로젝트를 길게 할 것을 주장 할 것입니다. 일정이 이미 지났습니다.
6. 소스 코드가 실행중인 실행 파일과 100 % 일치하지 않을 수 있습니다.
7. 부서에서 개발 리팩토링 개발을 망설이고 있지만 실제로 원하는 비즈니스는 수행되고 있지 않습니다.
8. 리팩토링에는 "깨끗한 개선 된 인터페이스"가 포함되어 다른 프로젝트를 지연된 배달 문제와 실패한 테스트로 끌어들일 수 있습니다.
9. 프로젝트가 완료되면 (이러한 노력의 50 % 이상이 완전히 실패한 경우) 모든 신용도를 잃게됩니다. 다른 도시의 다른 회사로 이사하여 다른 사람의 말을들을 준비가되어야합니다.
10. 프로젝트가 성공하면 모든 사람들이 그 악몽이 무엇인지 기억할 것입니다.

전염병과 같은 재 작성 / 리팩토링 프로젝트를 피할 것을 촉구합니다. 이들은 전문가 경력에서 가장 혼란스러운 경험이 될 수 있습니다.

"파산하지 않으면 해결하지 마십시오"라는 문구에는 많은 지혜가 있습니다.

내 인생에서 나는 왜 어떤 사람들이 맹목적으로 변화를 두려워하는지 이해할 수 없다. 그것은 당신 자신의 능력에 대한 자신감이 부족한 것이다.

나는 어제 밤 요세미티 국립 공원에서 쇼를 보았고 1940 년부터 1990 년대 후반까지 단 하나의 새로운 세쿼이아 나무가 싹 트지 않았다는 것이 주목되었다. 그 이유는 산불을 피하는 것에 대한 엄격한 정책이 있었으며 세쿼이아 소나무 콘이 씨앗을 열고 풀기 위해 불에서 열이 필요하다는 것이 밝혀졌습니다.

알다시피, 10 년마다 화재가 건강했습니다. 기존의 나무 (공정)를 건강하게 유지하고 새로운 나무 (기능)를위한 공간을 만들기 위해 축적 된 데드 우드와 가시 나무를 모두 제거했습니다.

현재 재 구축 사례가 분명한 프로젝트를 진행 중입니다. 레거시 소프트웨어는 .NET 웹 양식을 사용하여 작성되었습니다. 거의 모든 비즈니스 로직은 HTML / 서버 태그보기 로직과 함께 통합되어 비즈니스가 성장한 지금 다른 애플리케이션으로 확장 할 수 없습니다.

경영진은 개발자에 대한 적절한 신뢰를 가지고 있기 때문에 어려운 일입니다.

예, 재건이 정말로 필요한지 자문 해보십시오. 가능한 한 기존 코드를 재사용하기 위해 최선을 다하십시오. 필요한 경우 해당 코드를 재 빌드에 통합하십시오. 과감한 변화를 두려워하는 것이 소프트웨어 개발자로서 존재하는 유일한 방법이라는 것을 누군가에게 설득시키지 마십시오.

행운을 빕니다!

경영진에게 기술적 부채를 처리 할 재정적 이유와 기술적 부채 감소를 관리하기위한 프레임 워크를 제공해야합니다.

기술 로드맵을 유지하는 것이 그러한 프레임 워크 중 하나입니다. 로드맵으로 시작하면 기술 부채를 줄이지 않고 기존 부채를 ​​줄일 수 있습니다.

많은 성공적인 장기 프로젝트에는 개발을 안내하기 위해 운영위원회와 로드맵이 연결되어 있습니다. 여러 개발 팀과 이해 관계자가있을 때 특히 유용합니다.

제 제안은이 전략에 대해 귀하의 관리자 (및 가능하면 돈이 지출되는 곳을 결정하는 사람들)와 논의하는 것입니다.

로드맵을 만들고 관리하는 일반적인 방법은 간단하지만 관리 팀의 지원이 필요합니다. 먼저 목표를 정의하십시오. 기술 부채 요소를 정의하고 기술 부채 요소를 줄이는 목표 시스템 아키텍처를 개발하십시오. 완벽 할 필요는없고 현재 실행 가능한 것보다 실행 가능하며 더 우수 할 필요는 없습니다. 소프트웨어, 개발 도구, 하드웨어 플랫폼, 시스템에 추가 될 수있는 새로운 주요 기능을 고려하십시오. 비용 분석을 수행하십시오. 원하는 아키텍처가 있다면 리팩토링을 수행하면 얻을 수있는 실질적인 이점은 무엇입니까? 이점에는 테스트 시간 단축,보다 안정적인 소프트웨어 제품, 예측 가능한 개발주기 등이 포함됩니다. 리팩토링 수행에 충분한 이점을 제공 할 수 있으면 관리 지원을받을 수 있습니다.

로드맵 및 관리 지원을 받으면 원하는 상태에 도달하기 위해 수행해야하는 일련의 단계 (계획이라고도 함)를 개발하십시오. 로드맵을 유지 관리하고, 로드맵에서 개발 팀을 교육하고 교육하며, 건축 무결성에 대한 변경 사항을 정기적으로 검토하는 운영위원회를 구성하는 것이 좋습니다.

로드맵은 정말 유용하며 Joel 테스트의 13 번째 질문은 "로드맵이 있습니까?"

다음은 최근 Red Hat Linux 로드맵 세션의 첫 시간 비디오입니다 .

리팩토링이 아닌 메이저 재 작성에 이미 관여 한 나는 재무 담당자가 프로젝트에 동의하도록하는 것이 주요 장애물 중 하나라는 데 동의 할 수 있습니다. 이 장애물을 극복하기 위해 회사 비즈니스가 중소 기 동안 물에서 죽을 것이라는 많은 문제를 지적한 보고서를 작성, 발표 및 방어해야했습니다.

합의가 이루어 지도록하는 주요 요소 :

• 기존 코드는 거의 지원되지 않는 개발 플랫폼 (PDP11-23)에서만 실행되는 더 이상 지원되지 않는 툴 체인 (MicroPower Pascal)에있었습니다.
• 도구 및 대상 작업을 할 수있는 개발자를 찾는 것이 거의 불가능 해졌습니다.
• 여분이 필요한 경우 대상 하드웨어를 더 이상 사용할 수 없었으며 제조업체는 수리 서비스를 제공하기를 점점 꺼려했습니다.
• 코드의 문제로 인해 고객 불만족과 직접적인 서비스 비용을 쉽게 확인할 수있었습니다.
• 대상 하드웨어의 한계로 인해 새로운 기능을 추가하거나 버그를 수정하는 것이 거의 불가능 해져 문제를 해결할 때 공간을 확보하기 위해 다른 영역을 리팩토링해야합니다.
• 8 시간의 빌드 시간으로 변경 사항을 개발하고 테스트하는 데 많은 비용이 들었습니다.

이 보고서는 지속적인 비용 추정과 함께 문제를 자세히 설명하고 3 가지 옵션을 제공했습니다.

1. 가까운 시일 내에 버그 수정이 없었던 곳에 얼어 붙습니다.
2. 유지 보수성에 관계없이 공간에 대해서만 코드를 최적화하십시오 . 최적화 된 코드를 유지하려는 사람은 최적화를 수행 한 사람보다 똑똑해야한다고 지적합니다.
3. 업계 표준의 광범위하게 가르치는 언어 (ANSI C)에서 새롭고 저렴한 COTS 하드웨어 (PC-104)에 대한 테스트 가능성과 유지 관리 성을 높은 요소로 재 구현 나머지 기존 하드웨어와 작동 할 수 있도록 인터페이스 카드를 설계했습니다. 비 휘발성 스토리지, 결함 상태에서 자동 재시작을 제공하는 워치 독 타이머와 같은 일부 새로운 기능 세트를 하루에 여러 번 충돌하고 재설정을 위해 £ 40 서비스 호출이 필요합니다 . 프로세스에서 더 나은 진단.

3 개월 계약으로 3 개월 째 계약을 체결 한 후 새로운 소프트웨어와 하드웨어를 개발하면서도 3 년 동안 열심히 일했지만 결과는 매우 좋았습니다.

기술적 부채가 덜한 경우 게릴라 리팩토링이라고 부르는 경향이 있습니다.

특정 모듈에 문제가있는 경우 :

1. 리팩토링 없이도 실패 할 수 있는 문제 를 보여주는 일련의 테스트 작성
2. 테스트가 여전히 실패하고 있음을 지적하는 개발의 일부로 리팩터링하십시오.