أفضل ممارسات البرمجة

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

يُعدّ نموذج الشلال منهجًا تطويريًا تسلسليًا؛ إذ يفترض تحديدًا إمكانية تحديد المتطلبات بشكل كامل في بداية المشروع. مع ذلك، يستشهد ماكونيل بثلاث دراسات تُشير إلى أن المتطلبات تتغير، في المتوسط، بنحو 25% خلال المشروع. ^{[ 10 ]} وتسعى المنهجيات الأخرى المذكورة أعلاه إلى تقليل تأثير هذه التغييرات في المتطلبات، غالبًا من خلال اتباع نهج تدريجي أو تراكمي أو تكراري. وقد تكون منهجيات مختلفة مناسبة لبيئات تطوير مختلفة.

منذ ظهورها في عام 2001، ازدادت شعبية تطوير البرمجيات الرشيقة، مدفوعةً برغبة مطوري البرمجيات في اتباع نهج أكثر تكرارية وتعاونية في تطوير البرمجيات. ^{[ 11 ]}

يقول ماكونيل: "إن أول شرط أساسي يجب عليك استيفاؤه قبل البدء في البناء هو بيان واضح للمشكلة التي من المفترض أن يحلها النظام." ^{[ 12 ]}

يؤكد ميك وهيث على أن الهدف المنشود هو وضع مواصفات مكتوبة واضحة وكاملة ودقيقة لا لبس فيها. ^{[ 13 ]} تجدر الإشارة إلى أنه قد لا يكون من الممكن تحقيق هذا الهدف، ومن المرجح أن يتغير الهدف على أي حال (كما ذكر في القسم السابق).

يميز سومرفيل بين متطلبات المستخدم الأقل تفصيلاً ومتطلبات النظام الأكثر تفصيلاً. ^{[ 14 ]} كما يميز بين المتطلبات الوظيفية (مثل تحديث سجل) والمتطلبات غير الوظيفية (مثل أن يكون وقت الاستجابة أقل من ثانية واحدة).

يشير هوار إلى: "هناك طريقتان لتصميم البرمجيات: الأولى هي جعلها بسيطة للغاية بحيث لا تظهر عليها أي عيوب واضحة ؛ والأخرى هي جعلها معقدة للغاية بحيث لا تظهر عليها أي عيوب واضحة . الطريقة الأولى أصعب بكثير." ^{[ 15 ]} (التشديد كما في النص الأصلي).

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

يجب مراعاة أي متطلبات نظام غير وظيفية (وقت الاستجابة، الموثوقية، قابلية الصيانة، إلخ) في هذه المرحلة. ^{[ 16 ]}

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

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

يقول ماير: "لا توجد لغة برمجة مثالية. بل لا توجد لغة واحدة هي الأفضل؛ إنما توجد لغات مناسبة أو ربما غير مناسبة لأغراض معينة. إن فهم المشكلة ومتطلبات البرمجة المرتبطة بها ضروري لاختيار اللغة الأنسب للحل." ^{[ 17 ]}

يقول ميك وهيث: "يكمن جوهر فن اختيار لغة البرمجة في البدء بالمشكلة، وتحديد متطلباتها، وأهميتها النسبية، إذ من المحتمل أن يكون من المستحيل تلبيتها جميعًا بنفس القدر من الكفاءة. بعد ذلك، ينبغي تقييم اللغات المتاحة وفقًا لقائمة المتطلبات، واختيار اللغة الأنسب (أو الأقل إثارةً للمشاكل)." ^{[ 18 ]}

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

حتى في حال عدم وجود خيار بشأن لغة البرمجة التي سيتم استخدامها، يقدم ماكونيل بعض النصائح: "لكل لغة برمجة نقاط قوة وضعف. كن على دراية بنقاط القوة والضعف الخاصة باللغة التي تستخدمها." ^{[ 19 ]}

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

في الأيام الأولى للحوسبة، كانت إحدى ممارسات التعليق هي ترك وصف موجز لما يلي:

1. اسم الوحدة
2. الغرض من الوحدة
3. وصف الوحدة
4. المؤلف الأصلي
5. التعديلات
6. المؤلفون الذين قاموا بتعديل الكود مع وصف لسبب تعديله.

ينبغي أن يكون "وصف الوحدة" موجزًا ​​قدر الإمكان ولكن دون التضحية بالوضوح والشمولية.

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

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

يمكن أن يكون اختبار الوحدة طريقة أخرى لإظهار كيفية استخدام الكود المقصود.

يُعتبر استخدام اصطلاحات التسمية الصحيحة ممارسة جيدة. أحيانًا يميل المبرمجون إلى استخدام X1 و Y1 وما إلى ذلك كمتغيرات وينسون استبدالها بمتغيرات ذات دلالة، مما يُسبب ارتباكًا.

يُعتبر استخدام الأسماء الوصفية ممارسة جيدة في العادة.

مثال: يمكن تسمية متغير لأخذ الوزن كمعامل للشاحنة TrkWeight أو TruckWeightKilograms أو Truck_Weight_Kilograms، وغالبًا ما يكون TruckWeightKilograms (انظر تسمية المتغيرات في Pascal case ) هو المفضل لأنه يمكن التعرف عليه على الفور، ولكن اصطلاح التسمية ليس دائمًا متسقًا بين المشاريع و/أو الشركات.

