소프트웨어의 부패
Software rot비트 썩음, 코드 썩음, 소프트웨어 침식, 소프트웨어 부패 또는 소프트웨어 엔트로피라고도 하는 소프트웨어 부패는 시간이 지남에 따라 소프트웨어 품질이 저하되거나 응답성이 저하되어 결과적으로 소프트웨어 장애가 발생하거나 사용할 수 없게 되거나 업그레이드가 필요할 수 있습니다.이것은 물리적인 현상이 아닙니다.소프트웨어가 실제로 부패하는 것이 아니라 소프트웨어가 상주하는 환경의 변화에 대한 응답성과 업데이트가 부족하기 때문입니다.
해커의 지식의 요약인 Jonesm File은 "비트 썩음"을 "아무것도 변하지 않았다"고 해도 시간이 지남에 따라 소프트웨어 프로그램의 성능 저하를 설명하는 농담적인 설명으로 정의한다.이 배경의 개념은 프로그램을 구성하는 비트가 방사능 [1]붕괴의 대상이 되는 것과 거의 같다.
원인들
소프트웨어가 동작하는 환경의 변경, 소프트웨어 자체의 일부 간의 호환성 저하, 사용되지 않거나 거의 사용되지 않는 코드에 버그가 발생하는 등 소프트웨어 부패의 원인이 되는 요인이 몇 가지 있습니다.
환경 변화
프로그램 환경(특히 프로그램 설계자가 예상하지 못한 변경)에 변경이 발생하면 소프트웨어는 더 이상 원래 의도한 대로 작동하지 않을 수 있습니다.예를 들어, 많은 초기 컴퓨터 게임 디자이너들은 [2]게임에서 CPU 클럭 속도를 타이머로 사용했습니다.그러나 새로운 CPU 클럭은 더 빨랐기 때문에 게임 플레이 속도가 증가하여 시간이 지남에 따라 게임을 사용할 수 없게 되었습니다.
일회성
프로그램 설계자가 아닌 사용자와 관련된 환경 변화가 있습니다.처음에 사용자는 시스템을 정상 작동시키고 일정 시간 동안 흠잡을 데 없이 작동할 수 있었습니다.다만, 시스템이 정상적으로 동작하지 않게 되었을 경우, 또는 유저가 설정 제어에 액세스 할 필요가 있는 경우는, 콘텍스트가 다른 것과 사용 불가능한 정보(패스워드의 분실, 지시의 누락, 또는 단순히 시행 착오로 최초로 설정되었을 때의 관리가 어려운 유저 인터페이스) 때문에, 그 초기 순서를 반복할 수 없습니다.정보 아키텍트 Jonas Söderström은 이 개념을 [3]Oneability라고 명명하고 "사용자가 시스템이 고장나면 복원할 수 없는 기술 시스템의 품질"이라고 정의합니다.
미사용코드
문서 필터나 다른 프로그램에서 사용하도록 설계된 인터페이스와 같이 자주 사용되지 않는 코드 부분에 눈에 띄지 않는 버그가 있을 수 있습니다.사용자 요건 및 기타 외부 요인의 변경에 따라 이 코드가 나중에 실행되어 버그가 노출되고 소프트웨어의 기능이 저하될 수 있습니다.
거의 업데이트되지 않은 코드
소프트웨어 및 시스템을 정상적으로 유지보수할 경우에도 소프트웨어가 부패할 수 있습니다.특히, 프로그램에 서로 떨어진 거리에서 기능하는 여러 부품이 포함되어 있는 경우, 한 부품에 대한 변경이 다른 부품에 미치는 영향을 고려하지 않으면 버그가 발생할 수 있습니다.
경우에 따라서는 소프트웨어가 사용하는 라이브러리의 형태가 변경되어 소프트웨어에 악영향을 미칠 수 있습니다.이전 버전에서 발견된 다른 소프트웨어 또는 보안 결함으로 인해 이전 버전에서 작동하던 라이브러리를 더 이상 사용할 수 없는 경우 프로그램에서 사용하는 데 필요한 라이브러리의 실행 가능한 버전이 더 이상 없을 수 있습니다.
온라인 접속
최신 상용 소프트웨어는 라이센스 확인 및 정보 액세스를 위해 온라인 서버에 연결하는 경우가 많습니다.소프트웨어에 전원을 공급하고 있는 온라인 서비스가 셧다운되면 동작을 [4][5]정지할 수 있습니다.
분류
소프트웨어 부패는 일반적으로 휴면 부패 또는 활성 부패로 분류됩니다.
휴면 부패
현재 사용되지 않는 소프트웨어는 응용 프로그램의 나머지 부분이 변경됨에 따라 점차 사용할 수 없게 됩니다.사용자 요건과 소프트웨어 환경의 변화도 악화의 한 원인이 됩니다.
활성 썩음
지속적으로 수정되는 소프트웨어는 적절한 완화 프로세스를 일관되게 적용하지 않으면 시간이 지남에 따라 무결성이 손실될 수 있습니다.그러나 많은 소프트웨어에서 새로운 요건을 충족하고 버그를 수정하기 위해 지속적인 변경이 필요하며 변경이 이루어질 때마다 소프트웨어를 재설계하는 것은 거의 현실적이지 않습니다.이로 인해 프로그램의 본질적인 진화 프로세스가 생성되어 원래 엔지니어링된 설계에서 벗어나게 됩니다.이로 인해 환경변화의 결과로 원래 설계자의 가정이 무효화되어 버그가 발생할 수 있다.
실제로는 갱신 문서보다 새로운 기능을 추가하는 것이 우선시될 수 있습니다.다만, 문서화가 없으면, 프로그램의 일부에 관한 특정의 지식이 없어질 가능성이 있습니다.이는 코딩 규약에 대한 최신 모범 사례를 따름으로써 어느 정도 완화될 수 있습니다.
활성 소프트웨어 부패는 응용 프로그램의 상용 수명이 다 되어 더 이상 개발이 중단되면 느려집니다.사용자는 대부분의 경우 남은 소프트웨어 버그에 대처하는 방법을 배우고, 아무것도 변하지 않기 때문에 소프트웨어의 동작은 일관되게 됩니다.
예
AI 프로그램 예시
AI 연구 초기부터 많은 주요 프로그램들이 복구할 수 없는 소프트웨어 부패로 어려움을 겪어왔다.예를 들어 원래의 SHRDLU 프로그램(초기 자연어 이해 프로그램)은 LISP와 PlANNER가 아직 개발 단계에 있던 시절에 개발되었기 때문에 더 이상 존재하지 않는 비표준 매크로와 소프트웨어 라이브러리를 사용하기 때문에 현대 컴퓨터나 컴퓨터 시뮬레이터에서 실행할 수 없습니다.
온라인 포럼 예시
관리자가 오픈소스 포럼 소프트웨어를 사용하여 포럼을 작성한 후 새로운 기능과 옵션을 추가하여 포럼을 대폭 수정한다고 가정합니다.이 프로세스를 수행하려면 기존 코드를 광범위하게 수정하고 해당 소프트웨어의 원래 기능에서 벗어나야 합니다.
여기서부터, 소프트웨어의 부패가 시스템에 영향을 주는 몇개의 방법이 있습니다.
- 관리자가 실수로 서로 또는 원래 소프트웨어와 충돌하여 포럼이 예기치 않게 동작하거나 완전히 중단될 수 있습니다.이는 그들이 원래 코드와 크게 어긋나 있기 때문에 포럼을 부활시키기 위한 기술 지원 및 지원을 얻기가 어려울 것이라는 매우 좋지 않은 상황에 놓이게 됩니다.
- 원래 포럼 소스 코드에 보안 구멍이 발견되어 보안 패치가 필요할 수 있습니다.단, 관리자가 코드를 광범위하게 수정했기 때문에 패치를 해당 코드에 직접 적용할 수 없을 수 있으므로 관리자가 업데이트를 효과적으로 다시 작성해야 합니다.
- 변경을 가한 관리자는 자리를 비울 수 있으며, 새로운 관리자에게는 완전한 문서가 없는 복잡하고 대폭 수정된 포럼이 남아 있습니다.변경 내용을 완전히 이해하지 못하면 새 관리자가 충돌 및 버그를 발생시키지 않고 변경하기 어렵습니다.게다가 원래의 시스템의 메뉴얼은 더 이상 입수할 수 없거나, 기능 요건의 미묘한 차이로 인해 오해의 소지가 있는 경우가 있습니다.
리팩터링
리팩터링은 소프트웨어 부패 문제를 해결하는 수단입니다.외부 [6]동작에 영향을 주지 않고 구조를 개선하기 위해 기존 코드를 다시 작성하는 과정으로 설명됩니다.여기에는 데드 코드 제거 및 광범위하게 수정되어 더 이상 효율적으로 작동하지 않는 섹션 다시 쓰기가 포함됩니다.소프트웨어의 외부 동작을 변경하지 않도록 주의해야 합니다.이러한 동작은 비호환성을 초래하여 소프트웨어 부패의 원인이 될 수 있습니다.
「 」를 참조해 주세요.
레퍼런스
- ^ Raymond, Eric. "Bit rot". The Jargon File. Retrieved 3 March 2013.
- ^ Inc, Ziff Davis (1992-01-28). PC Mag. Ziff Davis, Inc. p. 286.
- ^ Jonas Söderström. "Onceability: The consequence of technology rot".
- ^ Amadeo, Ron (31 October 2016). "The (updated) history of Android". Ars Technica. Retrieved 31 October 2021.
- ^ "Adobe CS2 is Now Available for Free, Sort Of". Mobile Magazine. 2013-01-14. Archived from the original on 2013-01-18. Retrieved 2013-01-20.
- ^ Fowler, Martin (October 11, 2007). "What Is Refactoring". Retrieved 2007-11-22.