Fixing the PR Bottleneck — Matt Pocock, AIHero

Watch on YouTube

Now Playing

Transcript

948 segments

0:01

حسناً. أنا هنا للحديث

0:03

عن معالجة عنق زجاجة

0:05

طلبات السحب (PR)، وهذا

0:06

عنوان ضخم لمحاولة

0:08

إصلاح مشكلة تكافح

0:09

معها معظم المؤسسات،

0:11

وأعتقد أنها كانت

0:12

تكافح معها تاريخياً

0:14

قبل الذكاء الاصطناعي

0:15

، أتعلمون؟ لطالما كان

0:17

لدينا عدد هائل من

0:18

طلبات السحب المعلقة

0:19

التي لم يكلف أحد نفسه

0:21

عناء مراجعتها، وقد

0:22

تزايد هذا الأمر بشكل

0:23

كبير الآن بسبب الضغوط

0:25

الجديدة التي يفرضها

0:26

الذكاء الاصطناعي بكل

0:27

قيوده الغريبة.

0:28

وللقيام بذلك،

0:29

سأستخدم معايير

0:31

مهاراتي، التي ربما

0:32

سمعتم عنها، وربما

0:34

استخدمتموها. ولديّ

0:35

مهارتان جديدتان

0:36

لأعلن عنهما، نأمل أن

0:38

تحسّنا طريقة تعاملكم

0:40

مع طلبات السحب،

0:41

وتحسّنا السرعة التي

0:43

يمكنكم بها مراجعتها

0:44

وإنجازها. السرعة. لقد

0:47

دُفعنا للقيام

0:48

بالمزيد بموارد أقل،

0:50

في الأساس، أو التعامل

0:52

مع طلبات سحب أكثر،

0:53

ومزيد من العمل، وما

0:55

إلى ذلك. وهذا هو الوعد

0:57

المركزي للذكاء

0:58

الاصطناعي، بأننا

0:59

سنكون قادرين على

0:59

استخدام هذه الوكلاء

1:01

لتوسيع نطاق عملنا

1:02

وإنجاز المزيد. وقد

1:03

أدى هذا إلى ظهور "مصنع

1:04

البرمجيات"، ربما

1:05

الكلمة الطنانة

1:06

الأكبر في يومنا هذا.

1:07

الجميع يتحدث عن مصنع

1:09

البرمجيات كلما أتيحت

1:10

لي الفرصة. وأنا أعتبر

1:12

مصنع البرمجيات في

1:13

المقام الأول مكاناً

1:14

لا يقوم فيه الإنسان

1:16

ببدء كل هذا العمل، بل

1:18

سنقوم بنقل بعض مهام

1:19

البدء هذه. سيتم تنفيذ

1:21

بعض عمليات البدء

1:22

بواسطة الوكلاء. وأنا

1:24

أفكر في ذلك ربما من

1:50

هناك يكون لديك

1:51

مُصنِّف مثل "جيف"

1:52

ليقول: "حسناً، دعونا

1:53

نحول هذا إلى إصلاح أو

1:54

إلى محاكاة للمشكلة".

1:56

أو ربما أقوم بتنبيه

1:57

الأشخاص مباشرة. وربما

1:59

يكون لديك أشياء أخرى.

2:00

ربما لديك "Planet Scale"

2:01

متصل، ليقدم لك تقارير

2:02

حول الاستعلامات

2:03

البطيئة في قاعدة

2:04

بياناتك. ربما يؤدي

2:05

ذلك بعد ذلك إلى تشغيل

2:06

جزء مختلف من مصنع

2:07

البرمجيات الخاص بك.

2:08

كل هذا لا يُشغَّل

2:09

بواسطة البشر، بل

2:11

بواسطة تعليمات

2:12

برمجية حتمية، أليس

2:13

كذلك؟ وهذه العناصر

2:14

تسرع من عمل مصنع

2:15

البرمجيات الخاص بك.

2:16

إنها تدفع بالمزيد من

2:17

التعليمات البرمجية

2:18

عبره. لكن بعد ذلك

2:19

تحتاج إلى مكابح، أليس

2:21

كذلك؟ إذا كان لديك

2:22

تسارع دائم يدفع

2:23

بالأشياء عبر مصنعك،

2:25

فسينتهي بك الأمر

2:26

بمدفع فوضى، أليس كذلك

2:27

؟ سينتهي بك الأمر

2:29

بمجرد كومة من طلبات

2:30

السحب الرديئة التي لن

2:31

تتمكن من لمسها أو

2:33

مراجعتها أو حتى النظر

2:34

إليها. لذا فأنت بحاجة

2:36

إلى مكابح. هذه هي

2:37

الآليات التي تبطئ

2:38

الوتيرة، وتزيد

2:39

الجودة، وتضمن ألا

2:41

تتحول قاعدة

2:41

التعليمات البرمجية

2:43

الخاصة بك إلى كابوس

2:44

من الفوضى البرمجية،

2:45

لأن الكود هو البيئة

2:47

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

2:48

إذا كان لديك كود سيئ

2:50

في قاعدة بياناتك،

2:51

فسيؤدي ذلك إلى توليد

2:52

المزيد من الكود السيئ

2:53

. لذا، سأتحدث عن هذه

2:55

الفواصل الثلاثة في

2:57

هذا العرض، وكيف

2:58

يمكننا استخدامها

2:59

لنكون أسرع بشكل غير

3:01

متوقع. إذًا، الفحوصات

3:03

