كيفية كتابة التعليقات على التعهدات

مقدمة من المترجم

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

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

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

مقدمة: لماذا تعتبر التعليقات الجيدة مهمة

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

 سجل بوابة $ - عبر الإنترنت -5 - cbeams المؤلف - قبل "الجمعة 26 مارس 2009"

 e5f4b49 إعادة إضافة ConfigurationPostProcessorTests بعد إزالته لفترة وجيزة في r814.  @ تجاهل طريقة testCglibClassesAreLoadedJustInTimeForEnhancement () حيث اتضح أن ذلك كان أحد المتهمين في كسر البناء الأخير.  يتسبب قرصنة محمل الفصل في تأثيرات خفية في المصب ، وكسر الاختبارات غير ذات الصلة.  لا تزال طريقة الاختبار مفيدة ، ولكن يجب تشغيلها فقط على أساس يدوي لضمان عدم تحميل CGLIB قبل الأوان ، ويجب ألا يتم تشغيله كجزء من الإنشاء التلقائي.
 قام 2db0f12 بإصلاح مشكلتين أساسيتين: + إرجاع ClassMetadataReadingVisitor إلى المراجعة 794 + إزالة ConfigurationPostProcessorTests حتى يحدد التحقيق الإضافي سبب فشل اختبارات المصب (مثل ClassPathXmlApplicationContextTests التي تبدو غير ذات صلة)
 147709f قرص لملفات package-info.java
 22b25e0 دمج Util و MutableAnnotationUtils الفئات في AsmUtils الموجودة
 7f96f57 تلميع

رعب. قارن مع هذه التعهدات الأحدث في نفس المستودع:

 سجل بوابة $ - عبر الإنترنت -5 - المؤلف pwebb - قبل "السبت 30 أغسطس 2014"

 5ba3db6 إصلاح فشل CompositePropertySourceTests
 84564a0 إعادة العملPropertySource منطق التحليل المبكر
 e142fd1 أضف اختبارات للبيانات الوصفية لـ ImportSelector
 887815f تحديث تبعية docbook وتوليد epub
 ac8326d استخدام موكيت البولندية

أي خيار تفضل؟

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

وعلى الرغم من أن تاريخ الالتزام بالعديد من المستودعات يبدو الخيار الأول ، إلا أن هناك استثناءات. الأمثلة الرائعة هي نواة لينكس و Git نفسها . ألق نظرة على Spring Boot أو أي مستودع آخر يتعامل معه Tim Pope .

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

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

إذا لم تكن قد فكرت حقًا في ما يجب أن يكون عليه تعليق الالتزام من الدرجة الأولى ، فمن المحتمل أنك لم تستخدم سجل git والأدوات المماثلة كثيرًا. هناك حلقة مفرغة: بما أن تاريخ ارتكاب الجرائم غير منظم وغير متجانس ، فإنهم لا يستخدمونه ولا ينتبهون. ولأنهم لا يستخدمونها ولا يهتمون بها ، فإنها تظل غير منظمة وغير متجانسة.

لكن قصة مستودع جيدة التصميم هي شيء جميل ومفيد. الأوامر اللوم ، تعود ، rebase ، سجل ، Shortlog وغيرها تأتي إلى الحياة . من المنطقي أن ننظر إلى التزامات الآخرين وسحب الطلبات ، وفجأة ، لم تعد مساعدة مؤلفيهم مطلوبة الآن. لفهم سبب حدوث شيء ما في [الكود] قبل أشهر أو سنوات ، يصبح الأمر ليس ممكنًا فحسب ، بل مناسبًا أيضًا.

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

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

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

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

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

المحتوى ما هي المعلومات التي يجب تضمينها (على الإطلاق) في نص التعليق؟ لماذا لا تكون هناك؟

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

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

سبع قواعد لتعليق باردة باردة

تذكر: كل هذا قيل من قبل .

1. افصل الرأس عن الجسم بسلسلة فارغة
2. يجب ألا يزيد عدد أحرف العنوان عن 50 حرفًا
3. تكبير العنوان الرئيسي
4. لا تضع نقطة في نهاية العنوان
5. استخدم الأمر في العنوان.
6. انتقل إلى السطر التالي في الجسم مع 72 حرفًا
7. في الجسم ، أجب على أسئلة ماذا ولماذا وليس كيف

على سبيل المثال:

 تلخيص التغييرات في 50 حرفًا أو أقل

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

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

 يتم فصل الفقرات بواسطة أسطر فارغة.

  - يمكنك عمل قوائم ذات تعداد نقطي

  - عادة علامة النجمة أو 
    شرطة مع مسافة أمامهم  ولكن هناك اتفاقيات مختلفة

 إذا كان لديك أداة تتبع الأخطاء [أو نظام إدارة المشروع] ،
 ضع روابط المهام في نهاية النص بهذه الطريقة:

 محلولة: # 123
 انظر أيضًا: # 456 ، # 789

1. افصل الرأس عن الجسم بسلسلة فارغة

