هل يجب أن تكون التعليمات البرمجية التي تم إنشاؤها قابلة للقراءة من قبل الإنسان؟
https://stackoverflow.com/questions/63257
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا أعمل على أداة من شأنها إنشاء الكود المصدري للواجهة وفئتين تنفذان تلك الواجهة.إن مخرجاتي ليست معقدة بشكل خاص، لذلك لن يكون من الصعب جعل المخرجات متوافقة مع معايير تنسيق التعليمات البرمجية العادية لدينا.
لكن هذا جعلني أفكر:ما مدى سهولة قراءة التعليمات البرمجية التي يتم إنشاؤها تلقائيًا؟متى يجب بذل جهد إضافي للتأكد من أن الكود الذي تم إنشاؤه يمكن قراءته وفهمه بسهولة من قبل الإنسان؟
في حالتي، فإن الفئات التي أقوم بإنشائها هي في الأساس مجرد حاويات لبعض البيانات المتعلقة بجزء آخر من البناء مع طرق للحصول على البيانات.لا ينبغي لأحد أن ينظر على الإطلاق إلى رمز الفئات نفسها، بل يحتاج فقط إلى استدعاء الحروف المختلفة التي توفرها الفئات.لذلك، ربما لا يكون من المهم جدًا أن تكون الشفرة "نظيفة" ومنسقة بشكل جيد ويسهل على الإنسان قراءتها.
ومع ذلك، ماذا يحدث إذا كنت تقوم بإنشاء تعليمات برمجية تحتوي على أكثر من قدر صغير من المنطق البسيط؟
المحلول
أعتقد أنه من المهم أيضًا أن تكون التعليمات البرمجية التي تم إنشاؤها قابلة للقراءة وتتبع أنماط الترميز العادية.في مرحلة ما، سيحتاج شخص ما إلى تصحيح التعليمات البرمجية أو رؤية ما يحدث "خلف الكواليس".
نصائح أخرى
نعم بالتاكيد!؛يمكنني حتى أن أقدم لك قصة لتوضيح سبب أهمية أن يتمكن الإنسان من قراءة الكود الذي تم إنشاؤه تلقائيًا بسهولة ...
لقد أتيحت لي ذات مرة فرصة العمل في مشروع جديد.الآن، أحد أول الأشياء التي عليك القيام بها عند البدء في كتابة التعليمات البرمجية هو إنشاء نوع من الاتصال وتمثيل البيانات من وإلى قاعدة البيانات.ولكن بدلاً من مجرد كتابة هذا الرمز يدويًا، كان لدينا شخص قام بتطوير منشئ التعليمات البرمجية الخاص به لإنشاء فئات أساسية تلقائيًا من مخطط قاعدة البيانات.لقد كان الأمر رائعًا حقًا، أصبحت المهمة الشاقة المتمثلة في كتابة كل هذه التعليمات البرمجية خارج أيدينا الآن ...كانت المشكلة الوحيدة هي أن الكود الذي تم إنشاؤه كان بعيدًا عن أن يكون قابلاً للقراءة لـ طبيعي بشر.
بالطبع لم نفكر في ذلك، لأنه وفر لنا الكثير من العمل.ولكن بعد فترة من الوقت بدأت الأمور تسوء، حيث تمت قراءة البيانات بشكل غير صحيح من إدخال المستخدم (أو هكذا اعتقدنا)، وحدث الفساد داخل قاعدة البيانات أثناء قيامنا بذلك فقط قراءة.غريب..لأن القراءة لا تغير أي بيانات (مرة أخرى، هكذا اعتقدنا)...
مثل أي مطور جيد، بدأنا في التشكيك في الكود الخاص بنا، ولكن بعد أيام من البحث..حتى عند إعادة كتابة الكود، لم نتمكن من العثور على أي شيء...وبعد ذلك اتضح لنا أن الكود الذي تم إنشاؤه تلقائيًا قد تم كسره!
والآن تنتظرنا مهمة أكبر، وهي التحقق من التعليمات البرمجية التي تم إنشاؤها تلقائيًا والتي لا يمكن لأي شخص عاقل أن يفهمها في فترة زمنية معقولة...أنا أتحدث عن رمز النمط غير البادئ والسيء حقًا مع أسماء المتغيرات والوظائف غير القابلة للنطق ...اتضح أنه سيكون من الأسرع إعادة كتابة الكود بأنفسنا، بدلاً من محاولة معرفة كيفية عمل الكود فعليًا.
في نهاية المطاف، قام المطور الذي كتب منشئ التعليمات البرمجية بإعادة تصميمه لاحقًا، لذلك أصبح ينتج الآن قابلة للقراءة الرمز، في حالة حدوث خطأ ما كما كان من قبل.
هنا رابط وجدت للتو حول الموضوع المطروح؛كنت أبحث في الواقع عن رابط لأحد الفصول من كتاب "المبرمج العملي". للإشارة إلى سبب بحثنا في الكود الخاص بنا أولاً.
أعتقد أن ذلك يعتمد على كيفية استخدام الكود الذي تم إنشاؤه.إذا لم يكن المقصود من الكود أن يقرأه البشر، على سبيل المثال.يتم تجديده كلما تغير شيء ما، ولا أعتقد أنه يجب أن يكون قابلاً للقراءة.ومع ذلك، إذا كنت تستخدم إنشاء التعليمات البرمجية كخطوة وسيطة في البرمجة "العادية"، فمن الممكن أن يكون للكود الذي تم إنشاؤه نفس سهولة القراءة مثل بقية التعليمات البرمجية المصدر.
في الواقع، قد يكون جعل التعليمات البرمجية التي تم إنشاؤها "غير قابلة للقراءة" ميزة، لأنها ستثني الأشخاص عن "اختراق" التعليمات البرمجية التي تم إنشاؤها، وبدلاً من ذلك تنفيذ تغييراتهم في منشئ التعليمات البرمجية بدلاً من ذلك - وهو أمر مفيد للغاية عندما تحتاج إلى إعادة إنشاء التعليمات البرمجية لأي سبب من الأسباب ولا تفقد التغييرات التي أجراها زميلك لأنه يعتقد أن الكود الذي تم إنشاؤه "انتهى".
نعم إنها كذلك.أولاً، قد تحتاج إلى تصحيح الأخطاء - ستسهل الأمر على نفسك.ثانيًا، يجب أن تلتزم بأي اتفاقيات ترميز تستخدمها في متجرك لأنه في يوم من الأيام قد يلزم تغيير الرمز يدويًا وبالتالي يصبح رمزًا بشريًا.يحدث هذا السيناريو عادةً عندما لا تغطي أداة إنشاء التعليمات البرمجية الخاصة بك شيئًا محددًا تحتاجه، ولا يعتبر تعديل الأداة مفيدًا لهذا الغرض فقط.
ابحث عن توليد التعليمات البرمجية النشطة ضد. توليد الكود السلبي.فيما يتعلق بتوليد التعليمات البرمجية السلبية، نعم بالتأكيد، دائما. فيما يتعلق بإنشاء التعليمات البرمجية النشطة، متى يحقق الكود هدف الشفافية، والذي يعمل تمامًا مثل واجهة برمجة التطبيقات الموثقة، إذن لا.
أود أن أقول إنه من الضروري أن يكون الكود قابلاً للقراءة من قبل الإنسان، ما لم تكن أداة إنشاء الكود الخاصة بك تحتوي على مصحح أخطاء ممتاز، فمن المحتمل أنك (أو زميل العمل المؤسف) ستحاول من خلال خصرك العميق في الكود تتبع هذا الخطأ بعيد المنال في النظام.لقد تركت رحلتي الخاصة إلى "التعليمات البرمجية من UML" مذاقًا مريرًا في فمي لأنني لم أتمكن من التعامل مع عملية تصحيح الأخطاء المفترضة "الهزلية".
الهدف الأساسي من التعليمات البرمجية التي تم إنشاؤها هو القيام بشيء "معقد" يسهل تعريفه في بعض اللغات ذات المستوى الأعلى.نظرًا لأنه يتم إنشاؤه، يجب أن تكون الصيانة الفعلية لهذا الكود الذي تم إنشاؤه ضمن الروتين الفرعي الذي يقوم بإنشاء الكود، وليس الكود الذي تم إنشاؤه.
ولذلك، ينبغي أن يكون لقابلية القراءة البشرية أولوية أقل؛تعتبر الأشياء مثل سرعة وقت التشغيل أو الوظيفة أكثر أهمية بكثير.هذا هو الحال بشكل خاص عندما تنظر إلى أدوات مثل Bison وFlex، والتي تستخدم التعليمات البرمجية التي تم إنشاؤها لإنشاء جداول بحث سريعة مسبقًا لإجراء مطابقة الأنماط، والتي سيكون من الجنون صيانتها يدويًا.
سوف تقتل نفسك إذا كان عليك تصحيح التعليمات البرمجية التي تم إنشاؤها بنفسك. لا تبدأ في التفكير أنك لن تفعل ذلك. ضع في اعتبارك أنه عندما تثق في التعليمات البرمجية الخاصة بك لإنشاء التعليمات البرمجية، فهذا يعني أنك قد أدخلت خطأين بالفعل في النظام - لقد أدخلت نفسك مرتين.
لا يوجد أي سبب على الإطلاق لعدم جعله قابلاً للتحليل البشري، فلماذا تريد أن تفعل ذلك في العالم؟
-آدم
هناك جانب آخر للمشكلة لم يتم ذكره وهو أن الكود الذي تم إنشاؤه يجب أن يكون أيضًا "سهل التحكم في الإصدار" (بقدر الإمكان).
لقد وجدت أنه من المفيد عدة مرات التحقق مرة أخرى من الاختلافات في التعليمات البرمجية التي تم إنشاؤها مقابل التعليمات البرمجية المصدر.
وبهذه الطريقة يمكنك أحيانًا العثور على أخطاء في الأدوات التي تولد التعليمات البرمجية.
من المحتمل جدًا أن يرغب شخص ما في المستقبل في الاطلاع على التعليمات البرمجية الخاصة بك ومعرفة ما يفعله.لذا فإن جعل الأمر مفهومًا إلى حد ما هو أمر جيد.
قد ترغب أيضًا في تضمين تعليق في أعلى كل ملف تم إنشاؤه يوضح كيفية إنشاء هذا الملف ولماذا تم إنشاؤه والغرض منه.
بشكل عام، إذا كنت تقوم بإنشاء تعليمات برمجية تحتاج إلى تعديلها بواسطة الإنسان لاحقًا، فيجب أن تكون قابلة للقراءة بواسطة الإنسان قدر الإمكان.ومع ذلك، حتى لو كانت التعليمات البرمجية التي سيتم إنشاؤها ولن يتم لمسها مرة أخرى، فلا تزال بحاجة إلى أن تكون قابلة للقراءة بدرجة كافية حتى تتمكن (باعتبارك المطور الذي يكتب منشئ التعليمات البرمجية) من تصحيح أخطاء المولد - إذا قام المولد الخاص بك بإصدار تعليمات برمجية سيئة، فقد يكون الأمر صعبًا لتعقب إذا كان من الصعب أن نفهم.
أعتقد أن الأمر يستحق أن نأخذ وقتًا إضافيًا لجعله قابلاً للقراءة من قبل الإنسان فقط لتسهيل تصحيح الأخطاء.
يجب أن تكون التعليمات البرمجية التي تم إنشاؤها قابلة للقراءة (يمكن عادةً التعامل مع التنسيق وما إلى ذلك بواسطة IDE نصف لائق).في مرحلة ما من عمر الكود، سيشاهده شخص ما وسيريد أن يفهمه.
أعتقد أنه بالنسبة لحاويات البيانات أو الكائنات ذات الأعمال المباشرة جدًا، فإن سهولة القراءة البشرية ليست مهمة جدًا.
ومع ذلك، بمجرد أن يضطر المطور إلى قراءة التعليمات البرمجية لفهم كيفية حدوث شيء ما، فإنه يجب أن يكون قابلاً للقراءة.ماذا لو كان المنطق لديه خطأ؟كيف سيكتشفه أي شخص إذا لم يتمكن أحد من قراءة الكود وفهمه؟سأذهب إلى أبعد من ذلك بإنشاء تعليقات لأقسام المنطق الأكثر تعقيدًا، للتعبير عن النية، لذلك من الأسهل تحديد ما إذا كان هناك خطأ بالفعل.
يجب أن يكون المنطق قابلاً للقراءة دائمًا.إذا كان شخص آخر سيقرأ الكود، فحاول أن تضع نفسك مكانه لترى ما إذا كنت ستفهم الكود بشكل كامل في المستوى العالي (والمنخفض؟) دون قراءة هذا الجزء المحدد من الكود.
لن أقضي الكثير من الوقت مع الكود الذي لن يتم قراءته أبدًا، ولكن إذا لم يكن الوقت طويلاً فسوف أتصفح الكود الذي تم إنشاؤه.إذا لم يكن الأمر كذلك، قم على الأقل بالتعليق لتغطية فقدان سهولة القراءة.
إذا كان من المحتمل أن يتم تصحيح هذا الرمز، فيجب عليك التفكير بجدية في إنشائه بتنسيق يمكن قراءته بواسطة الإنسان.
هناك أنواع مختلفة من التعليمات البرمجية التي تم إنشاؤها، ولكن الأنواع الأكثر بساطة هي:
- تم إنشاء التعليمات البرمجية التي ليس من المفترض أن يراها المطور.على سبيل المثال، كود xml-ish الذي يحدد التخطيطات (فكر في ملفات .frm، أو الملفات الرهيبة التي تم إنشاؤها بواسطة SSIS)
- التعليمات البرمجية التي تم إنشاؤها والتي من المفترض أن تكون أساسًا لفئة سيتم تخصيصها لاحقًا بواسطة المطور الخاص بك، على سبيل المثال، يتم إنشاء التعليمات البرمجية لتقليل ملل الكتابة
إذا كنت تصنع هذا الأخير، فأنت قطعاً تريد أن يكون الكود الخاص بك قابلاً للقراءة من قبل الإنسان.
الفئات والواجهات، بغض النظر عن كونها "خارجة عن الحدود" للمطورين التي تعتقد أنها ينبغي أن تكون، ستندرج بالتأكيد ضمن نوع التعليمات البرمجية الذي تم إنشاؤه رقم 2.سيتم ضربهم بواسطة مصحح الأخطاء عند نقطة واحدة أخرى - تطبيق تنسيق التعليمات البرمجية هو أقل ما يمكنك القيام به من سهولة عملية تصحيح الأخطاء عندما يصل المترجم إلى تلك الفئات التي تم إنشاؤها
مثل أي شخص آخر هنا تقريبًا، أقول اجعله قابلاً للقراءة.لا يكلفك الأمر شيئًا إضافيًا في عملية الإنشاء الخاصة بك وسوف تقدره أنت (أو خليفتك) عندما يبدأون في الحفر.
للحصول على مثال حقيقي - انظر إلى أي شيء ينشئه Visual Studio.منسق بشكل جيد، مع التعليقات وكل شيء.
التعليمات البرمجية التي تم إنشاؤها هي تعليمات برمجية، ولا يوجد سبب يمنع أن تكون أي تعليمات برمجية قابلة للقراءة ومنسقة بشكل جيد.هذا رخيص خاصة في الكود الذي تم إنشاؤه:لا تحتاج إلى تطبيق التنسيق بنفسك، فالمولد يقوم بذلك نيابةً عنك في كل مرة!:)
كخيار ثانوي في حال كنت كسولًا حقًا، ماذا عن تمرير الكود من خلال أداة تجميل من اختيارك قبل كتابته على القرص لضمان مستوى معين من الاتساق على الأقل.ومع ذلك، فإن جميع المبرمجين الجيدين تقريبًا الذين أعرفهم يقومون بتنسيق أكوادهم البرمجية بشكل متحذلق، وهناك سبب وجيه لذلك:لا يوجد رمز للكتابة فقط.
نعم بالتأكيد للعديد من الأسباب الوجيهة التي سبق ذكرها أعلاه.وهناك أمر آخر وهو أنه إذا كانت التعليمات البرمجية الخاصة بك بحاجة إلى التحقق من قبل أحد المقيمين (لقضايا السلامة والاعتمادية)، فمن الأفضل جدًا أن يكون الكود قابلاً لإعادة الاستخدام بواسطة الإنسان.إذا لم يكن الأمر كذلك، فسوف يرفض المقيم تقييمه وسيتم إعادة النظر في مشروعك من قبل السلطات.الحل الوحيد إذن هو التقييم..منشئ الأكواد (وهذا عادة ما يكون أكثر صعوبة ؛))
يعتمد ذلك على ما إذا كان سيتم قراءة الكود بواسطة مترجم فقط أم بواسطة إنسان أيضًا.بالإضافة إلى ذلك، من المهم ما إذا كان من المفترض أن تكون التعليمات البرمجية فائقة السرعة أو ما إذا كانت سهولة القراءة مهمة.عندما تكون في شك، ابذل جهدًا إضافيًا لإنشاء تعليمات برمجية قابلة للقراءة.
أعتقد أن الجواب هو:هذا يعتمد.
*يعتمد ذلك على ما إذا كنت بحاجة إلى تكوين التعليمات البرمجية التي تم إنشاؤها وتخزينها كقطعة أثرية.على سبيل المثال، نادرًا ما يحتفظ الأشخاص بمخرجات كود الكائن من مترجم c أو يقومون بتكوينها، لأنهم يعرفون أنه يمكنهم إعادة إنتاجها من المصدر في كل مرة.أعتقد أنه قد يكون هناك تشبيه مماثل هنا.*يعتمد ذلك على ما إذا كنت بحاجة إلى التصديق على الكود وفقًا لبعض المعايير، على سبيل المثال.ميسرا-C أو DO178.*يعتمد ذلك على ما إذا كان سيتم إنشاء المصدر عبر أداتك في كل مرة يتم فيها تجميع التعليمات البرمجية، أو ما إذا كان سيتم تخزينه لتضمينه في البنية في وقت لاحق.
شخصيًا، إذا كان كل ما تريد فعله هو إنشاء الكود، وتجميعه في ملف قابل للتنفيذ ثم التخلص من الكود الوسيط، فلا أرى أي فائدة في جعله جميلًا للغاية.