الآلية. هذه هي

3:04

الفحوصات الحتمية في

3:05

مستودع الكود الخاص بك

3:06

، والتي نستخدمها منذ

3:08

آلاف السنين، أو ربما

3:09

منذ الخمسينيات.

3:10

فحوصات حتمية تتضمن

3:11

التدقيق اللغوي،

3:13

والاختبارات، وفحص

3:15

الأنواع، وجودة الكود

3:16

؛ كلها تعمل معًا

3:18

وبنفس الطريقة في كل

3:20

مرة. وفوق ذلك، لدينا

3:22

المراجعة الآلية. حيث

3:23

نستخدم وكلاء يفحصون

3:25

الكود ويقولون: "حسنًا

3:27

، هذه للأشياء التي لم

3:28

تكتشفها الاختبارات،

3:30

أو للنظر في بنية

3:31

الكود بشكل عام". وفوق

3:33

ذلك، الطبقة الثالثة

3:34

والأخيرة هي المراجعة

3:36

البشرية. أي أشخاص

3:37

يقومون بمراجعة طلبات

3:38

السحب (PRs). هذه الطبقات

3:40

الثلاث تشكل هذا النوع

3:41

من الكعكة التي ينتهي

3:42

بنا المطاف بها عند

3:44

المراجعة البشرية.

3:45

وبالطبع، السرعة

3:46

الأكبر تعني المزيد من

3:47

طلبات السحب. لذا،

3:49

الهدف هنا هو جعل

3:50

المراجعة البشرية

3:51

أسرع بالاعتماد على

3:52

المرحلتين الأوليين.

3:54

وسوف نضع حداً للفوضى.

3:56

هذا هو المبدأ الأول؛

3:58

إذا رفعت جودة الكود

4:00

الذي تقدمه، ستقوم

4:02

بمراجعة بشرية أقل لأن

4:04

العمل سيكون أفضل،

4:05

وبالتالي ستحتاج إلى

4:07

تدخلات أقل. إذًا،

4:10

الفحوصات الآلية.

4:12

الفحوصات الآلية غير

4:13

مكلفة. الشيء الرائع

4:15

فيها أنها لا تستهلك

4:16

رموزًا (tokens) كما تفعل

4:17

المراجعة الآلية، ولا

4:19

تتطلب جهدًا بشريًا،

4:20

بل تستهلك فقط دورات

4:21

المعالج. على سبيل

4:22

المثال، تقوم بتشغيل

4:23

الاختبارات الخاصة بك

4:24

مع كل تغيير في الكود.

4:26

ربما تتطلب تلك

4:27

الاختبارات بعض

4:28

الرموز، لنقل إن

4:29

وكيلًا تسبب في خطأ

4:30

واكتشفه الاختبار،

4:31

حينها تحتاج لإنفاق

4:33

بعض الرموز لإصلاحه.

4:34

لكن في رأيي، هذه رموز

4:36

أنفقت بشكل جيد جدًا.

4:37

إذًا، الفحوصات غير

4:39

مكلفة. هذا يعني أنه

4:40

يمكنك إضافة الكثير

4:41

والكثير منها إلى

4:43

مستودعاتك. وربما أنت

4:44

لا تستخدم ما يكفي

4:45

منها أو لست مبدعًا

4:46

بما يكفي في استخدامها

4:48

. لكن، الفحوصات يمكن

4:50

أن تكذب. هل يعني نجاح

4:52

الاختبارات التلقائية

4:53

(CI) أن الكود جاهز

4:55

للدمج؟ لا، ليس كذلك.

4:57

لذا، كنا نحتاج دائمًا

4:58

، بالإضافة إلى هذه

4:59

الفحوصات، إلى طبقة

5:01

إضافية لمعرفة ما إذا

5:02

كان هناك أي خطأ كارثي

5:03

في الكود قبل طرحه.

5:05

وهكذا، فإن جميع

5:06

المراحل الأخرى،

5:07

المراجعة البشرية

5:08

والمراجعة الآلية، هي

5:09

في الواقع أجهزة كشف

5:10

كذب. إنها مخصصة لكشف

5:12

الأكاذيب في الفحوصات

5:13

الآلية. الآن، أريد أن

5:15

أريكم بعض هذه

5:16

الأكاذيب، أولاً لأن

5:17

هذا يساعدنا عند

5:18

التفكير في الكود

5:20

والاختبارات الآلية

5:21

لندرك مدى سوء الأمر

5:23

وتفاقمه. أولها

5:24

الاختبارات التكرارية

5:25

(تحصيل حاصل). اختبار

5:27

يعيد تأكيد التنفيذ لا

5:28

أكثر. أدمن "أوبوس 5"

5:30

على استخدام هذه

5:30

الاختبارات. لا أفهم

5:32

تماماً لماذا. كان

5:33

لديها، على سبيل

5:34

المثال، حد أحرف منشور

5:36

X يساوي 280. هل يمكن

5:37

لأحد تخمين الاختبار

5:38

الذي كُتب لاختبار هذا

5:40

السلوك؟ أليس كذلك؟

5:41

ربما رأيت هذا ألف مرة

5:43

من قبل. هذا كود حقيقي

5:44

من وكلاء أو من أشياء

5:45

وجدتها تقوم بها

5:46

الوكلاء. لقد نص على: "

5:48

توقع أن يكون حد أحرف

5:50

منشور X هو 280". هكذا بدا

5:52

التنفيذ. وبشكل أساسي،

