레거시 시스템을 추진하는 관리를 처리하는 방법?

저는 현재 유급 인턴십을하고 있으며 지난 5 년간 여러 개발자가 서로 다른 시간에 개발 한 오래된 시스템을 유지 관리하는 일을 해왔습니다. 경영진은 "시스템 수명이 다함"에 동의하며 현재 시스템을 사용하는 최종 사용자로부터 버그 보고서를 상당히 정기적으로받습니다.

경영진은 이제 1 년 동안 프로젝트를 확장하고 프로세스에서 사용자 기반의 거의 3 배를 늘리려 고합니다.

인턴 (또는 엔트리 레벨 포지션)으로서 어떻게 "푸시 백"합니까? 공개 문서에도 불구하고 이미 우려 사항을 설명하는 보고서를 작성했습니다. 변경 제안을위한 프로토콜 또는 문서 유형이 있습니까? 제안을 할 수있는 입장입니까, 아니면 기존 시스템을 계속 지원해야합니까?

• 분명히, 소프트웨어 개발은 ​​우리 회사의 주요 사업이 아닙니다. 따라서 내부 프로토콜이 없습니다. 또한이 프로젝트에는 공식적인 문서가 없으며 요구 사항 문서도 없습니다. 개발은 매우 특별합니다.

저는 현재 유급 인턴십을하고 있으며 지난 5 년간 여러 개발자가 서로 다른 시간에 개발 한 오래된 시스템을 유지 관리하는 일을 해왔습니다. 경영진은 "시스템 수명이 다함"에 동의하며 현재 시스템을 사용하는 최종 사용자로부터 버그 보고서를 상당히 정기적으로받습니다.

사람들이 여전히 시스템을 사용하고 있으며 비즈니스 활동을 지원하고 있다면 시스템은 더 이상 사용되지 않습니다. 여전히 사용되고 있기 때문에 비즈니스는 버릴 수 없으며 시스템이 더 이상 필요하지 않을 때까지 지원해야합니다. 비즈니스 목표가 변경되거나 최종 사용자에게 새로운 시스템이 개발, 테스트 및 성공적으로 배포 된 것일 수 있습니다.

실제로 5 년은 그리 길지 않습니다. 10 년 전의 코드로 작업 한 적이 있습니다. 여전히 사용자의 요구에 부응한다면 왜 버려야합니까? 그것은 그것을 개발하는데 소비 된 많은 돈을 버리고 있습니다. 비용 증가로 인해 유지 보수가 불가능하거나 요구 사항이 급격히 변할 때까지이를 버릴 사업상의 이유는 없습니다.

경영진은 이제 1 년 동안 프로젝트를 확장하고 프로세스에서 사용자 기반의 거의 3 배를 늘리려 고합니다.

경영진이이 시스템이 "실시간 지원"이라고 말하면 왜 추가 시스템을 배포하려고합니까? 유지 보수 활동은 교체 될 때까지 레거시 시스템에서 계속되는 것이 일반적이지만, 시스템이 수명이 다한 경우 일반적으로 더 많은 사람들에게 배치되지 않습니다. 유지 관리를 연장하는 것은 하나의 일이지만 시스템에 의존하는 사용자를 추가하는 것은 서로 다른 상황입니다.

나에게 그것은 실제로 수명이 다한 것이 아니라 유지 보수 단계에 있으며 시스템이 더 이상 사용자의 요구를 충족시키지 못할 때까지 계속 유지됩니다.

인턴 (또는 엔트리 레벨 포지션)으로서 어떻게 "푸시 백"합니까? 공개 문서에도 불구하고 이미 우려 사항을 설명하는 보고서를 작성했습니다. 변경 제안을위한 프로토콜 또는 문서 유형이 있습니까? 제안을 할 수있는 입장입니까, 아니면 기존 시스템을 계속 지원해야합니까?

기존 시스템을 계속 지원해야합니다. 나중에 소프트웨어는 회사의 주요 사업이 아니라고 언급합니다. 이러한 환경에서 소프트웨어 팀의 역할은 회사의 주요 비즈니스를 지원하는 것입니다. 그러나 소프트웨어 팀은 비즈니스 목표를 염두에 두어야합니다.

