كيف تبدأ كتابة كود عالي الجودة في أي نقطة من رحلة البرمجة الخاصة بك

صورة الائتمان: مختبر مجنون

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

دعونا نلقي نظرة على بعض هذه السمات بتفاصيل أكثر قليلاً:

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

من الآمن أن نقول عندئذٍ ، أن الاقتران الفضفاض سيؤدي إلى إعادة استخدام أكبر للشفرة وسهولة صيانة أكبر.

  • قراءة
    شفرة قابلة للقراءة - يدعي كل مبرمج أن التعليمات البرمجية الخاصة به سهلة القراءة للغاية ، لكن من الواضح أن هذا ليس هو الحال. ما هو ، رمز قابل للقراءة بعد ذلك؟ قبل أن نحدد ما هو ، ربما السؤال الأكثر أهمية هو ، لماذا أهمية القراءة على أي حال؟ عندما تبدأ العمل في مشاريع أكبر ، ستجد أن قاعدة كودك تنمو بمئات الأسطر يوميًا ، مما يعني أنه في غضون أسابيع قليلة قد تكون قد نسيت المنطق وراء القرارات التي اتخذتها. وبالمثل ، سيجد الأشخاص الآخرون الذين يعرضون الشفرة أنه من المستحيل فهم الشفرة إذا لم تكن قابلة للقراءة. نأمل أن تتمكن من البدء في معرفة كيف أن وجود كود غير قابل للقراءة قد يجعل الصيانة كابوسًا.
    الآن ، يمكننا تعريف الشفرة المقروءة على أنها سهلة الفهم أو المتابعة المنطقية. هناك الكثير من الأشياء التي يمكنك القيام بها لجعل الكود أكثر قابلية للقراءة ، ويمكنك العثور على العديد منها هنا ولكن بشكل عام ،
    - تعليق الكود الخاص بك ،
    - متغيرات الاسم (مؤقتة وغير ذلك) بشكل ثابت وصفي ،
    - تجنب سطور طويلة للغاية من الكود (> 120 حرفًا)
    - مجموعات رمز النموذج
    - جاف (لا تكرر نفسك): إذا وجدت نفسك رمز النسخ واللصق ، توقف و فكر طويلاً و صعبًا - ربما تقوم بشيء خاطئ
    - YAGNI (لن تحتاجها): تجنب كتابة الكود الذي لا يعتاد لأنه سيؤدي إلى حدوث ارتباك في الطريق
    - استخدام التعشيش بشكل ضئيل و
    - استخدم المسافات المناسبة و / أو المسافة البادئة (نعم ، يمكن أن تكون المسافة البيضاء جميلة) ويجب أن تكون في طريقك لإبداع الفن!

أريد أن أكتب كود الجودة ... ماذا أحتاج أن أفعل؟

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

اعتماد اختبار التنمية مدفوعة (TDD)

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

على سبيل المثال ، إذا طُلب منك كتابة رمز لآلة حاسبة تضيف رقمين وترجع مجموعهما ؛ هناك طريقتان للتعامل مع هذه المهمة:

أمثلة لمتابعة في بيثون

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

2. لذا ، فإن الكود الخاص بنا من النهج 1 يعمل بشكل جيد ، حيث يُرجع المجموع 6 و 9 إلى 15 ... لا نحتاج إلى اختبار تطوير ، أليس كذلك؟ خطأ! دعنا نفكر في النهج القائم على الاختبار لفترة ثانية ...

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

  • مرت سلسلتين كحجج لوظيفة لدينا؟
  • مرت عدد صحيح وسلسلة لوظائفنا؟

بعد ذلك ، نكتب اختبارات لهذه السيناريوهات التي من غير المرجح أن تحدث في نهاية العالم ، مثل:

دعونا الآن نلقي نظرة على الشكل الذي سيبدو عليه رمز الآلة الحاسبة إذا تمت كتابته مع مراعاة الاختبارات أعلاه:

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

في نواح كثيرة ، يستعير TDD من قانون مورفي:

أي شيء يمكن أن تذهب الخطأ، وسوف تذهب الخطأ

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

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

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

يمكنك قراءة المزيد حول البدء باستخدام TDD هنا وكذلك مقالتي هنا.

استخدام أدوات مراجعة الكود الآلي

لقد تحدثنا باستفاضة عن العديد من الأشياء التي تُعتبر الكود عالي الجودة ، وربما في يوم من الأيام ، ستفهم بعمق جميع جوانب جودة الكود - حتى أنك قد تكتسب القدرة على تحليل النصوص البرمجية للمبرمجين الآخرين بسرعة نشير إلى القضايا والإصلاحات للقضايا المذكورة. حتى يأتي ذلك اليوم ، أوصي (بشدة) أن تدمج استخدام أدوات مراجعة الشفرة الآلية في سير عملك.

أحب أن أفكر في أدوات مراجعة التعليمات البرمجية كحراس ؛ يراقبونك وأنت تكتب الرمز الخاص بك وفي كثير من الأحيان (قبل و / أو بعد الالتزام ، اعتمادا على أداة معينة) ، وسيقومون بإعلامك كيف يمكنك تحسين التعليمات البرمجية الخاصة بك. هناك العديد من أدوات مراجعة التعليمات البرمجية هناك ويمكنك مشاهدة قائمة هنا ؛ لقد قمت شخصياً بتجربة استخدام Codacy و Code Climate حتى هذه النقطة. مناخ الترميز والشفرة مجانيان للاستخدام مع repos github مفتوح المصدر - يتم دفع رسوم إعادة شراء خاصة. لقد كنت سعيدًا باستخدام Codacy ، لكنني جديد تمامًا في سير العمل هذا ، لذلك ، حيث أنني أتعلم المزيد عن الأدوات المختلفة ، فقد أقوم بإجراء تغيير أو قد لا أقوم بتغييره.

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

بعد المراجعة ، يتم نشر النتائج على لوحة معلومات جميلة تسليط الضوء على أهم جوانب التعليمات البرمجية الخاصة بك.

لقطة شاشة للوحة معلومات مشروع Codacy

تحليل النتائج
تكشف مراجعة الشفرة عن الكثير من الأشياء حول الكود - الجيد والسيئ والقبيح على حد سواء. ستدرك أن السعي إلى كتابة تعليمات برمجية أفضل يستدعي الاستعداد لمواجهة أوجه القصور في عملك باستمرار حتى تتمكن من تحسينها.

من لوحات المعلومات الواردة أعلاه ، أول ما نراه هو أن هذا المشروع بالذات مُنح درجة B - وهو أمر غير سيئ على الإطلاق كنقطة انطلاق.

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

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

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

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

وجهة نظر موسعة لمشكلة معينة

استفد من أدوات التكامل المستمر (CI)

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

سأكتب مقالًا آخر حول تحسين جودة قاعدة الشفرة الخاصة بك كفريق يستخدم أدوات / بناء الخوادم CI مثل Travis CI و Jenkins. احترس من ذلك.

التكامل المستمر (CI) هو ممارسة تطوير تتطلب من المطورين دمج الكود في مستودع مشترك عدة مرات في اليوم. بعد ذلك يتم التحقق من كل عملية تسجيل وصول بواسطة بنية آلية ، مما يسمح للفرق باكتشاف المشكلات في وقت مبكر.
لوحة معلومات مشروع Travis CI

دعنا نختتم هذا

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

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

إخلاء المسئولية: أنا لست خبيرا (ليس على الأقل حتى الآن) ، مجرد رجل يوثق رحلته التعليمية