5:54

أعاد الاختبار تأكيد

5:56

التنفيذ. هذا هو

5:57

الاختبار التكراري.

5:59

والاختبارات

6:00

التكرارية سيئة لأنها

6:02

حساسة للغاية تجاه

6:04

الهيكلية. إنها حساسة

6:06

جداً لآليات العمل

6:08

الداخلية للنظام. هذا

6:09

يعني أنني لا أستطيع

6:11

تغيير ذلك الثابت دون

6:12

فشل الاختبار. ولا

6:14

يمكنني إعادة تسمية

6:15

ذلك الثابت دون فشل

6:17

الاختبار أيضاً. إنه

6:18

مرتبط بشدة بهيكلية

6:20

نظامي. ووجدت مثالاً

6:22

آخر أكثر فظاعة، إن

6:24

جاز التعبير. هذا

6:26

اختبار لا يصدق. ما

6:29

يفعله هنا هو اختبار

6:30

ما إذا كان عنصران في

6:32

واجهة المستخدم

6:33

يظهران بالترتيب

6:34

الصحيح. إنه يتحقق من

6:36

أن صفحة تفاصيل العرض

6:38

أو قسم الفيديو يأتي

6:39

بعد خطة المحتوى. ما

6:41

يفعله هو أنه لا يقوم

6:43

بعرضه على الشاشة. بل

6:45

يقرأ الملف الفعلي،

6:46

والوحدة البرمجية في

6:48

ذاكرته، ثم يبحث عن

6:50

الشيء الصحيح. إذن،

6:52

يجد خطة المحتوى، ويجد

6:54

الفيديوهات، ثم يتوقع

6:56

أن تأتي الفيديوهات

6:57

بعدها في المصدر. وهو

6:59

أمر جنوني إذا فكرت

7:00

فيه، لأنني أستطيع

7:01

ببساطة تغيير شكل

7:02

المادة المصدرية

7:04

وسيفشل هذا الاختبار.

7:05

إنه حساس للغاية

7:06

لهيكلية قاعدة الكود

7:07

الخاصة بي. لذا، هذه

7:08

طريقة أخرى يمكن أن

7:10

تفشل بها الفحوصات

7:10

الآلية. وهناك أيضاً...

7:12

أوه، عذراً. الفحوصات

7:14

الآلية يمكنها أن تكذب

7:15

. هناك أيضاً اختبارات

7:17

لا يمكن أن تفشل

7:18

حرفياً. سيبدو هذا

7:19

مألوفاً لك إذا كنت قد

7:20

أسرفت في استخدام "

7:21

المحاكاة"(Mocking) سابقاً

7:22

أو استخدمت أشياء

7:23

مشابهة. على سبيل

7:24

المثال، لدينا هنا

7:26

وظيفة استخدام تعزيز

7:27

الصوت. وهذه الوظيفة،

7:29

تستخدم داخلها واجهة

7:30

برمجة تطبيقات سياق

7:31

الصوت في نموذج كائن

7:33

المستند (DOM). لا تقلق

7:34

إذا لم تكن تعرف أياً

7:35

من هذه المصطلحات. لكن

7:36

ما نقوم به هنا هو مجرد

7:38

إنشاء هيكل زائف ببعض

7:39

الطرق الوهمية. واتضح

7:40

أن سياق الصوت لديه

7:42

أوضاع خطأ معقدة،

7:43

وسيفشل إذا استخدمته

7:45

في ظروف غريبة. لذا،

7:47

القيام بهذا فقط يعني

7:48

أن اختبارنا لا يمكن

7:49

أن يفشل باستخدام تلك

7:50

الأوضاع، وسنواجه

7:52

أخطاء غريبة في

7:52

الإنتاج لا تستطيع

7:54

اختباراتنا إصلاحها.

7:55

إذن السؤال هو، إذا

7:56

كان بإمكانك التحايل

7:58

على الاختبارات

7:59

الآلية، سواء كنت تعلم

8:01

بذلك، وحتى بطرق حسنة

8:03

النية أيضًا. الذكاء

8:04

الاصطناعي لا يحاول

8:06

كتابة اختبارات سيئة

8:07

هنا. إنه يأخذ

8:08

تعليماتنا فقط ويكتب

8:10

اختبارات مرتبطة بشكل

8:11

مفرط بالهيكل بدلاً من

8:13

تنفيذ الكود فعليًا.

8:14

فكيف نجعل الاختبارات

8:16

الآلية أصعب في

8:17

التحايل عليها؟ إذا

8:18

استطعنا فعل ذلك،

8:19

فيمكننا زيادة جودة

8:21

تلك الاختبارات، مما

8:22

يعني رفع معايير

8:23

الجودة لدينا. وأول

8:25

شيء أحبه حقًا في هذا

8:26

هو التصميم القائم على

8:28

الكود. إذ يمكنك في

8:29

الواقع تصميم مخرج لك

8:31

من هذه الاختبارات

8:32

السيئة. إذًا، كيف

8:33

يبدو التصميم الجيد

8:34

القائم على الكود؟ لقد

8:36

تحدثت عن هذا من قبل في

8:37

محادثات سابقة عن

8:38

هندسة الذكاء

8:38

الاصطناعي، وهي

8:39

الوحدات البرمجية

8:40

العميقة. هذه وحدات

8:41

تخفي سلوكًا معقدًا

8:43

خلف واجهات بسيطة. هذه

8:45

فكرة لجون أوسترهوت من