그 동안에는 지나치게 강력하지 않은 방법으로 제안을 캡처하십시오. 시스템과 통합 될 수 있거나 새로운 시스템이 만들어 질 때 / 장점과 장점이있을 때 사용할 수있는 다른 기술이나 기술을 지적하십시오. 이 작업을 수행하는 방법은 회사에 따라 다르지만 나중에 고려할 사항은 Wiki 또는 기타 공동 작업 사이트를 설정하는 것이 좋습니다.

소프트웨어가 아닌 비즈니스에서 소프트웨어는 비용이 들며 소프트웨어 팀 (특히 소프트웨어 프로젝트 / 프로그램 관리자)은 최종 사용자의 요구를 지원하면서 가능한 한 소프트웨어 시스템을 구축 및 유지 관리하는 비용을 최소화하기 위해 노력해야합니다. . (어쨌든 내가 알 수있는 한) 사용자의 요구를 충족시키는 소프트웨어를 버리는 것은 소프트웨어 팀의 최선의 이익에 반하는 것입니다.

* 명확히하기 위해 소프트웨어 개발은 ​​우리 회사의 주요 사업이 아닙니다. 따라서 내부 프로토콜이 없습니다. 또한 프로젝트에는 공식 문서가 없으며 요구 사항 문서가 없습니다. 개발은 매우 특별합니다.

나에게 이것은 문제이다. 문서를 작성하지 않고 사양으로 개발하지 않으며 일관성이 없으면 소프트웨어 개발 비용이 증가하는 경향이 있습니다. 이를 해결하기 위해 노력하는 것이 저의 최우선 과제이며 코딩 표준, 버전 제어, 자체 문서화 코드 및 디자인 문서 생성, 결함 추적 및 요구 사항 사양과 같은 작업을 수행함으로써 그렇게 할 것입니다.

이미 우려 사항에 대한 보고서를 작성했습니다

좋은. 인턴으로 할 수있는 정도에 관한 것입니다. 그러한 보고서를 작성할 때 나중에 참조 할 수 있도록 감정적 인 편견이없는 편견없이 전문적인 방식으로 어려운 사실을 제시하는 것을 강조합니다. 보고서를 읽을 사람을 모릅니다. 설명하고 있거나 문제를 일으킨 결정을 내렸거나하지 않은 사람이있을 수 있습니다. 냉담한 사실 이외의 다른 것은 모욕이나 범죄와 같은 사람들에 의해 취해질 수 있으며, 그들이 당신을 좋아하지 않고 심각하게 받아들이지 않을 것입니다.

경영진은 이제 1 년 동안 프로젝트를 확장하고자하며, 그 과정에서 거의 3 배의 사용자 기반

이와 같은 비즈니스 의사 결정은 그들이 이용할 수있는 리소스로 인해 결정하려고하기 때문에 이루어집니다. 경영진이 레거시 소프트웨어의 문제를 알고 있고 사용자 불만 사항을 알고 있다고 확신하지만 리팩토링 또는 재 작성을 처리하는 데 사용할 수있는 소프트웨어 개발 리소스가 있습니까?

대부분의 경우, 특히 소프트웨어가 회사의 빵과 버터가 아니고 소프트웨어에 대한 품질과 사용자 만족도가 직접적으로 수익에 영향을 미치지 않는 경우에는 그렇지 않습니다. 이런 종류의 결정을 내리는 것은 때때로 당신이 무엇을 하든지 손실 된 상황에 처하기 때문에 관리자가되는 것이 짜증나는 이유입니다.

지난 5 년간 여러 개발자가 서로 다른 시간에 개발 한 구식 시스템 유지

이 시점까지 프로젝트 전체에 실수가있었습니다. 견고한 사용자 입력 또는 요구 사항 부족, 변화하는 요구 사항 및 요구 사항을 관리하기위한 적절한 제품 관리 및 변경 제어 부족, 구현할 적절한 기술 리소스 부족으로 오늘날의 문제가 발생했습니다. 그래도 쓸모없는 것이 올바른 단어인지는 모르겠습니다. 기본 기술이 지원되지 않는 프레임 워크 및 기술을 기반으로 구축 되었습니까? 아니면 최첨단 기술이나 이상적인 기술이 아닙니까?

인턴 (또는 엔트리 레벨 포지션)으로서 어떻게 "푸시 백"합니까?

