تشير التحديثات الخاطئة إلى وجود مشكلة أعمق


Windows 10 في عرض طوكيو التقديمي يوليو 2015

من الواضح أن تحديث Windows في 10 أكتوبر 2018 لم يكن الأكثر نجاحًا. ظهرت رسائل حول فقدان الملفات على أجهزة الكمبيوتر بسرعة ، وتوقفت Microsoft عن توزيع التحديث. منذ ذلك الحين ، تم إصلاح الخطأ ، الآن يتم اختبار تحديث جديد قبل إعادة إصداره.

هذا ليس تحديث Windows الأول الذي يواجه مشاكل - في التحديثات السابقة رأينا أشياء مثل عدم التوافق الكبير في الأجهزة - ولكن من الواضح أنه أصبح أسوأ. يعرف معظمنا عن النسخ الاحتياطية ، ولكن في الواقع ، لا تحتوي العديد من البيانات ، وخاصة على أجهزة الكمبيوتر المنزلية ، على نسخة احتياطية ، واختفاءها مزعج للغاية.

Windows كخدمة

في Windows 10 ، تم التخطيط لتغيير عملية التطوير بشكل جذري. أرادت Microsoft الاستجابة بشكل أفضل لاحتياجات العملاء والسوق - وغالبًا ما تطرح ميزات جديدة. تم تقديم Windows 10 باعتباره أحدث إصدار من Windows. مثل كل التطورات الجديدة ستصبح تحديثات لنظام Windows 10 ، يتم تسليمها من خلال نظام التحديث عدة مرات في السنة. يسمى نموذج التطوير الجديد هذا باسم Windows كخدمة. وبعد بعض الفوضى الأولية ، استقرت Microsoft على تحديثين وظيفيين كل عام : في أبريل وفي أكتوبر.

كانت هذه الجهود ناجحة. تطرح Microsoft ميزات جديدة مفيدة للنموذج الجديد ، دون إجبار المستخدمين على الانتظار ثلاث سنوات لتحديث الإصدار الرئيسي. على سبيل المثال ، تم إصدار ميزة ملائمة لتشغيل Edge بشكل غير مرئي في جهاز افتراضي ، مما يوفر حماية أكبر ضد مواقع الويب الضارة. أصبح Windows Subsystem for Linux (WSL) ، الذي يسمح لك بتشغيل برامج Linux على نظام Windows ، أداة للمطورين والمسؤولين. من الصعب ملاحظة الفوائد للمستخدمين العاديين ، ولكن يمكنك ذكر ميزات VR المتوافقة مع SteamVR ، وأداء اللعبة المحسن وموضوع مظلم . على الرغم من أن التحسينات ليست مهمة جدًا ، بشكل عام ، فإن نظام التشغيل Windows 10 الحالي أفضل بالتأكيد من ذلك الذي ظهر قبل ثلاث سنوات.


في الأيام التي تم فيها تحديث Windows كل ثلاث سنوات فقط ، كان من الصعب تخيل أن WSL ستصبح أداة مفيدة على الإطلاق.

كل هذا جيد ، وكان من الصعب القيام ببعض الأشياء (على الأقل بنجاح) بدون تقديم Windows كنموذج خدمة. تطوير WSL ، على سبيل المثال ، كان مبنياً على ملاحظات المستخدمين. تحدث المستخدمون عن حالات عدم التوافق الموجودة وساعدوا في تحديد أولويات تطوير الميزات الجديدة. لا أعتقد أن WSL ستحصل على مثل هذا الزخم للتطوير بدون تقدم تحديث ثابت كل ستة أشهر - لن يرغب أحد في الانتظار ثلاث سنوات لرؤية تصحيح بسيط. على سبيل المثال ، حتى تبدأ حزمة مهمة بالنسبة لهم في العمل بشكل صحيح. تكافئ التحديثات المنتظمة الأشخاص على رسائل الخطأ لأن الجميع يرى حقًا أنه تم إصلاح الأخطاء في الوقت المناسب.

المشكلة مع Windows كنموذج خدمة هي الجودة. المشاكل السابقة في هذا النموذج والتحديثات الأمنية قد قوضت بالفعل الثقة في سياسة تحديث Windows 10. كان المستخدمون المتمرسون يعتقدون أن جودة تحديثات الأمان الشهرية قد انخفضت في Windows 10 ، وتثبيت تحديثات الميزات نصف السنوية بمجرد ظهورها أمر مجنون . هذه الشكاوى لها تاريخ طويل. أصبحت التحديثات الضعيفة مدعاة للقلق بعد فترة وجيزة من إصدار Windows 10.

جعلت المشكلة الأخيرة مع حذف الملفات الخبراء سببًا أنه قد يكون هناك العديد من تحديثات الميزات في السنة . يجب على Redmond تقليل عددهم إلى واحد ، ويجب على Microsoft تعليق تطوير الميزات الجديدة وإصلاح الأخطاء فقط . يشعر البعض بالقلق من أن الشركة قريبة بشكل خطير من فقدان خطير للثقة في التحديثات ، وبالنسبة لبعض مستخدمي Windows ، فقد هذه الثقة بالفعل.

هذه ليست المكالمات الأولى لـ Microsoft لإبطاء تحديثات الميزات - كانت هناك مخاوف من صعوبة استيعاب كل هذا لأقسام تكنولوجيا المعلومات والمستخدمين العاديين ، ولكن مع المشاكل الواضحة لآخر تحديث ، تصبح هذه المكالمات ذات صلة بشكل خاص.

إنها ليست مسألة تردد ، ولكن لتحديثات كيف يتم تحضيرها

لكن أولئك الذين يصرون على تحديث واحد في السنة بدلاً من تحديثين يخطئون. المشكلة ليست في تواتر الخرج. تكمن المشكلة في عملية تطوير Microsoft.

لماذا لا تكمن المشكلة في المصطلحات؟ يمكننا إلقاء نظرة على جداول تحديث أنظمة التشغيل الأخرى.

من ناحية ، يتم تحديث macOS و iOS و Android بشكل أقل تكرارًا ، لذلك قد تحصل على الانطباع بأن Microsoft متحمسة للغاية. من ناحية أخرى ، هناك سوابق للتحديثات الناجحة على مثل هذا التردد: بالنسبة إلى Ubuntu ، هناك إصداران سنويًا ، و ChromeOS من Google ، مثل متصفح Chrome ، يتلقى التحديثات كل ستة أسابيع. إذا تجاوزت نظام التشغيل ، فسيقوم برنامج Microsoft Office Insider بتشغيل قناة شهرية يتم فيها إصدار ميزات جديدة لمستخدمي Office كل شهر - ويقوم المطورون بالمهمة دون التسبب في الكثير من الشكاوى وفي نفس الوقت توفير تدفق ثابت من الميزات والإصلاحات الجديدة. غالبًا ما يُصدر فريق Visual Studio تحديثات لبيئة التطوير والخدمات التفاعلية الخاصة بهم. من الواضح أن لدى Microsoft فرق تكيفت بشكل جيد مع الواقع ، حيث يتم تحديث تطبيقاتها بانتظام.

سوف نتجاوز نطاق البرامج المحلية ونلقي نظرة على خدمات الشبكة والخدمات السحابية. هناك ، تقدم Microsoft وشركات أخرى بشكل متزايد توصيلًا مستمرًا . يتم نشر كل تحديث في النظام تلقائيًا على خوادم الإنتاج بعد اجتياز عدد كاف من الاختبارات التلقائية.

بالطبع ، لا يمكن مقارنة أي من هذه المشاريع في التعقيد مع Windows. قد يكون لدى Ubuntu مجموعة متنوعة من الحزم ، ولكن على أي حال ، يتم تطوير العديد منها بشكل مستقل. تبقى الحقيقة: حجم Windows كبير بشكل غير عادي - والمكونات مدمجة بشكل غير مسبوق في قاعدة تعليمات برمجية واحدة. في بعض الأماكن ، يكون رمز Windows قديمًا بشكل استثنائي.

