Visual Basic은 새로운 .NET에서 이상한 사람입니다.

지난주 일련의 블로그 게시물에서 Microsoft는 .NET 언어를 개발하는 방법에 대한 근본적인 변경 사항을 자세히 설명했습니다. C # 및 F # 개발자에게는 희소식 이었지만 Microsoft는 Visual Basic의 변경 사항에 대해 긍정적 인 의견을 제시했지만 오래된 언어의 장기적인 미래는 불확실 해 보입니다.

마이크로 소프트의 비쥬얼 베이직은 오랫동안 세계에서 가장 좋아하는 언어 중 하나 였지만 확실히 가장 널리 사용되는 언어 중 하나였으며 실제로 Microsoft를 엔터프라이즈 단계의 중심에 두었습니다. 클라이언트-서버 응용 프로그램 개발을위한 언어로서의 처음 6 번의 반복부터 .NET 플랫폼의 일부로 다시 태어나 기까지 Visual Basic은 엔터프라이즈 응용 프로그램의 빠른 개발을위한 도구였습니다. 이는 부분적으로 사용자 인터페이스 구성 요소의 방대한 라이브러리와 공통 데이터베이스에 대한 커넥터 및 타사가 추가 기능을 제공하여 비즈니스를 구축 할 수있는 구성 요소 모델 때문입니다.

Microsoft 개발 전략의 기반으로 .NET으로의 전환은 C #과 같은 새로운 언어에 적합했지만 이전 Visual Basic에서 새로운 VB.NET으로 코드를 쉽게 마이그레이션 할 수없는 Visual Basic으로의 변경을 의미했습니다.

개발자에게는 어려운 전환이었으며 Visual Basic은 엔터프라이즈 개발 및 Microsoft 내부에서 마음을 잃기 시작했습니다. 그럼에도 불구하고 Microsoft는 C #과 VB.NET을 동기화 상태로 유지하겠다고 약속했습니다. C # 용으로 만들어진 기능은 두 언어가 함께 개발되는 Visual Basic의 일부가됩니다. 그 이유는 동일한 작업에 자주 사용되었고 동일한 기본 특성을 가지고 있었기 때문입니다. 둘 다 동일한 도구를 사용하는 강력한 형식의 객체 지향 언어입니다.

Visual Basic 및 C # : 새로운 분기가 다가오고 있습니다.

지난주 발표와 함께 그 공동 진화는 사라졌습니다. 마이크로 소프트는 곧 출시 될 Visual Basic 15부터 시작하여 두 언어가 다른 방식으로 사용되도록 할 것입니다.

놀라운 이혼이 아닙니다. C #의 인기는 비약적으로 성장한 반면 Visual Basic은 천천히 차트에서 미끄러 져 Stack Overflow와 같은 인기 프로그래밍 쿼리 사이트의 레이더에서 거의 사라졌습니다. 사용 사례도 변화하고 있습니다. Visual Basic은 여전히 ​​원래의 클라이언트-서버 패러다임에 초점을 맞추고있는 반면 C #은 클라우드 및 온 프레미스에서 작동하는 n 계층 웹 기반 애플리케이션을 위한 도구가되었습니다 . 웹 및 클라우드에서 작동하도록 구축 된 앱이 점점 더 많아지면서 C #이 많은 프로젝트에서 첫 번째 선택이 된 것은 놀라운 일이 아닙니다.

언어 개발 방법에도 변화가 있습니다. C #은 개방형 디자인 모델로 전환되었습니다. 즉, 활성 메일 링리스트와 공개 GitHub 저장소 덕분에 사용자가 새로운 기능의 우선 순위를 정할 수 있습니다. Microsoft는 이미 회사 외부에서 새로운 기능을 가져 왔습니다. 이는 연구 그룹과 내부 제품 관리 팀에 초점을 맞춘 기존 언어 엔지니어링 프로세스에서 큰 변화입니다.

Visual Basic에는 개방형 디자인 모델도 있지만 C #과는 우선 순위가 다릅니다. 이미 Visual Studio 2017 릴리스 후보의 일부로 현재 빌드에서 C # 기능의 하위 집합을 지원합니다.

C #이 Visual Basic에서 계속 갈라짐에 따라 두 언어가 함께 작동 할 수 있어야하지만 별도로 개발되는 것을 보게 될 것입니다. 둘 다 동일한 .NET API를 처리해야하며 둘 다 Visual Studio 도구의 일부입니다.

