التغييرات في أنظمة البرمجيات المعقدة ويبدو أن تأخذ إلى الأبد ، أليس كذلك؟ حتى المهندسين غالباً ما يعتقدون أن التغييرات تتجاوز ما يفترض أن يكون ، على الرغم من أننا ندرك مدى تعقيد النظام!
بالنسبة للعملاء ، فإن الموقف غير مفهوم أكثر. تتفاقم المشكلة بسبب التعقيد العشوائي ، الذي يتم إضافته بمرور الوقت بسبب ضعف دعم النظام. هناك شعور بأننا نحاول جمع الماء من سفينة بها ألف حفرة.
لذلك ، عاجلاً أم آجلاً ، سيرسل العميل خطابًا: "لماذا يستغرق الجحيم وقتًا طويلاً؟" دعونا لا ننسى أن لدينا ، كمهندسين برمجيات ، نافذة على العالم ، غالبًا ما يفتقرون إليها. إنهم يثقون بنا كثيرًا ، ولكن في بعض الأحيان ، يبدو التغيير الذي لا أهمية له كثيرًا من الوقت. وبسبب هذا ، تنشأ أسئلة.
لا تغضب من هذا السؤال ؛ خذها كفرصة لإظهار التعاطف وإعطاء الشخص صورة أوضح عن تعقيد النظام. في الوقت نفسه ، يمكنك اقتراح طرق لتحسين الموقف. عندما ينزعج شخص ما ، فهذه هي أفضل لحظة لتقديم حل!
يتم نشر رسالة أدناه ، والتي أرسلناها مرارًا وتكرارًا بشكل أو بآخر على مر السنين. نأمل أن تساعدك في الإجابة على هذه الأسئلة.
خطاب
عزيزي العميل ،
رأيت تعليقك على البطاقة "أخبر قبل انتهاء المهمة" وسيسعدني مناقشتها في اجتماعنا التالي. هنا ، للإشارة ، سوف ألخص أفكاري ، ليس من الضروري الإجابة.
لإعادة صياغة ملاحظتك:
تغيير الموعد النهائي لاستكمال المهام يوم واحد للإعلام عن طريق البريد يجب أن يأخذ سطر واحد. كيف يمكن أن يستغرق 4-8 ساعات؟ ما الذي أفتقده؟من ناحية ، أنا أتفق معك. ما عليك سوى تغيير جزء الطلب من
tasks due <= today إلى
tasks due <= tomorrow .
من ناحية أخرى ، بتقليلها إلى فكرة مبسطة ، نتجاهل عن غير قصد التعقيد الكامن ونتخذ عددًا من القرارات الهندسية. بعض منهم يجب أن نناقش.
الجزء 1. لماذا هذا التغيير صغير أكثر مما يبدو؟
هذا تغيير بسيط صغير ، سطر واحد من التعليمات البرمجية. إن قضاء يوم كامل عليه ، حتى نصف يوم ، يبدو مبالغًا فيه.
بالطبع ، لا يمكنك فقط طرح تغيير في الإنتاج دون تشغيل محلي على الأقل أو على خادم اختبار. يجب عليك التأكد من تنفيذ التعليمات البرمجية بشكل صحيح ، وإذا تغير الطلب ، فأنت بحاجة إلى مقارنة الإخراج والتأكد من أنه يبدو صحيحًا إلى حد ما.
هنا ، يمكن أن تكون المقارنة بين الحد الأدنى ، مجرد فحص صغير: تأكد من أن النتائج معقولة ، إلخ. هذا إخطار للموظفين الداخليين. إذا كانت الرياضيات حسب التاريخ غير صحيحة (خطأ بسيط) ، فسوف نسمع عنها سريعًا من الفرق. إذا كان ، على سبيل المثال ، بريدًا إلكترونيًا لعملائك ، فستكون هناك حاجة إلى دراسة أعمق. ولكن بالنسبة لهذا الاختبار والمراجعة السهل ، فإن ما بين 20 إلى 40 دقيقة كافية ، اعتمادًا على ما إذا كان هناك شيء غريب أو غير متوقع. حفر في البيانات يمكن أن تأكل الوقت. إطلاق التغييرات دون إجراء مراجعة هو ببساطة إهمال غير مهني.
وبالتالي ، فإننا نضيف وقتًا للوجستيات العادية ، مثل الالتزام بالكود ، ودمج التغييرات ، والنشر ، وما إلى ذلك: من بداية العمل إلى الإصدار في الإنتاج ، تمر ساعة واحدة على الأقل من مهندس مختص محترف.
بالطبع ، هذا يفترض أنك تعرف بالضبط أي سطر من التعليمات البرمجية للتغيير. يعيش سير العمل في النظام القديم بشكل أساسي ، ولكن بعض أجزاء المنطق تعيش في النظام الجديد. يعد نقل المنطق من النظام القديم جيدًا ، لكن هذا يعني أن وظيفة المهمة مقسمة حاليًا إلى نظامين.
نظرًا لأننا نعمل معًا لفترة طويلة ، فإن فريقنا يعرف العملية التي ترسل رسالة بريد إلكتروني بمهمة منتهية الصلاحية ويمكنه الإشارة إلى سطر من التعليمات البرمجية في النظام الجديد الذي يبدأ العملية. لذلك لا يتعين علينا إضاعة الوقت في اكتشاف ذلك.
ولكن إذا نظرنا إلى رمز المهمة في النظام القديم ، فهناك أربع طرق مختلفة على الأقل لتحديد ما إذا كانت المهمة مستحقة. بالإضافة إلى ذلك ، بالنظر إلى أنماط وسلوك البريد الإلكتروني ، هناك مكانان على الأقل يبدو أنه تم تطبيق المنطق المخصص لهذه المهمة.
ثم منطق الإعلام أكثر تعقيدًا مما كنت تعتقد. إنه يميز بين المهام العامة والفردية ، المفتوحة والخاصة ، التكرار ، وظيفة الإخطار الإضافي للمدير في حالة المهمة المتأخرة ، إلخ. لكن يمكننا أن نكتشف بسرعة أنه في الواقع ، يتم استخدام تعريفين فقط من أصل 6 + من المهمة المتأخرة للإخطارات. ويحتاج الأمر إلى تغيير شيء واحد فقط من أجل تحقيق الهدف.
يمكن أن تستغرق هذه المراجعة بسهولة نصف ساعة أخرى أو نحو ذلك ، وربما أقل إذا كنت في هذا الجزء من قاعدة الشفرة مؤخرًا. بالإضافة إلى ذلك ، يعني التعقيد الكامن أنه يمكننا تجاوز تقديرنا للاختبار اليدوي. ولكن دعونا نضيف 30 دقيقة فقط لبذل المزيد من الجهد.
وبالتالي ، وصلنا إلى 1.5 ساعة لنشعر بالثقة من أن التغيير سوف يتم كما هو متوقع.
بالطبع ، لم نتحقق بعد مما إذا كانت أي عمليات أخرى تستخدم استعلامًا قابلاً للتغيير. لا نريد تعطيل وظائف أخرى عن طريق الخطأ عن طريق تغيير مفهوم "الموعد النهائي" إلى اليوم الذي يسبق اليوم الأخير لإكمال المهمة. يجب أن ننظر في قاعدة الكود من وجهة النظر هذه. في هذه الحالة ، يبدو أنه لا توجد تبعيات كبيرة - ربما لأن الجزء الأكبر من واجهة المستخدم لا يزال على النظام القديم. لذلك ، ليست هناك حاجة للقلق بشأن تغيير أو اختبار العمليات الأخرى. في أفضل الأحوال ، هذا هو آخر 15-30 دقيقة.
أوه ، وبما أن الجزء الرئيسي لواجهة مستخدم المهام لا يزال في النظام القديم ، فنحن نحتاج حقًا إلى تقديم نظرة عامة سريعة على وظيفة المهمة في هذا النظام والتأكد من صحة الملاحظات. على سبيل المثال ، إذا كانت واجهة المستخدم تسلط الضوء على المهام التي وصل الموعد النهائي لها ، فيمكننا تغيير هذا المنطق لمطابقة الإشعار. أو على الأقل أعود واسأل العميل كيف يريد أن يفعل ذلك. في الآونة الأخيرة ، لم أنظر إلى وظيفة المهمة في النظام القديم ولا أتذكر ما إذا كان لديها أي فكرة عن الموعد / التأخير. يضيف هذا الاستعراض آخر 15-30 دقيقة. ربما أكثر إذا كان للنظام القديم أيضًا العديد من التعاريف لـ "المهمة" ، إلخ.
وهكذا ، ذهبنا في نطاق ساعتين إلى ساعتين ونصف لإكمال المهمة بثقة في أن كل شيء سيكون على ما يرام ، دون آثار جانبية غير مقصودة أو تشويش في عمل المستخدم.
الجزء 2. كيف يمكنني تقليل هذا الوقت؟
لسوء الحظ ، فإن النتيجة الوحيدة لهذه الجهود هي فقط إنجاز المهمة. هذا ليس الأمثل ، وهو أمر مخيب للآمال للغاية. المعرفة التي اكتسبها المطور في سياق العمل هي شخصية وسريعة الزوال. إذا احتاج مطور آخر (أو أنفسنا بعد 6 أشهر) مرة أخرى إلى إجراء تغييرات على هذا الجزء من الشفرة ، فسيتعين تكرار العملية.
هناك نوعان من التكتيكات الرئيسية لعلاج الوضع:
- قم بتنظيف قاعدة الكود بنشاط لتقليل الازدواجية والتعقيد.
- اكتب الاختبارات الآلية.
ملاحظة: لقد ناقشنا المستندات بالفعل ، ولكن في هذه الحالة ، ليس هذا هو الحل الأفضل. تعد الوثائق مفيدة للأفكار عالية المستوى ، مثل شرح منطق الأعمال أو العمليات المتكررة بشكل متكرر ، مثل قائمة الشركاء الجدد. ولكن عندما يتعلق الأمر بالكود ، تصبح الوثائق ضخمة جدًا وتصبح قديمة عندما تتغير الشفرة.
لقد لاحظت أنه لم يتم تضمين أي من هذه التكتيكات في 2-5 ساعات.
على سبيل المثال ، الحفاظ على قاعدة رمز نظيفة يعني أنه بدلاً من إكمال المهمة ببساطة ، نطرح أسئلة:
- لماذا توجد العديد من الطرق المختلفة لتحديد المهام التي اقترب / انتهت مهلتها؟
- هل يحتاجون جميعا ويعملون عليها؟
- هل يمكن تقليل هذه الأساليب إلى مفهوم أو طريقتين؟
- إذا تم تقسيم المفهوم بين النظامين القديم والجديد ، فهل يمكن توحيده؟
و هكذا.
يمكن أن تكون إجابات هذه الأسئلة سريعة جدًا: على سبيل المثال ، إذا صادفنا رمزًا واضحًا. أو قد تستغرق عدة ساعات: على سبيل المثال ، إذا تم استخدام المهام في العديد من العمليات المعقدة. بمجرد حصولنا على هذه الإجابات ، سيستغرق الأمر المزيد من الوقت لإعادة التنظيم للحد من الازدواجية / الارتباك والحصول على وصف واحد لمفهوم "الموعد النهائي" - أو إعادة تسمية المفاهيم في التعليمات البرمجية لفهم بوضوح كيف تختلف ولماذا.
ولكن في النهاية ، سيصبح هذا الجزء من قاعدة الكود أكثر بساطة ، وسيكون من الأسهل قراءته وتعديله.
تكتيك آخر نستخدمه عادة هو الاختبار الآلي. بمعنى ما ، الاختبارات الآلية تشبه الوثائق التي لا يمكن أن تكون قديمة والتي يسهل اكتشافها. بدلاً من تشغيل التعليمات البرمجية يدويًا وعرض الإخراج ، نكتب رمز اختبار يقوم بتشغيل الطلب والتحقق من الإخراج برمجيًا. يمكن لأي مطور تشغيل رمز الاختبار هذا لفهم كيفية عمل النظام والتأكد من أنه لا يزال يعمل بهذه الطريقة.
إذا كان لديك نظام يتمتع بتغطية اختبار مناسبة ، فستستغرق هذه التغييرات وقتًا أقل بكثير. يمكنك تغيير المنطق ثم تشغيل مجموعة الاختبار الكاملة والتأكد من ذلك
- التغيير يعمل بشكل صحيح ؛
- التغيير لم يكسر أي شيء (هذه معلومات أكثر قيمة مما كانت عليه في الفقرة الأولى).
عندما نبني أنظمة من نقطة الصفر في Simple Thread ، فإننا نضمن دائمًا وقتًا لكتابة الاختبارات الآلية في تقييم المواعيد النهائية. هذا يمكن أن تبطئ التطوير الأولي ، ولكن يحسن كثيرا من كفاءة العمل والصيانة. فقط عندما ينمو النظام ، هل تفهم حقًا أهمية الاختبارات ، ولكن في هذه المرحلة قد يكون من الصعب جدًا إعادة الاختبارات إلى النظام. كما أن وجود الاختبارات يبسط عمل الموظفين الجدد بشكل كبير ، كما أن تغيير سلوك النظام يكون أسرع وأكثر أمانًا.
الجزء 3. من أين أتينا؟ إلى أين نحن ذاهبون؟
اليوم ، نادراً ما نشير في تقييمك إلى وقت مسح الشفرة أو كتابة الاختبارات. هذا جزئيًا لأن اختبارات الكتابة من نقطة الصفر تعتبر عملية بسيطة ، وإضافة الاختبارات إلى قاعدة بيانات قاعدة البيانات الخلفية هي الكثير من العمل ، مثل استعادة الأساس تحت المنزل الذي يعيش فيه الناس.
هذا يرجع أيضًا جزئيًا إلى حقيقة أن البدء في العمل معك ، نتحول على الفور إلى وضع الإنعاش. لدينا مشاكل شبه يومية في مزامنة بيانات الجهات الخارجية ، ومشاكل أسبوعية في إنشاء التقارير ، والطلبات المستمرة لدعم تغييرات البيانات الصغيرة ، وعدم كفاية المراقبة وتسجيل النظام ، وما إلى ذلك. قاعدة الشفرات تغرق تحت وطأة الديون التقنية ، ونحن نحاول الحفاظ على الأنظمة محمومة تطفو ، في حين الشائكة الثقوب مع الشريط الكهربائي.
بمرور الوقت ، أصبحت الأنظمة أكثر ثباتًا وموثوقية ، فنحن نوفر أتمتة / توفير واجهة مستخدم للخدمة الذاتية لطلبات الدعم المتكررة. لا يزال لدينا الكثير من الديون الفنية ، لكننا خرجنا من وضع الطوارئ. لكنني لا أعتقد أننا سنبتعد تمامًا عن عقلية الإنعاش هذه إلى عقلية "خطة وتنفيذ" أكثر نشاطًا واستباقية.
نحاول مسح الكود أثناء التنقل ، ونختبر دائمًا اختبارًا كاملاً. لكن الحرص والاجتهاد لا يؤدي إلى إعادة بناء المساكن أو إنشاء البنية التحتية اللازمة لإجراء اختبارات تلقائية جيدة.
إذا لم نبدأ في دفع بعض الديون الفنية ، فلن نتمكن أبدًا من تحسين الوضع بشكل كبير. سيستغرق المطورون المؤهلون تأهيلا عاليا أشهر للتنقل وإجراء تغييرات غير تافهة.
بمعنى آخر ، تتراوح مدة عرض هذه المهام من 4 إلى 8 ساعات بحوالي 2 إلى 4 أضعاف العرض ، ولكنها ستقلل بشكل كبير من الجهود المبذولة لمثل هذه التغييرات في المستقبل. إذا كان هذا الجزء من قاعدة الشفرة أكثر نظافة ولديه تغطية جيدة مع الاختبارات التلقائية ، فسيتمكّن مطور خبير متمرس من إكماله في غضون ساعة أو أقل. والنقطة الأساسية هي أن المطور الجديد سيستغرق المزيد من الوقت.
لمثل هذا التغيير في الشروط ، نحتاج إلى موافقتك. هذه محاولة واعية لتحسين أداء نظامك بشكل أساسي ، وليس فقط كيف ينظر المستخدمون إليه. أنا أفهم أنه من الصعب الموافقة على هذه الاستثمارات على وجه التحديد لأنه لا توجد فائدة واضحة ، لكننا سعداء للجلوس معك وإعداد بعض الأرقام الواضحة التي ستوضح كيف ستؤتي هذه الاستثمارات ثمارها على المدى الطويل من وجهة نظر هندسية.
شكرا لك
البريد