هل تعتقد أنه يجب على شركة البرمجيات أن تفرض على المطورين أسلوبًا في البرمجة؟[مغلق]

https://stackoverflow.com/questions/145508

02-07-2019
|

سؤال

إذا كنت تعتقد أنه لا ينبغي ذلك، اشرح السبب.

إذا كانت الإجابة بنعم، ما مدى عمق المبادئ التوجيهية في رأيك؟على سبيل المثال، ينبغي تضمين المسافة البادئة للتعليمات البرمجية؟

المحلول

أعتقد أ فريق (بدلا من شركة) بحاجة إلى الاتفاق على مجموعة من الإرشادات لأسلوب متسق بشكل معقول.يجعلها أكثر وضوحا للصيانة.

مدى عمق؟ضحلة كما يمكنك الاتفاق عليها.وكلما كان الأمر أقصر وأكثر وضوحًا، زاد احتمال موافقة جميع أعضاء الفريق عليه والالتزام به.

نصائح أخرى

تريد أن يقرأ الجميع ويكتبوا التعليمات البرمجية بطريقة قياسية.هناك طريقتان يمكنك من خلالهما تحقيق ذلك:

قم باستنساخ مطور واحد عدة مرات وتأكد من خضوعهم جميعًا لنفس التدريب.نأمل أن يتمكنوا جميعًا من كتابة نفس قاعدة التعليمات البرمجية.
امنح المطورين الحاليين لديك تعليمات واضحة بشأن ما تحتاجه.علامات التبويب أو المسافات البادئة.حيث يجلس الأقواس.كيفية التعليق.إرشادات الالتزام بالتحكم في الإصدار.

كلما تركت دون تحديد أكثر، زادت احتمالية تعارض أحد المطورين في الأسلوب.

يجب على الشركة أن تفرض ضرورة اتباع بعض الأساليب.ما هو النمط ومدى عمق المبادئ التوجيهية يجب أن يتم تحديدهما بشكل جماعي من قبل مجتمع المطورين في الشركة.

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

إذا كنت تستخدم .Net، فانظر إلى stylecop وfxcop وResharper

هل تعتقد أنه يجب على شركة البرمجيات أن تفرض على المطورين أسلوبًا في البرمجة؟

ليس بطريقة من أعلى إلى أسفل.يجب أن يتفق المطورون في شركة البرمجيات على أسلوب ترميز مشترك.

إذا كانت الإجابة بنعم، ما مدى عمق المبادئ التوجيهية في رأيك؟

يجب عليهم فقط وصف الاختلافات عن الاتفاقيات المعروفة، ومحاولة إبقاء الانحراف في حده الأدنى.يعد هذا أمرًا سهلاً للغات مثل Python أو Java، وغير واضح إلى حد ما بالنسبة لـ C/C++، ويكاد يكون مستحيلًا بالنسبة لـ Perl وRuby.

على سبيل المثال، ينبغي تضمين المسافة البادئة للتعليمات البرمجية؟

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

نعم، ولكن في حدود المعقول.

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

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

إن تجاوز ذلك، في رأيي الصادق، أمر "شرجي" بعض الشيء ومزعج بلا داعٍ للمطورين.

نقطة جيدة لهاميش سميث:

الأسلوب مختلف تمامًا عن أفضل الممارسات.إنه لأمر مخز أن "معايير الترميز" تميل إلى لفة الاثنين معًا.إذا تمكن الناس من الحفاظ على جزء النمط إلى الحد الأدنى والتركيز على أفضل الممارسات التي من المحتمل أن تضيف قيمة أكبر.

لا أعتقد أنه يجب على فريق التطوير أن يكون لديه إرشادات خاصة بالأسلوب يجب عليهم اتباعها كقاعدة عامة.هناك استثناءات، على سبيل المثال استخدام <> مقابل."" في عبارات #include, ولكن هذه الاستثناءات يجب أن تأتي من الضرورة.

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

for( int n = 0; n < 42; ++42 ) {
 // blah
}

...عندما اعتادوا على رؤية هذا:

for(int n = 0; n < 42; ++42 )
{
 // blah
}

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

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

أعتقد أن وجود قاعدة بيانات متسقة أمر مهم.إنه يزيد من قابلية صيانة الكود الخاص بك.إذا كان الجميع يتوقع نفس النوع من التعليمات البرمجية، فيمكنهم قراءتها وفهمها بسهولة.

إلى جانب ذلك، لا يمثل الأمر الكثير من المتاعب نظرًا لـ IDEs اليوم وقدرات التنسيق التلقائي الخاصة بها.

ملاحظة:لدي هذه العادة المزعجة المتمثلة في وضع تقويم الأسنان في السطر التالي :).لا يبدو أن أي شخص آخر يحب ذلك

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

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

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

في رأيي أعتقد أنه ضروري للغاية مع المعايير وأدلة الأسلوب.لأنه عندما تنمو قاعدة التعليمات البرمجية الخاصة بك، فسوف ترغب في جعلها متسقة.

كملاحظة جانبية، هذا هو سبب حبي لبايثون؛لأنه يفرض بالفعل الكثير من القواعد حول كيفية تنظيم تطبيقاتك وما شابه.قارن ذلك بـ Perl أو Ruby أو أي شيء آخر تتمتع فيه بحرية مطلقة (وهو أمر ليس جيدًا في هذه الحالة).

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

يجب أن تتبع جميع التعليمات البرمجية التي طورها الفريق المعين نفس المعيار تمامًا.
يجب أن تتبع جميع التعليمات البرمجية التي تم تطويرها لمشروع معين نفس المعيار تمامًا.
ومن المرغوب فيه أن تستخدم الفرق التي تنتمي إلى نفس الشركة نفس المعيار.

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

