هذه المقالة هي ملخص لكتاب روبرت كود النظيف ورؤيتي لكيفية تنظيف الكود. لا توجد أقسام في الاختبار ، TDD ، ما هي الهندسة المعمارية التي يجب أن تكون ، وما إلى ذلك. هنا كل شيء يدور حول ما يجب أن يكون عليه الرمز النظيف.
نعم ، ربما تم اختراق موضوع Clean Code بالفعل ، ولكن مع ذلك ، لا يعرف الجميع ذلك ، علاوة على ذلك ، لم أقابل نظائر المحتوى المضمّن في مقالتي.
عام
لا توجد طريقة وحل حقيقي. هناك واحد هو الأنسب لمهمة محددة.
عند حل مشكلة ، حاول إعادة إنتاج جميع الحالات التي قد تؤثر على هذه المهمة على الإطلاق وتنفيذ المهمة مع مراعاة جميع الحالات على الإطلاق.
أيضًا ، عند حل المشكلة ، حاول الانتقال من الاتجاه المعاكس. افهم نوع النتائج التي تريد الحصول عليها في النهاية واجعل على هذا الأساس الخوارزمية التي سيتم تنفيذ المهمة من خلالها.
قبل إرسال مهمة لتحريرها ، تحقق مما إذا كانت تعمل بشكل صحيح. هل هناك أي أخطاء فيه. ينطبق هذا حتى على تلك الالتزامات التي يتم إرسالها إلى الفرع الخاص بك. السيناريو الأكثر مثالية هو أنه لا يمكن لأي شخص العثور على أخطاء في الوظيفة التي طورتها.
فكر دائمًا في الكيفية التي يمكنك بها جعل كودك أبسط وأكثر نظافة وأكثر قابلية للقراءة.
- ما الحالات التي يمكن أن يكون للمهمة؟
- هل أخذت كل شيء في الاعتبار؟
- ما الخطأ الذي قد يحدث؟
- ما يمكن الجمع بين؟
- هل هناك وظائف مماثلة؟
- ما هو غير ضروري هنا؟
- كيف تجعل الأمر أسهل؟
- كيف تجعلها أكثر قابلية للقراءة؟
- كيف تجعلها أكثر وضوحا؟
كود نظيف
كيف تكتب كود نظيف وجيد؟ إنه مثل كتابة كتاب. أولاً تقوم بعمل مسودة ثم تمشيطها إلى الحالة التي سيكون من دواعي سرورك قراءتها. تذكر دائمًا أن كودك يجب أن يحكي قصة حتى يتمكن القارئ من فهمها.
يتم فهم الكيان - واجهة ، فئة ، طريقة ، متغير ، كائن ، إلخ.
- الرمز النظيف بسيط ومعبّر ويركز على مهمة محددة.
- كود نظيف سهل القراءة ، مثل النثر. إذا لم يكن الأمر كذلك ، فمن الجدير إعادة بيعها.
- كود نظيف سهل التعديل. لا ينبغي ربطه بشكل صارم بكومة من الكيانات. يمكن تغيير أي كيان بسهولة.
- يمر كود نظيف من خلال مراجعة أفضل بكثير. إذا ذهبت المراجعة مع الكثير من التعليقات ، فهي ليست نظيفة ويجب إعادة بنائها.
- يبدو الرمز النظيف دائمًا أنه تم العمل عليه لفترة طويلة جدًا. مهما كانت الطريقة التي تسعى إلى تحسينها ، ستصل إلى استنتاج مفاده أن هذا الرمز هو الأفضل. وبناءً على ذلك ، يُعتقد أن الشفرة النظيفة تتم بأدق التفاصيل.
- قاعدة الكشفية: اترك مكان وقوف السيارات أنظف مما كانت عليه من قبل. هذا يتحول بسهولة إلى البرمجة. انظر الرمز القذر؟ اجعلها أكثر نظافة أثناء حل مشكلتك. لا يجب أن تبتعد عن هذا ، وإذا كان الرمز المتسخ متسخًا للغاية ، فيجب عليك تخصيص مهمة ووقت منفصل لتنظيفه.
- لا تخف من إجراء تغييرات. إذا كنت ترغب في صنعها ، فلديك أسباب لذلك ، مما يعني أنك ستجعل الشفرة أفضل وأكثر نظافة. علاوة على ذلك ، ستظهر الاختبارات ما إذا كان هناك أي أخطاء في التعليمات البرمجية (بشرط أن تكون موجودة على الإطلاق).
- يجب أن يكون أي كيان مسؤولاً عن وظيفة واحدة فقط. ويجب أن تؤديها بشكل جيد. مسؤولية واحدة.
- إذا كان الكيان مسؤولاً على الفور عن إجراءين أو أكثر ، فيجب فصل وظيفته.
- يجب قراءة الرمز من الأعلى إلى الأسفل.
- في بنية جيدة ومختصة ، إجراء تغييرات دون تكاليف وجهد كبير.
- حذف الرمز الميت. الرمز الميت هو رمز لن يتم استدعاؤه تحت أي ظرف من الظروف أو رمز لا يستخدم في أي مكان.
الأسماء والأقسام
- استخدم أسماء واضحة وسهلة النطق لأي كيانات. يجب أن يصفوا سبب وجود هذا الكيان ، وماذا يفعل وكيف يتم استخدامه.
- لا تخف من إضاعة الوقت في اختيار أفضل اسم ودود. سوف تربح في المستقبل من خلال العمل أو قراءة هذا الرمز.
- إذا كان اسم الكيان لا يتوافق مع وظيفته أو لا يفهم الاسم ما يفعله الكيان ، فيجب إعادة تسميته إلى الاسم الأكثر فهمًا. إذا كان هذا مستحيلًا ، فهناك خطأ في وظيفته ويجب إعادة بنائه.
- الكيان ، الذي يحمل اسم "و" ، "مع" - ينتهك المسؤولية الفردية. وظيفة مثل هذا الكيان تستحق المشاركة. ولكن في بعض الأحيان يتم تجاهل هذه القاعدة.
- نصوص غير مفهومة ، يجب أن تؤخذ الخطوط في متغيرات وتعطيها أسماء واضحة.
- يجب أن تحتوي أسماء الطرق على فعل يصف ما تفعله هذه الطريقة والكلمة الرئيسية التي تعمل بها هذه الطريقة. إذا كان اسم الطريقة لا يحتوي على فعل ، فيجب ألا يكون هذا الكيان أسلوبًا أو يجب إعطاؤه الاسم الصحيح.
- يجب تجنب نفس الأسماء لغرضين مختلفين.
- إذا كان للكيان اسم مشابه لاسم كيان آخر ، فمن المرجح أن تكون وظيفته متشابهة للغاية ويجب دمجها؟ إذا لم يكن الأمر كذلك ، يجب تغيير أسمائهم بحيث لا تكون متشابهة.
- إذا قمت بإعادة تسمية أحد الكيانات ذهنيًا عندما تقرأ الرمز بحيث يمكنك فهم وظائفه بشكل أكثر وضوحًا ، فقم بإعادة تسميته إلى هذا الاسم العقلي.
- اختر كلمة واحدة لمفهوم واحد. سيكون من الصعب فهم الوظيفة عندما تحصل على الأسماء وتسترجعها وتدخلها. أفضل في كل مكان.
- إن الاسم الطويل والمفهوم أفضل من الاسم القصير ولكنه غير مفهوم.
وظائف
- يجب أن تكون الوظائف قصيرة ومضغوطة.
- يجب أن تكون الوظائف قصيرة جدًا ومدمجة للغاية.
- الحد الأقصى التقريبي هو 20 سطرًا و 150 حرفًا في سطر واحد ، إذا لم يكن مناسبًا ، فأنت بحاجة إلى الفصل.
- يجب أن تؤدي الوظيفة عملية واحدة فقط.
- يجب أن تفعل ذلك بشكل جيد ويجب ألا تفعل أي شيء آخر.
- إذا كانت الوظيفة تؤدي فقط تلك الإجراءات التي تكون في نفس مستوى التجريد ، عندها تقوم الوظيفة بعملية واحدة.
- لتحديد ما إذا كانت الوظيفة تؤدي أكثر من عملية ، حاول استخراج وظيفة أخرى منها ، والتي لن تكون إعادة صياغة بسيطة للتطبيق.
- أي عبارات شرطية مع تحديدات طويلة من خلال مفتاح التبديل ، إذا كان يجب أن يتم تقسيمها أو دمجها دون تكرار ، ربما إلى فئات مع عمليات التنفيذ ، ونقل خيار التنفيذ إلى الفئة الأساسية أو المصنع أو شخص آخر.
- إذا ، وإلا ، في حين ، وما إلى ذلك. يجب أن يحتوي على استدعاء دالة واحدة. سيكون أكثر قابلية للقراءة وأكثر وضوحا وأسهل.
- العدد المثالي لوسيطات الإدخال للدالة = 0. إذا كان هناك أكثر من ثلاث وسائط إدخال ، فيجب عليك التفكير في كيفية التخلص منها ، على سبيل المثال ، إنشاء فئة لهذه الوسيطات.
- كلما زادت حجج المدخلات ، زادت صعوبة فهم الوظيفة.
- تشير الدالة التي يتم تمرير الوسيطة إليها ، والتي يعتمد عليها تشغيل الدالة ، إلى أن الوظيفة تؤدي أكثر من عملية واحدة. يجب تقسيم هذه الوظائف إلى قسمين وتسميتها بمستوى أعلى.
- يجب أن تعطي الدالة التي تعدل وسيطة الإدخال مرجعًا للكائن الذي تم تغييره ، وليس فقط تعديله دون الرجوع.
String transform(String text) - إذا كان يجب على الدالة تغيير وسيطة الإدخال ، فدعها تغير حالة كائن مالكها.
- إذا لم تتغير وسيطة الإدخال الخاصة بالوظيفة (وتم استخدامها بشكل أكبر في الرمز) ، فيجب عليك نسخ قيمة الوسيطة والعمل مع النسخة الموجودة داخل الوظيفة.
- بدلاً من إرجاع null ، من الأفضل استخدام كائن فارغ -
Collection.empty() أو كائن فارغ - EmptyObject() . - حاول دائمًا استخدام الوظائف غير الثابتة. إذا لم يكن ذلك ممكنًا ، فاستخدم ثابتًا.
- إذا كان هناك رمز يجب أن يتبع واحدًا تلو الآخر ، فمرر نتائج الوظيفة الأولى إلى الثانية حتى لا يغير شخص ما تسلسل المكالمات.
- استخدم تعدد الأشكال بدلاً من if / else أو switch / case أو when.
- تجنب الظروف السلبية.
التعليقات
- لا تستخدم التعليقات إذا كان بإمكانك استخدام دالة أو متغير بدلاً من ذلك.
- لا تعلق على الكود السيئ - أعد كتابته. لا يستحق شرح ما يحدث في الشفرة السيئة ، فمن الأفضل أن تجعلها صريحة ومفهومة.
- يمكن استخدام التعليقات لنقل بعض المعلومات ، والتحذيرات بشأن العواقب ، ولكن ليس لتوضيح كيفية عمل الشفرة.
- استخدم TODO و FIXME في الحالات التي تحتاج فيها إلى ملاحظة أن الرمز يحتاج إلى تحسين ، ولكن لا توجد الآن موارد لهذا الغرض.
- استخدم
//region REGIONNAME //endregion REGIONNAME ، وإذا كنت تستخدم ، //region REGIONNAME //endregion REGIONNAME فيما إذا كان من الممكن تقسيم المنطقة إلى كيانات. - رمز المستند معقد ولكنه نظيف.
- لا تترك الرمز القديم المعلق. يمكنك العثور عليها في سجل الالتزام ، إذا لزم الأمر.
- يجب أن تكون التعليقات موجزة وواضحة. تعليقات المعلومات يجب ألا تحتوي على الكثير من المعلومات. يجب أن يكون كل شيء موجزًا وواضحا.
- اتبع التعليمات البرمجية المعتمدة في المشروع.
- اتبع القواعد المقبولة في الفريق.
- مع مراعاة التنسيق والنمط ، ستكون الشفرة أسهل في القراءة وأفضل. ليس عبثا أن الكتاب أعطي للمحرر قبل نشره.
- يجب أن يكون لديك أدوات تلقائية تقوم بتنسيق الرمز نيابةً عنك.
- يجب أن يكون ملف المصدر مثل مقال صحفي. يوجد عنوان ووصف موجز في شكل المعلمات والمحتوى في شكل وظائف. إذا لم يكن الأمر كذلك ، فعليك تغيير التنسيق.
- يجب أن تكون الكيانات المرتبطة ببعضها البعض قريبة ، على سبيل المثال ، في حزمة واحدة ، بحيث يكون من الأسهل التنقل عبر الرمز.
- يجب أن تكون متغيرات (حقول) الفئة في أعلى الفصل.
- يجب أن تكون متغيرات الطريقة أقرب إلى مكان استخدامها.
- يجب أن تكون الوظائف بترتيب المكالمة. إذا قام أحدهما باستدعاء الآخر ، فيجب أن تكون وظيفة الاستدعاء فوق الاستدعاء. من ناحية أخرى ، قد تكون الوظائف الخاصة ذات المستوى الأدنى في نهاية الملف ولا تتداخل مع فهم التعليمات البرمجية عالية المستوى. لكنني أفضل الطريقة الأولى.
كائنات وهياكل البيانات
- يجب عليك العمل مع الملخصات حتى يمكن تغيير التنفيذ بسهولة.
- يجب عليك العمل مع التجريدات ، لأن العميل الذي يستخدم الوظيفة يجب ألا يعرف تفاصيل التنفيذ ، يجب أن يعرف أي تطبيق يستخدم في هذه الحالة.
- يجب عليك توفير واجهة برمجة تطبيقات يجب أن تعمل معها وإخفاء تفاصيل التنفيذ وهيكله. لذلك سيكون من الأسهل العمل مع هذه الكيانات وإضافة أنواع جديدة من السلوكيات والوظائف والتطبيقات.
- DTO - كائن نقل البيانات. فئة تحتوي على بيانات فقط ولا تحتوي على وظائف. من الضروري نقل بعض البيانات. يجب أن يكون كائن من هذه الفئة غير قابل للتغيير.
فصول
- يجب أن تكون الفئات مضغوطة.
- يجب أن تكون الفصول أكثر إحكاما.
- يجب أن يصف اسم الفصل مسؤوليتها. من هنا يمكنك حساب حجم الفصل.
- يجب أن تتوافق وظيفية الفصل بشكل واضح مع اسم الفصل.
- قسّم الترابط إلى فئات صغيرة. يجب ألا يكون هناك تماسك صارم وفير - فهذا يعقد دعم وتطوير المشروع.
- تذكر المسؤولية الفردية. يجب أن يكون للكيان سبب واحد فقط للتغيير.
- لاحظ التغليف. يجب أن يكون التغليف الضعيف هو الملاذ الأخير دائمًا.
- عادةً ما نعلن عن خصوصية المتغيرات والوظائف المساعدة ، ولكن في بعض الأحيان يجب الإعلان عن حمايتها والقدرة على الوصول إليها من الاختبار.
- إذا كانت مجموعة من الوظائف تنتمي إلى وظيفة معينة ، فيمكن عندئذٍ ويجب تخصيص هذه المجموعة من الوظائف لفئة منفصلة واستخدام مثيلها.
معالجة الخطأ
- استخدم الاستثناءات بدلاً من إرجاع رموز الخطأ.
- معالجة الخطأ هي عملية واحدة. إذا كان هناك كلمة رئيسية تجريبية في الوظيفة ، فلا يجب أن يكون هناك أي شيء آخر في الوظيفة بعد انتهاء عملية
catch/finally . - إذا كان لديك تعدادًا يسرد الأخطاء ، فمن الأفضل التخلص منه واستخدام الاستثناءات بدلاً من ذلك.
- استخدم الاستثناءات غير المحددة للإشارة بوضوح إلى المكان الذي توجد فيه مشكلات. لا يلزم أن يتم اكتشاف مثل هذه الأخطاء ، وبدلاً من ذلك تحتاج إلى كتابة رمز بحيث لا يوجد هذا الخطأ أبدًا.
- قم بتمرير ما يكفي من المعلومات مع طرح استثناء حتى يتمكن مستخدمو الشفرة فيما بعد من فهم ما حدث بالفعل.
- بدلاً من العبارات الشرطية مع معالجة الخطأ ، من الأفضل طرح الاستثناءات ومعالجتها.
- لا تمرر فارغة في أي مكان. حاول تجنب ذلك قدر الإمكان.
- معالجة الأخطاء هي مهمة منفصلة ولا تنطبق على المنطق الرئيسي للبرنامج.
الحدود
- نستخدم دائمًا بعض المكتبات التي تمنحنا في الغالب وظائف واسعة جدًا أو صغيرة جدًا أو تتعارض مع الوظيفة المتوقعة ، مما يجعل الشفرة أكثر فوضى في استخدامها النهائي. يمكنك تجنب ذلك ببساطة عن طريق تطبيق أنماط مثل الديكور أو المحول أو الواجهة أو غيرها.
- هناك حالات عندما تحتاج إلى العمل مع وظيفة قيد التطوير أو لم يتم تكييفها بعد للاستخدام في رمز الإنتاج. في هذه الحالة ، يجب أن تتخيل ما تتوقعه من المكتبة / هذه الوظيفة وكتابة الواجهة الخاصة بك أو إنشاء كيان ستعمل معه في مشروعك بالطريقة التي تريدها. عندما تكتمل المكتبة وتصبح مستقرة ، يمكنك تكييفها مع الهياكل الجاهزة الخاصة بك واستخدام الوظائف الجاهزة.
خاتمة
تقدم هذه المقالة إرشادات فقط لكتابة كود نظيف. بالطبع ، يمكن إهمالها. عليك فقط أن تفهم أن أيًا من قراراتك يجب أن يكون لديه حجج مؤيدة له.