8:46

فلسفة تصميم

8:47

البرمجيات. إذا نظرنا

8:49

إلى هاتين الوحدتين،

8:50

لدينا (أ)، التي تحتوي

8:52

على تنفيذ كبير يختبئ

8:54

خلف واجهة صغيرة في

8:55

الأعلى. هل هذا مفهوم؟

8:57

ثم لدينا (ب) وهي واجهة

8:58

كبيرة، بها الكثير من

9:00

الوظائف التي يمكنك

9:01

استدعاؤها، وتلك

9:02

الوظائف فرديًا لا

9:03

تفعل الكثير. هل يبدو

9:04

هذا منطقيًا؟ أجل؟

9:06

الآن، إذا كان لديك

9:07

وحدة عميقة مثل (أ) هنا

9:09

، سيكون لديك عدد أقل

9:11

من الاختبارات

9:12

الحساسة للهيكل لأنك

9:14

تخفي المزيد من

9:15

التنفيذ خلف تلك

9:16

الواجهة. إذا كان

9:17

الاختبار يتم فقط عند

9:19

تلك الواجهة، فستحصل

9:20

على اختبارات أفضل.

9:21

لذا، مهمتك هنا هي

9:23

إجبار الوكلاء على

9:24

استخدام تلك الواجهة

9:25

الصغيرة بدلاً من

9:27

الوصول إلى التنفيذ

9:28

لاختبار تفاصيل

9:29

التنفيذ الغريبة هذه.

9:31

لذا، لدي مهارة لهذا

9:33

الغرض. يمكنك الحصول

9:35

على أكثر قواعد الكود

9:36

غرابة، وأسوأ قاعدة

9:38

كود وقعت عليها عيناك،

9:40

ويمكنك تشغيل هذه

9:41

المهارة عليها

9:42

وستجعلها أفضل. ما

9:44

يفعله هذا أساسًا هو

9:45

منحك فرصًا لتعميق

9:46

الوحدات البرمجية.

9:48

ويبدو الأمر هكذا

9:49

تقريبًا. ارفعوا

9:50

أيديكم إذا كنتم قد

9:50

استخدمتم هذه المهارة

9:51

، بالمناسبة. لست

9:52

متأكدًا من عدد

9:53

الأشخاص الذين

9:53

يتبعونني في هذه

9:54

القاعة. أجل، حسنًا.

9:55

إنه أمر رائع حقًا.

9:57

بشكل أساسي، إنه يمنحك

9:58

مستند HTML. سأبتعد عن

10:00

الطريق هنا. لكل الفرص

10:01

المختلفة والمحتملة

10:03

التي يراها. لذا،

10:04

يمكننا أن نرى هنا

10:05

حالة قبل وحالة بعد،

10:07

حيث نقوم نوعاً ما

10:08

بتقليل التكرار،

10:09

وننشئ وحدة برمجية

10:10

عميقة وقابلة

10:11

للاختبار. ومن ثم

10:13

يمكنك المضي قدماً في

10:14

تنفيذ ذلك. وملحق بهذا

10:16

، هناك أيضاً نوع من

10:17

اللغة التي جمعتها

10:19

لوصف الوحدات

10:20

البرمجية، لأنه إذا

10:21

حاولت يوماً القراءة

10:23

عن كيفية هيكلة قاعدة

10:25

كود، ستجد 20 نهجاً

10:26

مختلفاً وكلها تسمى DDD

10:28

، وما تحتاجه هو لغة

10:30

متسقة يمكنك

10:30

استخدامها في فريقك

10:32

للحديث عن هذه الأمور.

10:34

لذا لدي مهارة صغيرة

10:35

في تصميم قواعد الكود

10:37

تحدد ما هي المحلية،

10:38

وما هي الاستفادة، وما

10:40

هو الرابط (seam). كنت

10:41

أستخدم الروابط قبل أن

10:43

تصبح شائعة. والمقصود

10:45

بالمحلية هو مدى ترابط

10:47

كل الكود في مكان واحد

10:49

بشكل جيد. كيف يمكنك

10:51

إجراء تغيير صغير في

10:53

وحدة واحدة وجعله يمتد

10:54

تأثيره للخارج؟ كما أن

10:56

الاستفادة هي ما تحصل

10:57

عليه عندما يكون لديك

10:59

وحدة عميقة، لأن

11:00

المستدعي، الشخص الذي

11:01

يستدعي تلك الوحدة

11:03

فعلياً، يحصل على قيمة

11:04

كبيرة من استدعاء دالة

11:06

بسيطة. كلاهما جيد

11:07

جداً في قواعد الكود.

11:09

واتضح أنهما جيدان

11:10

للوكلاء أيضاً. لكن،

11:12

أنا أصف نوعاً ما كل

11:13

هذه المعايير

11:14

البرمجية المتكلفة،

11:16

ولكن كيف نتأكد فعلياً

11:18

من أن الوكيل يلتزم

11:19

بها، أليس كذلك؟ كيف

11:21

تتأكد من أن الوكيل

11:22

ينشئ وحدات عميقة ويضع

11:23

اختبارات جيدة ولا

11:24

يكتب تلك الاختبارات

11:26

السخيفة التكرارية أو

11:27

الحساسة للهيكل؟

11:30

حسناً، أعتقد أن معظم

11:32

الناس يخطئون في هذا.

11:35

ونصيحتي الأولى هي: لا

11:37

تضع معايير برمجية في

11:39