بالطبع ، تؤدي هذه العوامل إلى تعقيد تطوير Windows ، ولكن هل من المستحيل حقاً التغلب على تحديثين كل عام؟ هذه ليست النقطة على الإطلاق. تحتاج فقط إلى عملية التطوير الصحيحة.


Windows 10 في وقت الإصدار عام 2015 (أين جميع الرموز الخاصة بي وقائمة ابدأ؟)

عملية متجذرة في التاريخ

لا تكشف Microsoft عن تفاصيل محددة لعملية تطوير Windows 10 ، ولكن هناك خصائص ملحوظة لهذه العملية (كيفية إرسال الميزات الجديدة إلى المطلعين ، وأنواع الأخطاء في الإنشاءات الداخلية) ، وهناك بعض المعلومات من داخل الشركة. تشير كل هذه الحقائق غير المباشرة إلى دونية عملية التنمية. احتفظ ببعض أوجه التشابه مع عملية التطوير التي استخدمتها الشركة خلال إصدارات Windows لمدة ثلاث سنوات. لقد انخفض التوقيت ، لكن النهج الأساسي لم يتغير.



في الأيام الخوالي ، عندما مرت بين سنتين وثلاث سنوات بين الإصدارات الكبيرة ، دخلت Microsoft في عملية مقسمة إلى عدة مراحل:

1. التصميم والتخطيط ؛
2. تطوير المكونات ؛
3. التكامل ؛
4. الاستقرار.

حوالي 4-6 أشهر من التخطيط والتصميم ، 6-8 أسابيع من الترميز المكثف ، ثم 4 أشهر من التكامل (عادةً ما يتم تطوير كل وظيفة في فرعها الخاص ، لذلك يجب أن يتم تجميعها ودمجها معًا) وتحقيق الاستقرار (اختبار وتصحيح الأخطاء). أثناء تطوير المنتج ، تتكرر هذه الدورة مرتين أو ثلاث مرات ؛ سيحتوي Windows على ثلاثة تكرارات ، أولها نموذج أولي ، والإثنان التاليان حقيقيان. قد تختلف مدة المراحل ، ولكن يتم استخدام الهيكل الأساسي على نطاق واسع في الشركة.

بعض الأشياء واضحة من هذه العملية. ولعل أكثر ما يلفت الانتباه هو أنه من المستغرب قضاء القليل من الوقت بشكل مباشر في تطوير رمز جديد: بالنسبة لإصدار Windows ، فهذه فترتين من 6 إلى 8 أسابيع طوال فترة الثلاث سنوات بأكملها. يمر الكثير من الوقت بين مرحلة التخطيط / التصميم والمنتج الذي يعمل بالفعل. هذا هو العامل الرئيسي الذي يجعل هذه العملية لا يمكن وصفها بأنها "تطوير مرن": الوظائف الجديدة مدمجة بقوة في المنتج النهائي ، لذلك من الصعب تغييرها استجابة للتعليقات.

يمثل فصل التطوير وإصلاح الأخطاء عن بعضها البعض أيضًا مشكلة: في مراحل التطوير والتكامل ، تعد موثوقية البرامج واستقرارها عديمة الجدوى. لا يتم اختبار الوظائف المتكاملة بشكل أساسي (لأن الاختبار يحدث لاحقًا) ولا يتم استخدامها مع بعضها البعض أبدًا (لأنه تم تطويرها جميعًا بشكل منفصل في الفروع الخاصة بها قبل مرحلة التكامل). يتم بعد ذلك جلب فوضى البرامج إلى مستوى مقبول من خلال الاختبار والإبلاغ عن الأخطاء وتصحيح الأخطاء خلال مرحلة التثبيت الطويلة. في هذه العملية ، تحتاج إلى تحسين موثوقية المنتج بشكل متكرر.


تقدم Nadella العالم لنظام التشغيل Windows 10 في عام 2015

