수명이 긴 웹 애플리케이션 개발 (20 년 이상)

현재 정부 토지 계획을위한 웹 응용 프로그램을 개발 중입니다. 애플리케이션은 대부분 브라우저에서 실행되며 데이터를로드하고 저장하기 위해 ajax를 사용합니다.

초기 개발을하고 졸업을합니다 (학생 직업). 그 후, 나머지 팀은 필요에 따라 가끔 기능을 추가합니다. 코딩 방법을 알고 있지만 대부분 토지 계획 전문가입니다.

Javascript 기술의 변화 속도를 고려할 때 20 년이 지난 지금도 계속 작동하는 코드를 작성하려면 어떻게해야합니까? 특히 코드를 미래에 대비하기 위해 어떤 라이브러리, 기술 및 디자인 아이디어를 사용해야합니까 (또는 피해야합니까)?

우리는 미래에 대해 무엇을 알지 못하기 때문에 그러한 수명을위한 소프트웨어 계획은 어렵습니다. 약간의 맥락 : Java는 21 년 전에 1995 년에 출판되었습니다. XmlHttpRequest는 17 년 전에 1999 년에 출판 된 Internet Explorer 5의 독점적 인 확장으로 처음 제공되었습니다. 모든 주요 브라우저에서 사용할 수있을 때까지 약 5 년이 걸렸습니다. 20 년 동안 앞서 가고자하는 것은 리치 웹 애플리케이션이 존재했던 시간에 불과합니다.

그 이후로 어떤 것들은 확실히 동일하게 유지되었습니다. 강력한 표준화 노력이 있었으며 대부분의 브라우저는 관련된 다양한 표준을 잘 준수합니다. 15 년 전 브라우저에서 작동 한 웹 사이트는 각 브라우저에 대한 해결 방법을 사용한 것이 아니라 모든 브라우저 의 공통 하위 집합 을 대상으로했기 때문에 여전히 동일하게 작동 합니다.

다른 것들이왔다 갔다했다 – 가장 두드러진 플래시. 플래시는 다양한 문제를 일으켜 사망에 이르렀습니다. 가장 중요한 것은 단일 회사에 의해 통제되었습니다. Flash 플랫폼 내에서 경쟁하는 대신 Flash와 HTML5와 HTML5가 경쟁했습니다.

이 역사에서 우리는 몇 가지 단서를 모을 수 있습니다.

• 간단하게 유지하십시오. 해결 방법을 사용하지 않고 지금 당장 작동하는 것을하십시오. 이 동작은 이전 버전과의 호환성을 위해 미래에도 오랫동안 사용 가능할 것입니다.

• 독점 기술에 의존하지 말고 공개 표준을 선호하십시오.

오늘날 JavaScript 세계는 매우 다양한 라이브러리와 프레임 워크로 변동이 심합니다. 그러나 20 년 동안 그중 어느 것도 중요하지 않을 것입니다 . 그때까지도 여전히 사용될 유일한 "프레임 워크"는 Vanilla JS 입니다.

라이브러리 나 도구를 사용하여 개발이 훨씬 쉬워 지려면 먼저 오늘날의 잘 지원되는 표준을 기반으로 구축해야합니다. 그런 다음 라이브러리 또는 도구를 다운로드하여 소스 코드에 포함시켜야합니다. 코드 리포지토리에는 시스템을 실행 가능하게하는 데 필요한 모든 것이 포함되어야합니다. 외부의 것은 미래에 깨질 수있는 의존성입니다. 이를 테스트하는 흥미로운 방법은 코드를 썸 드라이브에 복사하고 다른 운영 체제를 사용하는 새 컴퓨터로 이동하여 인터넷에서 연결을 끊고 프런트 엔드가 작동하는지 확인할 수 있습니다. 프로젝트가 일반 HTML + CSS + JavaScript와 아마도 일부 라이브러리로 구성되어 있다면 통과 할 것입니다.