당신은 권력이 가장 낮은 위치에 있고 일시적입니다. 당신이 옳은지는 중요하지 않습니다. 인턴이 "뒤로 밀려 올"것을 기대하지는 않을 것입니다. 나는 그들이 배우고 문제를보고 토론하며 명령을 따를 것을 기대합니다. 그게 다야. 일단 주문이 주어지면 나는 논의 할 시간이 그 시점에 끝났기 때문에 그들의 능력을 최대한 발휘할 것으로 기대합니다.

당신은 인턴입니다. 나는 당신이 원격으로 일상적인 비즈니스 요구 사항을 전체적으로 잃어 버렸는지, 다른 사람들이 알다시피, 5 살짜리 코드베이스는 실제로 그렇게 오래되지 않았는지 의심합니다.

레거시 시스템 교체에 대한 결정이 항상 기술적으로 추진되는 것은 아닙니다. 비즈니스 요구 사항의 변화에 ​​의해 주도됩니다. 이들에 대한 입력은 유지 관리와 관련된 어려움이 될 수 있습니다. 그러나 하루가 끝났을 때, 당신의 입장이 반드시 모든 가용하고 필요한 지식을 가지고 있다는 것을 의미하지는 않습니다. 나는 당신이 실제로 현재 가장 좋은 움직임에 대해 전화를 걸기 위해 필요한 지식이 거의 없다고 말할 수 있습니다.

당신에게 나의 충고는 이것입니다 : 경험으로부터 배우고 당신의 지식이 매일 사업을 운영해야하는 사람들의 지식보다 우선한다고 가정하지 마십시오.

당신의 임무는 반짝이는 새로운 교체를 제안하지 말고 시스템을 계속 작동시키는 것입니다.

많은 젊은 프로그래머들은 구형 시스템의 유지 관리가 반짝이는 새로운 시스템을 설계하는 것보다 프로그래밍 작업의 더 큰 부분이라는 것을 인식하지 못하는 것 같습니다.

뒤로 밀지 마십시오. 당신이해야 할 유일한 일은 명확하고 간결한 방식으로 우려 사항을 표명하는 것입니다. 중요한 것은 앞으로 일할 대부분의 비즈니스에 레거시 시스템이 있다는 것입니다. 대부분의 경우 교체하기에는 너무 비싸기 때문에 이러한 레거시 시스템을 유지 관리해야합니다.

대부분의 경우 현재 시스템을 더 나은 시스템으로 교체하려는 가장 좋은 의도가있을 수도 있지만, 새롭고 다른 버그가 발생할 수 있습니다. 이전과 같은 지점에 있어야합니다. 더 이상 서버가 목적을 갖지 않거나 최신 시스템과 완전히 호환되지 않을 때까지 더 이상 사용되지 않습니다. 우리 회사는 지금 막 ASP.NET으로 변환하고있는 20 세 이상의 시스템을 가지고 있습니다. 시스템은 여전히 ​​실행 중이지만 이전 기술에 대한 지원이 줄어들고 있으며 최신 웹 브라우저에서 작동하게되면 점점 더 많은 시간이 소요됩니다.

할 수있는 일 :

물건을 더 깨끗하게 두십시오

무언가를 유지할 때는 시작했을 때보 다 깨끗하게 두십시오. 다음에 누군가 수정해야 할 때는 이해하기 쉬우므로 문제를 해결하고 정리하십시오.

문서 작성

문서 부족이 문제인 경우 문서를 작성하십시오. 시스템의 특정 부분을 작업 할 때 문서를 작성하십시오.

덜 고통스럽게 만드십시오

내가 말했듯이, 당신은 당신의 우려를 표명 할 수 있지만 최선을 다하는 것은 시스템에서 부지런히 일하고 당신을 따르는 사람들을 위해 일하는 것이 더 좋게 만드는 것입니다. 버그를 올바르게 수정하십시오. 문서. 분산 코드 냄새가납니다. 더 나아지십시오. 그리고 이런 일을 할 때 상사에게 알리십시오. 개발 프로세스를 개선하기 위해 X, Y 및 Z를 수행한다고 말하십시오. 그것은 신뢰성을 높이고 장기적으로 당신과 당신의 회사를 다른 무엇보다 도울 것입니다.

당신은하지 않습니다 !!! 이것은 위대한 기회입니다!

당신은 배울 인턴쉽입니다! 이 프로젝트는 현실 세계입니다.

당신은 그것을 가지고 매우 운이 좋다. 당신이 자격이 없다는 사실은 당신의 걱정이 아닙니다. (경영진이 이것을 깨달았을 때 당신은 많은 것을 얻었을 것입니다)