العالم الجديد ليس بالجديد

في العالم الجديد ، نرى أن دورة الشركة الكاملة تستغرق سبعة أو ثمانية أشهر. على الرغم من وجود ستة أشهر فقط بين الإصدارات ، فإن بداية الدورة التالية تحدث قبل اكتمال الدورة السابقة - بالنسبة إلى المطلعين ، يتضح ذلك من افتتاح مجموعة Skip Ahead.

كقاعدة ، يبدأ كل تحديث بفترة هادئة إلى حد ما مع العديد من التغييرات المرئية ، ثم يأتي بعد بضعة أشهر مع إدخال تغييرات كبيرة - وعدد كبير من الأخطاء. قبل حوالي شهر من التحديث ، نرى تباطؤًا حادًا في عدد التغييرات التي تم إجراؤها وتركيزًا قويًا على إصلاحات الأخطاء ، وليس على الميزات الجديدة.

كما يصف موظفو Microsoft أنفسهم ، فإن الأشهر القليلة الماضية من التطوير تشمل مرحلة "أخبر" ، ثم شهر واحد من مرحلة "طلب إذن". في مرحلة "الإخطار" ، يتم إعلام إدارة Windows بالتغييرات التي تم إجراؤها على سياسة قبول هذه التغييرات بشكل افتراضي. في مرحلة "طلب الإذن" ، يُسمح بإجراء تغييرات مهمة فقط ، كقاعدة عامة ، تغييرات قليلة فقط في اليوم.

على سبيل المثال ، تم إصدار أول إصدار من تحديث أكتوبر (الاسم الرمزي RS5) إلى المطلعين في 14 فبراير ، وحدث البناء المستقر لتحديث أبريل (RS4) بعد شهرين في 16 أبريل. لم يتلق RS5 أي ميزات جديدة مهمة حتى 7 مارس. تمت إضافة العديد من الميزات خلال مايو ويونيو ويوليو ، ثم تم إجراء تغييرات صغيرة فقط في أغسطس وسبتمبر. تمت إزالة العديد من الميزات الصغيرة في أغسطس ، حيث كان من الصعب الاستعداد لإطلاقها في أكتوبر.

بالطبع ، لقد تغيرت العملية قليلاً. على سبيل المثال ، تظهر الميزات الجديدة في الإصدارات المسبقة على مدار عدة أشهر. هذا يشير إلى أن تكامل الوظائف الجديدة يبدو أنه يحدث في وقت أبكر بكثير - حيث يتم تطوير الوظائف ، وليس في حزمة دمج كبيرة في النهاية.

انخفاض في الجودة

ولكن هناك أوجه تشابه رئيسية. الأهم من ذلك ، يتم دمج رمز عربات التي تجرها الدواب عمدا في قاعدة بيانات مشتركة ، وتستخدم مرحلة الاختبار والتثبيت لحل أي مشاكل. حتى هذه اللحظة معترف بها بشكل صريح: عند الإعلان عن تجميع أولي جديد ، تحذر Microsoft: "كالمعتاد في بداية دورة التطوير ، يمكن أن تحتوي التجميعات على أخطاء يمكن أن تكون مؤلمة. إذا كان هذا يسبب لك أي إزعاج ، فقد تفكر في التبديل إلى دورة تحديث بطيئة (حلقة بطيئة). هناك ، ستظل التجمعات ذات جودة أعلى. "

نرى هذا في الممارسة العملية في RS5. في أكتوبر من العام الماضي ، مع التحديث ، قدموا ميزة جديدة لـ OneDrive: العناصر النائبة ، التي تعرض الملفات في السحابة التي لا يتم تنزيلها محليًا. عندما يحاول تطبيق فتح ملف ، يقوم OneDrive باستخراج الملف بشفافية من التخزين السحابي ويحفظه محليًا ، ولا يعرف التطبيق حتى أنه لم يكن من الممكن الوصول إلى الملف محليًا في البداية. نفذت بنية RS5 وظيفة تنظيف ملفات السحابة المنسوخة من التخزين المحلي إذا نفدت مساحة القرص.