20 년 동안 생존 한 코드보다 훨씬 중요한 것은 데이터 가 20 년 동안 존속 한다는 것 입니다. 기회는 그것이 보존 할 가치가있는 것입니다. 데이터 작업이 용이하면 최신 기술로 대체 시스템을 구축하는 것이 쉬울 것입니다.

• 따라서 명확하고 잘 문서화 된 데이터 모델로 시작하십시오.
• Oracle ^[1] 또는 SQL Server 와 같이 잘 지원되는 기존 데이터베이스 시스템을 사용하십시오 .
• 기본 기능을 사용하고 화려한 새 기능을 사용하지 마십시오.
• 영리한 것 보다 단순한 것을 선호하십시오 .
• 미래의 유지 관리 성이 성능과 같은 측면을 희생시키면서 올 수 있음을 인정하십시오. 예를 들어, 저장 프로 시저를 사용하고 싶을 수도 있지만, 누군가가 시스템을보다 간단한 저장소 솔루션으로 마이그레이션하지 못하게되면 향후 유지 관리 성이 제한 될 수 있습니다.

일단 그것을 가지고 나면, 앱 자체의 미래를 보장하는 것은 데이터 모델을 둘러싼 래퍼 (wrapper)이기 때문에 더 간단합니다. 예를 들어 10 년 안에 아무도 더 이상 Javascript를 사용하지 않고 앱을 마이그레이션해야하는 경우 대체 할 수 있습니다. WASM 또는 무언가. 상호 의존성이 적은 모듈 식으로 유지하면 향후 유지 관리가 쉬워집니다.

^[1] 이 답변에 대한 대부분의 의견은 Oracle이 DB에 대해 Oracle을 사용하는 것에 대해 강한 입장을 취합니다. Oracle이 다루기 어려운 이유는 가파른 학습 곡선과 설치 오버 헤드가있는 합법적 인 이유가 많이 있습니다. 이것들은 Oracle을 DB로 선택할 때 전적으로 유효한 관심사이지만 우리의 경우 범용 DB를 찾고 있지 않지만 주요 관심사는 유지 관리 성 입니다. 오라클은 70 년대 후반부터 존재 해 왔으며 앞으로 수년간 지원 될 것이며, 컨설턴트가 계속 운영 될 수 있도록 지원하는 수많은 컨설턴트 및 지원 옵션 에코 시스템이 있습니다. 이것은 많은 회사에게 고가의 엉망입니까? 확실한. 그러나 20 년 동안 데이터베이스를 계속 운영 합니까? 꽤 비슷하게.

amon의 이전 답변 은 훌륭하지만 언급되지 않은 두 가지 추가 사항이 있습니다.

• 브라우저에 관한 것이 아닙니다. 장치도 중요합니다.

  amon은 “15 년 전 브라우저에서 작동했던 웹 사이트는 여전히 동일하게 작동 할 것” 이라는 사실을 언급 합니다. 그러나 15 년이 아니라 10 년 전에 생성 된 웹 사이트는 대부분의 사용자를 위해 대부분의 브라우저에서 작동하는 웹 사이트를 살펴보십시오. 오늘날 많은 사용자가 브라우저를 변경 한 것이 아니라 장치를 사용했기 때문에 해당 웹 사이트를 전혀 사용할 수 없습니다. 이러한 웹 사이트 는 작은 화면의 모바일 장치 에서 끔찍한 것처럼 보이며 개발자가 JavaScript click이벤트 에 의존하기로 결정한 경우 tap이벤트가 중요하다는 사실을 알지 못하면 전혀 작동하지 않습니다 .

