A Microsoft fejlesztője felhívja a menedzsmentet a .Net Hot Reload probléma kezelése miatt

A nyílt forráskódú közösség tagjai nemrégiben dühösek voltak a Microsoftra, amiért nyilvánvalóan szándékosan eltávolítottak egy funkciót a nyílt forráskódú .Net 6 szoftverfejlesztői platformról (amelyet a Microsoft kezel), így a professzionális fejlesztők helyette a Visual Studio 2022-t használnák, a Microsoft meglehetősen drága, de nagyon költséges verzióját. erős IDE.

Kiderült, hogy a Microsofton belüli fejlesztők ugyanolyan dühösek voltak, és A Microsoft visszavonta döntését nem nyugtatta meg őket, sokan tartanak attól, hogy a Microsoft a következő alkalomtól rövid távú pénzügyi érdekeit helyezi a nyílt forráskódú közösséggel való kapcsolatuk elé.

Ez a kiadást eredményezte névtelen levél a Microsoft vezetőségének amelyben a szerző közvetlenül azzal vádolja a céget, hogy hazudott a menedzsment védelmében.

Megjegyzik, hogy a Microsoft szándékosan próbálta elrejteni a Hot Reload eltávolítását azáltal, hogy elsiette a PR-t, mielőtt a .Net 6 fejlesztői megjegyzéseket fűzhetnének, és hogy a Microsoft mentsége, hogy nem tudtak a .Net 6 és VS 2022 Hot Reload-jára összpontosítani, üresen csengett, amikor nem volt ilyen azt jelzi, hogy a munkát nem lehetett mindkét esetben kielégítően befejezni.

Aggodalmukat fejezték ki amiatt, hogy a Microsoft további erőfeszítéseket tesz a .Net 6 megbénítására a VS 2022 előmozdítása érdekében, annak ellenére, hogy a nyílt forráskódú eszközök meglehetősen népszerűek magán a Microsofton belül.

A szerző átlátható vizsgálatot kért a Hot Reload lehúzásának módjáról és a Microsoft menedzsmentjének megváltoztatásáról, hogy ilyen elgondolkodtató döntéseket ne lehessen hozni.

A kissé rideg hangnem ellenére, amely miatt sokan azt hitték, hogy a feljegyzés nem valódi, számos Microsoft MVP jelentkezett, és megerősítette, hogy a levelet valóban a Microsoft DivDev részlegének egyik alkalmazottja írta.

Olvassa el az alábbi levelet teljes egészében:

A Microsoft fejlesztői részlegének vezetőségéhez

Mi, akik a Microsoft Developer Division (DevDiv) részlegében dolgozunk, szeretnénk reagálni a közelmúltban kibontakozó vitákra a dotnet 6 „dotnet watch” funkciójának visszavonása és visszaállítása körül. Miközben hálásak vagyunk, hogy a hidegebb fejek győztek és a „dotnet watch” megőrizték, nem bízunk benne, hogy ez nem fog megismétlődni? éppen ellenkezőleg.