هذه ميزة ذكية ومفيدة حقًا تعمل على تحسين التكامل مع التخزين السحابي. هذا هو رمز جديد. يوجد برنامج تشغيل kernel يوفر رابطًا بين رمز المزامنة السحابية (المستخدم لتحميل الملفات وتنزيل التغييرات) والرموز في نظام الملفات. هناك أيضًا واجهة برمجة تطبيقات (يبدو أن الجهات الخارجية يمكنها أيضًا استخدام هذه الميزة لخدمات المزامنة).


تستخدم إصدارات Windows المسبقة "شاشة الموت" الخضراء بدلاً من اللون الأزرق ، لذا يسهل تمييزها

من المنطقي أن نفترض أن Microsoft ستجري مجموعة من الاختبارات لهذا الرمز الجديد: إنشاء ملف ، والتحقق من التزامن ، وحذف نسخة محلية مع حفظ الرمز ، وفتح الرمز مع تحميل الملف الفعلي ، وحذف الملف بالكامل ، وما إلى ذلك. هناك العديد من العمليات الأساسية لمعالجة الملفات والأدلة ، وفي أي عملية تطوير مرنة ، هناك اختبارات للتحقق من أن جميع العمليات تعمل كما هو متوقع ، وتقوم API بما يجب عليها القيام به.

بالإضافة إلى ذلك ، كان من المعقول افتراض أن أي تغيير في الكود يكسر الاختبارات سيتم رفضه ولن يُسمح بالاندماج. يجب إصلاح الرمز ، ويجب أن يجتاز اختباراته قبل أن يصل إلى الفرع الرئيسي من Windows ، وأكثر من ذلك حتى يذهب إلى اختبار بيتا.

ومع ذلك ، كان هناك خطأ في العديد من البنيات الأولية: تم تعليق النظام عند حذف دليل متزامن مع OneDrive. لم يتم دمج هذا الخطأ فقط في كود Windows ، ولكن تم إصداره أيضًا للمستخدمين النهائيين.

اختبر البرنامج قبل الإصدار وليس بعده

يشير هذا إلى بعض المبادئ الأساسية لتطوير Windows. إما أنه لا توجد اختبارات على الإطلاق لهذا الرمز (قيل لي أنه نعم ، يُسمح بدمج الرمز بدون اختبارات ، على الرغم من أنني آمل ألا يكون هذا هو القاعدة) ، أو أن إخفاقات الاختبار تعتبر مشاكل غير مقبولة ، ويُسمح للمطورين بدمج التعليمات البرمجية التي من الواضح أنها ليست يعمل بشكل صحيح. في الخارج ، لا يمكننا أن نقول بالضبط ما يحدث بالضبط - ربما حتى مزيج من كلا النهجين - ولكن لا يمكن وصف أي منهما بالخير.

بالنسبة للأجزاء القديمة من Windows ، يمكن اعتبار هذا أكثر عذرًا - بعد كل شيء ، تم تطويرها قبل عصر الاختبار الآلي ، وقد لا تكون هناك اختبارات في الواقع. لكن شارات OneDrive ليست جزءًا قديمًا من Windows ؛ إنها ميزة جديدة تمامًا. لا يوجد سبب وجيه لعدم وجود مجموعة قوية من الاختبارات لاختبار الوظائف الأساسية للرمز الجديد. ولا يجب بالتأكيد تضمين رمز معيب معروف في قاعدة الرمز حتى يتم إصلاحه ، ناهيك عن إرساله إلى المختبرين.

ونتيجة لذلك ، لا يزال تطوير Windows 10 يتبع المبادئ القديمة. يتم سكب ميزات جديدة في قاعدة البيانات مع تدهور الاستقرار والموثوقية. من المفترض أن يتم جلب قاعدة الكود إلى مستوى مقبول في مرحلة الاختبار والاستقرار.

