Microsoft 개발자는 .Net Hot Reload 문제 처리에 대해 관리를 호출합니다.

오픈 소스 커뮤니티의 구성원은 최근 Microsoft가 관리하는 오픈 소스 .Net 6 소프트웨어 개발 플랫폼에서 기능을 의도적으로 제거하여 전문 개발자가 Microsoft의 상당히 비싸지만 매우 높은 Visual Studio 2022를 대신 사용하게 된 것에 대해 Microsoft에 분노했습니다. 강력한 IDE.

Microsoft 내부의 개발자들도 똑같이 화를 냈고 마이크로소프트의 결정 번복 많은 사람들이 Microsoft가 오픈 소스 커뮤니티에 대한 참여보다 단기적인 재정적 이익을 두는 다음 기회를 두려워하면서 그들을 달래지 못했습니다.

이로 인해 Microsoft 경영진에게 보내는 익명의 편지 저자는 경영진을 보호하기 위해 거짓말을 한 회사를 직접 비난합니다.

그들은 .Net 6 개발자가 언급하기 전에 Microsoft가 의도적으로 PR을 서두르면서 Hot Reload 제거를 숨기려고 했으며 .Net 6 및 VS 2022 모두에 대해 Hot Reload에 집중할 수 없다는 Microsoft의 변명은 아무 것도 없었을 때 공허하게 울렸다고 말합니다. 둘 다 만족스럽게 작업을 완료할 수 없다는 표시입니다.

그들은 오픈 소스 도구가 마이크로소프트 내부에서 꽤 인기가 있음에도 불구하고 VS 6를 추진하기 위해 마이크로소프트가 .Net 2022을 무력화시키기 위해 더 많은 노력을 기울일 것이라는 우려를 표명했습니다.

저자는 Hot Reload가 어떻게 풀렸는지에 대한 투명한 조사와 그러한 성급한 결정을 다시 내릴 수 없도록 Microsoft의 관리를 변경해 줄 것을 요청했습니다.

많은 사람들이 메모가 진짜가 아니라고 믿게 만든 다소 거친 어조에도 불구하고 많은 Microsoft MVP가 앞으로 나와 이 편지가 실제로 DivDev 부서의 Microsoft 직원이 작성한 것임을 확인했습니다.

아래의 편지 전체를 읽으십시오.

Microsoft 개발자 사업부 리더십에게,

Microsoft Developer Division(DevDiv)에서 근무하는 분들은 최근 dotnet 6의 "dotnet watch" 기능의 철회 및 복원을 둘러싸고 있는 논란에 대해 답변을 드리고자 합니다. 우리는 더 차가운 사람들이 우세한 "dotnet watch"에 감사하면서 우리는 이런 일이 다시는 일어나지 않을 것이라고 확신하지 못합니다. 그 반대입니다.

이 점을 보여주기 위해 Scott Hunter의 최근 블로그 게시물(https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/)을 살펴보겠습니다. 상황과 개발자 부서의 운영 방식에 대해 우리가 알고 있는 모든 것을 기반으로 볼 때 Scott이 쓴 내용은 거의 사실로 보이지 않고 일어난 일과 모순됩니다. 분명히 하자면 이것은 Scott Hunter에 대한 공격이 아닙니다. 대신, 다른 사람들이 경영진을 보호하기 위해 얼마나 멀리 갈 의향이 있는지 보여줍니다.

“팀으로서 우리는 .NET이 개방형 플랫폼이 되고 개방형 개발을 수행하는 데 전념하고 있습니다. Hot Reload 기능을 개발할 때부터 기본적으로 열린 자세를 채택하기로 결정했다는 사실이 이를 증명합니다.”

풀 리퀘스트에 대한 정보가 없습니다. 우리는 블로그 게시물(https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/)에서 이를 언급했으며, 이를 피하기 위해 불투명하게 PR을 서두르고 있습니다. 코멘트. 이것이 그 반대인 것이 분명할 때 어떻게 우리가 투명하다고 말할 수 있습니까? 마치 우리 모두가 이것이 잘못되었다는 것을 집단적으로 알고 있었지만 어쨌든 따라야 했던 것과 같습니다.

"대다수의 .NET 개발자는 Visual Studio를 사용하고 있으며 VS가 .NET 6에 대해 최상의 경험을 제공하도록 하고 싶습니다."

이것이 사실일지라도 이것이 우리가 Visual Studio가 아닌 사용자에 대해 신경 쓰지 않는다는 것을 의미합니까? 이 기능을 개발이 너무 늦게 구현하면 어떻게 Visual Studio가 Hot Reload에 대해 최상의 경험을 할 수 있게 될까요? 닷넷 개발을 위해 항상 Visual Studio를 사용하지 않는 사람들을 모욕하는 일이며 우리가 구축한 것을 사용하는 고객이나 직원을 이해하지 못한다고 말합니다.

우리는 CLI를 사용하고 VS Code를 사용합니다. 다른 척 그만해.

“우리는 이 계획을 실행하는 방식에서 실수를 저질렀습니다. 범위를 지정하는 과정에서 코드 경로를 호출하지 않고 실수로 소스 코드를 삭제하게 되었습니다.”

분명히 말해서, 이 "실수"에 대해 엔지니어를 비난하는 것은 비겁한 일입니다. 문제는 기능을 제거하는 것이지 어떻게 수행했는지가 아닙니다. 제거하는 대신 "끄기"만 했다면 변경 사항을 되돌리지 않았을 것입니까? 이 코드가 적극적으로 작업되었습니까? 아니면 썩어버렸습니까?

