"إذا أراد العامل أن يؤدي عمله بشكل جيد، فعليه أولاً أن يشحذ أدواته." - كونفوشيوس، "مختارات كونفوشيوس. لو لينجونج"
الصفحة الأمامية > برمجة > المعركة التي لا تنتهي ضد تعقيد البرمجيات

المعركة التي لا تنتهي ضد تعقيد البرمجيات

تم النشر بتاريخ 2024-08-18
تصفح:934

The Never Ending Battle Against Software Complexity

ما هو التعقيد؟

لقد انتهيت مؤخرًا من قراءة كتاب "فلسفة تصميم البرمجيات" وفي الفصل الثاني يستكشف موضوع تعقيد البرمجيات. 

كتاب "فلسفة تصميم البرمجيات" يحدد التعقيد عمليا:

"التعقيد هو أي شيء متعلق ببنية نظام برمجي يجعل من الصعب فهمه وتعديله."

بمعنى آخر، يمكن أن يتخذ التعقيد أشكالًا عديدة، وليس من الضروري أن يكون له أي علاقة بالأداء، يمكن أن تكون التعليمات البرمجية الخاصة بك فعالة وتظل معقدة

أود مشاركة بعض التعريفات والأفكار الأساسية من الكتاب في هذه المقالة. لكن أولاً، دعونا نتخيل موقفًا شائعًا ربما مررت به بالفعل...


قصة رعب قصيرة

دعونا نتعمق في قصة الرعب التي ربما مر بها أو سيختبرها العديد منكم.

  1. لقد بدأ الأمر باستخدام تطبيق بسيط لإدارة مهام CRUD. كان الكود نظيفًا ومعياريًا وسهل الصيانة. كان فريق التطوير سعيدًا، وعمل النظام بشكل مثالي مع العملاء الأوائل.

  2. بدأت المشاكل عندما باع فريق المبيعات النظام لشركة كبيرة، مدعيًا أنه يحتوي على تكامل التقويم وإشعارات البريد الإلكتروني ومولد تقارير مذهل. مع الانتهاء من عملية البيع، كان لا بد من تنفيذ هذه الميزات بسرعة.

  3. تكامل التقويم: كان على الفريق التكامل مع تقويم Google وOutlook. قام مطورون مختلفون بتنفيذ الحلول، مما أدى إلى أساليب غير متسقة.

  4. إشعارات البريد الإلكتروني: تمت إضافة إشعارات البريد الإلكتروني بعد ذلك. استخدم أحد المطورين مكتبة معينة، بينما أنشأ آخر حلاً مخصصًا. جعلت الأساليب المختلطة الكود مربكًا.

  5. منشئ التقارير: بالنسبة لمولد التقارير، استخدم المطورون تقنيات مختلفة: ملفات PDF، وصادرات Excel، ولوحات المعلومات التفاعلية. عدم وجود نهج موحد جعل الصيانة كابوسا.

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

تطوير البرمجيات لا يحدث في الفراغ؛ وتؤثر فيه عوامل داخلية وخارجية مختلفة. لقد كنا جميعًا، أو سنكون، في مثل هذا الموقف.


بداية النهاية

ثم بدأت المشاكل:

  1. التغيرات في جزء واحد من النظام أثرت على الأجزاء الأخرى بشكل غير متوقع.
  2. تتطلب التغييرات الصغيرة تعديلات في العديد من الملفات الأخرى، مما يجعل التقديرات صعبة.
  3. شهرًا بعد شهر، أصبح من الصعب فهم الكود، وغالبًا ما يتم إصلاحه من خلال التجربة والخطأ.
  4. انخفضت الإنتاجية، وأصبح الجميع يخشون مهام الصيانة.
  5. الدعوة الحتمية لـ "نحن بحاجة إلى إعادة البناء".
  6. لا يمكن التعامل مع بعض المهام إلا بواسطة مطورين محددين (كلاسيكي)
  7. بمرور الوقت، أصبحت البرامج المكتوبة بشكل جميل والموثقة جيدًا بمثابة حطام قطار.