الاختبار الآلي غير الكافي و / أو تجاهل أخطاء الاختبار ، بدوره ، يعني أن مطوري Windows لا يمكنهم التأكد من أن التغييرات والتصحيحات لن تسبب تأثيرات مضاعفة. هذا هو المكان الذي جاءت منه مرحلة تطوير "طلب الإذن": مع اكتمال التحديث ، يجب تقليل عدد التغييرات إلى الحد الأدنى لأن Microsoft غير متأكدة من أن نطاق وتأثير كل تغيير يتم عزله. تأتي هذه الثقة فقط مع بنية تحتية ضخمة من الاختبارات المنضبطة: أنت تعلم أن التغيير آمن لأن جميع الاختبارات تمر بنجاح. بغض النظر عن نوع الاختبار الذي تجريه الشركة لنظام التشغيل Windows ، فمن الواضح أنه لا يكفي لاكتساب هذه الثقة.

ولكن من نواح أخرى ، تتصرف مايكروسوفت كما لو كانت لديها هذا اليقين. الشركة لديها العديد من الاختبارات. قيل لي أن دورة اختبار كاملة لنظام التشغيل Windows تستغرق عدة أسابيع. يتم تنفيذ هذه الدورة الكاملة حقًا ، وليس فقط في التجميعات التي تدخل فعليًا في الإنتاج. مثال على ذلك هو تحديث أكتوبر 2018: تم تجميع الرمز في 15 سبتمبر ، وفي 2 أكتوبر ، أصبح التجميع عامًا. بغض النظر عن أي بناء RS5 مر بدورة اختبار كاملة ، هذه ليست تلك التي تلقيناها بالفعل ، لأن دورة الاختبار الكاملة تستغرق الكثير من الوقت.

هذا موقف مثير للجدل. إذا تم إجراء التغييرات اللاحقة على الشفرة بدرجة عالية من الثقة في أنها لم تكسر أي شيء ، فيمكنك بدء دورة الاختبار الكاملة في التجميع السابق. ولكن إذا كانت Microsoft على ثقة كبيرة من أن هذه التغييرات لن تكسر أي شيء ، فلن تضطر إلى خنقها كثيرًا في مرحلة "طلب الإذن".


يمكن أن يعمل Windows 10 حقًا مثل جهاز موثوق

كيف تفعل ذلك بشكل صحيح

نرى اختلافًا كبيرًا مع المشاريع الحقيقية الرشيقة. على سبيل المثال ، عملية تطوير تستخدمها Google لخادم شحن الإعلانات. هذا جزء مهم من البنية التحتية للشركة ، لكن المطورين الجدد في الشركة يصفون أنهم أجروا تغييرات لإغلاق خطأ صغير - وبدأت التغييرات في الإنتاج خلال اليوم. عندما يتم إرسال إصلاح إلى المستودع ، يتم إعادة بنائه تلقائيًا ويخضع لبطارية من الاختبارات. ثم ينظر المشرف على قسم الكود هذا في التغيير ويقبله ويدمجه مع قاعدة الكود الرئيسية ، التي يتم اختبارها ونشرها في الإنتاج.

بالطبع ، من غير العدل أن تقارن هذا مع Windows: بعد كل شيء ، من الأسهل كثيرًا على الخدمات السحابية التراجع عن التغيير عند اكتشاف خطأ. يعد تعديل Windows باستخدام شاشة زرقاء عند بدء تشغيل النظام أكثر صعوبة للتراجع والاستعادة. — Google, , , . , .

. , . Microsoft — « , », , .


Chrome , , —

على الرغم من أن التطبيقات السحابية توفر بعض المرونة ، إلا أن طرق Agile مناسبة أيضًا لبرامج سطح المكتب. على سبيل المثال ، لدى Google عمليات مماثلة لمتصفح Chrome. تحتوي الإصدارات التجريبية من Chrome على أخطاء نادرة ، ولكن بشكل عام ، رمزها قريب من جودة الإصدار. في الواقع ، مبدأ تطوير Chrome هو أنه حتى أحدث إصدار يجب أن يكون بجودة الإصدار. يمكنك استخدام إصدار مطور البرامج من Chrome كمتصفح عادي - وفقط من خلال الرمز ستدرك أن هذه قناة ألفا وليست قناة مستقرة. هذا ممكن بفضل الأتمتة الشاملة للاختبارات والفحوصات: طوال عملية التطوير ، يكون رمز Chrome عالي الجودة ، بدون انخفاض في الجودة ، مع التغييرات اللاحقة التي نراها في Windows.

