종합적으로 : 레거시 시스템을 어떻게 유지할 것인가? [닫은]

뉴욕-고층 건물이 떨리는 폭발로 83 세의 증기 파이프가 뉴욕과 다른 미국 도시들 아래에서 수 마일의 튜브, 전선 및 철이 점점 더 늙어 위험에 빠질 수 있다는 강력한 메시지를 보냈습니다.

2007 년 7 월 맨해튼의 파열 증기관에 관한 이야기

우리는 소프트웨어 부패 와 기술적 부채 에 대해 들었습니다 .

그리고 우리는 다음과 같은 소식을 들었습니다.

• "밥 아저씨"마틴-누가 " 엉망을 만드는 결과 " 에 대해 경고했습니다 .
• Michael C. Feathers-누가 '레거시 코드로 효과적으로 작업 하기 '에 대한 지침을 제공했습니다 .

따라서 소프트웨어 엔지니어링 커뮤니티는 이러한 문제를 알고 있습니다.

그러나 저는 우리 사회가 이러한 문제가 어떻게 작업 시스템과 응용 프로그램을 괴롭힐 수 있는지 이해하지 못하는 것 같습니다.

Steve McConnell 은 다음과 같이 말합니다 .

... 금융 부채와 달리 기술 부채는 눈에 잘 띄지 않으므로 사람들은 무시하기가 더 쉽습니다.

이것이 사실이고, 그것이 사실이라고 생각한다면, 정부와 기업이 해커가 너무 늦을 때까지 정기 유지 관리 및 강화를 연기 할 수 있다고 우려합니다. [NYC 및 스팀 파이프와 매우 유사합니다.]

내 질문:

• NYC 및 스팀 파이프와 동등한 소프트웨어를 피할 수있는 방법이 있습니까?

레거시 시스템의 유지 관리와 관련된 주요 문제는 a) 해당 시스템의 속도를 높이고 b) 시스템을 계속 유지하려는 사람이 없다는 것입니다.

나는 최근에 젊은 프로그래머들이 메인 프레임에 관심이 있는지 아닌지에 대해 비슷한 질문을했다. 컨센서스는 아니오로 기울었다.

레거시 시스템을 유지 관리하는 것은 경력 자살로 간주됩니다. 관성 규칙이있는 많은 회사에서 훈련 시스템에 대한 투자가이 시스템의 최상위에 머무르는 데 투자가 거의 없기 때문에 인력 측면에서 단일 장애 지점이 발생합니다. 비슷한 시스템에서 일하는 사람들은 시스템에서 장기적인 미래를 보지 않고 경력에 해를 끼치기 때문에 경로를 찾고 있습니다.

일부 산업에서는 데이터 유지 관리 규정이 레거시 시스템을 합리적으로 감시하는 데 중요한 요소가 될 수 있습니다. 이것은 내가 생각하는 금융 산업의 문제입니다. 내가 아는 한, 이러한 규정은 일반적으로 시간 제한이 있습니다.

그러나 실제로는 다음과 같은 일이 발생할 것이라고 생각합니다.

그래프에서 더 현대적인 시스템으로 전환하는 비용이 기존 시스템의 단점을 해결할 수있는 비용이 기존 시스템을 유지하기위한 비용보다 저렴하기 때문에 비용이 절감되는 지점이 나옵니다.

IBM은 현재 많은 메인 프레임을 판매하고 있으며, 대형 머신이 젊은 전문가들의 무리를 막지 않도록 매우 열심히 노력하고 있습니다. 그러나 나는이 단계에서 충분하다고 생각하지 않습니다. 그들은 탄소 발자국과 실제 처리 능력 측면에서 USP를 가지고 있습니다.

그러나 Linux를 실행할 수 있기 때문에 IBM 메인 프레임을 구매하는 사람마다 전기 비용이 적게 들고 매우 효율적이며, 해당 서버에 대해 더 잘 알고 있기 때문에 서버 팜을 선택하는 사람이 더 있습니다. 더 많은 프로그래머들도 있습니다.