وكلاء التنفيذ لديك.

11:42

مفهوم؟ دعوني أوضح ذلك

11:44

. إذا تخيلت أن وكيل

11:45

التنفيذ يبدو كهذا،

11:47

حيث يمثل هذا كل

11:48

الأشياء التي يحتاج

11:49

الوكيل للقيام بها في

11:51

نافذة سياقه الواحدة.

11:52

يحتاج لأن يكون قادراً

11:53

على الاستكشاف، أي

11:55

البحث عن الكود الذي

11:56

سيغيره. ثم يحتاج

11:57

لتغييره فعلياً، أي

11:58

إجراء التحديثات على

11:59

الملفات باللون

12:00

الأخضر. وبعد ذلك

12:01

يحتاج إلى بعض

12:02

الميزانية لتصحيح

12:03

الأخطاء في الشيء نفسه

12:04

. أي لتشغيل تلك

12:05

الفحوصات التلقائية،

12:07

وللتحقق والتأكد

12:08

فعلياً من أنه يعمل.

12:10

الآن، اتضح أن هذا عمل

12:12

كثير جداً. وإذا حاولت

12:14

فرض معاييرك البرمجية

12:16

عليه أيضاً، فسيكون

12:18

أداؤه أسوأ. لذا،

12:20

عملية التنفيذ مثقلة

12:22

بالأعباء. هذا هو

12:23

النموذج الذهني الذي

12:24

أريدك أن تمتلكه.

12:25

وهكذا، هل يمكننا

12:26

إيجاد طريقة لفرض تلك

12:27

المعايير البرمجية

12:28

بطريقة لا تكون مثقلة

12:29

جداً؟ حسناً، هذا هو

12:31

جهدي في هذا الصدد. هذه

12:32

هي مهارتي في مراجعة

12:33

الكود. وهي تستقبل ملف

12:35

التعديلات "diff". وتقوم

12:37

بقراءة ملف داخل

12:38

المستودع يسمى معايير

12:40

البرمجة، والذي يمكنك

12:42

كتابته وتخصيصه. ثم

12:43

تتحقق مما إذا كان

12:44

الكود يتبع تلك

12:46

المعايير. لذا، إذا

12:47

نظرنا إلى وكيل

12:48

المراجعة هنا، فإنه

12:50

يقوم بشكل حاسم

12:51

بتشغيله كوكيل فرعي.

12:52

فهو يمتلك نافذة سياق

12:54

خاصة به للتعامل مع

12:55

الأمر. ويمتلك

12:56

ميزانيته الخاصة. هذا

12:58

الوكيل يحتاج إلى

12:59

القيام ببعض

13:00

الاستكشاف، أليس كذلك

13:01

؟ لأنه بالطبع يستقبل

13:02

التعديلات ويعرف

13:04

موقعها ومكان الكود،

13:05

لكنه ينبغي أن يقوم

13:06

ببعض الاستكشاف

13:07

للحصول على سياق أوسع

13:09

وفهم أعمق للكود. لكنه

13:10

لا يحتاج إلى القيام

13:11

بأي تنفيذ. ولا يحتاج

13:13

إلى القيام بأي تصحيح

13:14

للأخطاء. لذا، بينما

13:15

يكون التنفيذ محملاً

13:17

بمهام كثيرة، تكون

13:18

المراجعة في الواقع

13:19

أقل عبئاً. لذلك، ليس

13:20

لديه الكثير ليفعله.

13:22

هذا يعني أنه يمكنك

13:23

تزويده بمجموعة كبيرة

13:24

من معايير البرمجة،

13:25

وسيقوم بعمل أفضل

13:26

بكثير مما لو حاولت

13:27

القيام بذلك أثناء

13:28

التنفيذ. أنا أفكر في

13:29

هذا الأمر، وهو شعور

13:31

غير مريح، أليس كذلك؟

13:33

لأننا جميعاً نريد

13:34

الحصول على كود جيد من

13:35

المرة الأولى. لكني

13:37

أعتبر هذه عملية من

13:38

جزأين لكتابة كود جيد:

13:40

التنفيذ حيث تجعله

13:42

يعمل، ثم مراجعة الكود

13:43

حيث تجعله جيداً

13:45

بالفعل. أنت تفرض

13:46

معايير البرمجة

13:47

الخاصة بك. وبالنسبة

13:49

للمطورين المخضرمين

13:50

بيننا، فإن هذا هو

13:52

جوهر نهج "red-green refactor".

13:53

نستخدم نافذة سياق

13:55

واحدة لجعل الكود يعمل

13:56

، ثم نستخدم نافذة

13:58

سياق أخرى لإعادة

13:59

هيكلته. هكذا يعمل

14:00

الأمر في ذهني على

14:01

الأقل، وقد كان ناجحاً

14:03

جداً بالنسبة لي. هذا

14:04

يعني أنه عندما تكون

14:05

لديك معايير برمجة، لا

14:07

تضعها في النطاق العام

14:09

. لا تضعها في ملف "

14:10

agents.md"، لأنها قد تشوش

14:12

على وكيل التنفيذ. قد

14:14

يقرأها، وقد لا يفعل

14:15

ذلك. بدلاً من ذلك،

14:17

ضعها في "coding standards.md"،

14:18

وبهذه الطريقة يقوم

14:19

وكيل مراجعة الكود

14:20

بالتعامل معها فقط.

14:22

لدي فكرة أخرى هنا،

14:23

فقد كنت أتحدث إلى

14:24