Ennek bemutatására nézzük meg Scott Hunter legutóbbi blogbejegyzését (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Mindazok alapján, amelyeket tudunk a helyzetről és a fejlesztői részleg működéséről, a Scott által írt dolgokból kevés tűnik igaznak, és ellentmond a történteknek. Hogy világos legyen, ez nem Scott Hunter elleni támadás; és ehelyett azt mutatja meg, hogy mások meddig hajlandók elmenni a menedzsment védelme érdekében.

„Csapatként elköteleztük magunkat amellett, hogy a .NET nyílt platform legyen, és a fejlesztésünket a nyílt környezetben végezzük. Maga a tény, hogy a Hot Reload funkció fejlesztésekor kezdettől fogva a nyitott testtartás mellett döntöttünk, ezt bizonyítja.”

A lehívási kérelemmel kapcsolatban semmi sem volt nyitva. Említettük ezt egy blogbejegyzésben (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/), és átláthatatlanul siettük a PR-t, hogy elkerülje. Hozzászólások. Hogyan mondhatjuk, hogy átláthatóak vagyunk, amikor ennek egyértelműen az ellenkezője? Mintha mindannyian közösen tudnánk, hogy ez helytelen, de mindenesetre együtt kell járnunk vele.

"A .NET-fejlesztők túlnyomó többsége a Visual Studio-t használja, és szeretnénk megbizonyosodni arról, hogy a VS a legjobb élményt nyújtja a .NET 6-hoz."

Még ha ez igaz is, ez azt jelenti, hogy nem törődünk a nem Visual Studio felhasználókkal? Hogyan tehetné ezt a funkciót a fejlesztés olyan késői szakaszában, hogy a Visual Studio a legjobb élményt nyújthassa a Hot Reload számára? Sértő azok számára, akik nem mindig a Visual Studiót használják dotnet-fejlesztéseikhez, és azt mondja, nem értjük ügyfeleinket, sőt alkalmazottainkat sem, akik az általunk építettet használják.

CLI-t használunk, és VS kódot használunk. Hagyd abba az ellenkezőjét.

„Hibát követtünk el, amikor végrehajtottuk ezt a tervet, ahogyan azt végrehajtottuk. A hatókörre tett erőfeszítéseink során akaratlanul is töröltük a forráskódot, ahelyett, hogy egyszerűen nem hívtuk volna meg azt a kódútvonalat.”

Hogy világos legyen, a mérnököt hibáztatni ezért a „hibáért” gyávaság. A probléma a funkció eltávolítása volt, nem pedig az, hogy hogyan hajtották végre. Azt mondjuk, ha csak „kikapcsoljuk” ahelyett, hogy eltávolítanánk, akkor nem állítottuk volna vissza a változtatást? Aktívan dolgoztak volna ezen a kódon, vagy hagyták volna elrohadni?

„Mivel a .NET 6-os kiadás és a Visual Studio 2022 kifutópályája egyre szűkösebb, úgy döntöttünk, hogy először a Hot Reload VS2022-re való bevezetésére összpontosítunk.”

Annak bizonyítására, hogy a „minőség-ellenőrzés” nem volt így a „dotnet watch” esetében, összehasonlítjuk egy másik termékkel, amelyet késleltetettünk: a MAUI-val.

A MAUI durva állapotban van. Az RC1 egyértelművé tette, hogy a minőség nem lesz elég magas a dotnet 6 kiszállítására; túl sok volt a javítanivaló, és nem volt elég idő rá. A MAUI csapata és partnerei ezeket a problémákat vezették be, ami a terméket a jövő év elejére tolta vissza.

Nem volt és továbbra sem utal arra, hogy a „dotnet óra” ugyanott lenne. A GitHub-problémák és a dotnet csapat lemaradása nem mutat aggályokat a minőség hiányával kapcsolatban. Éppen ellenkezőleg, jól ment. Ezek sokkal hamarabb felmerültek volna a kiadási ciklusunkban, ha valódi minőségi aggályok merültek volna fel, nem három héttel a szállítás előtt.

„Mint sok vállalatra igaz, megtanuljuk egyensúlyba hozni az OSS közösség igényeit, és a .NET vállalati szponzorai lenni.”

Ha a sorok között olvasunk, ez az állítás igaz. Összeütközésbe kerülünk azzal, amit a dotnetbe, a Visual Studio-ba és a Visual Studio Code-ba helyeztünk. A Hot Reload megtartása a Visual Studio „érték-hozzáadásaként” megőrzi azokat a fizetős termékhez, és kevesebb okot okoz a VS Code használatára. Hideg és kiszámított módon ennek teljesen értelme van, és egyben abszolút nonszensz is.

Mi lenne, ha a Hot Reload for Visual Studio-on dolgozó csapatok „dotnet órát” integrálnának termékeikbe? Mi lenne, ha a vezetés hetekkel az általános kiadás előtt meghúzná ezeket a funkciókat? Hogyan javítaná ez a Visual Studiót? Folyamatosan távolítunk el alkatrészeket a CLI-ből, mert attól tartunk, hogy bevételt veszítünk a Visual Studio-ból?

A legjobb Visual Studiót úgy építjük fel, hogy a bolygó legjobb futási idejét biztosítjuk. Amikor a Visual Studio csapata funkciókkal egészíti ki a dotnet alapjait, következetes alapot biztosítunk, amelyen mindenki dolgozhat és hozzájárulhat. A legjobb IDE-t úgy építhetjük fel, ha a futásidőben együttműködünk, és nem rontjuk tetszőlegesen nyílt forráskódú termékeinket.

Mi a következő lépés? Zárt forráskódú termékké tesszük az Omnisharpot? Hogy megbizonyosodjunk arról, hogy nem kaphat olyan új funkciókat, amelyek elveszik a Visual Studio „értékét”? Hogy ne adjunk funkciókat a Ridernek? Egyáltalán hogyan segít ez nekünk? A vezetés ezen döntései biztosítják, hogy a Visual Studio mindig másodosztályú legyen a piacon található összes többihez képest. Az ilyen lépések nem csak az ügyfelekkel ártanak nekünk, hanem az is, ahogyan belső termékeket építünk. Nem csak minket bántanak az „OSS közösséggel”, hanem mindenkit a fejlesztői részlegen és a Microsofton.

Ha valóban átláthatóak akarunk lenni ezzel kapcsolatban, akkor a következő változtatásokat kell végrehajtanunk, hogy ez helyes legyen:

Teljes idővonalra van szükségünk, nyilvánosan közzétéve, hogy ez hogyan történt, és akik közvetlenül felelősek azért, hogy miként vezetett ehhez.
Soha többé nem szabad elsietni egy PR-t. Kezdettől fogva egyértelmű volt, hogy a kód eltávolítása rossz lépés volt, és ha valóban visszajelzést akarunk a közösségtől, akkor nem utána, hanem előtte hajlandónak kell lennünk meghallgatni.
Ha ezeket a döntéseket a vezetők egyoldalúan hozták meg, meg kell akadályoznunk, hogy ez soha többé ne fordulhasson elő. Látható összeférhetetlenség volt a VS és a dotnet „szükségletei” között. Fékekre és ellensúlyokra van szükség annak megakadályozására, hogy bárki, bármilyen magasan is álljon, ne hozzon ilyen döntéseket anélkül, hogy valódi visszajelzést kapna a részlegen belülről és kívülről.

Itt nem az a célunk, hogy megsértsünk egyetlen olyan személyt sem a vezetésben, aki esetleg meghozta ezt a döntést. Ehelyett az alapvető probléma megoldása: senkinek sem kellene annyi ereje, hogy olyan közel befolyásoljon egy terméket, mint például a dotnet, hogy közvetlenül megjelenjen. Bárki, aki a Fejlesztői részleget vezeti, megteheti ugyanezt, amit meg kell akadályoznunk. Ha világos irányelvekkel kell megvédeni ezeket a termékeket, amelyek mindennek a Visual Studio alapját képezik, akkor nemcsak a legjobbakká válhatunk a nyílt forráskódú szoftverek irányítóiként, hanem a lehető legjobb IDE felépítésében is.

Köszönöm Graeme a tippet.