궁극적으로 많은 것은 관련 산업에 달려 있습니다. 몇 년 동안 메인 프레임에 크게 의존해 왔으며 여전히 널리 사용되는 특정 산업 분야에서 일하고 있습니다. 그러나 호스팅 솔루션은 점점 더 대중화되어 대기업의 기술을 통합 할 수있게되었으며, 이는 실패 시점에서 개별 회사가 직면 한 일부 문제를 제거하며, 일부 공급 업체는 비 메인 프레임 기반 솔루션을 매우 강력하게 검토하고 있습니다. 해당 산업에 내재 된 문제에 대해

결론적으로 요약하자면, 유지 관리 대 마이그레이션의 경제적 관점이 마이그레이션을 선호하는 즉시 레거시 시스템에서 마이그레이션으로 이동하게 될 것입니다. 그러나 그것은 새롭고 펑키하지 않으며 다음 큰 일을하는 방식으로 매우 대중적인 얼굴을 가지지 않기 때문에 많은 사람들에게 보이지 않습니다. 이 마이그레이션은 서비스 제공 업체 나 최신 기술 (특히 서비스 제공 업체가 직접 영향을받는 기술)로 마이그레이션 될 수 있습니다.

저의 경험, 특히 네트워크에서 레거시 시스템에 대한 의존도를 제거하려는 움직임이 있습니다.

대부분의 사업체는 이미 기술 부채에 대해 무지하고 있으며, 말 그대로 파산하여 파산하게 될 때까지 상황이 나쁘다는 사실조차 깨닫지 못합니다. 나는 실제로 보았다그런 일이 생겨서 예쁘지 않았습니다. 더 나빠진 것은 사업주들에게 기술 부채 빚을 고치려고 노력하고 그것을 고쳐야한다는 사실을 반복적으로 시도했고, 매번 고치는 데 필요한 시간과 자원을 소비하지 않기 때문에 거절 당했다는 사실이었다 그것. 최종 결과는 10 년이 지난 후 시스템이 마침내 실패한 후 (내가 없어진 후) 복구 할 수 없었고, 사업을 그만 두었습니다. 10 년 동안 약간의 돈을 소비한다는 것을 깨닫기에는 너무 어리석기 때문입니다. 문제를 완전히 무시하는 것보다 낫습니다. 나는 그 회사의 터무니없는 어리 석음에 대해 몇 시간 동안 울부 짖을 수 있었고, 가장 고통스러운 것은 주인 이 그렇지 않은 경우 완전히 피할 수 있다는 것입니다. 다른 모든 것을 완전히 잘라서 빠르게 돈을 벌 수 있습니다.

그것은 자신의 시스템이 심하게 작성 및 일부 무거운 리팩토링 (그렇지 않은 경우가 있기 때문에 보통의 경우 총 재 작성해야 할 경우 사업을 말하려고 굉장히 어려운 일 입니다 나쁜 참조). 대부분의 시간 그들은 단지 당신이 새로운 기능을 변경하거나 추가 할 어려운 것을 그들에게 경고하는 경우에도 당신을 쏠거야 (난 그냥 더미에 더 많은 쓰레기를 레이어링하지, 올바른 방법을 의미), 또는 고려 하면 을 현재 상태의 시스템에 문제가 있으므로 비즈니스에 해를 끼칩니다.

솔직히 말하면 전투에서 패배하고 싸울 가치가 없다는 결론에 도달했습니다. 기술 부채에 대해 알만큼 똑똑한 사람들은 그것에 대해 두 번 이야기 할 필요가 없으며 처음부터 위험을 알고 있으며 다른 사람들은 너무 늦을 때까지 어떤 종류의 이유나 경고도 듣지 않습니다. 최선의 (물론 가장 비현실적인) 옵션은 자연 선택이 시작되고 무지한 사람들이 멸종되고 지적인 사람들 만 떠나게하는 것입니다. 나는 과거에 개인적으로 시도한 모든 것이 완전히 무시되거나 회사의 눈에 내 가치를 떨어 뜨리거나 ( "불평") 심지어 더 이상 그것을 다루는 더 이상 실제적인 방법을 모른다. "무엇입니까"를 수정하는 데 "너무 집중되어"있기 때문에 종료되었습니다 부서진 사람은 아무도 마음이 아프다는 것을 알 수있었습니다.