".NET 6 릴리스 및 Visual Studio 2022에 대한 활주로가 짧아짐에 따라 우리는 먼저 VS2022에 Hot Reload를 가져오는 데 집중하기로 결정했습니다."

"품질 관리"가 "dotnet watch"의 경우가 아님을 보여주기 위해 지연된 다른 제품인 MAUI와 비교합니다.

MAUI는 거친 모양입니다. RC1은 dotnet 6이 출시될 때까지 품질이 충분히 높지 않을 것이라는 점을 분명히 했습니다. 고칠 것은 너무 많았고 그것을 할 시간은 충분하지 않았습니다. MAUI 팀과 그 파트너는 이러한 문제를 리더십에 전달하여 제품을 내년 초로 미뤘습니다.

"dotnet watch"가 같은 위치에 있었다는 표시는 없었고 지금도 없습니다. GitHub 문제나 dotnet 팀의 백로그를 살펴보면 품질이 거기에 없다는 우려를 보여줍니다. 오히려 잘하고 있었다. 실제 품질 문제가 있었다면 출시 XNUMX주가 아니라 출시 주기에서 훨씬 더 빨리 언급되었을 것입니다.

"많은 회사가 그렇듯이 우리는 OSS 커뮤니티의 요구 사항을 균형 있게 조정하고 .NET의 기업 후원자가 되는 방법을 배우고 있습니다."

행 사이를 읽으면 이 진술은 사실입니다. 우리는 우리가 dotnet, Visual Studio 및 Visual Studio Code에 넣은 것과 충돌합니다. Hot Reload를 Visual Studio의 "부가 가치"로 유지하면 유료 제품에 고정되어 VS Code로 이동할 이유가 줄어듭니다. 냉정하고 계산된 방식으로 그것은 완전히 말이 되며 또한 절대 말도 안되는 소리입니다.

Visual Studio용 Hot Reload 작업을 하는 팀이 제품에 "dotnet watch"를 통합하면 어떻게 될까요? 경영진이 일반 릴리스 몇 주 전에 이러한 기능을 제거했다면 어떻게 될까요? 어떤 식으로든 Visual Studio를 개선할 수 있습니까? Visual Studio에서 수익을 잃을까봐 CLI에서 계속해서 일부를 제거하시겠습니까?

최고의 Visual Studio를 구축하는 방법은 지구상에서 최고의 런타임을 확보하는 것입니다. Visual Studio 팀이 dotnet 기반에 기능을 추가하면 모든 사람이 작업하고 기여할 수 있는 일관된 기반이 생깁니다. 임의로 오픈 소스 제품을 악화시키지 않고 런타임에 협력하여 최고의 IDE를 구축할 수 있습니다.

무엇 향후 계획? Omnisharp를 클로즈드 소스 제품으로 만들 것인가? Visual Studio의 "가치"를 빼앗는 새로운 기능을 얻을 수 없도록 하시겠습니까? Rider에게 기능을 제공하지 않으려면? 그것이 우리에게 어떤 도움이 됩니까? 경영진에 의한 이러한 결정은 Visual Studio가 항상 시장의 다른 모든 제품에 비해 XNUMX급이 되도록 합니다. 이러한 움직임은 고객뿐 아니라 내부적으로 제품을 구축하는 방식에도 피해를 줍니다. 그들은 "OSS 커뮤니티"뿐만 아니라 개발자 부서와 Microsoft의 모든 사람들에게 피해를 줍니다.

이에 대해 진정으로 투명하게 하려면 다음과 같이 변경하여 올바르게 수정해야 합니다.

우리는 이 일이 어떻게 일어났는지, 어떻게 이 일이 발생했는지에 대한 직접적인 책임이 있는 사람들에 대해 공개적으로 게시된 완전한 타임라인이 필요합니다.
우리는 다시는 홍보를 서두르지 말아야 합니다. 코드를 제거하는 것이 잘못된 행동이라는 것은 처음부터 분명했으며, 커뮤니티의 피드백을 진정으로 원한다면 사후가 아니라 사전에 기꺼이 경청해야 합니다.
이러한 결정이 지도부의 일방적인 결정이라면 다시는 그런 일이 일어나지 않도록 해야 합니다. VS의 "필요"와 dotnet의 "필요" 사이에는 명백한 이해 충돌이 있었습니다. 아무리 높은 사람이더라도 부서 안팎의 진정한 피드백 없이 이와 같은 결정을 내리지 않도록 견제와 균형이 필요합니다.

여기에서 우리의 목표는 이러한 결정을 내릴 수 있는 지도력의 특정 사람을 모욕하지 않는 것입니다. 대신, 핵심 문제를 해결하는 것입니다. dotnet과 같은 제품에 직접 출시가 임박한 제품에 영향을 미칠 수 있는 권한을 가진 사람은 아무도 없습니다. 개발자 사업부를 이끄는 사람이라면 누구나 같은 행동을 할 수 있으므로 방지해야 합니다. Visual Studio의 모든 것의 기초를 형성하는 이러한 제품을 보호하기 위한 명확한 지침을 갖는다면 우리는 오픈 소스 소프트웨어의 청지기로서 동급 최고가 될 뿐만 아니라 우리가 할 수 있는 최고의 IDE를 구축하는 데 도움이 될 것입니다.

팁을 주신 Graeme님, 감사합니다.