كيف تجعل التعليمات البرمجية الخاصة بك أنظف

يقضي المطورون معظم الوقت في قراءة التعليمات البرمجية الحالية والحفاظ عليها. نحاول فهم ما يفعله وكيفية تغييره أو توسيعه. فلماذا التركيز فقط على الأداء؟

يجب أن تكون قابلية القراءة بنفس الأهمية عند إنشاء كود تدوم.

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

فائدة أخرى هي عندما تكون في موقع تأهيل مطورين جدد . يعتمد الإعداد الناجح على سهولة قراءة الكود الحالي.

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

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

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

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

المقروئية مهمة

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

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

ابدأ بالأساسيات . هذه هي الخطوات الأولى التي يمكنك اتخاذها لتحسين التعليمات البرمجية الخاصة بك وجعلها أكثر نظافة:

• استخدم أسماء ذات معنى
• تحسين الوظائف
• تفضل الثبات
• أفضِّل البرمجة التصريحية على الإلزامية
• أبقها بسيطة يا غبي - قبلة
• لا تكرر نفسك - جاف
• لن تحتاجه - YAGNI

استخدم أسماء ذات معنى

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

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

كود بدون أسماء ذات معنى

كود بأسماء ذات معنى

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

يجب أن تحتوي الفئات والكائنات على أسماء أو عبارات اسمية مثل أسمائها ، مثل customer أو htmlParser emailSender

ولكن ، أثناء اتباع هذه القاعدة ، حاول تجنب الأسماء التي تحتوي على أسماء عامة مثل data ، info ، manager ، processor ، ووحدة controller ... ، لأن هذه الأسماء في أغلب الأحيان لا توفر الكثير من المعنى.

لا يخبرك المصطلح العام بمجالها. يخبرك فقط بما يحتويه بأوسع معاني ممكن.

على سبيل المثال ، الكائن المسمى info أصعب بكثير من قراءة userInfo . أيضًا ، يمكن أن يكون لديك infos متعددة أو controllers أو managers في جميع أنحاء الكود ، لذلك من الأسهل اتباع منطق الكود عندما تكون هذه الأسماء مميزة للمجال.

يجب تسمية الطرق باستخدام أفعال أو عبارات فعلية مثل postPayment أو deletePage أو insert . من الجيد تجنب استخدام الأسماء المختصرة لأنها غالبًا ما تكون مربكة وبديهية فقط أثناء التطوير الأولي.

بدلاً من ذلك ، استخدم الأسماء القابلة للنطق . يسهل فهمها وحفظها أثناء قراءة الكود وفهمه.

الاسم السيئ بدون تعليق لا يعطي أي معنى:

اسم أفضل للتفسير الذاتي:

اختر مصطلحًا واحدًا لكل مفهوم والتزم به

من المربك أن يكون لديك عمليات fetch retrieve get طرق مكافئة لفئات مختلفة.

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

تحسين الوظائف

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

تعمل المسافات البادئة في الوظائف أيضًا على زيادة الاحتفاظ بالسياق . يجب أن يكون لديك تفسير جيد لسبب وجود مستويين (أو أكثر) من المسافة البادئة في دالة.

إذا أمكن ، استبدل كتل المسافة البادئة المتداخلة باستدعاءات الوظائف .

نسخة أقل مسافة بادئة من "حساب الراتب للموظفين" أعلاه:

لتحسين إمكانية القراءة ، يجب أن تقوم الوظيفة بشيء واحد فقط .

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

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

قدِّم مستويات متعددة من التجريد

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

يسهل فهم العديد من وظائف مستوى التجريد العالي مقارنةً ببعض الوظائف منخفضة المستوى. يجب أن تستند التجريدات إلى سلوك المجال .

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

تنظيم الوظائف بشكل هرمي حسب المستويات يجعل الكود يروي قصة سلوكية بدلاً من وصفة خطوة بخطوة.

يجب أن تحتوي الوظائف على أقل عدد ممكن من الحجج . نادرا ما يتم استخدام أكثر من 2.

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

غالبًا ما تكون حجج الإخراج غير متوقعة وغير طبيعية لذا تجنبها.

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

يجب أن تكون الوظيفة إما أمرًا ينفذ إجراءً (تأثير جانبي) ، أو استعلامًا يُرجع البيانات إلى المتصل ، ولكن ليس كليهما.

يجب التأكيد على "دورهم" من خلال الاسم. لا ينبغي أبدًا أن يكون هناك سوء فهم إذا كانت الوظيفة أمرًا أو استعلامًا باسمها.

مثال على اسم الأمر الذي يعدل وسائطه:

مثال على اسم الاستعلام الذي يستخرج القيم بدون تعديل حالة الوسيطات:

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

تفضل الثبات

ماذا يعني "الثبات" في الواقع في البرمجة؟

إنها خاصية تنص على أنه لا يمكن تعديل الكائن / المتغير بعد إنشائه بالكامل . التعليمات البرمجية غير القابلة للتغيير بدلاً من الحالة المتغيرة للكائن تنشئ نسخة مع حالة معدلة.

كود متغير:

نفس السلوك في التعليمات البرمجية الثابتة:

الثبات يجعل الكود أبسط وأسهل في المتابعة .

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

الكائنات غير القابلة للتغيير آمنة بطبيعتها ، مما يعني أنه ليست هناك حاجة لكتل ​​التزامن لأنك تعمل دائمًا مع حالة متسقة غير قابلة للتغيير.

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

أفضِّل البرمجة التصريحية على الإلزامية

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

توضح البرمجة الحتمية كيفية القيام بالأشياء . ينصب تركيزها على ميكانيكا خطوة بخطوة مثل العبارات الشرطية والحلقات والطفرات.

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

حاول تجريد كود الأمر إلى التصريحي .

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

السلوك أكثر وضوحًا في الأسلوب التعريفي كما هو موضح أدناه:

أبقها بسيطة يا غبي - قبلة

غالبًا ما يأتي المطورون بحلول " ذكية " لمشكلة معينة.

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

يجب أن تكون البساطة هدفًا رئيسيًا في التصميم . تجنب التعقيدات غير الضرورية.

لا تكرر نفسك - جاف

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

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

تصبح الصيانة بسهولة كابوسًا مع الكثير من التكرارات.

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

ولكن ، تمامًا كما تعلمنا كأطفال ، بعد وقت اللعب ، حان وقت التنظيف. خدم هؤلاء المكررون غرضهم. حان الوقت الآن لإزالتها.

لن تحتاجه - YAGNI

لا تنفذ شيئًا "قد" تحتاجه في المستقبل ، نفذ فقط ما تحتاجه . ما "قد" نحتاجه في كثير من الأحيان ليس شيئًا نحتاجه بالفعل لاحقًا.

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

الخطوات التالية

الخطوات التالية التي يمكنك اتخاذها لتحسين مبادئ SOLID .

هي خمسة مبادئ تصميم تهدف إلى جعل تصميمات البرامج أكثر قابلية للفهم ومرونة وقابلية للصيانة :

1. مبدأ المسؤولية الفردية - SRP
2. مبدأ مفتوح - OCP
3. مبدأ استبدال Liskov - LSP
4. مبدأ فصل الواجهة - ISP
5. مبدأ انعكاس التبعية - DIP

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

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

عند الحديث عن الأعضاء الجدد ، تحقق من منصبنا المفتوح لمطور Java الأول أو أي وظائف شاغرة أخرى في صفحة الوظائف لدينا.