لا تتعلق هندسة البرمجيات فقط بتعلم اللغة وبناء بعض البرامج، بصفتك مهندس برمجيات أو مطور برمجيات، من المتوقع أن تكتب برنامجًا جيدًا، إذن السؤال ما الذي يجعل البرامج جيدة؟ يمكن الحكم على البرامج أنها جيدة من خلال قراءة جزء من الكود المكتوب في المشروع، إذا كانت الكود سهل الفهم وسهل التغيير، فمن المؤكد أنها برامج جيدة.
أهمية كتابة كود نظيف:
من الشائع في التطوير المشاريع ألا يرغب أحد في مواصلة المشروع بكود فوضوي، ولكن أحيانًا يتجنب المطورون كتابة كود نظيف، بسبب ضغوط الموعد النهائي لتسليم المشروع، ويندفعون للمضي قدمًا بشكل أسرع، ولكن ما يحدث في الواقع هو أن ينتهي بهم الأمر بشكل أبطأ؛ وذلك لأن عدم كتابتهم كود نظيف قد أحدث المزيد من الأخطاء البرمجية التي يحتاجون إلى إصلاحها لاحقًا للعودة إلى نفس الجزئية من الكود، تستغرق هذه العملية وقتًا أطول بكثير من الوقت المستغرق في كتابة كود نظيف، كشفت دراسة أن نسبة الوقت المستغرق في قراءة الكود مقابل الكتابة تزيد عن (10) إلى (1).
لا يهم إذا كنت مبتدئًا أو مبرمجًا خبيراً، يجب أن تحاول دائمًا أن تصبح مبرمجًا جيدًا (وليس مجرد مبرمج)، تذكر أنك مسؤول عن جودة الكود الخاص بك، لذا اجعل برنامجك جيدًا بما يكفي حتى يتمكن المطورون الآخرون من فهمه.
ما الذي يجعل الكود نظيفاً؟
قبل أن نناقش كيفية كتابة الكود النظيف، دعونا نرى بعض خصائصه:
1- يجب أن يكون الكود النظيف قابلاً للقراءة، إذا كان على شخص ما أن يقرأ الكود الخاص بك، فيجب أن يشعر بأنه يقرأ شعر أو نثر.
2- يجب أن يكون الكود النظيف أنيقًا، ويجب أن تكون ممتعاً للقراءة.
3- يجب أن يكون الكود النظيف بسيطاً، ويجب أن يتبع مبدأ المسؤولية الفردية (SRP).
4- يجب أن يكون الكود النظيف سهل الفهم، وسهل التغيير.
5- يجب أن يقوم الكود النظيف بتجاوز جميع الاختبارات بنجاح.
نصائح حول كتابة كود نظيف:
استخدم أسماء ذات مغزى:
سوف تكتب الكثير من الأسماء للمتغيرات والدوال والفئات والحزم وأشياء من هذا القبيل، تعوّد على استخدام أسماء ذات معنى في الكود الخاصة بك، مهما كانت الأسماء التي تذكرها في الكود الخاص بك يجب أن تفي بثلاثة أهداف: ما الذي تفعله، ولماذا توجد، وكيف يتم استخدامها، علي سبيل المثال:
int b; //number of users
في المثال أعلاه، تحتاج إلى ذكر تعليق عند تعريف اسم متغير وهذا ليس من سمات الكود الجيد، إذ يجب أن يكشف الاسم الذي تحدده في الكود عن مقصده، ويجب أن تحدد الغرض من المتغير أو الدالة، لذلك بالنسبة للمثال أعلاه، سيكون اسم المتغير الأفضل هو:
int number_of_users;
قد يستغرق الأمر بعض الوقت لاختيار أسماء ذات معنى ولكنه يجعل كودك أكثر وضوحًا، ويسهل قراءتها للمطورين الآخرين وكذلك لنفسك، حاول أيضًا قصر الأسماء على ثلاث أو أربع كلمات.
مبدأ المسؤولية الفردية (SRP):
تعتبر الفئات (Classes) أو الدوال (functions) طريقة جيدة لتنظيم الكود في أي لغة برمجة، لذلك عندما تكتب الكود، تحتاج إلى الاهتمام بكيفية كتابة دالة تنقل الغرض منها، يرتكب معظم المبتدئين هذا الخطأ؛ لأنهم يكتبون دالة يمكنها التعامل والقيام بكل شيء تقريبًا (أداء مهام متعددة)، وذلك يجعل الكود الخاص بك أكثر إرباكًا للمطورين ويخلق مشاكل عندما يحتاجون إلى إصلاح بعض الأخطاء أو العثور على جزء من الكود، لذلك عندما تكتب دالة، يجب أن تتذكر شيئين لجعل دالتك نظيفة وسهلة الفهم:
- يجب أن تكون صغيرة.
- يجب أن تفعل شيئًا واحدًا فقط، ويجب أن تفعل ذلك بشكل جيد.
تأكد أيضًا من أن دالتك يجب ألا تحتوي على أكثر من ثلاث معاملات (parameter)، حيث تؤدي المزيد من المعاملات إلى أداء المزيد من المهام، لذا حاول تقليل المعاملات قدر الإمكان، تمرير أكثر من ثلاث معاملات يجعل كودك مربك وكبير جدًا ويصعب تصحيحه إذا كانت هناك أي مشكلة، إذا كانت دالتك تحتوي على جملة (try-catch-finally)، فقم بإنشاء دالة منفصلة تحتوي فقط على عبارات (try-catch-finally)، واستخدم اسمًا وصفيًا لدالتك أيضاً، والذي يجب أن يحدد بوضوح ما تفعله، مثال:
function subtract(x, y) { return x - y; }في المثال أعلاه، يوضح اسم الدالة أن الغرض منه هو إجراء عملية طرح لرقمين، كما أنه يحتوي على معاملين فقط.
تجنب كتابة التعليقات غير الضرورية:
من الشائع أن يستخدم المطورون التعليقات، لتحديد الغرض من سطر في الكود الخاصة بهم، في الواقع أن التعليقات مفيدة في شرح وظيفة الكود، ولكنها تتطلب أيضًا مزيدًا من الصيانة لكودك، ينتقل كود التطوير هنا وهناك، ولكن إذا ظل التعليق في نفس المكان، فيمكن أن يؤدي إلى مشكلة كبيرة، حيث يمكن أن يحدث ارتباكًا بين المطورين ويتشتت انتباههم أيضًا بسبب التعليقات غير المجدية.
ليس الأمر كما لو أنه لا يجب عليك استخدام التعليقات على الإطلاق، في بعض الأحيان يكون ذلك مهمًا، على سبيل المثال: إذا كنت تتعامل مع واجهة برمجة تطبيقات تابعة لجهة خارجية حيث تحتاج إلى شرح بعض السلوكيات هناك، يمكنك استخدام التعليقات لشرح التعليمات البرمجية الخاصة بك ولكن لا تكتب التعليقات حيث لا يكون ذلك ضروريًا.
اليوم، يعد تركيب (syntax) لغات البرمجة الحديثة هي اللغة الإنجليزية، وهذا جيد بما يكفي لشرح الغرض من سطر في الكود الخاصة بك، لتجنب التعليقات في الكود الخاصة بك، استخدم أسماء ذات معنى للمتغيرات أو الوظائف أو الملفات.
اكتب كودًا قابلاً للقراءة للأشخاص:
يرتكب الكثير من المبرمجين (وخاصة المبتدئين) أخطاء أثناء كتابة الكود، إذ يكتبون كل شيء في سطر واحد ولا يضعون “مسافات بيضاء” أو مسافة بادئة أو فواصل أسطر في الكود، مما يجعل الكود الخاصة بهم فوضوي ويصعب صيانته، هناك دائمًا احتمال أن يتمكن شخص آخر من الوصول إلى الكود الخاصة بك، وسيتعين عليهم العمل عليه.
والكود الغير قابل للقراءة يضيع وقت المطورين الآخرين عندما يحاولون قراءته وفهمه، لذلك انتبه دائمًا إلى تنسيق الكود الخاصة بك، سيوفر هذا وقتك وطاقتك عندما تعود إلى الكود الخاصة بك بعد يومين لإجراء بعض التغييرات.
اكتب اختبارات الوحدة Unit Tests:
كتابة اختبار الوحدة مهم جدًا في التطوير، يجعل كودك نظيف ومرن وقابل للصيانة، حيث أن إجراء التغييرات في الكود وتقليل الأخطاء أسهل، هناك عملية في تطوير البرمجيات تسمى التطوير المدفوع بالاختبار (TDD)، حيث يتم تحويل المتطلبات إلى بعض حالات الاختبار المحددة، ثم يتم تحسين البرنامج لاجتياز اختبارات جديدة.
كن حذرًا مع الاعتمادية Dependency:
في تطوير البرمجيات، تحتاج حقًا إلى توخي الحذر بشأن الاعتمادية، إذا كان ذلك ممكنًا، يجب أن تكون الاعتمادية دائمًا أحادية الاتجاه، على سبيل المثال، لنفترض أن لدينا كلاس “مطبخ” يعتمد على كلاس “غسالة الصحون”، طالما أن كلاس غسالة الصحون لا تعتمد أيضًا على كلاس المطبخ، فهذا يعني أن الاعتمادية ذات اتجاه واحد، إذ يستخدم كلاس المطبخ غسالة الأطباق فقط، لكن غسالة الأطباق يمكن لأي شخص استخدامها، ليس بالضرورة أن يكون مطبخًا.
هذا المثال من الاعتمادية في اتجاه واحد من السهل إدارته، لكن من المستحيل أن يكون لديك دائمًا اعتمادية أحادية الاتجاه، إذ يجب أن نحاول الحصول على أكبر عدد ممكن، في الاعتمادية ثنائية الاتجاه، يعتمد كلا الكيانين (objects) على بعضهما البعض، لذلك يجب أن يتواجدوا معًا على الرغم من أنهم منفصلون، فيصبح من الصعب تحديث بعض الأنظمة، لذا كن حذرًا دائمًا بشأن إدارة الاعتمادية .