뉴욕과 다른 미국 도시들 아래에있는 수 마일의 튜브, 전선 및 철은 점점 더 나이가 들어 위험하게 불안정해질 수 있습니다.

일화에 대해서도 16-17 세기 파리에서 같은 주장이 이루어졌다. 너무 많은 구멍과 터널이 그 지역의 지질학으로 인한 자연적인 구멍 외에도 그 아래에 파여져 가끔 건물이 무너졌습니다.

전체 도시 블록이 땅에 무너질 때까지 불필요한 구멍과 터널을 자갈과 뼈로 채우라는 지시가 주어졌습니다 (그들은 또한 붐비는 묘지 문제가있었습니다). 도시는 콘크리트가 발명 될 때까지 그런 식으로 살아 남았습니다.

여기서 요점은 많은 조직이 소프트웨어 유지 관리를 위해 마지막 순간을 기다리는 경향이 있지만 토목 기술자와 같은 코더가 작업을 빠르고 잘 수행한다는 것입니다.

우리는 Y2k 버그에서 살아 남았습니다. Y2036 버그는 많은 조직이 하드웨어 및 소프트웨어를 업그레이드하도록합니다. 세계는 2012 년에 끝날 수 있습니다. 그러나 컴퓨터 과학자는 사회학 자나 문학 비평가 가 아닙니다 .

아, 그리고 그 말이 진행되는 동안 : 다음 관리자가 당신이 사는 곳을 아는 악한 정신병자 인 것처럼 코드를 작성하십시오.

요즘 레거시 코드는 무엇이라고 생각합니까? 작년의 코드, 지난 십년 간의 코드 또는 지난 세기의 코드?

돈은 레거시 시스템의 유지 관리에 관한 대화를 주도합니다. 기술 부채는 시스템 변경 비용 증가로 그 형태를 취합니다.

잘못 설계되고 지능적으로 설계된 시스템으로 작업했습니다. 흥미로운 점은 유지 비용이 그다지 다르지 않다는 것입니다. 가장 큰 문제는 현재 사용중인 잘못된 아키텍처로, 일반적으로 스케일링 문제 또는 주요 변경이 필요한 경우에 나타납니다. 주요 코드 영역을 단일 스레드에서 다중 스레드로 쉽게 변환 할 수 없습니다.

내가 경험하는 가장 중요한 문제는 사용 된 개발 언어입니다. 오래된 시스템은 오늘날 덜 인기있는 언어로 작성되므로 더 많은 교육을 받거나 더 노련한 (비싸고) 희귀 한 리소스를 고용해야합니다. 두 경우 모두 작은 수영장으로 인해 솔루션만큼 많은 문제를 일으키는 경향이있는 숙련 된 개인을 찾는 데 어려움을 겪고 있습니다.

약속 된 재 작성과 관련하여 막대한 투자를 한 대부분의 시스템은 재 작성을 정당화하지 않습니다. 소프트웨어가 얼마나 오래 작동하고 향상 될 수 있는지 놀랍습니다. 하드웨어 변경 (회사에서 지원하는 일부 시스템에서 특수 하드웨어 사용)이 가장 큰 문제인 경향이 있습니다. 향상 기능은 종종 레거시 코드를 새로운 기능과 통합하는 메커니즘에 의해서만 제한됩니다.

이것은 이미 큰 문제입니다. 그리고 그것은 변화의 징후를 보이지 않습니다.

60 년대와 70 년대에 모든 종류의 대규모 기관은 종이에 대한 회계 처리에서 컴퓨팅 시스템에 대한 회계 처리로 전환했습니다. 압도적으로 그들은 COBOL을 선택했습니다. 대부분 은 여전히 ​​해당 COBOL 시스템의 업데이트 버전을 사용하고 있습니다. http://cis.hfcc.edu/faq/cobol 참조 대한 통계는 을