كما ذكر الآخرون، أعتقد أن الأمر يجب أن يكون عن طريق الهندسة أو عن طريق الفريق - الشركة (أي الشركة).وحدات الأعمال) لا ينبغي أن تشارك في هذا النوع من القرار.

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

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

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

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

مثل أي نظام آخر يهدف إلى الخير وليس الشر، فإن القوة الحقيقية للمرشد تكمن في أيدي شعبه.سيحدد المطورون أنفسهم ما هي الأجزاء الأساسية والمفيدة، ومن ثم، على أمل، استخدامها.

مثل القانون.أو اللغة الإنجليزية.

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

RTFM، ثم اجمع الأشياء الجيدة واستمر في ذلك.

نعم، أعتقد أن الشركات يجب أن تفعل ذلك.قد يحتاج المطور إلى التعود على أسلوب البرمجة ولكن في رأيي يجب أن يكون المبرمج الجيد قادرًا على العمل مع أي أسلوب برمجة.كما قال مدحت:من المهم أن يكون لديك قاعدة تعليمات برمجية متسقة.

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

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

نعم.

تعد معايير الترميز طريقة شائعة للتأكد من أن التعليمات البرمجية داخل مؤسسة معينة ستتبع مبدأ أقل المفاجآت:الاتساق في المعايير بدءًا من تسمية المتغير إلى المسافة البادئة إلى استخدام الأقواس المتعرجة.

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

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

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

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

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

تتضمن الإرشادات المهمة (بدون ترتيب معين):

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

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

وأوافق على أن الاتساق هو المفتاح.لا يمكنك الاعتماد على الطباعة الجميلة لـ IDE لإنقاذ الموقف، لأن بعض المطورين لديك قد لا يحبون استخدام IDE، ولأنه عندما تقوم بالبحث عبر قاعدة تعليمات برمجية مكونة من آلاف الملفات المصدر، فإنه ببساطة ليس من الممكن الطباعة الجميلة قم بطباعة جميع الملفات عند بدء العمل عليها، وقم بإجراء التراجع بعد ذلك حتى لا يحاول VCS الخاص بك الالتزام بجميع التغييرات (سد المستودع بتحديثات لا داعي لها والتي تثقل كاهل الجميع).

أود أن أقترح توحيد ما يلي على الأقل (حسب الترتيب التنازلي من حيث الأهمية):

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

رأيي:

بعض القواعد الأساسية جيدة لأنها تساعد الجميع على قراءة الكود والحفاظ عليه
تعتبر الكثير من القواعد سيئة لأنها تمنع المطورين من الابتكار بطرق أكثر وضوحًا لوضع التعليمات البرمجية
يمكن أن يكون النمط الفردي مفيدًا لتحديد محفوظات ملف التعليمات البرمجية.يمكن استخدام أدوات الاختلاف/اللوم ولكن التلميح لا يزال مفيدًا

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

نعم من حيث استخدام معيار تسمية شائع بالإضافة إلى تخطيط مشترك للفئات والتعليمات البرمجية خلف الملفات.كل شيء آخر مفتوح.

يجب على كل شركة.يضمن أسلوب الترميز المتسق إمكانية قراءة أعلى وقابلية للصيانة لقاعدة التعليمات البرمجية عبر فريقك بأكمله.

لا يمتلك المتجر الذي أعمل فيه معيارًا موحدًا للتشفير، ويمكنني القول إننا (كفريق) نعاني كثيرًا من ذلك.عندما لا تكون هناك إرادة من الأفراد (كما هو الحال مع بعض زملائي)، يتعين على قائد الفريق أن يضرب بقبضته على الطاولة ويفرض شكلاً من أشكال إرشادات الترميز الموحدة.

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

يعد إنشاء معيار رسمي أمرًا خاطئًا لأن معيار الترميز الخاص بالشركة عادةً ما يكون صارمًا للغاية وغير قادر على التدفق مع المجتمع العام باستخدام اللغة.

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

معايير الترميز:نعم.لأسباب تناولتها بالفعل في هذا الموضوع.

معايير التصميم:لا.إن قراءتك المقروءة هي غير المرغوب فيها المحيرة، والعكس صحيح.التعليق الجيد ومعاملة الكود لهما فائدة أكبر بكثير.المسافة البادئة لـ GNU أيضًا.

تعجبني إجابة إيليا لأنها تتضمن أهمية سهولة القراءة واستخدام التكامل المستمر كآلية للتنفيذ.ذكر Hibri FxCop، وأعتقد أن استخدامه في عملية البناء كأحد المعايير لتحديد ما إذا كان البناء ناجحًا أم فاشلًا سيكون أكثر مرونة وفعالية من مجرد توثيق المعيار.

أوافق تمامًا على ضرورة تطبيق معايير الترميز، ويجب أن تكون دائمًا على مستوى الفريق.ومع ذلك هناك بعض الاستثناءات.

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

هناك نوعان من الاتفاقيات.

اتفاقيات النوع أ:"من فضلك افعل هذا فهو أفضل"

والنوع ب:"من فضلك قم بالقيادة على الجانب الأيمن من الطريق"، بينما لا بأس بالقيادة على الجانب الآخر، طالما أن الجميع يفعل نفس الشيء.

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

أيضًا، يجب أن يكون المطور الجديد قادرًا على احترام ممارسات قاعدة التعليمات البرمجية الحالية ومتابعتها.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow