นักพัฒนาของ Microsoft เรียกการจัดการเกี่ยวกับการจัดการปัญหา .Net Hot Reload

สมาชิกของชุมชนโอเพ่นซอร์สไม่พอใจ Microsoft ที่เห็นได้ชัดว่าจงใจลบคุณลักษณะออกจากแพลตฟอร์มการพัฒนาซอฟต์แวร์โอเพ่นซอร์ส .Net 6 (ซึ่ง Microsoft จัดการ) เพื่อให้นักพัฒนามืออาชีพใช้ Visual Studio 2022 แทน Microsoft ค่อนข้างแพง แต่มาก IDE ที่ทรงพลัง

ปรากฎว่านักพัฒนาใน Microsoft โกรธพอๆ กัน และ การกลับรายการของ Microsoft ต่อการตัดสินใจของพวกเขา ไม่ได้ทำให้พวกเขาพอใจ หลายคนกลัวว่าโอกาสถัดไปที่ Microsoft จะให้ความสำคัญกับผลประโยชน์ทางการเงินในระยะสั้นมากกว่าการมีส่วนร่วมกับชุมชนโอเพ่นซอร์ส

ส่งผลให้มีการปล่อย จดหมายนิรนามถึงฝ่ายบริหารของ Microsoft ซึ่งผู้เขียนกล่าวหาโดยตรงว่าบริษัทโกหกเพื่อปกป้องผู้บริหาร

พวกเขาทราบว่า Microsoft พยายามซ่อนการลบ Hot Reload โดยเจตนาโดยเร่ง PR ก่อนที่นักพัฒนา .Net 6 จะแสดงความคิดเห็นได้ และข้อแก้ตัวของ Microsoft ที่พวกเขาไม่สามารถมุ่งเน้นไปที่ Hot Reload สำหรับทั้ง .Net 6 และ VS 2022 นั้นดูไร้สาระเมื่อไม่มี บ่งชี้ว่างานไม่สามารถเสร็จสิ้นได้อย่างน่าพอใจสำหรับทั้งคู่

พวกเขาแสดงความกังวลว่า Microsoft จะพยายามเพิ่มเติมเพื่อทำลาย .Net 6 ด้วยความพยายามที่จะผลักดัน VS 2022 แม้ว่าเครื่องมือโอเพ่นซอร์สจะค่อนข้างเป็นที่นิยมใน Microsoft เองก็ตาม

ผู้เขียนขอให้มีการสอบสวนอย่างโปร่งใสว่า Hot Reload ถูกดึงออกมาอย่างไรและเปลี่ยนแปลงฝ่ายบริหารของ Microsoft เพื่อไม่ให้เกิดการตัดสินใจที่ฉับไวเช่นนี้อีก

แม้จะมีน้ำเสียงที่ค่อนข้างเคร่งขรึมซึ่งทำให้หลายคนเชื่อว่าโน้ตนั้นไม่ใช่ของจริง Microsoft MVP จำนวนหนึ่งออกมาและยืนยันว่าจดหมายดังกล่าวเขียนขึ้นโดยพนักงานของ Microsoft ในแผนก DivDev

อ่านจดหมายฉบับเต็มด้านล่าง:

ถึงความเป็นผู้นำของ Microsoft Developer Division

พวกเราที่ทำงานใน Microsoft Developer Division (DevDiv) ต้องการตอบสนองต่อข้อโต้แย้งล่าสุดเกี่ยวกับการดึงและคืนสถานะคุณสมบัติ "dotnet watch" ของ dotnet 6 ในขณะที่เรารู้สึกขอบคุณที่หัวเย็นได้รับชัยชนะและ "dotnet watch" ถูกรักษาไว้เราไม่รู้สึกมั่นใจว่าสิ่งนี้จะไม่เกิดขึ้นอีกหรือไม่ค่อนข้างตรงกันข้าม

เพื่อแสดงประเด็นนี้ เราจะดูบล็อกโพสต์ล่าสุดโดย Scott Hunter (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/) จากทุกสิ่งที่เรารู้เกี่ยวกับสถานการณ์และวิธีที่ Developer Division ดำเนินการ สิ่งที่ Scott เขียนดูเหมือนจะเป็นความจริงเพียงเล็กน้อยและขัดแย้งกับสิ่งที่เกิดขึ้น เพื่อความชัดเจน นี่ไม่ใช่การโจมตีสก็อตต์ ฮันเตอร์; และเป็นการแสดงให้เห็นว่าคนอื่นๆ เต็มใจที่จะปกป้องการจัดการไปไกลแค่ไหน

“ในฐานะทีม เรามุ่งมั่นที่จะให้ .NET เป็นแพลตฟอร์มเปิดและดำเนินการพัฒนาในที่เปิดเผย ความจริงที่ว่าเราตัดสินใจที่จะใช้ท่าทางเปิดโดยค่าเริ่มต้นตั้งแต่เริ่มต้นสำหรับการพัฒนาคุณสมบัติ Hot Reload นั้นเป็นข้อพิสูจน์ถึงสิ่งนั้น”