من الدليل إلى الأمر git الالتزام :

على الرغم من أن هذا ليس ضروريًا ، فمن الجيد أن تبدأ تعليقًا على الالتزام بخط واحد قصير (أقل من 50 حرفًا) يلخص التغييرات التي تم إجراؤها ، ثم سطر فارغ ثم وصف أكثر تفصيلاً. يعتبر النص قبل السطر الفارغ الأول في التعليق رأس الالتزام ويستخدم في أوامر Git المختلفة. على سبيل المثال ، Git-format-patch (1) يحول الالتزام إلى بريد إلكتروني ؛ يستخدم الفريق رأس الالتزام لموضوع الرسالة وباقي النص في نص الرسالة.

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

  إصلاح الخطأ المطبعي في مقدمة دليل المستخدم 

قال ما يكفي ؛ إذا أراد المستخدم معرفة نوع الخطأ المطبعي الذي تم إصلاحه ، يمكنه فقط إلقاء نظرة على التغييرات بأنفسهم باستخدام git show أو git diff ، أو git log -p .

إذا ارتكبت شيئًا من هذا القبيل باستخدام سطر الأوامر ، فسيكون من الملائم استخدام الخيار -m لتنفيذ git :

  الالتزام $ git -m "إصلاح الخطأ المطبعي في مقدمة دليل المستخدم" 

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

 Derezz برنامج التحكم الرئيسي

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

التعليقات التي تحتوي على نص ليس مناسبًا لكتابتها باستخدام الخيار -m . سيكون من الأفضل استخدام محرر نصوص لهذا الغرض. إذا لم تقم بعد بتهيئة المحرر للاستخدام مع Git ، فاقرأ هذا القسم من كتاب Pro Git .

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

 سجل $ git
 الالتزام 42e769bdf4894310333942ffc5a15151222a87be
 المؤلف: كيفين فلين <kevin@flynnsarcade.com>
 التاريخ: الجمعة يناير 01 00:00:00 1982 -2002

  Derezz برنامج التحكم الرئيسي

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

وها هو الأمر git log --oneline الذي يعرض فقط خط الرأس:

 سجل $ git - على الإنترنت
 42e769 Derezz برنامج التحكم الرئيسي

أو git shortlog ، التي تلتزم بها المجموعات من قبل المؤلف ، مرة أخرى ، للإيجاز ، يظهر العنوان فقط:

 اختصار $ git
 كيفين فلين (1):
       Derezz برنامج التحكم الرئيسي

 آلان برادلي (1):
       إدخال برنامج الأمن "ترون"

 إد ديلينجر (3):
       إعادة تسمية برنامج الشطرنج إلى "MCP"
       تعديل برنامج الشطرنج
       ترقية برنامج الشطرنج

 والتر جيبس ​​(1):
       إدخال برنامج الشطرنج protoype

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

2. قصر العنوان على 50 حرفًا

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

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

تدعم واجهة GitHub هذه الاتفاقيات بشكل واضح. سيحذرك إذا تجاوزت الحد المسموح به وهو 50 حرفًا:


وقطع جميع الرؤوس التي يزيد طولها عن 72 حرفًا ، واستبدال القطع الناقص:


لذا حاول الوصول إلى 50 حرفًا ، ولكن ضع في اعتبارك أن 72 حرفًا صارمًا.

3. تكبير العنوان

كل شيء بسيط هنا. تكبير جميع العناوين.

على سبيل المثال:

• تسارع إلى 88 ميلاً في الساعة

بدلاً من ذلك:

• تسارع إلى 88 ميلا في الساعة

4. لا تضع نقطة في نهاية العنوان

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

على سبيل المثال:

• افتح أبواب حجرة الكبسولة

بدلاً من ذلك:

• افتح أبواب حجرة الكبسولة.

5. استخدم الحتمية في العنوان.

الحالة الحتمية تعني حرفياً: شكل فعل يعبر عن إرادة (طلب أو طلب أو نصيحة). بعض الأمثلة:

• نظف غرفتك (رتب الغرفة)
• أغلق الباب
• أخرج القمامة

كل من القواعد السبع التي تقرأ عنها مكتوبة في الحالة الحتمية ("اذهب إلى السطر التالي في الجسم مع 72 حرفا" ، وما إلى ذلك).

قد يبدو هذا النموذج وقحًا قليلاً ، وبالتالي لا يستخدم كثيرًا [باللغة الإنجليزية - تقريبًا. عبر. ]. لكنها مثالية لرأس الالتزام. أحد الأسباب هو حقيقة أن Git نفسها تستخدم الضرورة عندما ترتكب نيابة عنك.
على سبيل المثال ، عند استخدام دمج git ، ستتم إضافة الرسالة التالية بشكل افتراضي:

 دمج فرع "myfeature"

وعند استخدام git العودة :

 إعادة "إضافة الشيء مع الأشياء"
	
 هذا يعود إلى ارتكاب cc87791524aedd593cff5a74532befe7ab69ce9d.

