كتابة التعليمات البرمجية القابلة لإعادة التدوير

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

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

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

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

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

1. تصبح سيد التنظيم

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

2. كن على دراية بما هو "تطبيق محدد" وما هو "عام"

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

3. افصل الكود عن القيم

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

4. حاول ألا ترميز أي قيم ليست بالضرورة مطلقة

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

5. تجنب وضع مسافات في أسماء الملفات

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

5. التعليق كل شيء لفظي

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

6. تجنب خلق التبعيات

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

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

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

7. تنسيق جميع التعليمات البرمجية الخاصة بك حقا بدقة

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

8. كل جزء من الكود له هدف محدد

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

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

رأس الصورة مجاملة من DKNG

بوجدان رانسيا

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