الكثير من الأشخاص

14:25

اليوم. الكثيرون

14:26

يقولون إنهم سمعوا عن

14:27

المراجعة والمراجعة

14:28

الآلية، وكيف تساعد في

14:29

حل مشكلة عنق الزجاجة

14:30

في طلبات السحب (PR).

14:31

يقول الكثيرون: "أوه،

14:33

نعم، نحن نستخدم خدمة

14:34

طرف ثالث". نستخدم "Cursor

14:36

Bug Bot". نستخدم "Code Rabbit".

14:38

أو شيئاً من هذا

14:39

القبيل. أعتقد أنني

14:40

حاولت حقاً في الماضي

14:42

ابتكار مهارة عامة

14:43

لمراجعة الكود، بحيث

14:45

تكتشف جميع الأخطاء

14:46

وتجري مراجعة أمنية

14:48

وما إلى ذلك. تبين أن

14:50

الأمر صعب للغاية،

14:51

لأنك إما أن تجعلها

14:52

عامة جداً فتنتج نتائج

14:54

إيجابية خاطئة لا

14:55

علاقة لها بحالتك، أو

14:57

تجعلها محددة جداً.

14:58

فتقول مثلاً: "حسناً،

15:00

ابحث عن كل ما يخص

15:01

TypeScript". وعندها لن

15:02

يتمكن مبرمجو Rust من

15:03

استخدامها. لذا، أقول

15:04

لا تعتمدوا على مراجعة

15:06

آلية خارجية. ابنوا

15:07

أدواتكم الخاصة. طوروا

15:09

معايير البرمجة

15:10

الخاصة بكم مع مرور

15:11

الوقت. وشاركوها مع

15:12

أعضاء فريقكم. وإذا

15:13

كانت لديكم فرصة لفرض

15:14

معايير برمجية، أو

15:16

كانت لديكم وثائق

15:17

مركونة لا يقرؤها أحد،

15:18

فهذا هو المكان

15:19

المناسب لوضعها فيه.

15:20

وأيضاً، عند استخدام

15:22

هذا المراجع الآلي،

15:23

فإن النزعة الطبيعية

15:25

للكثيرين هي القول: "

15:27

أوه نعم، وكيل مراجعة

15:28

الكود الخاص بي يقرأ

15:30

الكود ثم يعلق على طلب

15:32

السحب (PR)". حسناً، ما

15:34

يفعله وكيل مراجعة

15:35

الكود في هذه الحالة

15:37

هو توفير المزيد من

15:38

العمل للمراجع البشري.

15:40

حيث يتعين على المراجع

15:41

البشري قراءة كل هذه

15:42

التعليقات الطويلة

15:43

وتحديد ما إذا كان

15:44

ينبغي علينا تنفيذ هذا

15:45

أو ذاك. يجب على

15:46

المراجع أن يلتزم

15:47

بالبرمجة. يجب عليه

15:48

إجراء الإصلاحات

15:49

بنفسه. أي يجب عليه

15:51

فعلياً تغيير الأشياء

15:52

التي يكتشفها. لأنه

15:53

عندما يأتي العنصر

15:54

البشري، فإنه يراجع

15:55

نتيجة نهائية جيدة

15:57

ومجهزة. إذا وجد أي شيء

15:58

لديه استفسارات حوله،

16:00

فيمكنه بالطبع

16:00

التعليق، لكن الأصل هو

16:02

أن يقوم بالتعديل.

16:03

توقفوا عن محاولة

16:04

كتابة كود مثالي من

16:05

المرة الأولى. توقفوا

16:07

عن جعل وكيل التنفيذ

16:08

هو الشيء الوحيد الذي

16:09

تركزون عليه، قائلين: "

16:11

سأجبره على أن يكون

16:12

مذهلاً". يتطلب الأمر

16:14

بعض التفكير خارج

16:15

الصندوق، ولكن بمجرد

16:16

أن تدرك ذلك، سيكون

16:18

الأمر رائعاً. حسناً.

16:20

مع كل تلك العملية،

16:21

قمنا بتشغيل فحوصاتنا

16:22

الآلية، وقمنا الآن

16:23

بتشغيل مراجعتنا

16:24

الآلية للتأكد من أن

16:25

الفحوصات الآلية ليست

16:27

مضللة. كيف يمكننا

16:28

إذاً تعظيم جودة طلب

16:29

السحب من حيث المراجعة

16:31

البشرية؟ كيف نجعلها

16:32

تعمل بأفضل شكل ممكن؟

16:34

نحن بحاجة إلى طلب سحب

16:36

ملائم للبشر. وهذه

16:37

مهارة جديدة يتم

16:38

إضافتها إلى المستودع

16:39

، وهي لا تزال قيد

16:41

التنفيذ، لكنني

16:42

سأطلقها قريباً، وهي

16:43

مهارة طلب السحب. هذه

16:44

واحدة من المهارات

16:45

التي كنت أفكر فيها

16:46

لفترة طويلة جداً. لم

16:47

أستقر تماماً بعد على

16:48

ما هو الأفضل في هذا

16:49

المجال. وأدركت أن

16:50

أفضل طريقة لاكتساب

16:51

مهارة مراجعة طلبات

16:53

السحب (PR) هي ببساطة

16:54

سرقة أفضل الأفكار لدى

16:55

الجميع. وهذا أمر رائع

16:57

للغاية. والآن، كيف

16:59

يبدو طلب السحب الجيد؟

17:01