• 잘못된 주제에 집중하고 있습니다.

  기술 변경은 한 가지이지만 더 중요한 것은 요구 사항의 변경입니다 . 제품을 확장해야하거나 추가 기능이 필요하거나 현재 기능을 변경해야 할 수도 있습니다.

  브라우저, 장치 또는 W3C에 어떤 일이 발생하든 상관 없습니다.

  코드를 리팩토링 할 수있는 방식으로 코드 를 작성 하면 제품이 기술과 함께 진화 할 것입니다.

  아무도 코드를 이해하고 유지 관리 할 수없는 방식으로 코드를 작성하는 경우 기술은 중요하지 않습니다. 환경 변화로 인해 다른 운영 체제로 마이그레이션하거나 자연스런 데이터 증가와 같은 단순한 것 같은 애플리케이션이 중단 될 수 있습니다. .

  예를 들어, 저는 소프트웨어 개발에서 10 년 동안 일합니다. 수십 개의 프로젝트 중에서 기술 때문에 변경 하기 로 결정한 것은 단 2 개 였습니다 . 더 정확하게는 지난 10 년 동안 PHP가 많이 발전했기 때문입니다. 고객의 결정조차 아니 었습니다. 그는 사이트가 PHP의 네임 스페이스 나 클로저를 사용하는지에 대해서는 신경 쓰지 않았습니다. 그러나 새로운 요구 사항 및 확장 성과 관련된 변경 사항은 많았습니다!

20 년을 지속 할 계획이 없습니다. 평범하고 단순합니다. 대신 목표를 구획화로 옮기십시오.

앱 데이터베이스가 독립적입니까? 지금 데이터베이스를 전환해야한다면 가능할 것입니다. 당신의 논리 언어는 불가지론 적입니까? 지금 완전히 새로운 언어로 앱을 다시 작성해야한다면? SRP 및 DRY와 같은 우수한 설계 지침을 따르고 있습니까?

저는 20 년 이상 프로젝트를 진행해 왔으며 상황이 바뀌 었다고 말할 수 있습니다. 팝업처럼. 20 년 전 팝업에 의존 할 수 있었지만 오늘은 할 수 없습니다. XSS는 20 년 전의 일이 아니 었습니다. 이제 CORS를 고려해야합니다.

따라서 여러분이하는 일은 논리가 잘 분리되어 있는지 확인하고 특정 공급 업체에 종속되는 모든 기술을 사용하지 않는 것입니다.

이것은 때때로 까다로울 수 있습니다. 예를 들어 .NET은 다른 어댑터에 해당되지 않는 MSSQL 데이터베이스 어댑터의 논리 및 방법을 공개하는 데 탁월합니다. MSSQL은 오늘날 좋은 계획처럼 보이지만 20 년 동안 계속 유지됩니까? 누가 알아. 이 문제를 해결하여 데이터 계층을 응용 프로그램의 다른 부분과 완전히 분리하는 방법의 예입니다. 최악의 경우 전체 데이터 계층 만 다시 작성하면 나머지 응용 프로그램은 영향을받지 않습니다.

다시 말해서 자동차처럼 생각합니다. 당신의 차는 20 년을 만들지 않을 것입니다. 그러나 새로운 타이어, 새로운 엔진, 새로운 변속기, 새로운 창문, 새로운 전자 제품 등으로 인해 같은 자동차가 오랫동안 도로에있을 수 있습니다.

@amon과 다른 사람들의 대답은 훌륭하지만 다른 관점에서 이것을 보도록 제안하고 싶습니다.

저는 20 년 넘게 사용되어 온 프로그램이나 코드 기반에 의존하는 대기업 및 정부 기관과 함께 일해 왔으며 모두 공통점이있었습니다. 회사는 하드웨어를 제어했습니다. 실행되는 것을 제어 할 때 20 년 이상 실행 가능하고 확장 가능한 것을 갖는 것은 어렵지 않습니다. 이 그룹의 직원은 배포 시스템보다 수백 배 빠른 최신 시스템에서 코드를 개발했지만 배포 시스템은 제 시간에 중단되었습니다.

웹 사이트는 서버와 브라우저의 두 가지 환경을 계획해야하므로 상황이 복잡합니다.

서버와 관련하여 두 가지 일반적인 선택이 있습니다.

