البحث في الموقع

هل لديك فريق من المبرمجين المميزين والمتحمسين؟ بالطبع قد اخترتهم بعناية من بين مئات المرشحين، هل هم متحمسون للمنتج؟ بالتأكيد، إنهم يستخدمون أحدث التقنيات، ولا ينامون أبدًا، ويكادون لا يأكلون أو يشربون أي شيء باستثناء القهوة، هل يؤمنون بنجاح عملك؟ لا شك في ذلك. إنهم يعيشون ويتنفسون كل هذه الميزات، الإصدارات، والتسليم المستمر (continuous delivery)، تجربة المستخدم، وغيرها. هل أنت متأكد من أنهم يطورون المنتج بشكل صحيح؟ حسنًا، نعم، أنت متأكد تمامًا؛ لم لا؟ هل يبدو هذا الصوت مألوفًا؟ لا يمكنني حساب عدد المرات التي سمعت فيها هذه القصص من قِبَل مؤسِسي الشركات الناشئة. معظمهم يفضلون فرقهم حتى يأتي ذلك اليوم الذي يلجؤون فيه لتوظيف فريق جديد. قد يكون هناك العديد من الأسباب المحتملة لمثل هذا الفشل التام، ولكن أحد هذه الأسباب هو الافتقار إلى التنظيم والمنهجية والمراجعات التقنية المستقلة. لا شيء يمكنه أن يحد من تطور الفريق أكثر من عدم الاهتمام بإنجازاته. ومن ناحية أخرى، يُعَد التنسيق المنتظم لنتائجه التي توصل لها وتوقعات الجودة الخاصة بك أحد العوامل الرئيسية التي ستضمن النجاح التقني لشركتك الناشئة. سأُلخِّص فيما يلي تجربتي في تنظيم مثل هذه المراجعات التقنية. تتم المراجعة المستقلة عندما تطلب من شخص خارج فريقك الاطلاع على شيفرتك المصدرية والمصادر التقنية الأخرى وإعطائك رأيًا موضوعيًا بشأنها. ينبغي على كل فريق برمجيات حديث أيضًا استخدام مراجعات للشيفرات الداخلية (internal code reviews)، وهذا شيء مختلف تمامًا. تحدث المراجعة الداخلية عندما يعرض أحد المبرمجين الشيفرة الخاصة به على أعضاء الفريق الآخرين ويسألهم عن رأيهم. يعتبر هذا نشاطًا يوميًا ولا علاقة له بالمراجعات المستقلة. يتم إجراء مراجعة مستقلة بواسطة مبرمج لا يعرف شيئًا عن فريقك. ينضم إلى الفريق، ويتحقق من الشيفرة في مستودعك، ويقضي بضعة ساعات (أو أيام) في النظر إليها والتفكير بها ويحاول فهم ما الذي تفعله. ثمَّ، يخبرك ما هو الخطأ وأين. يشرح كيف يمكنه تحسينه بشكل أفضل، وأين سيجري التغيير، وما الذي سيفعله بدلًا من ذلك. ثمَّ تدفع له ويغادر. قد لا تشاهده أبدًا مرةً أخرى، لكن استنتاجاته واقتراحاته تساعدك على التحقق من صحة الشيفرة الخاصة بك وتقييم أداء فريقك بشكل صحيح. في Zerocracy، نقوم بمراجعات مستقلة لكل مشروع من مشاريعنا، وهذه قائمة بالمبادئ التي نستخدمها: اجعل المراجعات المستقلة منهجية هذه هي القاعدة الأولى والأكثر أهمية - نظّم المراجعات التقنية باستمرار. بالإضافة لذلك، أبلغ فريقك بالجدول الزمني، واجعله مستعدًا للمراجعات. وفقًا لتجربتي، تعدّ مرة واحدة في الشهر ممارسة جيدة. يجب أن تستغرق المراجعة الكاملة من ساعتين إلى ثماني ساعات وفقًا لحجم شيفرتك المصدرية. لا تقضِ أكثر من ثماني ساعات في مراجعة الشيفرة؛ ليس هناك فائدة من التعمق في الشيفرة خلال المراجعات المستقلة. ادفع لإيجاد الأخطاء نحن دائمًا ندفع ثمنًا للأخطاء، وليس للوقت الذي نقضيه في العثور عليها. نطلب من مراجعينا الاطلاع على الشيفرة والإبلاغ عن أكبر عدد من الأخطاء التي نظن أننا بحاجتها. لكل خطأ، ندفع ثمن 15 دقيقة لوقتهم. بمعنى آخر، نفترض أن المراجع الجيد يمكنه العثور على ما يقارب أربع مشكلات ويبلغ عنها في ساعة واحدة. على سبيل المثال، مراجع يقبض 150 دولارًا في الساعة (قد يختلف الأجر في البلاد العربية). نوظفه ونطلب منه أن يجد أخطر 20 مشكلة حرجة يمكنه أن يكتشفها ويبلغ عنها. تقديرنا هو أنه ينبغي أن يقضي خمس ساعات في هذا العمل. وبالتالي، سوف يحصل على 750 دولارًا عندما يكون لدينا 20 خطأ في نظام التتبع الخاص بنا والذي أبلغنا عنه. إذا وجد عددًا أقل، فسيحصل على أموال أقل نسبيًا. سيساعدك جدول الدفع هذا في جعل المراجع يركز على الهدف الرئيسي لعملية المراجعة – وهو العثور على المشكلات والإبلاغ عنها. لا توجد أهداف أخرى. الشيء الوحيد الذي تهتم أنت به هو معرفة ما هي المشاكل المتعلقة بحلك التقني الحالي. هذا هو ما تدفع مقابله. وظّف الأفضل وادفع أكثر تخبرني تجربتي أن وظيفة المُرَاجع المستقل مهمة للغاية. إنّه ليس مجرد مبرمج بل هو أكثر من ذلك، إنّه مهندس قادر على النظر إلى الحل من مستوى تجريدي عالٍ للغاية، وفي نفس الوقت يهتم بالتفاصيل كثيرًا؛ يجب أن يكون بارعًا في تصميم الأنظمة المماثلة؛ و يعرف كيفية كشف الخطأ والإبلاغ عنه وتزويدك بتفاصيل كافية؛ يجب أن يفهم مجال عملك وما إلى ذلك؛ إلى جانب كل ذلك، ينبغي أن يكون متحمسًا لمساعدتك. أنت لا توظفه للعمل بدوام كامل وإنّما فقط عمل لبضع ساعات. نصيحتي هي محاولة الحصول على أفضل الأشخاص، ودفع أجورهم بقدر ما يطلبون، وعادةً ما يكون أكثر من 100 دولار في الساعة. لا تتفاوض، فقط ادفع. إنّها مجرد بضعة مئات من الدولارات، لكن تأثير مساهمتهم هذه سيكون هائلًا. ملاحظة: قد تختلف الأسعار في الوطن العربي ويمكن أن تكون أقل مما ذُكِر آنفًا. اسأل وتوقع النقد إنّه خطأ شائع أن تسأل مراجعًا، "هل تعجبك الشيفرة الخاصة بنا؟" لا تتوقع منه أن يخبرك كم أن الشيفرة الخاصة بك ممتازة. ليس هذا ما تدفع مقابله، فأنت لديك فعليًا فريق كامل من المبرمجين لتشجيعك. يمكنهم إخبارك الكثير عن الشيفرة التي يكتبونها ومدى روعتها. لا تريد سماع ذلك مرة أخرى من المراجع. بدلًا من ذلك، أنت تريد أن تعرف ما هو الخطأ وماذا تحتاج لإصلاحه. وفقًا لما سبق، يجب أن تكون أسئلتك مثل، "ما هي المشكلات التي تعتقد أنه يتعين علينا حلّها أولًا؟" سيحاول بعض المراجعين إقناعك بتعليقات إيجابية لكن تجاهل هذا الإطراء وأَعِدهُم إلى الهدف الرئيسي - وهو الأخطاء. الجدول الزمني للدفع الموضح أعلاه يجب أن يساعدك بذلك. غيّر المراجعين باستمرار حاول ألا تستخدم المراجع نفسه أكثر من مرة في نفس المشروع (أعني في الشيفرة الأساسية نفسها). أعتقد أنَّ السبب هنا واضح، لكن دعني أعيد التأكيد: لا تحتاج أن يكون مراجعك لطيفًا معك وأن يخبرك بمدى جودة الشيفرة. إنما تريده أن يكون موضوعيًا ويركز على المشكلات، وليس على الجوانب الجيدة. إذا وظّفت نفس الشخص مرارًا وتكرارًا، فسوف تجعله مرتبط نفسيًا بالشيفرة المصدرية. لقد شاهدها مرة واحدة؛ والآن سيراها مرة أخرى. لقد أخبرك بالفعل عن بعض المشاكل، والآن عليه أن يعيدها مرة أخرى. لن يشعر بالراحة عند القيام بذلك. بدلًا من ذلك، سيبدأ بالشعور كأنه عضو في الفريق وسيشعر بالمسؤولية تجاه الشيفرة المصدرية وأخطائها. سيبدأ مثله مثل أي عضو آخر في الفريق، في إخفاء المشكلات بدلًا من الكشف عنها. إذن، استشر شخصًا جديدًا لكل مراجعة تقنية مستقلة جديدة. كن لطيفًا وصادقًا مع فريقك يمكن أن تكون المراجعات المستقلة مزعجة بالنسبة للمبرمجين لديك. قد يعتقدون بأنك لا تثق بهم. قد يشعرون أنك لا تحترمهم كأخصائيين تقنيين. ربما يقررون أنك تستعد لطردهم جميعًا وأنّك تبحث حاليًا عن أشخاص جدد. هذا الأمر ممكن جدًا ويعطي تأثيرًا جانبيًا مدمرًا للغاية في المراجعة المستقلة. كيف يمكن تجنب ذلك؟ لا أستطيع أن أقدم لك نصيحة شاملة، لكن أَفضل اقتراح يمكنني تقديمه هو: أن نكون صادقين معهم. أخبرهم أن جودة المنتج أمر خطير بالنسبة لك ولعملك. اشرح لهم أنَّ الشركة تدفع لهم مقابل عملهم وأنّه من أجل الحفاظ على استمرارية الرواتب، عليك التشديد على مراقبة الجودة بشكل منتظم، موضوعي، مستقل وصادق. في النهاية، إذا تمكنت من تنظيم المراجعات كما توضح هذه المقالة، فسيكون الفريق ممتنًا جدًا لك. سيحصلون على الكثير من الآراء والأفكار الجديدة من كل مراجعة وسيطلبون منك تكرارها باستمرار. راجع من اليوم الأول لا تنتظر حتى نهاية المشروع، لقد رأيت هذا الخطأ عدة مرات. كثيرًا ما يعتقد مؤسسو الشركات الناشئة أنّه يجب ألا يشتتوا انتباه فريقهم حتى يتم الانتهاء من المنتج ويصبح جاهزًا للسوق. يعتقدون أنّه يجب عليهم أن يسمحوا للفريق بالعمل على تحقيق مراحل المشروع والاعتناء بالجودة لاحقًا، "عندما يكون لدينا مليون زائر يوميًا" لن يأتي هذا اليوم أبدًا إذا سمحت لفريقك بالاستمرار بدون إدارة. ابدأ في إجراء مراجعات مستقلة من اللحظة التي يُرفع فيها الملف الأول على مستودع Git. وحتى يصبح المستودع كبيرًا بدرجة كافية، ربما تنفق 300 دولار مرة واحدة شهريًا لتلقي رأي موضوعي ومستقل بشأن جودته. هل سيدمر هذا ميزانيتك؟ امنع النقاشات، واطلب تقاريرًا رسمية لا تدع المراجعين يتحدثون إلى الفريق. إذا قمت بذلك، فإن فكرة المراجعة المستقلة ستنهار بالكامل. إذا كان المُراجع قادرًا على طرح أسئلته بطريقة غير رسمية ومناقشة تصميم النظام الخاص بك مع المبرمجين لديك، فستعجبه إجاباتهم ويمضي قدمًا. لكن باعتبارك مالكًا للشركة ستبقى بالمستوى نفسه الذي كنت به قبل المراجعة. الهدف من المراجعة ليس إسعاد المراجع وإنما العكس تمامًا. أنت تريد إرباكه، فإذا كان في حيرةٍ حيال وجود خطأ في التصميم، سيشعر بضرورة الإبلاغ عن الخطأ الموجود. يجب أن تعبّر الشيفرة المصدرية عن نفسها، ويجب أن يفهم أي شخص غريب (المراجع) كيف تعمل هذه الشيفرة بسهولة. إذا لم يكن الأمر كذلك، فهناك شيء خاطئ يجب إصلاحه. التعامل مع أي سؤال كأنه خطأ لا تتوقع أن ينتج المراجع أي أخطاء في الوظائف، مثل "أنقر على هذا الزر فيتوقف النظام". نادرًا ما يحدث هذا، إن حدث. فريقك جيد جدًا في اكتشاف هذه المشكلات وحلها. والمراجعات المستقلة ليست حول هذا النوع من الأخطاء. الهدف الرئيسي من المراجعة المستقلة هو اكتشاف الأخطاء في الهيكلية والتصميم. قد يعمل المنتج الخاص بك، ولكن قد يكون هناك عيوب خطيرة في هيكلية التصميم تُعيقك، مثلًا، من التعامل مع النمو الهائل في حركة البيانات على شبكة الويب. سيساعدك مراجع مستقل في العثور على هذه العيوب ومعالجتها في وقت أقرب. من أجل الحصول على هذا النوع من الأخطاء من المراجع، يجب عليك تشجيعه على الإبلاغ عن أي شيء لا يعجبه - استخدام التكنولوجيا بدون دافع، والافتقار إلى التوثيق، والهدف غير الواضح لملف، وعدم وجود وحدة اختبار، وغير ذلك. تذكر، المراجع ليس عضوًا في فريقك ولديه أفكاره الخاصة حول التقنيات التي تستخدمها والتطوير البرمجي بشكل عام. عليك أن تهتم بمطابقة وجهة نظره مع فريقك. بعد ذلك، عليك الاهتمام بإصلاح جميع حالات عدم التطابق الضرورية. راجع كل شيء، وليس فقط الشيفرة المصدرية دع المراجع الخاص بك ينظر إلى جميع المصادر التقنية التي لديك، وليس فقط ملفات شيفرة المصدر (‎.java ، .rb ، .php، وما إلى ذلك)؛ امنحه حق الوصول إلى مخطط قاعدة البيانات، ولوحة التكامل المستمر، وبناء البيئة، نظام تتبع المشكلات، الخطط والجداول الزمنية، وجداول الأعمال، وتقارير التشغيل، وخط النشر، وسجلات الإنتاج، وتقارير أخطاء العملاء، والإحصاءات، وغيرها. كل شيء يمكن أن يساعده في فهم كيفية عمل نظامك، والأهم من ذلك، أين وكيف ينهار، إنه أمر مفيد للغاية. لا تجعل معرفة المراجع تقتصر على الشيفرة المصدرية فقط - فهذا ببساطة لا يكفي، دعه يطّلع على المشروع بالكامل، وسوف تحصل على تقرير أكثر تفصيلًا واحترافيةً. تابع كيفية حل التناقضات بمجرد حصولك على تقرير من المُراجع، تأكد من أنَّ أكثر المشاكل أهمية ستدخل مباشرًة إلى عمل فريقك. تأكد من عنونتها وإنهائها. هذا لا يعني أنه يجب عليك إصلاحها جميعًا والاستماع إلى كل ما يقوله المراجع. بالطبع لا، المهندس هو الذي يدير العمل، وليس المراجع. يجب أن يقرر المهندس الخاص بك ما هو الصحيح وما هو الخطأ في التنفيذ التقني للمنتج. ولكن من المهم أن تجعله يحل جميع المخاطر التي طرحها المراجع. ستحصل في كثير من الأحيان منه على إجابات مثل هذه الإجابة: "نحن لا نهتم بذلك الآن"، "لن نصلحه حتى الإصدار التالي،" أو "إنه مخطئ! نحن نفعلها بشكل أفضل." هذه الإجابات صالحة تمامًا، ويمكن أن تحصل عليها (المراجعون أشخاص ويخطئون أيضًا). ستساعدك الإجابات التي تم إيجادها على فهم ما يفعله فريقك ومدى فهمهم لعملهم. إذا كان بإمكانك تزويدنا بالمزيد من الاقتراحات، بناءً على تجربتك فيرجى نشرها في التعليقات وسأضيفها إلى القائمة. ترجمة -وبتصرف- للمقال You Do Need Independent Technical Reviews!‎ لصاحبه Yegor Bugayenko