أو عند النقر فوق الزر "دمج" في واجهة طلب السحب على GitHub:

 دمج طلب السحب # 123 من someuser / somebranch

لذا ، عندما تكتب رسائل الالتزام الخاصة بك في الحالة الحتمية ، فإنك تتبع القواعد المنصوص عليها في Git نفسها. على سبيل المثال:

• النظام الفرعي لإعادة البناء X لسهولة القراءة
• تحديث وثائق البدء
• إزالة الطرق المهملة
• نسخة الإصدار 1.0.0

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

• علة ثابتة مع ص
• تغيير سلوك X

وأحيانًا تصف العناوين ببساطة محتويات الالتزام:

• المزيد من الإصلاحات للأشياء المكسورة
• طرق API جديدة حلوة

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

يجب أن يستكمل رأس الالتزام المكون بشكل صحيح الجملة التالية:

• إذا تم تطبيق هذا الالتزام سوف < الالتزام رأس >

على سبيل المثال:

• في حالة تطبيقه ، سيعمل هذا الالتزام على إعادة بناء النظام الفرعي X لسهولة القراءة
• إذا تم تطبيق هذا الالتزام ، فسيتم تحديث وثائق البدء
• إذا تم تطبيقه ، فسيزيل هذا الالتزام الطرق المتروكة
• إذا تم تطبيقه ، سيصدر هذا الالتزام الإصدار 1.0.0

إذا تم تطبيق هذا الالتزام ، فسوف يدمج طلب السحب # 123 من المستخدم / الفرع

تأكد من أن الأفعال في حالات مزاجية أخرى غير ضرورية لا تعمل هنا:

• إذا تم تطبيق هذا الالتزام ، سيتم إصلاح الخلل مع Y
• إذا تم تطبيقه ، سيؤدي هذا الالتزام إلى تغيير سلوك X
• إذا تم تطبيقه ، فإن هذا الالتزام سيصلح المزيد من الإصلاحات للأشياء المكسورة
• إذا تم تطبيقه ، فإن هذا الالتزام سيعمل على استخدام طرق API الجديدة

تذكر: استخدام الأمر المهم مهم فقط في رأس الالتزام. في نص الإلتزام ، هذا اختياري.

6. انتقل إلى السطر التالي في الجسم مع 72 حرفًا

لا يقوم Git نفسه بترتيب فواصل الأسطر تلقائيًا. عند تعديل نص التعليق ، يجب أن تتذكر الحد الأيمن وتعيين فواصل الأسطر يدويًا.

من المستحسن أن تذهب إلى السطر التالي بـ 72 حرفًا حتى يتمكن Git من وضع مسافة بادئة ويظل مناسبًا لـ 80 حرفًا في المجموع.

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

7. في الجسم ، أجب على الأسئلة "ماذا" و "لماذا" ، وليس "كيف"

يوفر هذا الالتزام من مستودع Bitcoin شرحًا ممتازًا لما ولماذا تغير:

 الالتزام eb0b56b19017ab5c16c745e6da39c53126924ed6
 المؤلف: بيتر وويل <pieter.wuille@gmail.com>
 التاريخ: الجمعة 1 أغسطس 22:57:55 2014 +0200

    تبسيط معالجة الاستثناء serialize.h

    إزالة "الحالة" و "باستثناء قناع" من دفق التسلسل. h
    التنفيذ ، وكذلك الأساليب ذات الصلة.

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

    نتيجة لذلك ، لا يتم الوصول إلى () جيدًا بعد الفشل (يوجد
    مكالمتان فقط ، إحداهما في الاختبارات) ، ويمكن استبدالهما فقط
    بواسطة! eof ().

    فشل () ، لا يتم استدعاء (n) والاستثناءات () مطلقًا.  حذف
    لهم.

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

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

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

ربما في المستقبل ستشكر نفسك على هذا!

نصائح

أحب سطر الأوامر. نسي IDE.

هناك العديد من الأسباب - من خلال عدد أوامر Git - لاستخدام سطر الأوامر إلى أقصى حد. Git هو أداة قوية بجنون. IDE - أيضًا ، ولكن كل منها بطريقته الخاصة. أستخدم IntelliJ IDEA كل يوم ، غالبًا ما كان علي التعامل مع الآخرين (على سبيل المثال ، Eclipse) ، لكنني لم أر أبدًا أن دمج Git في IDE يمكن مقارنته بالبساطة والقدرات مع سطر الأوامر (بمجرد فهمك لها).

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

عندما تحتاج إلى فتح الإمكانات الكاملة لـ Git ، فإن سطر الأوامر لا يعلى عليه.
تذكر أنه سواء كنت تستخدم Bash أو Zsh أو Powershell - فهناك نصوص برمجية لإكمال الأوامر التي تنقذك من الحاجة الماسة لتذكر جميع الأوامر الفرعية والخيارات.

اقرأ كتاب Pro Git Book

كتاب Pro Git الرائع ( أيضًا باللغة الروسية - ترجمة تقريبًا ) متاح مجانًا. استفد من هذا!