이 인턴쉽을 마치면 자격이 될 것입니다. 좋은 소식입니다.

추신 : 종교적으로 백업하십시오. 어떤 일이든 롤백 할 수 있는지 확인하십시오. "쉬운 수정 사항"인 문제부터 시작하지만 사용자에게는 큰 어려움이 있습니다. 아기 발걸음을 내 딛으십시오.

매우 이론적 인 의미에서 레거시 시스템 이라는 것은 없습니다 . 나는 매우 오래된 전화 (레거시 시스템)를 가지고 있으며 요즘에는 좋은 안드로이드 전화 (현대 플랫폼)가 있지만 내 전화가 작동하고 필요한 것을 수행합니다. 왜 그걸 버려야합니까?

오늘날 "레거시"라고 부르는 모든 시스템은 언젠가는 최첨단이었습니다. 우리가 필요한 시간입니다. 또한 상당한 규모의 작업이 이루어지면 현대 플랫폼에서 전체 작업을 다시 수행하는 것이 아니라 자동으로 버그가 발생하지 않습니다 (또는 고통이 없음).

다음은 내가 권장하는 사항입니다.

1. "레거시 시스템"에 대한 싫어하는 것을 먼저 치워 두십시오. 이렇게하면 생산성이 매우 높아집니다.

2. 지금하고있는 것과 생각한 것을 문서화하십시오. 단계적으로 단계적으로 있습니다. 문서를 작성하는 데 필요한 시간보다 더 좋은 시간은 없습니다.

3. "레거시 시스템 (legacy system)"의 발전을 푸시 백 (back-back)하는 대신, 출구의 경로를 매끄럽게 정의하십시오. 기존 시스템과의 상호 운용성을 방해하지 않으면 서 새로운 플랫폼 형태로 단계적으로 수행 할 수있는 격리 된 새로운 개발을 경영진에게 확신시킬 수 있음을 확인하십시오. 사물이 발전함에 따라 천천히 (그리고 이것이 느리게 진행될) 레거시 시스템을 유지할 필요성은 사라질 것입니다. 이것이 오래된 시스템에 작별 인사를하는 유일한 방법입니다.

디판

진실은 아무도 인턴에게 그들이하고 싶은 일을주지 않는다는 것입니다. 당신이 가장 후배 인 사람이라면 가장 흥미 진진한 일을합니다. 조직이 더 흥미로운 일을하도록 믿을 수 있는지 여부에 대해 조직에 많은 것을 말하면서 개인적으로 얼마나 잘 처리하는지.

따라서 버그 수정을 통해 제공 할 수 있고, 터치하는 코드의 각 부분을 조금 더 낫게 만들어 리팩토링하고, 단위 테스트를 생성하고,이 시스템에 대해 생성하여 시작하여 리팩터링 할 수 있음을 보여주는 귀중한 기회가 있습니다. 이 시스템에 갇힌 다음 가난한 영혼에 대한 문서를 작성하여 문서화 할 수 있습니다. 또한 사용자를 효과적으로 처리하고 (보고 된 버그에 대한 세부 정보를 얻을 수 있음) 그들의 요구를 충족시킬 수있는 기회를 제공합니다. 프로젝트가 현재 소스 제어에없는 경우 프로젝트를 배치하고 버그 추적기에서 버그를 추적하지 않으면 시작하십시오. 이러한 유형의 행동은 전문적으로 일하는 방법을 알려줍니다.

또는 반대 방향으로 나아가서 프로젝트가 얼마나 나쁜지, 프로젝트를 교체하는 것이 얼마나 멋진 지 알 수 있습니다. 어느 경우 에나 인턴십 후에는 그 회사에서 일자리를 얻지 못할 것입니다.

다른 해에가는 것이 비용 효율적인지 판단하기에 충분한 정보가 없을 것입니다. 회사를 이해하고 사용자를 추가하는 이유는 흥미로울 것입니다. 약간의 성장이 진행되고있는 것처럼 보이며 재정적으로 또는 특정 시간 제한 아래에서 다른 앱을 빌드하기 위해 물러 설 여유가 없습니다. 새로운 앱을 구축하는 것이 어쨌든 최선의 선택은 아닙니다. 그들이 오래된 기술로 시작하지 않는 한 5 년은 그리 오래된 것이 아닙니다.