ไม่มีอะไรเกี่ยวกับคำขอดึงที่เปิดอยู่ เราพูดถึงมันในบล็อกโพสต์ ( https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/ ) และรีบประชาสัมพันธ์เพื่อหลีกเลี่ยง ความคิดเห็น เราจะพูดได้อย่างไรว่าเราโปร่งใสในเมื่อสิ่งนี้ตรงกันข้ามอย่างชัดเจน ราวกับว่าเราทุกคนรู้ว่าสิ่งนี้ผิด แต่ก็ต้องไปด้วยกันอยู่ดี

“นักพัฒนา .NET ส่วนใหญ่ใช้ Visual Studio และเราต้องการให้แน่ใจว่า VS มอบประสบการณ์ที่ดีที่สุดสำหรับ .NET 6”

แม้ว่าจะเป็นความจริง แต่นี่หมายความว่าเราไม่สนใจผู้ใช้ที่ไม่ใช่ Visual Studio หรือไม่ การดึงคุณสมบัตินี้ในการพัฒนาช้าจะทำให้ Visual Studio มีประสบการณ์ที่ดีที่สุดสำหรับ Hot Reload ได้อย่างไร เป็นการดูถูกผู้ที่ไม่ได้ใช้ Visual Studio สำหรับการพัฒนา dotnet เสมอ และบอกว่าเราไม่เข้าใจลูกค้าหรือแม้แต่พนักงานที่ใช้สิ่งที่เราสร้าง

เราใช้ CLI และเราใช้ VS Code หยุดแสร้งทำเป็นอย่างอื่น

“เราทำผิดพลาดในการดำเนินการตามแผนนี้ในลักษณะที่ดำเนินการ ในความพยายามของเราที่จะกำหนดขอบเขต เราลงเอยด้วยการลบซอร์สโค้ดโดยไม่ได้ตั้งใจ แทนที่จะแค่ไม่เรียกใช้เส้นทางโค้ดนั้น”

เพื่อความชัดเจน การตำหนิวิศวกรสำหรับ "ความผิดพลาด" นี้เป็นเรื่องขี้ขลาด ปัญหาอยู่ที่การนำคุณลักษณะนี้ออก ไม่ใช่วิธีการดำเนินการ เรากำลังจะบอกว่าถ้าเพียง "ปิด" แทนที่จะลบออก เราจะไม่เปลี่ยนกลับการเปลี่ยนแปลงใช่หรือไม่ รหัสนี้จะใช้งานได้จริงหรือปล่อยให้เน่า?

“เมื่อรันเวย์สั้นลงสำหรับ .NET 6 และ Visual Studio 2022 เราจึงเลือกที่จะเน้นที่การนำ Hot Reload มาสู่ VS2022 ก่อน”

เพื่อแสดงให้เห็นว่า "การควบคุมคุณภาพ" ไม่ใช่กรณีของ "นาฬิกา dotnet" เราจะเปรียบเทียบกับผลิตภัณฑ์อื่นที่เราล่าช้า: MAUI

MAUI อยู่ในสภาพที่หยาบ มันชัดเจนโดย RC1 ว่าคุณภาพจะไม่สูงพอเมื่อเวลาที่ dotnet 6 จัดส่ง มีมากเกินไปที่จะแก้ไขและไม่มีเวลาพอที่จะทำ ทีม MAUI และพันธมิตรนำปัญหาเหล่านี้มาสู่ความเป็นผู้นำ ซึ่งผลักดันผลิตภัณฑ์กลับไปในช่วงต้นปีหน้า

มีและยังไม่มีข้อบ่งชี้ว่า "นาฬิกา dotnet" อยู่ในที่เดียวกัน การผ่านปัญหา GitHub หรืองานในมือของทีม dotnet แสดงความกังวลใดๆ ว่าคุณภาพไม่ได้อยู่ที่นั่น ตรงกันข้าม มันกำลังไปได้สวย สิ่งเหล่านี้จะถูกนำมาใช้เร็วขึ้นมากในวงจรการเปิดตัวของเรา หากมีข้อกังวลด้านคุณภาพที่แท้จริง ไม่ใช่สามสัปดาห์ก่อนจัดส่ง

“เช่นเดียวกับหลายๆ บริษัท เรากำลังเรียนรู้ที่จะสร้างสมดุลระหว่างความต้องการของชุมชน OSS และการเป็นผู้สนับสนุนองค์กรสำหรับ .NET”

ถ้าเราอ่านระหว่างบรรทัด ข้อความนี้เป็นจริง เราขัดแย้งกับสิ่งที่เราใส่ลงใน dotnet, Visual Studio และ Visual Studio Code การรักษา Hot Reload ให้เป็น "มูลค่าเพิ่ม" สำหรับ Visual Studio จะล็อกสิ่งเหล่านั้นไว้ในผลิตภัณฑ์ที่ต้องชำระเงินและมีเหตุผลน้อยกว่าในการข้ามไปที่ VS Code ในทางที่เยือกเย็นและคำนวณได้นั้นสมเหตุสมผลและเป็นเรื่องไร้สาระอย่างยิ่ง