تسمية الأعراض

من الواضح أن لدينا الآن نظامًا معقدًا.

الآن دعونا "نحلل" هذا التعقيد لتسهيل التعرف عليه والتخفيف منه.

حسنًا، "التخفيف" يعني:

"لتخفيف حدة أو خطورة أو ألمًا؛ للتخفيف."

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

"التحكم في التعقيد هو جوهر برمجة الكمبيوتر."

— بريان كيرنيغان

يشير مؤلف الكتاب المذكور إلى أن التعقيد يظهر عادة في ثلاث طرق، سنستكشفها هنا.

تغيير التضخيم

يحدث تضخيم التغيير عندما يتطلب تغيير يبدو بسيطًا تعديلات في العديد من الأماكن المختلفة.

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

الحمل المعرفي

يشير الحمل المعرفي إلى مقدار المعرفة والوقت الذي يحتاجه المطور لإكمال المهمة.

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

  • فهم عمليات تكامل التقويم المختلفة (Google وOutlook).
  • فهم الأساليب المتميزة لإشعارات البريد الإلكتروني.
  • التنقل عبر التعليمات البرمجية المجزأة لمنشئ التقارير، والتعامل مع ملفات PDF وExcel ولوحات المعلومات.
  • ادمج هذه التقنيات والأساليب المتنوعة للعثور على الخطأ وإصلاحه.

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

مجهول مجهول

المجهول المجهول هو عندما لا تعرف ما لا تعرفه.

هذا هو أسوأ مظهر من مظاهر التعقيد لأنك قد تغير أشياء لا ينبغي عليك تغييرها، مما يتسبب في انهيار كل شيء.

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

أسباب التعقيد

بعد أن شاهدنا قصة الرعب والأعراض الثلاثة الرئيسية، دعونا ننظر إلى أسباب التعقيد.

1. التبعيات

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

تعريف:

توجد التبعية عندما لا يمكن فهم التعليمات البرمجية أو تعديلها بشكل منفصل، مما يتطلب النظر في التعليمات البرمجية ذات الصلة أو تعديلها.

أنواع التبعيات:

  • مباشر: الوحدة أ تعتمد بشكل مباشر على الوحدة ب.
  • متعدية: الوحدة أ تعتمد على الوحدة ب، والتي تعتمد على الوحدة ج.
  • دورية: الوحدات A وB وC مترابطة بشكل دائري.

2. الغموض

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

تعريف:

يحدث الغموض عندما تكون المعلومات المهمة غير واضحة.

أمثلة على الغموض:

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

تذكر: التعقيد تدريجي

  • نادرا ما يحدث التعقيد بسبب "خطأ" واحد أو قرار سيء.
  • يتراكم التعقيد "ببطء" من خلال القرارات والتبعيات السيئة مع مرور الوقت.

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

"كل شيء عبارة عن مقايضة في هندسة البرمجيات."
- لا أتذكر المؤلف

خاتمة

يمكنني كتابة الكثير من القواعد والاستراتيجيات والأطر التي ربما رأيتها بالفعل على الإنترنت حول كيفية تجنب التعقيد: SOLID، وأنماط التصميم، وYAGNI، وKISS، وما إلى ذلك.

ومع ذلك، يمكنك توحيدها جميعًا في مبدأ توجيهي واحد (كما هو مذكور في "المبرمج العملي."): "هل ما أقوم بتنفيذه سهل التغيير؟" إذا كانت الإجابة لا، إذن ربما كنت تزيد من التعقيد.

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

شكرًا لك!

بيان الافراج تم نشر هذه المقالة على: https://dev.to/juniorklawa/the-never-ending-battle-against-software-complexity-46k1?1 إذا كان هناك أي انتهاك، يرجى الاتصال بـ [email protected] لحذفه
أحدث البرنامج التعليمي أكثر>

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

Copyright© 2022 湘ICP备2022001581号-3