التخطيط مقابل الاختبار – تطوير البرمجيات

رشيقة، سكروم، كلمات فاخرة لكتابة البرامج التي تقدم

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

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

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

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

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

على أي حال، لقد بدأت للتو الحصول على الدبلوم لمساعدتي في فهم سبب أهمية استخدام العديد من استراتيجيات التخطيط المختلفة. لماذا أكتب في يوم واحد ما يمكنني قضاء شهر في القيام به "بشكل صحيح"؟ أعلم أنني سأقرأ هذا مرة أخرى في غضون عامين وأتساءل عما كنت أفكر فيه؛ إما ذلك أو سأقول لنفسي "واو، هذا هو الوقت الذي كنت أنهي فيه ما كنت أكتبه". على الرغم من ذلك، على محمل الجد، أنا متأكد من أنه في نهاية الأمر سأدرك أين أخطأت، وفي هذه الأثناء سأستمر في كتابة التطبيقات باستخدام أسلوب RAD الخاص بي (أنا سعيد لأنه يحتوي على اسم!) على الرغم من أنه لا يناسب ذوق الجميع، إلا أنه يعمل بشكل جيد بالنسبة لي.

ملحوظة: من كان يظن أن أسلوبي في التطوير له اسم، وقد تم تصنيفه على أنه منهجية رشيقة! هنا مقالة ممتازة تشرح منهجيات رشيقة بشيء من التفصيل.