لقد انتهيت مؤخرًا من قراءة كتاب "فلسفة تصميم البرمجيات" وفي الفصل الثاني يستكشف موضوع تعقيد البرمجيات.
كتاب "فلسفة تصميم البرمجيات" يحدد التعقيد عمليا:
"التعقيد هو أي شيء متعلق ببنية نظام برمجي يجعل من الصعب فهمه وتعديله."
بمعنى آخر، يمكن أن يتخذ التعقيد أشكالًا عديدة، وليس من الضروري أن يكون له أي علاقة بالأداء، يمكن أن تكون التعليمات البرمجية الخاصة بك فعالة وتظل معقدة
أود مشاركة بعض التعريفات والأفكار الأساسية من الكتاب في هذه المقالة. لكن أولاً، دعونا نتخيل موقفًا شائعًا ربما مررت به بالفعل...
دعونا نتعمق في قصة الرعب التي ربما مر بها أو سيختبرها العديد منكم.
لقد بدأ الأمر باستخدام تطبيق بسيط لإدارة مهام CRUD. كان الكود نظيفًا ومعياريًا وسهل الصيانة. كان فريق التطوير سعيدًا، وعمل النظام بشكل مثالي مع العملاء الأوائل.
بدأت المشاكل عندما باع فريق المبيعات النظام لشركة كبيرة، مدعيًا أنه يحتوي على تكامل التقويم وإشعارات البريد الإلكتروني ومولد تقارير مذهل. مع الانتهاء من عملية البيع، كان لا بد من تنفيذ هذه الميزات بسرعة.
تكامل التقويم: كان على الفريق التكامل مع تقويم Google وOutlook. قام مطورون مختلفون بتنفيذ الحلول، مما أدى إلى أساليب غير متسقة.
إشعارات البريد الإلكتروني: تمت إضافة إشعارات البريد الإلكتروني بعد ذلك. استخدم أحد المطورين مكتبة معينة، بينما أنشأ آخر حلاً مخصصًا. جعلت الأساليب المختلطة الكود مربكًا.
منشئ التقارير: بالنسبة لمولد التقارير، استخدم المطورون تقنيات مختلفة: ملفات PDF، وصادرات Excel، ولوحات المعلومات التفاعلية. عدم وجود نهج موحد جعل الصيانة كابوسا.
التعقيد المتزايد: تم تطوير كل ميزة بشكل منفصل وبسرعة، مما يؤدي إلى التبعيات بين الميزات. بدأ المطورون في إنشاء "إصلاحات سريعة" لجعل كل شيء يعمل، مما زاد من تعقيد النظام واقترانه.
تطوير البرمجيات لا يحدث في الفراغ؛ وتؤثر فيه عوامل داخلية وخارجية مختلفة. لقد كنا جميعًا، أو سنكون، في مثل هذا الموقف.
ثم بدأت المشاكل:
من الواضح أن لدينا الآن نظامًا معقدًا.
الآن دعونا "نحلل" هذا التعقيد لتسهيل التعرف عليه والتخفيف منه.
حسنًا، "التخفيف" يعني:
"لتخفيف حدة أو خطورة أو ألمًا؛ للتخفيف."
أعتقد أن التعقيد غالبًا ما يكون متأصلًا في الكود. بعض الأشياء معقدة بطبيعتها. إن دورك كمطور لا يقتصر فقط على إنشاء تعليمات برمجية يمكن للكمبيوتر تنفيذها بكفاءة، ولكن أيضًا إنشاء تعليمات برمجية يمكن للمطورين المستقبليين (بما في ذلك نفسك في المستقبل) العمل معها.
"التحكم في التعقيد هو جوهر برمجة الكمبيوتر."
— بريان كيرنيغان
يشير مؤلف الكتاب المذكور إلى أن التعقيد يظهر عادة في ثلاث طرق، سنستكشفها هنا.
يحدث تضخيم التغيير عندما يتطلب تغيير يبدو بسيطًا تعديلات في العديد من الأماكن المختلفة.
على سبيل المثال، إذا طلب مالك المنتج حقل "الأولوية" أو "تاريخ الانتهاء" وكانت كياناتك مقترنة بإحكام، فما عدد التغييرات التي ستحتاج إلى إجرائها؟
يشير الحمل المعرفي إلى مقدار المعرفة والوقت الذي يحتاجه المطور لإكمال المهمة.
لذا تخيل هذا السيناريو: انضم مطور جديد إلى الفريق، وتم تكليفه بإصلاح خطأ في منشئ التقارير. لإكمال هذه المهمة، يحتاج المطور إلى:
إنه السيناريو الكلاسيكي "من المستحيل تقديره"، حيث يمكن أن تستغرق المهمة نقطة واحدة أو ثماني نقاط - من الأفضل أن تستخدم D20 وتستجيب وفقًا لذلك.
المجهول المجهول هو عندما لا تعرف ما لا تعرفه.
هذا هو أسوأ مظهر من مظاهر التعقيد لأنك قد تغير أشياء لا ينبغي عليك تغييرها، مما يتسبب في انهيار كل شيء.
مثال: قام أحد المطورين بتعديل رمز إرسال البريد الإلكتروني لإضافة إشعار جديد، غير مدرك أنه سيؤثر على منشئ التقارير، الذي يعتمد على هذه الوظيفة. وقد تسبب هذا في مشكلات كبيرة للعملاء، وهو ما يمثل أسوأ أشكال التعقيد الناشئ.
بعد أن شاهدنا قصة الرعب والأعراض الثلاثة الرئيسية، دعونا ننظر إلى أسباب التعقيد.
التبعيات ضرورية في البرامج ولا يمكن التخلص منها بالكامل. أنها تسمح لأجزاء مختلفة من النظام بالتفاعل والعمل معًا. ومع ذلك، فإن التبعيات، عندما لا تتم إدارتها بشكل صحيح، يمكن أن تزيد من التعقيد بشكل كبير.
توجد التبعية عندما لا يمكن فهم التعليمات البرمجية أو تعديلها بشكل منفصل، مما يتطلب النظر في التعليمات البرمجية ذات الصلة أو تعديلها.
يحدث الغموض عندما تكون المعلومات المهمة غير واضحة. قد يؤدي ذلك إلى صعوبة فهم قاعدة التعليمات البرمجية، مما يؤدي إلى زيادة الحمل المعرفي وخطر المجهول.
يحدث الغموض عندما تكون المعلومات المهمة غير واضحة.
نظرًا لأنه تدريجي، فمن السهل التفكير، "فقط هذه المرة، لن يكون الأمر مهمًا." ولكن عندما تتراكم، فإن إصلاح واحد أو اثنين من التبعيات وحده لن يحدث فرقًا كبيرًا.
"كل شيء عبارة عن مقايضة في هندسة البرمجيات."
- لا أتذكر المؤلف
يمكنني كتابة الكثير من القواعد والاستراتيجيات والأطر التي ربما رأيتها بالفعل على الإنترنت حول كيفية تجنب التعقيد: SOLID، وأنماط التصميم، وYAGNI، وKISS، وما إلى ذلك.
ومع ذلك، يمكنك توحيدها جميعًا في مبدأ توجيهي واحد (كما هو مذكور في "المبرمج العملي."): "هل ما أقوم بتنفيذه سهل التغيير؟" إذا كانت الإجابة لا، إذن ربما كنت تزيد من التعقيد.
يؤدي التأكد من سهولة تغيير التعليمات البرمجية إلى تبسيط عملية الصيانة، وتقليل الحمل المعرفي على المطورين، ويجعل النظام أكثر قدرة على التكيف وأقل عرضة للأخطاء.
شكرًا لك!
تنصل: جميع الموارد المقدمة هي جزئيًا من الإنترنت. إذا كان هناك أي انتهاك لحقوق الطبع والنشر الخاصة بك أو الحقوق والمصالح الأخرى، فيرجى توضيح الأسباب التفصيلية وتقديم دليل على حقوق الطبع والنشر أو الحقوق والمصالح ثم إرسالها إلى البريد الإلكتروني: [email protected]. سوف نتعامل مع الأمر لك في أقرب وقت ممكن.
Copyright© 2022 湘ICP备2022001581号-3