จะเกิดอะไรขึ้นถ้าทีมที่ทำงานเกี่ยวกับ Hot Reload สำหรับ Visual Studio รวม "dotnet watch" ไว้ในผลิตภัณฑ์ของตน จะเกิดอะไรขึ้นหากผู้นำดึงคุณลักษณะเหล่านี้ออกไปหลายสัปดาห์ก่อนการเปิดตัวทั่วไป จะปรับปรุง Visual Studio ในทางใดทางหนึ่งได้อย่างไร เราจะลบส่วนต่างๆ ออกจาก CLI ต่อไปเพราะกลัวว่าจะสูญเสียรายได้จาก Visual Studio หรือไม่

วิธีที่เราสร้าง Visual Studio ที่ดีที่สุดคือการมีรันไทม์ที่ดีที่สุดในโลก เมื่อทีม Visual Studio เพิ่มคุณสมบัติให้กับพื้นฐานของ dotnet เรามีฐานที่สม่ำเสมอสำหรับทุกคนในการทำงานและมีส่วนร่วม เราสามารถสร้าง IDE ที่ดีที่สุดได้โดยการทำงานร่วมกันในรันไทม์ ไม่ทำให้ผลิตภัณฑ์โอเพนซอร์สของเราแย่ลง

อะไรต่อไป? เราจะทำให้ Omnisharp เป็นผลิตภัณฑ์แบบปิดหรือไม่? เพื่อที่เราจะแน่ใจได้ว่าไม่สามารถรับคุณลักษณะใหม่ที่นำเอา "คุณค่า" ของ Visual Studio มาใช้ได้? เพื่อที่เราจะไม่แจกฟีเจอร์ให้ไรเดอร์? มันช่วยเราได้อย่างไร? การตัดสินใจโดยผู้นำเหล่านี้ทำให้แน่ใจได้ว่า Visual Studio จะเป็นรองทุกสิ่งในตลาด การเคลื่อนไหวเช่นนี้ไม่เพียงแต่ทำร้ายเรากับลูกค้า แต่ยังรวมถึงวิธีที่เราสร้างผลิตภัณฑ์ภายในองค์กรด้วย พวกเขาไม่เพียงแค่ทำร้ายเราด้วย “ชุมชน OSS” แต่ทุกคนในแผนกนักพัฒนาและ Microsoft

หากเราต้องการแสดงความโปร่งใสในเรื่องนี้ เราควรทำการเปลี่ยนแปลงเหล่านี้เพื่อให้ถูกต้อง:

เราต้องการไทม์ไลน์ที่สมบูรณ์ โพสต์ในที่สาธารณะ ว่าสิ่งนี้เกิดขึ้นได้อย่างไร และผู้รับผิดชอบโดยตรงในการที่สิ่งนี้นำไปสู่สิ่งนี้
เราไม่ควรเร่งรีบประชาสัมพันธ์อีกต่อไป มันชัดเจนตั้งแต่เริ่มต้นแล้วว่าการลบโค้ดเป็นการกระทำที่ผิด และถ้าเราต้องการคำติชมจากชุมชนจริงๆ เราต้องเต็มใจที่จะรับฟังไม่ใช่หลังจากนั้น แต่ก่อนหน้านั้น
หากการตัดสินใจเหล่านี้เกิดขึ้นเพียงฝ่ายเดียวโดยผู้นำ เราต้องป้องกันไม่ให้สิ่งนั้นเกิดขึ้นอีก มีความขัดแย้งทางผลประโยชน์ที่ชัดเจนระหว่าง "ความต้องการ" ของ VS กับของ dotnet จำเป็นต้องมีการตรวจสอบและถ่วงดุลเพื่อป้องกันไม่ให้บุคคลใด ๆ ไม่ว่าจะสูงเพียงใด จากการตัดสินใจเช่นนี้โดยไม่มีการตอบรับที่แท้จริงจากภายในและภายนอกแผนก

เป้าหมายของเราที่นี่คือไม่ดูถูกบุคคลใดที่เป็นผู้นำที่อาจทำการตัดสินใจนี้ มันคือการแก้ไขปัญหาหลัก: ไม่มีใครควรมีอำนาจมากพอที่จะส่งผลกระทบต่อผลิตภัณฑ์เช่น dotnet ใกล้เคียงกับการเปิดตัวโดยตรง ใครก็ตามที่เป็นผู้นำแผนกนักพัฒนาสามารถดำเนินการแบบเดียวกัน ซึ่งเราต้องป้องกัน การมีแนวทางที่ชัดเจนในการปกป้องผลิตภัณฑ์เหล่านี้ซึ่งเป็นรากฐานของทุกสิ่งที่ Visual Studio ไม่เพียงแต่ทำให้เราเป็นผู้ดูแลซอฟต์แวร์โอเพ่นซอร์สที่ดีที่สุดในระดับเดียวกันเท่านั้น แต่ยังช่วยให้เราสร้าง IDE ที่ดีที่สุดเท่าที่เราจะทำได้อีกด้วย

ขอบคุณแกรมสำหรับคำแนะนำ