아놀드 슈워제네거 (Arnold Schwarzenegger)가 2 년 전에 개발한지 6 개월 만에 20 만 주 공무원의 임금을 삭감 할 수 없다는 사실을 발견했을 때와 같이, 우리는 종종이 사실을 무작위로 상기시켜줍니다 ( http : //www.infoworld 참조) . com / d / developer-world / californias-cobol-conundrum-067 확인).

전환 위험이 있으므로 이러한 시스템 변경을 정당화하기는 매우 어렵습니다. 이제까지. 그것은 내 평생의 현실이었습니다. 그러나 나는 그 사실이 자녀의 생애에 변화를 줄 이유가 없다고 생각합니다. 또는 자녀의 평생.

나보다 오래된 코드를 유지 한 친구가 있습니다. 그녀가 처음 일한 지 30 년 만에 회사에 돌아온 친구가 있는데, 그녀는 기억조차 못하는 언어로 프로그램이 여전히 실행 중이고 변경되지 않았다는 것을 알게되었습니다!

두 가지 모두 일어날 수있는 일에 대한 실화로 마무리하겠습니다.

1970 년대에 회사거래자에게 온라인 시장을 제공하기 위해 설립되었습니다. PDP-11은 가격 대비 성능이 좋았 기 때문에 선택했습니다. 그들은 기계의 성능 한계를 뛰어 넘어 시스템을 고도로 최적화 된 PDP-11 어셈블리로 작성했습니다. 몇 년 후 PDP-11 판매가 중단되었습니다. 그러나 사업은 훌륭했고 기계는 지속되었으며 중고 교체품은 쉽게 구할 수있었습니다. 그들은 플랫폼을 유지했습니다. 그 후 몇 년이 지나면 교체품을 찾기가 더 어려워졌습니다. 거래 플랫폼을 대체하기위한 주요 프로젝트가 작성되었습니다. 실패했습니다. 그들은 다시 시도했다. 그리고 다시 실패했습니다. 실패의 주요 원인은 거래 시스템의 작동 방식을 아무도 모르고 더 이상 PDP-11 어셈블리를 읽을 수 없다는 것이 었습니다. 그때 구원이 닥쳤습니다. 누군가 Linux에서 실행되는 PDP-11 어셈블러를 만들었습니다.

따라서 2000 년에 10 억 달러 / 년 규모의 비즈니스로 들어오는 거래는 이더넷-데크 넷 브리지를 통해 Linux 컴퓨터로 가서 PDP-11 기계를 고도로 최적화 된 PDP- 11 조립. 속도를 위해.

지난 10 년 동안 회사와는 아무런 관련이 없었습니다. 그래서 그들이 에뮬레이트 된 PDP-11에서 여전히 실행되고 있는지 말할 수 없습니다. 나는 십진 화가 그들의 마진을 압박하게해서 이주하는 또 다른 노력을했다는 것을 안다. (나는 그 곳에서 해고당한 여러 사람들을 인터뷰했기 때문에 이야기를 배웠고, 무슨 일이 있었는지 물었다.)

사용자의 입장에서 볼 때 매우 우려되는 것 같습니다. 부패가 지연되거나 더 잘 방지 되려면 문제가되는 소프트웨어에 족쇄가 없어야합니다. 게시자는 소스 코드를 무료로 설정했거나 마지막 사용자가 소스 코드 사용을 중지 할 때까지 소스를 유지 관리하고 업그레이드해야합니다. 그렇지 않으면 비즈니스 세계에서 비슷한 부패로 인해 비즈니스가 중단 될 가능성이 매우 높으므로 소프트웨어가 부패에 완전히 개방 된 상태로 유지됩니다.

즉, 소프트웨어 저작권 및 라이센스 제한 기간은 매우 짧아야하며,이 기간이 지나면 소프트웨어 및 해당 코드베이스가 공개 도메인에 들어가서 그대로 유지됩니다. 따라서, 사용자가 소스를 계속 업그레이드하거나 다른 사람을 고용하여 썩음을 지연 및 / 또는 피할 수있게한다.

또는 자유 소프트웨어에 대해 어느 정도 개방적이라면 AGPL 또는 GPL과 같은 자유 라이센스 또는 기타 자유 소프트웨어 라이센스로 프로그램을 작성할 수 있습니다. 내가 본 것에서 소프트웨어 소스가 어떤 이유로 든 개발자에게 더 이상 관심을 갖지 않으면 소스 기반은 식욕을 잃고 새로운 삶을 영위합니다. 내가 본 한, 데비안 운영 체제의 패키지는이 수명주기를 따르는 경향이 있습니다.

다양한 정부 및 민간 산업 응용 프로그램을 지원하면서 대부분의 회사와 미국 정부는 코드가 썩어지고 최신 보안 트렌드를 지키지 않을 위험에 대해 잘 알고 있다고 말합니다.

우리는 정기적으로 다양한 취약성에 대해 소프트웨어 인증을 받아야하며 대부분의 정부 전자 시스템, 심지어 오래된 전자 시스템은 정기적으로 업데이트하여 보안을 유지해야합니다.

물론 예외가 있으며 해커는 항상 움직이고 있지만 사람들은 당신이 무언가를 버리고 다시는 만질 수 없다는 것을 잘 알고 있다고 생각합니다.

경고 : 이것은 약간 자유 형식이 될 것입니다 ...

귀하의 우려 사항을 살펴볼 수있는 두 가지 방법이 있습니다.

당신이 그것을 생각하면, 일부 우주 왕복선과 위성은 원래 발사 한 것과 동일한 코드를 실행했습니다. 반면에 일부는 원격 인 경우에도 업데이트되도록 설계되었습니다.

중요한 것은 환경입니다. 분명히 환경을 수정하지 않는 한 코드는 더 이상 사용되지 않습니다. 이 경우 코드 썩음은 실제로 존재하지 않습니다. 코드 자체 (또는 생성 된 이진 파일)는 썩을 수 없습니다. 완전히 다른 각도에서 공격을 시작하면 깨질 수 있습니다. 썩는 것이 아니라 환경에 적응하지 않는 것입니다. 그것을 진화적인 문제라고 생각하십시오.

그러나 우리의 환경은 변합니다. 그리고 어떻게 든 문제의 열쇠는 해결책입니다. 우리의 환경은 매우 빠르게 변화하여 오늘날에는 소프트웨어 솔루션이 시간이 지나도 진화하지 않을 것으로 예상합니다. 우리는 지난 해 업데이트되지 않은 소프트웨어 프로젝트를 간과하고 명확한 로드맵을 생성하지 않는 제품 및 고객 지원에 대해 신음 할 것입니다. 그리고 이것이 잘 작동하더라도 명확한 로드맵, 좋은 지원, 정기적 인 업데이트를 얻을 수 있습니다. 이제는 도전자가 기하 급수적으로 성장할 가능성이 항상 있습니다. 우리는 종종 거대 기업이 항상 지배하기 때문에 항상 지배 할 것이라고 생각하는 실수를합니다. 그러나 무리에서 지배적 인 요소가 오래 될 때와 마찬가지로, 대규모 소프트웨어 / 하드웨어 / 공급 업체가 오래 될 때마다 아니면 조금 게으르다. 그리고 도전자는 5 ~ 10 년 전에 확립 된 지배적 인 지배자보다 훨씬 빠르게 일을 처리합니다. 또는 지배자는 시장에서 혼란을 겪는 동안 (경제적으로 말하면, 다른 분야에 영향을 미침), 잘 뛰고 간신히 생존 할 것이며, 상황은 계속 될 것입니다. 어쩌면 그것은 불완전 해 보이지만 그 자체로는 유기적 인 과정입니다.

따라서 사용자 관점에서 문제가 그렇게 크지 않은 것 같습니다. 코드 썩음은 사용자의 관점에서 발생하지 않을 것입니다.

이제 우리가 사용자 관점에서 사물을 보지 못하거나 알 수없는 이유, 정부 개발, 임시 여행 등의 이유로 면역성이있는 시스템에 대해 이야기하고 있다고 가정하고 실제로 가정합니다. 아주 오래 살기 위해 살아 남기 위해 우리는 당신이 참조한 텍스트를 봐야합니다. 그리고 아마도 신뢰할 수있는 시스템과 내결함성 시스템에 대한 더 많은 문헌이있을 것입니다. 더 나아가고 싶겠지 만. 우리는 단지 내결함성을 원치 않고 진화 시스템을 원합니다.

진화의 문제점은 변화를 가져오고 변화는 실패 지점을 초래한다는 것입니다. 지금 이것들을 살펴보고 그것들을 해결하기 위해 우리가 할 수있는 일을 보자.

우리는 여전히 인프라 / 아키텍처 / 창업적인 은유에 의존 할 수 있습니다 (결국 우리는 모두 소프트웨어 엔지니어이지만 소프트웨어 엔지니어링과 같은 것은 없습니다). 튜브 시스템이 여전히 작동하는 동안 (일부 결함이있는), 빅 벤이 여전히 작동하거나 (일부 결함이있는 경우) 에펠 탑이 여전히 서있는 이유가 있습니다. 이는 인프라의 핵심 요소 (또는 그다지 중요하지 않은 요소)와 함께 소프트웨어로 수행해야 할 작업도 지속적으로 수행하기 때문입니다. 이러한 개체는 반드시 오래 지속되도록 설계되지는 않았지만 필요할 때 영구적 인 감독과 적시 개선 및 수리의 혜택을 누 렸습니다. 당신이 원한다면 핫픽스를 부르십시오.

반면에 일부 디자인은 지속적인 검사가 불가능하다는 것을 알면서도 중단없이 견고하게 실행되도록 설계되었습니다. 이 경우 우리는 좋은 디자인과 공식적인 모델로 전환합니다. 주어진 환경에 대해 신뢰성 요소 (가용성, 신뢰성, 안전, 무결성, 유지 보수성)를 수량화 할 수 있습니다. 통계는 나머지와 미래를 계획하기 위해 나머지를 수행합니다. 문제는 다음과 같습니다. 실제 의미에서 진화 할 시스템을 구축 할 수 있습니까?

Clean Code의 Jeff Langer는 비슷한 질문을합니다 ... 증기 파이프에 대한 언급없이 :)