• 훨씬 더 빠른 다양한 지원 기능에 대해서는 운영 체제에 의존하지만 OS가 "동결"되어야 할 수도 있습니다. 이 경우 서버에 대한 OS 설치 백업을 준비해야합니다. 10 년 안에 문제가 발생하면 누군가가 OS를 다시 설치하거나 다른 환경에서 작동하도록 코드를 다시 작성하는 것을 미치게 만들고 싶지 않습니다.

• 주어진 언어 / 프레임 워크 내에서 버전이 지정된 라이브러리를 사용하십시오. 속도는 느리지 만 가상 환경에서 패키지 될 수 있으며 다른 운영 체제 나 아키텍처에서 실행될 수 있습니다.

브라우저의 경우 서버에서 모든 것을 호스트해야합니다 (즉, 글로벌 CDN을 사용하여 파일을 호스팅 할 수 없음). 우리는 미래의 브라우저가 여전히 적어도 호환성을 위해 HTML과 Javascript를 실행한다고 가정 할 수 있지만 실제로는 추측 / 가정이며 제어 할 수는 없습니다.

대부분의 응용 프로그램의 핵심은 데이터입니다. 데이터는 영원합니다. 코드는 더 소비 가능 하고 변경 가능하며 가단성입니다. 그러나 데이터는 보존해야합니다. 따라서 매우 견고한 데이터 모델을 만드는 데 집중하십시오. 스키마와 데이터를 깨끗하게 유지하십시오. 새로운 응용 프로그램은 동일한 데이터베이스 위에 구축 될 수 있습니다.

무결성 제약 조건을 적용 할 수있는 데이터베이스를 선택하십시오. 시간이 지남에 따라 강제 구속 조건을 위반하는 경향이 있습니다. 아무도 통지하지 않습니다. 외래 키, 고유 제약 조건, 검사 제약 조건 및 유효성 검사 트리거와 같은 기능을 최대한 활용하십시오. 교차 테이블 고유성 제한 조건을 적용하기 위해 인덱싱 된 뷰를 남용하는 몇 가지 트릭이 있습니다.

따라서 응용 프로그램이 언젠가 다시 작성 될 것임을 수락해야 할 수도 있습니다. 데이터베이스가 깨끗하면 마이그레이션 작업이 거의 없습니다. 이주는 노동력과 결함의 측면에서 매우 비쌉니다.

기술적 인 관점에서 볼 때 대부분의 응용 프로그램을 클라이언트의 JavaScript 형식이 아닌 서버에 배치하는 것이 좋습니다. 가상화 덕분에 동일한 OS 인스턴스에서 동일한 애플리케이션을 매우 오랫동안 실행할 수있을 것입니다 . 그다지 좋지는 않지만 비싼 유지 보수 및 하드웨어 비용없이 20 년 후에 앱이 작동한다는 보장입니다. 이렇게하면 적어도 오래되고 작동하는 코드를 계속 실행하는 것이 안전하고 저렴하다는 단점이 있습니다.

또한 일부 기술 스택은 다른 기술 스택보다 안정적 입니다. 나는 .NET이 현재 최상의 호환성 호환성 이야기를 가지고 있다고 말하고 싶습니다. 마이크로 소프트는 그것에 대해 심각하게 죽었다. Java와 C / C ++도 정말 안정적입니다. 파이썬은 파이썬 3의 주요 변경 사항이 매우 불안정하다는 것을 증명했습니다. 웹을 깨는 것은 어떤 브라우저 벤더에게도 옵션이 아니기 때문에 JavaScript는 실제로 매우 안정적으로 보입니다. 그래도 실험적이거나 펑키 한 것에 의존해서는 안됩니다. ( "펑키"는 "보면 알 것"으로 정의 됨).

다른 대답은 의미가 있습니다. 그러나 클라이언트 기술에 대한 의견이 너무 복잡하다고 생각합니다. 저는 지난 16 년간 개발자로 일해 왔습니다. 내 경험상 클라이언트 코드를 직관적으로 유지하는 한 괜찮을 것입니다. 따라서 프레임 / iframe 등의 "해킹"이 없습니다. 브라우저에서 잘 정의 된 기능 만 사용하십시오.