ينبغي أن يكون الكود الذي يكتبه المبرمج بسيطًا. يجب تقليل المنطق المعقد لتحقيق أمر بسيط إلى أدنى حد، لأن الكود قد يُعدَّل من قِبل مبرمج آخر في المستقبل. قد لا يكون المنطق الذي طبّقه مبرمج ما منطقيًا تمامًا لمبرمج آخر. لذا، احرص دائمًا على أن يكون الكود بسيطًا قدر الإمكان. ^{[ 21 ]}

يجب ألا يحتوي كود البرنامج على قيم ثابتة (حرفية) تشير إلى معلمات بيئية، مثل مسارات الملفات المطلقة، وأسماء الملفات، وأسماء المستخدمين، وأسماء المضيفين، وعناوين IP، وعناوين URL، ومنافذ UDP/TCP. وإلا، فلن يعمل التطبيق على مضيف ذي تصميم مختلف عن المتوقع. يمكن للمبرمج الماهر تحديد معلمات هذه المتغيرات وتهيئتها لبيئة الاستضافة خارج التطبيق نفسه (على سبيل المثال، في ملفات الخصائص، أو على خادم التطبيقات ، أو حتى في قاعدة البيانات). قارن ذلك بمبدأ "نقطة تعريف واحدة" ^{[ 22 ]} (SPOD).

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

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

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

نظرة عامة على كل ما سبق:

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

تتضمن أفضل الممارسات لبناء التعليمات البرمجية عمليات بناء واختبار يومية، أو الأفضل من ذلك التكامل المستمر ، أو حتى التسليم المستمر .

يُعدّ الاختبار جزءًا لا يتجزأ من تطوير البرمجيات، ويتطلب تخطيطًا مسبقًا. ومن المهم أيضًا أن يتم الاختبار بشكل استباقي؛ أي أن تُخطط حالات الاختبار قبل بدء كتابة الكود، وأن تُطوّر حالات الاختبار أثناء تصميم التطبيق وكتابة الكود.

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

يُعدّ النشر المرحلة الأخيرة من إطلاق التطبيق للمستخدمين. ومن أفضل الممارسات في هذا الصدد: ^{[ 23 ] [ 24 ]}

1. اجعل بنية التثبيت بسيطة: قلل عدد الملفات والمجلدات إلى الحد الأدنى. لا تقم بتثبيت أي شيء لن تستخدمه أبدًا.
2. احتفظ فقط بما هو ضروري: يجب أن تضمن أنشطة إدارة تكوين البرامج تطبيق هذا المبدأ. يجب أرشفة الموارد غير المستخدمة (الإصدارات القديمة أو المعطوبة من الملفات، وشفرة المصدر، والواجهات، وما إلى ذلك) في مكان آخر للحفاظ على بساطة الإصدارات الأحدث.
3. حافظ على تحديث كل شيء: يجب أن تضمن أنشطة إدارة تكوين البرامج تطبيق هذا الإجراء. بالنسبة لعمليات النشر القائمة على التحديثات التفاضلية، تأكد من أن إصدارات الموارد المنشورة حاليًا هي الأحدث قبل نشر التحديثات التفاضلية. إذا لم تكن متأكدًا، فقم بعملية نشر من البداية (احذف كل شيء أولًا ثم أعد النشر).
4. اعتمد استراتيجية متعددة المراحل: اعتمادًا على حجم المشروع، قد تكون هناك حاجة إلى المزيد من عمليات النشر. ^{[ 25 ]}
5. يجب أن تكون هناك استراتيجية للتراجع: يجب أن تكون هناك طريقة للتراجع إلى إصدار سابق (يعمل).
6. اعتمد على الأتمتة في العمليات المتكررة: فمجال الخطأ البشري واسع للغاية، لذا يجب تجنب العمليات اليدوية. استخدم أداةً مدمجةً في كل نظام تشغيل، أو استخدم لغة برمجة نصية لعمليات النشر عبر المنصات. ^{[ 26 ] [ 27 ]}
7. أعد إنشاء بيئة النشر الحقيقية: ضع في اعتبارك كل شيء (أجهزة التوجيه، وجدران الحماية، وخوادم الويب، ومتصفحات الويب، وأنظمة الملفات، وما إلى ذلك).
8. لا تقم بتغيير إجراءات النشر والبرامج النصية أثناء التنفيذ، وقم بتوثيق هذه التغييرات: انتظر حتى يتم إصدار نسخة جديدة وسجل هذه التغييرات بشكل مناسب.
9. تخصيص عملية النشر: تتطلب منتجات البرمجيات الحديثة، مثل واجهات برمجة التطبيقات والخدمات المصغرة، اعتبارات محددة لضمان نجاح عملية النشر. ^{[ 28 ] [ 29 ] [ 30 ]}
10. تقليل المخاطر من مراحل التطوير الأخرى: إذا كانت الأنشطة الأخرى مثل الاختبار وإدارة التكوين خاطئة، فمن المؤكد أن عملية النشر ستفشل. ^{[ 31 ] [ 32 ]}
11. ضع في اعتبارك تأثير كل جهة معنية: الاعتبارات التنظيمية والاجتماعية والحكومية. ^{[ 33 ] [ 34 ] [ 35 ]}