ما هي أكثر سياسات تطوير الويب الأكثر شيوعا في شركات البرمجيات؟ [مغلق

Question

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

• المسافة البادئة المحددة للترميز بين فرق التنمية
• تعليقات محددة قبل كل طريقة، قبل كل إعلان متغير
• اتفاقيات التسمية، قضية الجمل أو أي شيء آخر.
• في تعليق HTML بعد كل علامة حاوية.
• في CSS، باستخدام كل إعلان مرة واحدة فقط.

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

Answer 1

أركز على أي سياسات حول ممارسات التنمية بدلا من تنسيق التعليمات البرمجية. بعض الأمثلة هي:

• دائما استخدام استعلامات SQL المعلمة. لا تسترسل إدخال المستخدم في استعلام.
• حافظ على HTML و CSS و JavaScript في ملفات منفصلة.
• يستخدم jslint أو أداة مكافئة كل الوقت الذي ارتكب الرمز.
• اختر معيار HTML (مثل HTML 4.01 صارمة). يجب التحقق من صحة كل HTML.

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

Answer 2

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

Answer 3

(بالنسبة لمشاريع PHP، على الأقل - لاحظ أن PHP مفتوح المصدر ولديه مجتمع مهم؛ لذلك، العديد من الأشياء مدفوعة تماما بما يتم ذلك في المجتمع)

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

• ابحث عن تعريف المعيار
• أعد استخدامه في أي مشاريع أخرى تستخدم نفس الإطار
  • حتى عند الذهاب إلى شركة أخرى، أو العمل لعميل آخر
  • أو عندما تأتي من شركة أخرى ؛-)

بالنظر إلى أننا نستخدم فقط ما بين 3 و 5 أطر لمشاريع PHP في الشركة التي أعمل بها، وأن العديد من القواعد المحددة في معاييرها هي نفسها، إنها ليست مشكلة حقيقية.

الأمر نفسه ينطبق إذا تم الترميز داخل / ارجع نوعا ما من CMS، على سبيل المثال، بالطبع.

عند عدم استخدام إطار محدد، نحاول التمسك بمجموعة مشتركة من القواعد مقبولة على نطاق واسع بين مجتمع PHP: بنفس الطريقة، فإنها تضمن هذه القواعد معروفة جيدا (حتى من قبل New-Comers إلى شركتنا), من السهل العثور عليها، وأن الكثير من الناس جربهم وتعززهم.

حول التعليقات، هناك أداة واحدة تستخدم جيدا في PHP: phpdocumentor (عن نفس الشيء مثل Javadoc) ؛ يحدد المعيار - هذا هو معيار De-Facto، حيث لا توجد أداة أخرى تستخدم كثيرا.

حول تعليق محدد علامات:

• نستخدم دائما param / @ @: يتم دمجها في IDE، لتوفير تلميح النوع، لذلك مفيدة
• آخر، نحن لا نستخدم الكثير: بضع خطوط ليقول ما هي الطريقة التي لا تكون واضحة؛ بضع خطوط إذا تم استخدام خوارزمية صعبة.

Camel-Case أو غيرها: نتمسك بما هو شائع بين كل من مجتمع PHP والأطر:

this_is_a_function

و

ThisIsAClassName

و

thisIsAMethodName

في HTML: قدر الإمكان، لا نستخدم تعليقات HTML، لأنها يتم إرسالها إلى المتصفح:

• يعني صفحات أكبر (موافق، وليس ذلك كثيرا)
• يعني التخلي عن المعلومات لا يحتاج المستخدم

إذا كان ذلك ممكنا، نستخدم التعليقات من محرك القالب.

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

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

لا يفعل السحر، لكنه يساعد على فهم الكود ... وكذلك، أيضا، اختبره، أعد استخدامه، ...

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