كيف يمكنك إعادة بناء

17:03

هذه المهارة بنفسك؟

17:04

حسناً، المبدأ الأول

17:06

هو أن بعض المراجعات

17:07

أهم من غيرها. ليست كل

17:09

مراجعة جوهرية، أليس

17:11

كذلك؟ وبمجرد أن تفهم

17:15

ذلك، ستدرك أنه يمكنك

17:17

تركيز طاقتك على

17:18

المراجعات المهمة

17:20

حقاً. ولكن كيف نصنفها

17:22

؟ عليك التفكير في طلب

17:24

السحب باستخدام

17:25

مصطلحات AWS: هل هو باب

17:27

ذو اتجاه واحد أم باب

17:29

ذو اتجاهين؟ معظم

17:30

طلبات السحب التي لديك

17:32

ستكون أبواباً ذات

17:33

اتجاهين. يمكنك دمج

17:35

طلب السحب ثم التراجع

17:36

عنه دائماً لاحقاً.

17:37

هذه هي الميزة العظيمة

17:39

لكونك مهندس برمجيات

17:40

مقارنة بمهندس مدني،

17:41

أليس كذلك؟ غالباً،

17:42

عندما تكون مهندساً

17:43

مدنياً، فالأمر عبارة

17:44

عن باب ذي اتجاه واحد،

17:45

صحيح؟ إذا أخطأت في

17:47

شيء ما، سينهار الجسر،

17:48

ولكن إذا كان لديك باب

17:49

ذو اتجاهين، فهذا يعني

17:51

أنه يمكنك التراجع عن

17:52

التغيير بسهولة. قد

17:53

يكون الأمر أكثر دقة

17:55

بقليل مما تتوقع. قد

17:57

يؤدي تغيير بسيط جداً

17:58

عن طريق الخطأ إلى

17:59

إرسال بريد إلكتروني

18:01

لـ 60 ألف شخص، وفي هذه

18:02

الحالة يكون باباً ذا

18:03

اتجاه واحد. عليك

18:04

مراجعة ذلك بعناية

18:05

فائقة جداً. إذا تضمن

18:07

عمليات ترحيل مكلفة أو

18:08

فقدان بيانات، فهو باب

18:09

ذو اتجاه واحد. راجع

18:10

طلب السحب هذا بدقة

18:12

متناهية. ولكن إلى

18:13

جانب ذلك، نحتاج إلى

18:15

فهم نطاق تأثير هذا

18:16

الطلب. ما الذي قد يسير

18:18

بشكل خاطئ؟ وإذا حدث

18:19

خطأ ما، فما مدى سوء

18:21

الأمر؟ وهذا يعني أنني

18:23

أضع ملخصاً لطيفاً في

18:24

أسفل جميع طلبات السحب

18:26

الخاصة بي تحت مسمى "

18:27

خطر الدمج". أستطيع أن

18:28

أرى أن هذا الباب ذو

18:30

اتجاهين. نطاق تأثيره

18:31

محدود، لذا يمكنني

18:32

القول: رائع، لا أحتاج

18:33

لإيلاء الكثير من

18:34

الاهتمام لهذا الأمر.

18:36

سأكتفي بمراجعته بشكل

18:37

بسيط. هذا أمر مهم حقاً

18:39

. بعد ذلك، نحتاج إلى

18:41

فهم ما يفعله طلب

18:42

السحب من الأساس، أليس

18:43

كذلك؟ لقد جربت طرقاً

18:45

عديدة لمعرفة ذلك،

18:46

وأفضل ما توصلت إليه

18:48

هو استخدام الكود

18:49

الزائف (Pseudo code). أود

18:51

هنا تقديم خالص الشكر

18:53

لمهارة "أرني"(Show me) من

18:55

مستودع مهارات الطبقة

18:57

البشرية لـ Dex Hadley. هذه

18:59

مهارة استثنائية

19:01

تختصر معظم النصوص

19:03

وتعرض لك الأمور في

19:04

صور ومخططات بدلاً من

19:06

ذلك. وهذا يجعل من

19:08

الأسهل بكثير فهم ما

19:09

يتغير ولماذا يتغير

19:11

فعلياً. إذن، ستحصل

19:12

على المجموعة

19:13

المعتادة من مخططات "

19:15

ميرميد" و UML، كما تعلم

19:16

، لتوضيح تسلسل

19:17

الأحداث التي وقعت.

19:19

ستحصل أيضاً على هذه

19:20

المخططات البسيطة

19:20

والجميلة مثل هذا، على

19:21

سبيل المثال. يمكننا

19:22

النظر إلى هذا ونقول: "

19:24

حسناً، نحن نعمل في

19:25

واجهة سطر الأوامر (CLI).

19:26

يمكننا أن نرى أنه تمت

19:28

إضافة أمر جديد."

19:29

ولدينا شيئان جديدان،

19:30

أعلام صغيرة هنا في

19:31

الأعلى. مجرد ملخصات

19:32

صغيرة كهذه. إنها حقاً

19:33

تحدث فرقاً هائلاً. من

19:35

الصعب المبالغة في

19:36

تقدير أهميتها. لذا،

19:37

أنت تحاول جعل فهم "

19:39

السبب" سريعاً قدر

19:41

الإمكان. وأعتقد أن

19:44

هناك مبدأً ثالثاً هنا

19:45

ينبغي أن تفكر فيه

19:47

كلما قمت بمراجعة

19:48

بشرية. لأننا، ولأننا

