تعاون أفضل من خلال إشراك المصممين في عملية مراجعة التعليمات البرمجية

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

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

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

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

آها! الوقت الحاضر

في يوليو 2017 ، قمت بتأسيس Confrere مع اثنين من المطورين ، وسرعان ما قمنا بتعيين مهندسنا الأول (أنا لست مطورًا بنفسي ، فأنا مصمم تجربة مستخدم أو مصمم محتوى). كان تعاوننا يسير بسلاسة مدهشة ، لدرجة أنه في استرجاع الماضي ، كان الموضوع المتكرر أننا شعرنا جميعًا أننا "نفعل ذلك بشكل صحيح".

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

كلمة "نظير" هي التي أعطتني لحظة آها. أدركت أن أولئك منا الذين يعملون ضمن تجربة المستخدم والتصميم والمحتوى لديهم الكثير لنتعلمه من المطورين عندما يتعلق الأمر بالتعاون.

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

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

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

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

طلبات السحب لها أدوار محددة بوضوح: هناك مؤلف ومراجع (مراجعون).

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

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

عندما يوافق المراجع (المراجعون) على طلب السحب ، يمكن لـ Ingvild دمج تغييراتها مع قاعدة الشفرة الرئيسية.

لماذا تهتم بمراجعة التعليمات البرمجية؟

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

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

- بروس جونسون ، المؤسس المشارك لـ Full Story

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

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

يؤدي وجود شخصين على الأقل دائمًا إلى الاطلاع على الكود إلى تقليص أفكار الكود "الخاص بي" و "الرمز" الخاص بك. إنه رمزنا .

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

مراجعة المبادئ لجميع التخصصات ، وليس فقط التعليمات البرمجية

مع المراجعات ، يوجد دائمًا مؤلف واحد ومراجع واحد أو أكثر. هذا يعني أنه يمكنك إشراك الأشخاص في وقت مبكر دون الوقوع في التصميم من قبل اللجنة.

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

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

حتى إذا لم نراجع الكود ، فهناك الكثير لنتعلمه من أفضل الممارسات الحالية لمراجعات الكود.

داخل فريقنا ، نحاول الالتزام بالمبادئ التالية عند إجراء المراجعات:

1. انتقد العمل وليس المؤلف.
2. كن ناقدًا ، لكن كن لطيفًا وفضوليًا.
3. ميّز بين أ) الاقتراحات ب) المتطلبات ، ج) النقاط التي تحتاج إلى مناقشة أو توضيح.
4. نقل المناقشات من النص إلى وجهًا لوجه. (عدد الفيديوهات)
5. لا تنسى مدح الأجزاء الجيدة! ما هو ذكي ، مبدع ، صلب ، أصلي ، مضحك ، لطيف ، وما إلى ذلك؟

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

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

مثال

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

الخطوة 1: جمع المتطلبات

المؤلف: Ida (UX)

المراجعون: Svein (الإستراتيجية) ، Dag-Inge (الهندسة) ، Ingvild (الهندسة).

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

الخطوة 2: نموذج بالحجم الطبيعي مع microcopy

المؤلف: Ida (UX)

المراجعون: إنجفيلد (هندسة) ، إيفيند (تصميم) ، سفين (إستراتيجية).

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

الخطوة 3: تنفيذ خطوات التسجيل

المؤلف: Ingvild (الهندسة)

المراجع: Ida (UX) و Dag-Inge (الهندسة).

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

الخطوة 4: اختبار المستخدم

المؤلف: Ida (UX)

المراجع: المستخدمون.

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

الخطوة 5: التصميم

المؤلف: Eivind (تصميم)

المراجعون: Ingvild (هندسة) و Ida (UX).

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

الخطوة السادسة: التنفيذ

المؤلف: Ingvild (الهندسة)

المراجع: Eivind (تصميم) ، Ida (UX) و Dag-Inge (هندسة).

ثم نعود إلى التنفيذ.

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

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

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

المراجعة المنتظمة الإرشادات التفصيلية

استلهامًا من الإرشادات التفصيلية حول التعليمات البرمجية ، نقوم أيضًا بإجراء عمليات مراجعة دورية مع بؤر مختلفة ، مسترشدين بالمبادئ التالية:

• تجول يتم معا.
• شخص واحد هو المسؤول عن المراجعة والتوثيق.
• الفكرة هي تحديد القضايا ، وليس بالضرورة حلها.
• اختر تنسيقًا يعطي أكبر قدر ممكن من السياق ، بحيث يسهل التعامل مع النتائج لاحقًا (مثل InvisionApp للمراجعات المرئية ، ومُحرر مستندات Google للنص ، وما إلى ذلك).

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

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

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

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

اختبار المستخدم هو أحد أشكال المراجعة

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

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

يعد تخطي اختبار المستخدم مخاطرة كبيرة مثل تخطي مراجعة التعليمات البرمجية.

هل المراجعة تعني الموت للإبداع؟

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

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

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

دعونا نصنع شيئًا رائعًا معًا.