작업 할 때 좋은 디자인을 만드는 데 도움이되는 4 가지 간단한 규칙이 있다면 어떨까요? 이러한 규칙을 따름으로써 코드의 구조와 디자인에 대한 통찰력을 얻어 SRP 및 DIP와 같은 원칙을 쉽게 적용 할 수 있다면 어떨까요? 이 4 가지 규칙이 좋은 디자인의 출현을 촉진한다면 어떨까요?

우리 중 많은 사람들이 Kent Beck의 4 가지 심플 디자인 규칙이 잘 설계된 소프트웨어를 만드는 데 큰 도움이된다고 생각합니다.

Kent (Extreme Programming Explained)에 따르면 다음 규칙을 따르는 경우 설계가“단순”합니다.

• 모든 테스트를 실행합니다
• 중복 없음
• 프로그래머의 의도를 표현
• 클래스 및 메소드 수를 최소화

모든 테스트를 실행하려면 ... 테스트를 실행해야하며 이는 기술 부채의 큰 지표입니다. 예를 들어, Mercury Quality Center와 같은 시스템에 10,000 개의 테스트 사례가 있고 그 테스트 중 어느 것도 자동화 되지 않은 경우, 이는 구축 된 기술 부채의 분명한 지표입니다.

그리고 Feathers와 그의 저서 "레거시 코드로 효과적으로 작업하기"가 등장합니다.