이러한 변화가 엔터프라이즈 개발자에게 의미하는 바

현재로서는 기업이 이러한 차이에 대해 할 일이 거의 없습니다.

그러나 앞으로는 친숙한 .NET Framework와 함께 .NET Standard 기본 클래스 라이브러리 집합을 지원하는 것으로 이동함에 따라 Visual Basic에서 플랫폼 간 작업에 대한 범위가 확실히 있습니다. 일부 코드는 이식 가능하지만 모든 Visual Basic 코드가 한 라이브러리 집합에서 다른 더 작은 집합으로 이동할 수있는 것은 아닙니다. 기존 코드는 순전히 Windows 및 순전히 온-프레미스 애플리케이션에 남아있을 가능성이 높습니다.

개발자는 .NET Standard를 통해 Visual Basic 코드를 최신 플랫폼으로 가져 오거나 더 넓은 범위의 대상 프레임 워크 및 장치를 제공하는 C #과 같은 언어로 이동하는 것 중에서 선택해야합니다.

.NET Standard는 모든 .NET 플랫폼을 대상으로하기 때문에 중요한 이퀄라이저입니다. 그러나 모든 .NET 언어에 필요한 것은 아닙니다. Visual Basic은 완전한 .NET Framework가없는 시스템에서 필요하지만 C #은 .NET Core와 같은 플랫폼을 직접 처리하여 API에 액세스 할 수 있습니다. 또한 Unity와 같은 C # 파생 제품이 고유 한 특수 API를 지원하기가 더 쉽습니다.

Windows의 .NET Framework 및 오픈 소스 .NET Core (Nano Server 및 컨테이너에서 실행)를 지원하는 C #은 클라우드 및 모바일 애플리케이션을위한 첫 번째 선택이 될 것이며 F # 함수형 프로그래밍 모델은 금융 서비스에 이상적입니다. 기계 학습에 의존하는 애플리케이션.

이러한 변화에 대한 분명한 동인 중 하나는 Microsoft의 Xamarin 인수입니다. 마이크로 소프트는 더 넓은 범위의 모바일 장치를 지원하기위한 크로스 플랫폼 도구 세트가 필요합니다. 윈도우 모바일은 기대했던대로 기업 시장 점유율을 얻지 못하고 있습니다. 영국과 같은 Windows Mobile 친화적 인 지역에서도 iOS와 Android는 시장의 80 % 이상을 차지합니다. 애플리케이션을위한 모바일 프런트 엔드를 구축하려는 Microsoft 개발자는 Xamarin과 같은 도구를 사용하여 지배적 인 모바일 플랫폼을 대상으로해야합니다.

Xamarin이 C #에 초점을 맞추면서 Microsoft는 C #이 앞으로의 일류 .NET 언어임을 분명히해야합니다. 마이크로 소프트가 최근 발표 한 언어 발표에는 명시되어 있지 않지만 강력하게 암시됩니다.

엔터프라이즈 언어 전략을 관리하는 방법

이것은 Visual Basic에 작별 인사는 아니지만 현재 위치와 원하는 위치를 파악해야 할 때입니다. 기존 Visual Basic 응용 프로그램은 계속 개발할 수 있지만 기본 .NET 플랫폼이 발전함에 따라 Visual Basic 개발자는 .NET API의 하위 집합 만 사용할 수 있습니다. 단기적으로는 문제가되지 않지만 특히 애플리케이션에 대한 모바일 또는 크로스 플랫폼 사용자 환경을 계획중인 경우 C # 또는 F #으로의 장기 마이그레이션을 준비해야합니다.

기술 부채의 과잉을 피하는 가장 좋은 방법은 C #을 새로운 개발의 우선 순위로 만드는 것임이 분명해 보입니다. C #은 최고 수준의 지원과 사용자 중심 디자인 모델을 제공합니다. 또한 Microsoft의 크로스 플랫폼 개발과 유니버설 Windows 플랫폼의 핵심이기도합니다. 즉, 비즈니스 로직을 한 번 작성한 다음 웹, Windows 10, iOS, Android 및 MacOS에 대한 사용자 지정 사용자 경험을 제공 할 수 있습니다. 또한 개발자가 초기 교육 후 새로운 기능을 선택하여 상대적으로 쉽게 전환 할 수 있어야하는 충분한 언어 공통성이 있습니다.