للقيام بذلك ، استثمرت Google في البنية التحتية. لديها نظام بناء موزع يبني Chrome بالتوازي على ألف نوى ، لذلك يمكن إكمال البناء الكامل في بضع دقائق فقط. تم إنشاء تفرع منضبط لجعل عمليات الاندماج سهلة ويمكن التنبؤ بها. لدى Google مجموعة واسعة من الاختبارات الوظيفية واختبارات الأداء للكشف عن الأخطاء والانحدارات في أقرب وقت ممكن. لا يأتي أي من هذا مجانًا ، ولكن من المهم أن تصدر Google إصدارات Chrome بطريقة مستدامة ومنتظمة.

لطالما كانت عملية تطوير Windows سيئة

في عملية التطوير الجديدة ، خصصت Microsoft نسبيًا مزيدًا من الوقت لكتابة وظائف جديدة ووقت أقل لتثبيت هذه الوظائف وإصلاحها. سيكون كل شيء جميلًا إذا كانت جودة الوظائف عالية من البداية ، مع بنية أساسية للاختبار ومعايير أعلى قبل دمج التعليمات البرمجية الجديدة. لكن التجربة مع Windows 10 حتى الآن هي أن Microsoft لم تطور العمليات والأنظمة اللازمة لدعم هذا النهج الجديد.

لن تؤدي مشكلة تقليل عدد المشاكل من قضيتين إلى واحدة في السنة إلى حل المشكلة. غالبًا ما يبدو لي أن الناس ينظرون إلى تطوير Windows السابق من خلال النظارات الوردية. ولكن إذا تذكرت أوقات Windows 7 والإصدارات السابقة ، فسوف نرى مشاكل مشابهة جدًا. ثم كانت النصيحة المعتادة هي عدم الترقية إلى إصدار جديد من Windows حتى يتم إصدار Service Pack 1. لماذا؟ نظرًا لأن الإصدار الأول كان دائمًا عربات التي تجرها الدواب وغير مستقرة بشكل غير مقبول - وكان من الأفضل الانتظار حتى تحل Service Pack 1 معظم هذه المشاكل.

الفرق ليس في أن النهج الجديد لتطوير Windows أسوأ بكثير من ذي قبل ، أو أن العملية القديمة أعطت نتائج أفضل. لا على الإطلاق.نرى الآن نفس الشيء كما حدث بعد ذلك ، فقط لحظة "انتظر Service Pack 1" تأتي مرتين في السنة. بعد كل تحديث جديد ، يأتي وقت تعتقد فيه Microsoft أن الشفرة جيدة بما يكفي لمستخدمي الشركات - عادةً بعد ثلاثة إلى أربعة أشهر من الإصدار الأولي. هذه هي حزمة الخدمة "الجديدة" الخاصة بنا 1.

وبالتالي ، فإننا نحصل على أسوأ ما في العالمين: من النهج القديم لتطوير Windows ، هناك إصدارات سيئة تحتاج إلى إصلاح. من نهج جديد - يصدر مرتين في السنة ، وليس مرة واحدة كل ثلاث سنوات. وبالتالي ، يستمر عدم الاستقرار حتى إصدار حزمة الخدمة لمعظم العام.

العيب الرئيسي هو زعزعة قاعدة الكود من خلال دمج الوظائف التي لم يتم اختبارها بشكل كافٍ على أمل إصلاحها لاحقًا. هذه عملية سيئة. كان هذا سيئًا في الوقت الذي تم فيه إصدار Windows كل ثلاث سنوات ، وكان سيئًا عندما تم إصداره كل ستة أشهر.

