اشراق العالم
03-19-2020, 12:14 AM
<div>الشفرة الجيدة قابلة للصيانة ، وقابلة لإعادة الاستخدام ، وقابلة للاختبار. تتناول النصائح التالية كيف يمكنك أنت و / أو فريق التطوير لديك التعامل مع مهام الترميز المختلفة وكيفية الحفاظ على كل شيء منظمًا قدر الإمكان. سأقدم لك بعض "أفضل الممارسات" التي ستساعدك على كتابة كود أفضل وتساعدك أنت وفريقك على السعادة والفعالية.
1. استخدم معيار الترميز
من السهل كتابة رمز سيء وغير منظم ، ولكن من الصعب الحفاظ على مثل هذا الرمز. عادة ما يتبع الكود الجيد بعض المعايير لتسمية الاصطلاحات ، التنسيق ، إلخ. هذه المعايير لطيفة لأنها تجعل الأشياء حتمية لأولئك الذين يقرؤون الكود الخاص بك بعد ذلك ، بما في ذلك نفسك.
يمكنك إنشاء معيار الترميز الخاص بك ، ولكن من الأفضل الالتزام بمعايير ذات قبول أوسع. المعايير التي يتم الحفاظ عليها علنًا مثل Zend Framework Coding Standard أو قريبًا ستصبح PSR-1 Coding Style Guide بدلاً من ذلك ، سيكون من الأسهل على الآخرين التكيف.
2. اكتب تعليقات مفيدة
التعليقات حاسمة. لن تقدرهم حتى تترك النص المكون من ألف سطر لبضعة أيام وتعود إليه وتحاول فهمه. التعليقات المفيدة تجعل الحياة أسهل لك ولأولئك الذين بعدك والذين يجب عليهم الحفاظ على التعليمات البرمجية الخاصة بك.
برمجة مواقع بالرياض (https://www.aait.sa/%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D9%85%D9%88%D8%A7%D9%82%D8%B9)
اكتب تعليقات ذات معنى من سطر واحد للخطوط المبهمة ؛ كتابة وصف كامل للمعلمات والوظائف للوظائف والأساليب ؛ بالنسبة للكتل المنطقية الصعبة ، صف المنطق بالكلمات قبلها إذا لزم الأمر. ولا تنس ، احرص دائمًا على تحديث تعليقاتك!
3. ريفاكتور
إعادة هيكلة الكود هي العادة الثامنة للمطورين ذوي الفعالية العالية. صدق أو لا تصدق ، يجب عليك إعادة هيكلة الكود الخاص بك على أساس يومي أو أن الكود الخاص بك ليس في صحة جيدة! تحافظ إعادة البناء على شفرتك الصحية ، ولكن ما الذي يجب عليك إعادة بيعه وكيف؟
يجب عليك إعادة بناء كل شيء ، من الهندسة المعمارية إلى الأساليب والوظائف الخاصة بك ، وأسماء المتغيرات ، وعدد الحجج التي تتلقاها الطريقة ، وما إلى ذلك.
كيفية إعادة البناء هي أكثر من فن أكثر من علم ، ولكن هناك بعض القواعد العملية التي يمكن أن تلقي بعض الضوء عليها:
إذا كانت وظيفتك أو أسلوبك يتألف من أكثر من 20-25 سطرًا ، فمن الأرجح أنك تقوم بتضمين الكثير من المنطق بداخلها ، وربما يمكنك تقسيمها إلى وظيفتين أو أكثر / وظائف أصغر.
إذا كان اسم أسلوبك / وظيفتك أكثر من 20 حرفًا ، فيجب إما إعادة التفكير في الاسم ، أو إعادة التفكير في الوظيفة / الطريقة بأكملها من خلال مراجعة القاعدة الأولى.
إذا كان لديك الكثير من الحلقات المتداخلة ، فقد تكون تقوم ببعض المعالجة كثيفة الموارد دون إدراك ذلك. بشكل عام ، يجب عليك إعادة التفكير في المنطق إذا كنت تداخل أكثر من حلقتين. ثلاث حلقات متداخلة أمر مروع!
ضع في اعتبارك ما إذا كانت هناك أي أنماط تصميم قابلة للتطبيق يمكن أن تتبعها التعليمات البرمجية الخاصة بك. لا يجب عليك استخدام الأنماط فقط من أجل استخدام الأنماط ، ولكن الأنماط تقدم حلول جاهزة جاهزة ومجرّبة يمكن أن تكون قابلة للتطبيق.
4. تجنب المدونة العالمية
تعتبر المتغيرات والحلقات العالمية فوضى ويمكن أن يثبت أنها مشكلة عندما ينمو تطبيقك إلى ملايين أسطر التعليمات البرمجية (التي يفعل معظمها!). قد تؤثر على الشفرة في مكان آخر يصعب تمييزها ، أو تسبب اشتباكات تسمية صاخبة. فكر مرتين قبل تلويث مساحة الاسم العامة باستخدام المتغيرات والوظائف والحلقات وما إلى ذلك.
القوالب (https://www.aait.sa/%D8%A7%D9%84%D9%82%D9%88%D8%A7%D9%84%D8%A8)
في حالة مثالية ، يجب ألا يكون لديك أي كتل محددة عالميًا. هذا هو. يجب كتابة جميع عبارات التبديل ، try-catch ، foreach ، while-loops ، وما إلى ذلك داخل طريقة أو دالة. يجب كتابة الأساليب داخل تعريفات الفئة ، ويجب أن تكون تعريفات الفئة والوظيفة داخل مساحات الأسماء.
5. استخدم أسماء ذات مغزى
لا تستخدم أبدًا أسماء مثل $ k و $ m و $ test لمتغيراتك. كيف تتوقع أن تقرأ مثل هذا الرمز في المستقبل؟ يجب أن تكون الشفرة الجيدة ذات معنى من حيث أسماء المتغيرات وأسماء الوظائف / الأساليب وأسماء الفئات. بعض الأمثلة الجيدة للأسماء ذات المعنى هي: $ request و $ dbResult و $ tempFile (اعتمادًا على إرشادات نمط التشفير الخاصة بك ، فقد تستخدم هذه الخطوط السفلية أو camelCase أو PascalCase).
6. استخدم هياكل ذات مغزى
هيكلة تطبيقك مهم جدا. لا تستخدم الهياكل المعقدة ، التزم دائمًا بالبساطة. عند تسمية الدلائل والملفات ، استخدم اصطلاح تسمية تتفق عليه مع فريقك ، أو استخدم واحدًا مرتبطًا بمعيار الترميز الخاص بك. قم دائمًا بتقسيم الأجزاء الأربعة لأي تطبيق PHP نموذجي بعيدًا عن بعضها البعض - CSS ، قوالب / تخطيطات HTML ، ********** ، PHP Code - ولكل محاولة لفصل المكتبات عن منطق الأعمال. من الجيد أيضًا أن تبقي التسلسل الهرمي للدليل ضحلًا قدر الإمكان حتى يسهل التنقل والعثور على الرمز الذي تبحث عنه.
طرق تصميم مواقع الانترنت (https://www.aait.sa/%D8%B7%D8%B1%D9%82-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D9%85%D9%88%D8%A7%D9%82%D8%B9-%D8%A7%D9%84%D8%A7%D9%86%D8%B1%D9%86%D8%AA)
7. استخدام برنامج التحكم في الإصدار
في الماضي ، اعتمدت فرق التطوير الجيدة على CVS وتصحيحات مختلفة للتحكم في الإصدار. في الوقت الحاضر ، على الرغم من ذلك ، لدينا مجموعة متنوعة من الحلول المتاحة. يجب أن تكون إدارة التغييرات والمراجعات سهلة ولكنها فعالة ، لذا اختر أي برنامج للتحكم في الإصدار يعمل بشكل أفضل مع سير عمل فريق التطوير. أفضل استخدام أداة التحكم في الإصدار الموزع مثل Git أو Mercurial ؛ كلاهما برمجيات حرة / مفتوحة المصدر وقوية للغاية.
1. استخدم معيار الترميز
من السهل كتابة رمز سيء وغير منظم ، ولكن من الصعب الحفاظ على مثل هذا الرمز. عادة ما يتبع الكود الجيد بعض المعايير لتسمية الاصطلاحات ، التنسيق ، إلخ. هذه المعايير لطيفة لأنها تجعل الأشياء حتمية لأولئك الذين يقرؤون الكود الخاص بك بعد ذلك ، بما في ذلك نفسك.
يمكنك إنشاء معيار الترميز الخاص بك ، ولكن من الأفضل الالتزام بمعايير ذات قبول أوسع. المعايير التي يتم الحفاظ عليها علنًا مثل Zend Framework Coding Standard أو قريبًا ستصبح PSR-1 Coding Style Guide بدلاً من ذلك ، سيكون من الأسهل على الآخرين التكيف.
2. اكتب تعليقات مفيدة
التعليقات حاسمة. لن تقدرهم حتى تترك النص المكون من ألف سطر لبضعة أيام وتعود إليه وتحاول فهمه. التعليقات المفيدة تجعل الحياة أسهل لك ولأولئك الذين بعدك والذين يجب عليهم الحفاظ على التعليمات البرمجية الخاصة بك.
برمجة مواقع بالرياض (https://www.aait.sa/%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D9%85%D9%88%D8%A7%D9%82%D8%B9)
اكتب تعليقات ذات معنى من سطر واحد للخطوط المبهمة ؛ كتابة وصف كامل للمعلمات والوظائف للوظائف والأساليب ؛ بالنسبة للكتل المنطقية الصعبة ، صف المنطق بالكلمات قبلها إذا لزم الأمر. ولا تنس ، احرص دائمًا على تحديث تعليقاتك!
3. ريفاكتور
إعادة هيكلة الكود هي العادة الثامنة للمطورين ذوي الفعالية العالية. صدق أو لا تصدق ، يجب عليك إعادة هيكلة الكود الخاص بك على أساس يومي أو أن الكود الخاص بك ليس في صحة جيدة! تحافظ إعادة البناء على شفرتك الصحية ، ولكن ما الذي يجب عليك إعادة بيعه وكيف؟
يجب عليك إعادة بناء كل شيء ، من الهندسة المعمارية إلى الأساليب والوظائف الخاصة بك ، وأسماء المتغيرات ، وعدد الحجج التي تتلقاها الطريقة ، وما إلى ذلك.
كيفية إعادة البناء هي أكثر من فن أكثر من علم ، ولكن هناك بعض القواعد العملية التي يمكن أن تلقي بعض الضوء عليها:
إذا كانت وظيفتك أو أسلوبك يتألف من أكثر من 20-25 سطرًا ، فمن الأرجح أنك تقوم بتضمين الكثير من المنطق بداخلها ، وربما يمكنك تقسيمها إلى وظيفتين أو أكثر / وظائف أصغر.
إذا كان اسم أسلوبك / وظيفتك أكثر من 20 حرفًا ، فيجب إما إعادة التفكير في الاسم ، أو إعادة التفكير في الوظيفة / الطريقة بأكملها من خلال مراجعة القاعدة الأولى.
إذا كان لديك الكثير من الحلقات المتداخلة ، فقد تكون تقوم ببعض المعالجة كثيفة الموارد دون إدراك ذلك. بشكل عام ، يجب عليك إعادة التفكير في المنطق إذا كنت تداخل أكثر من حلقتين. ثلاث حلقات متداخلة أمر مروع!
ضع في اعتبارك ما إذا كانت هناك أي أنماط تصميم قابلة للتطبيق يمكن أن تتبعها التعليمات البرمجية الخاصة بك. لا يجب عليك استخدام الأنماط فقط من أجل استخدام الأنماط ، ولكن الأنماط تقدم حلول جاهزة جاهزة ومجرّبة يمكن أن تكون قابلة للتطبيق.
4. تجنب المدونة العالمية
تعتبر المتغيرات والحلقات العالمية فوضى ويمكن أن يثبت أنها مشكلة عندما ينمو تطبيقك إلى ملايين أسطر التعليمات البرمجية (التي يفعل معظمها!). قد تؤثر على الشفرة في مكان آخر يصعب تمييزها ، أو تسبب اشتباكات تسمية صاخبة. فكر مرتين قبل تلويث مساحة الاسم العامة باستخدام المتغيرات والوظائف والحلقات وما إلى ذلك.
القوالب (https://www.aait.sa/%D8%A7%D9%84%D9%82%D9%88%D8%A7%D9%84%D8%A8)
في حالة مثالية ، يجب ألا يكون لديك أي كتل محددة عالميًا. هذا هو. يجب كتابة جميع عبارات التبديل ، try-catch ، foreach ، while-loops ، وما إلى ذلك داخل طريقة أو دالة. يجب كتابة الأساليب داخل تعريفات الفئة ، ويجب أن تكون تعريفات الفئة والوظيفة داخل مساحات الأسماء.
5. استخدم أسماء ذات مغزى
لا تستخدم أبدًا أسماء مثل $ k و $ m و $ test لمتغيراتك. كيف تتوقع أن تقرأ مثل هذا الرمز في المستقبل؟ يجب أن تكون الشفرة الجيدة ذات معنى من حيث أسماء المتغيرات وأسماء الوظائف / الأساليب وأسماء الفئات. بعض الأمثلة الجيدة للأسماء ذات المعنى هي: $ request و $ dbResult و $ tempFile (اعتمادًا على إرشادات نمط التشفير الخاصة بك ، فقد تستخدم هذه الخطوط السفلية أو camelCase أو PascalCase).
6. استخدم هياكل ذات مغزى
هيكلة تطبيقك مهم جدا. لا تستخدم الهياكل المعقدة ، التزم دائمًا بالبساطة. عند تسمية الدلائل والملفات ، استخدم اصطلاح تسمية تتفق عليه مع فريقك ، أو استخدم واحدًا مرتبطًا بمعيار الترميز الخاص بك. قم دائمًا بتقسيم الأجزاء الأربعة لأي تطبيق PHP نموذجي بعيدًا عن بعضها البعض - CSS ، قوالب / تخطيطات HTML ، ********** ، PHP Code - ولكل محاولة لفصل المكتبات عن منطق الأعمال. من الجيد أيضًا أن تبقي التسلسل الهرمي للدليل ضحلًا قدر الإمكان حتى يسهل التنقل والعثور على الرمز الذي تبحث عنه.
طرق تصميم مواقع الانترنت (https://www.aait.sa/%D8%B7%D8%B1%D9%82-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D9%85%D9%88%D8%A7%D9%82%D8%B9-%D8%A7%D9%84%D8%A7%D9%86%D8%B1%D9%86%D8%AA)
7. استخدام برنامج التحكم في الإصدار
في الماضي ، اعتمدت فرق التطوير الجيدة على CVS وتصحيحات مختلفة للتحكم في الإصدار. في الوقت الحاضر ، على الرغم من ذلك ، لدينا مجموعة متنوعة من الحلول المتاحة. يجب أن تكون إدارة التغييرات والمراجعات سهلة ولكنها فعالة ، لذا اختر أي برنامج للتحكم في الإصدار يعمل بشكل أفضل مع سير عمل فريق التطوير. أفضل استخدام أداة التحكم في الإصدار الموزع مثل Git أو Mercurial ؛ كلاهما برمجيات حرة / مفتوحة المصدر وقوية للغاية.