19:51

لا نقوم بـ أم، ولأن

19:55

عملياتنا الآن أصبحت

19:57

انسيابية للغاية،

19:58

وجميعنا نتعاون حول

20:00

ملفات المهارات ذاتها

20:02

وملفات التوجيه ذاتها.

20:05

نحن جميعاً نبني بيئة

20:07

لتعمل وكلاؤنا فيها

20:08

معاً. يجب أن تنظر إلى

20:10

العملية التي تنتج

20:11

الكود الخاص بك على

20:12

أنها لا تقل أهمية عن

20:14

الكود نفسه. بمعنى آخر

20:15

، عندما تقوم بمراجعة

20:17

بشرية، فأنت لا تراجع

20:18

الكود فحسب، بل تراجع

20:20

النظام الذي أنشأه.

20:21

والنظرية هنا هي أنك

20:22

لا تريد أبداً كتابة

20:24

التعليق نفسه مرتين.

20:25

أليس كذلك؟ أنت لا

20:27

تريد أبداً أن ترى

20:28

الوكيل يرتكب الخطأ

20:29

نفسه في طلبي سحب (PR)

20:30

مختلفين. إذاً، ما هي

20:31

الآلية التي يمكنك من

20:33

خلالها جعل مراجعتك

20:34

البشرية ذات قيمة؟

20:35

حسناً، هذه مهارة

20:36

جديدة. تسمى "ريترو"(retro

20:38

). وهي اختصار لـ "

20:39

مراجعة استرجاعية"(

20:40

retrospective). أنت تأخذ

20:41

جلسة قمت بها بشكل

20:42

أساسي. يمكن أن تكون

20:44

جلسة وكيل واحدة، أو

20:45

طلب سحب مع الجلسة، أو

20:46

يمكنك ببساطة أن تطلب

20:47

منه النظر في: "حسناً،

20:48

انظر إلى كل طلبات

20:50

السحب التي قمنا بها

20:51

خلال الأسبوع الماضي،

20:52

وكل المراجعات،

20:53

واجمعها كلها معاً."

20:54

دعنا نقوم بمراجعة

20:55

استرجاعية لها.

20:57

وسيقترح فحوصات آلية

20:58

ومعايير برمجية لجعل

21:00

الجلسة التالية أفضل.

21:02

إذن، هذا هو التأثير

21:04

التراكمي، حيث إنك من

21:05

خلال إجراء مراجعة

21:07

بشرية، ترفع جودة

21:08

المراجعة البشرية

21:09

التالية وتوفر على

21:10

نفسك جهداً أقل في

21:12

المرة القادمة. و "

21:13

ريترو" مهارة ذكية

21:14

حقاً. إنها تضيف

21:15

الكثير من الأشياء.

21:17

لذا، من الواضح أنها

21:18

تقترح فحوصات آلية.

21:19

وتقترح تحديثات لملف

21:20

معايير البرمجة (coding

21:22

standards.md). وتقوم بأشياء

21:23

ذكية أخرى أيضاً. فهي

21:25

تنظر إلى مؤشرات

21:26

التنقل. ما مدى سهولة

21:27

عثور الوكيل على

21:28

معلوماته؟ هل يمكننا

21:29

توفير مؤشر داخل ملف (

21:31

agents.md) لمساعدته في

21:32

المرة القادمة؟ وهي

21:33

تنظر أيضاً في اقتصاد

21:34

استخدام الأدوات. هل

21:35

هناك أدوات مختلفة

21:36

نستخدمها في الجلسة

21:38

يمكن، كما تعلم، جعلها

21:39

أكثر كفاءة في استخدام

21:40

الرموز؟ من المدهش عدد

21:41

الأشياء التي تكتشفها

21:42

هذه الأداة في الواقع،

21:43

لأنها غالباً ما تكون

21:44

صعبة التصحيح من

21:45

الخارج. إنها تبحث في

21:46

التضخم أيضاً. إذن، هل

21:48

هناك ملفات توجيه

21:49

متضخمة؟ هل هناك

21:50

مهارات متضخمة تساهم

21:51

في هذه النتائج السيئة

21:53

؟ هل يمكننا جعلها

21:54

أكثر تنظيماً؟ إذاً،

21:56

هذا هو الهدف. إنه جعل

21:58

المراجعة البشرية

21:59

أسرع. نقوم بذلك من

22:01

خلال تعزيز المراجعة

22:03

المؤتمتة، ونجعل

22:04

المراجعة البشرية غير

22:06

مؤلمة وبسيطة

22:07

واختيارية بقدر ما

22:09

نحتاج. أنت لا تحتاج

22:10

حقاً إلى مراجعة كل

22:12

قرار يمكن التراجع عنه

22:13

. لكن كل قرار لا يمكن

22:14

التراجع عنه يجب

22:15

مراجعته. وهكذا، هذه

22:17

هي مهاراتي. أنا هنا

22:19

على hero.dev/skills ونحن

22:20

نطلق الإصدار 1.3 هذا

22:22

الأسبوع. لقد كان من

22:23

الرائع قضاء الوقت

22:24

معكم. لقد كان مؤتمراً

22:26

لطيفاً حقاً. سأكون في

22:27

الخارج في الردهة إذا

22:28

أراد أي شخص الدردشة.

22:30

شكراً جزيلاً

22:31

لاستضافتي. شكراً لك

22:32

يا باريس.

Interactive Summary

Ask follow-up questions or revisit key timestamps.

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