كيفية كتابة كود نظيف

يعد جعل التعليمات البرمجية الخاصة بك نظيفة وجميلة طريقة رائعة للوفاء بالمواعيد النهائية. ضرب روبرت مارتن المسمار في رأسه بأحد عباراته البليغة: "المقياس الحقيقي الوحيد لجودة التعليمات البرمجية هو وحدة What-The-F**ks/Minute" ." " في الأصل). اسمحوا لي أن أشرح ماذا يعني هذا. في كل مرة أقوم فيها بمراجعة الكود، يمر ذهني بواحدة من ثلاث مشاعر:

• "ماهذا الهراء؟! ي للرعونة؟!" (باشمئزاز) - هذا ليس كل شيء سيء للغاية....
• "ماهذا الهراء؟! ي للرعونة؟!" (بإعجاب) - حسنًا، لقد فعلها رجل ذكي!
• "ماهذا الهراء؟! ي للرعونة؟!" (بغضب) - نوع من الارتباك، ما الذي نتحدث عنه أصلاً؟!

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

ما في الاسم

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

"وظيفة واحدة" شيء واحد

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

1. يجب أن تكون صغيرة
2. يجب عليهم أن يفعلوا شيئًا واحدًا، ومهمة واحدة، وأن يفعلوا ذلك جيدًا

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

"التعليقات لا تعوض عن الكود السيئ"

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

"تنسيق التعليمات البرمجية هو دائمًا أولوية"

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

قم أولاً بإنشاء كتلة "محاولة الالتقاط أخيرًا".

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

دعونا نلخص ذلك

ستساعدنا عبارة واحدة غير عادية في تلخيص كل ما سبق. هذا هو حس الكود أو "الحس بالرمز العام"، وهو نوع من المعادل المبرمج للحس السليم. على حد تعبير روبرت مارتن: "إن كتابة تعليمات برمجية نظيفة تتطلب الاستخدام المنهجي للعديد من التقنيات الصغيرة، والتي يتم تطبيقها كنتيجة لشعور دقيق ومؤلم إلى حد ما بـ "النظافة". تُسمى هذه التقنيات الصغيرة مجتمعة باسم حس الكود . " البعض منا لديه هذا "الحس السليم" منذ البداية، بينما يتعين على الآخرين تطويره من خلال الممارسة المستمرة. لا تساعد هذه الغريزة على التعرف على الفرق بين الكود السيئ والجيد فحسب، بل تساعد أيضًا في تشكيل استراتيجيات تهدف إلى تحويل الكود السيئ إلى كود جيد. الكود السيئ يدمر كل شيء. إذا تحدثنا مجازيًا، إذا قمت بتجميد أشهى الكعكات ببراز الكلاب، فعندئذ... اه... من غير المرجح أن يحبها أي شخص. يساعد الإحساس بالرمز المبرمج على استخدام الأدوات المناسبة لتحقيق هدفه المتمثل في إنشاء تعليمات برمجية نظيفة. المبرمج الذي يفهم معنى حس الكود هو فنان يمكنه إنشاء عمل فني على شاشة فارغة سيتم تذكره لسنوات عديدة. وكما لخص هارولد "هال" أبيلسون، أستاذ علوم الكمبيوتر في معهد ماساتشوستس للتكنولوجيا والمدير المؤسس لمؤسسة المشاع الإبداعي ومؤسسة البرمجيات الحرة، الأمر قائلاً: "يجب أن تتم كتابة البرامج أولاً حتى يتمكن الناس من قراءتها، ثم حتى يتمكنوا من قراءتها". أعدم "سيارة" . ما يمكنك قراءته حول هذا الموضوع: "دليل براعة البرمجيات الرشيقة" - روبرت مارتن. "دليل التقدير السريع" - مايك كوهن نبذة عن المؤلف: رافي شانكار راجان هو مدير برنامج تكنولوجيا المعلومات العالمي من مومباي (الهند). مدون مشهور، شاعر هايكو، متحمس لعلم الآثار وعاشق للتاريخ. يمكنك التواصل معه على تويتر , متوسط ​​, LinkedIn