브라우저에서 항상 호환성 모드를 사용하여 계속 작동 할 수 있습니다.

몇 달 전만해도 내 요점을 증명하기 위해 17 년 동안 웹 응용 프로그램을 실행 해 온 고객의 자바 스크립트 코드에서 밀레니엄 버그를 수정했습니다. 최근 컴퓨터, 최신 데이터베이스, 최신 운영 체제에서 여전히 작동합니다.

결론 : 간단하고 깨끗하게 유지하면 괜찮을 것입니다.

몇 가지 공리 :

• 진실은 살아남는다. 이와 관련하여 문제 공간의 "무엇"과 "어떻게"를 진실로 나타내는 알고리즘과 데이터 모델이 될 것입니다. 그러나 개선 및 개선의 가능성이나 문제 자체의 발전 가능성은 항상 있습니다.
• 언어가 진화합니다. 이것은 자연어와 마찬가지로 컴퓨터 언어에서도 마찬가지입니다.
• 모든 기술은 노후화에 취약합니다. 일부 기술은 다른 기술보다 시간이 오래 걸릴 수 있습니다

가장 안정된 기술 및 표준 (폐기에 가장 취약한 기술)은 비 독점적이며 가장 널리 채택 된 경향이 있습니다. 채택이 넓을수록 거의 모든 형태의 변화에 ​​대한 관성이 커집니다. 독점적 인 "표준"은 항상 소유자와 경쟁 세력의 재산과 변덕에 취약합니다.

20 년은 컴퓨터 산업에서 매우 오랜 시간입니다. 5 년이 더 현실적인 목표입니다. 5 년 안에 응용 프로그램에서 해결해야 할 모든 문제를 완전히 재정의 할 수 있습니다.

설명 할 몇 가지 예 :

C와 C ++은 오랫동안 사용되어 왔습니다. 그들은 거의 모든 플랫폼에서 구현됩니다. C ++는 계속 발전하고 있지만 "모든"플랫폼에서 사용할 수있는 "범용"기능은 더 이상 사용되지 않습니다.

플래시는 거의 보편적 인 표준이되었지만 독점적입니다. 널리 사용되는 모바일 플랫폼에서 지원하지 않기로 결정한 기업의 결정은 기본적으로 어디에서나 끝났습니다. 웹을 제작하는 경우 모든 플랫폼에서 컨텐츠를 사용할 수 있기를 원합니다. 당신은 모바일 시장이 된 주요 시장을 놓치고 싶지 않습니다.

WinTel (Windows / x86)은 Microsoft 및 Intel의 독점적 임에도 불구하고 최적화되지 않은 플랫폼 (16 비트 내부 / 8 비트 외부 8088 vs 동시 Apple Macintosh 32 비트 내부 / 16 비트 외부 68000)에서 시작했으며 침식 소비자 시장에서 애플은 여전히 ​​비즈니스 플랫폼을위한 실질적인 선택이다. 모든 시간 (25 년) 동안, 이전 버전과의 호환성에 대한 약속은 미래의 개발을 방해하고 이전 박스에서 작업 한 것이 여전히 새로운 박스에서 작동 할 것이라는 상당한 확신을 얻었습니다.

마지막 생각들

비즈니스 로직을 구현하기 위해 JavaScript가 최선의 선택이 아닐 수도 있습니다. 데이터 무결성과 보안의 이유로 서버에서 비즈니스 로직을 수행해야하므로 클라이언트 측 JavaScript는 UI 동작으로 제한되어야합니다. 서버에서도 JavaScript가 최선의 선택이 아닐 수 있습니다. 소규모 프로젝트의 경우 다른 스택 (Java 또는 C #)보다 작업하기가 쉽지만 작업이 복잡 할 때보다 체계적인 솔루션을 작성하는 데 도움이되는 형식이 없습니다.