هذا ليس من عمل المطلعين

المشكلة الثانية هي طبيعة الاختبارات. كان لدى Microsoft عددًا كبيرًا من المختبرين ، وتم تعيين عدد معين من المطورين والمختبرين لكل وظيفة. تم فصل العديد منهم أو نقلهم إلى وظائف أخرى في عام 2014. كانت الفكرة أنه سيتم تعيين المزيد من مسؤوليات الاختبار للمطورين الذين ينشئون هذه الميزات. يوفر برنامج Windows Insider أيضًا كمية كبيرة من الاختبارات غير الرسمية - مع ملايين المشاركين (المطلعين). هذا أكثر بكثير من أي من برامج Windows التجريبية السابقة.

, . , , . , Microsoft . . , , , , . , , .

وعدت Microsoft بتغيير عملية التعليقات مع المطلعين على ذلك بحيث تشير إلى شدة المشكلة وتلفت الانتباه إلى هذه الأنواع من المشاكل. يمكن أن يساعد ذلك إذا استخدم المطلعون مؤشرات الخطورة بشكل صحيح ، ولكن يبدو أنها غير كافية لحل المشكلة الرئيسية: الكثير من تقارير الأخطاء ذات الجودة المنخفضة للغاية.

يشير هذا إلى مشكلة جودة التعليمات البرمجية. القوة الحقيقية لـ Insider هي مجموعة متنوعة من الأجهزة والبرامج. يمكن للمستخدمين المطلعين تحديد أكثر أخطاء التوافق الغريبة ومشكلات السائقين وما إلى ذلك. لكن المطلعين يجب ألا يقوموا باختبار الوظائف الأساسية ولكن غالبًا ما يكون هناك شعور بأن Microsoft تستخدمهم كمختبرين بدوام كامل.

علاوة على ذلك ، إذا انخفضت جودة الكود أثناء التطوير ، فعادةً ما تكون الإصدارات السابقة غير مناسبة للاستخدام اليومي على أجهزة الكمبيوتر العادية. فهي ليست موثوقة بما فيه الكفاية. وهذا بدوره يقوض قيمة الاختبار من قبل المطلعين: فهم لا يقومون بتثبيتها على جهاز الكمبيوتر الرئيسي ولا يخضعون للتجميع لمجموعة كاملة من الأجهزة والبرامج. يستخدمون أجهزة الكمبيوتر الثانوية والآلات الافتراضية.

عليك أن تستثمر في أدواتك

يعد تطوير بنية أساسية تجريبية مثل Chrome لمشروع ضخم مثل Windows مهمة خطيرة للغاية. على الرغم من أن بعض أجزاء Windows تسمح بإجراء الاختبار دون اتصال ، إلا أنه لا يمكن اختبار أجزاء أخرى بشكل فعال إلا على نظام متكامل ومتكامل. يعتمد بعضها ، مثل ميزة مزامنة ملف OneDrive ، على تشغيل خدمات الشبكة الخارجية. هذه ليست مهمة تافهة.

سيكون التغيير الهائل هو اعتماد المبدأ القائل بأن كود Windows يجب أن يوفر جودة الإصدار في كل لحظة من الوقت - ليس "بعد عدة أشهر من التصحيح" ، ولكن "الآن ، في أي لحظة". لكن هذا شرط ضروري. يجب أن تحقق Microsoft موقفًا حيث يكون لكل تحديث جديد جودة إصدار من اليوم الأول. الحالات التي لا يمثل فيها التحديث إلى أحدث إصدار مشكلة - ويمكن قبول هذا الاختيار بأمان. يجب أن تكون تحديثات الميزات غير مرئية للمستخدمين. إن تقليل عدد الإصدارات إلى إصدار واحد سنويًا أو إصدار واحد في ثلاث سنوات لن يوفر هذا الوضع ، ولم يحدث أبدًا. يجب أن تتغير العملية نفسها ، وليس التوقيت.