أسئلة مقابلات مهندس البرمجيات

المنهجية: البحث عن المكمّل

الحل بالقوة الغاشمة يفحص كل زوج ممكن، ويستغرق O(n^2). والنهج الأفضل هو استخدام جدول تجزئة يربط كل قيمة بفهرسها. فأثناء المرور على المصفوفة، تكون القيمة التي نحتاجها لكل عدد x هي target - x. فإذا كان هذا المكمّل موجودًا بالفعل في الجدول، نُرجع الفهرس الحالي والفهرس المخزّن. وإلا نخزّن x مع فهرسه ونتابع. الفكرة الأساسية لصحة الحل هي أننا عند معالجة الفهرس i يكون الجدول محتويًا على قيم الفهارس السابقة تحديدًا، لا أكثر ولا أقل. وهذا يعني أنه إذا كان هناك زوج صالح ينتهي عند i، فسنجده فورًا. كما يمنع ذلك استخدام العنصر نفسه مرتين، لأننا لا نطابق إلا مع العناصر السابقة. التعقيد الزمني O(n) لأن كل قيمة تُدرج في الجدول ويُبحث عنها مرة واحدة. والتعقيد المكاني O(n) للجدول. ومن الحالات الحدية: القيم المكررة، والأعداد السالبة، والصفر، وعدم وجود زوج صالح إذا كانت المسألة تسمح بذلك.

المنهجية: نافذة منزلقة مع آخر فهرس ظهر فيه كل حرف

نستخدم نافذة منزلقة لا تحتوي إلا على أحرف غير مكررة. نحتفظ بالمؤشر left وبجدول يربط كل حرف بآخر فهرس ظهر فيه، ثم نحرّك المؤشر right عبر السلسلة. فإذا كان الحرف الحالي قد ظهر داخل النافذة الحالية، ننقل left إلى الموضع التالي لفهرسه السابق. بعد ذلك نحدّث فهرس الحرف ونسجّل أكبر طول بلغته النافذة. التفصيل المهم هنا أن المؤشر left لا يتحرك إلا إلى الأمام. فإذا كان الحرف قد ظهر قبل بداية النافذة الحالية، فلا ينبغي أن يؤدي إلى تقليصها. لهذا تكون صيغة التحديث left = max(left, lastSeen[char] + 1). التعقيد الزمني O(n) لأن كل حرف يُعالَج مرة واحدة، والمؤشر left لا يتحرك إلا إلى الأمام. والتعقيد المكاني O(k)، حيث يمثل k حجم مجموعة الأحرف. ومن الحالات الحدية: السلسلة الفارغة، وكون جميع الأحرف فريدة، وكونها جميعًا مكررة، وأحرف Unicode إذا كانت لغة البرمجة تتعامل مع الأحرف بشكل مختلف عن البايتات.

المنهجية: المفتاح القياسي (Canonical key)

الكلمات المتجانسة حرفيًا (anagrams) تتكون من الأحرف نفسها بالعدد نفسه. لذلك ننشئ لكل كلمة مفتاحًا قياسيًا، ونجمع الكلمات بحسب هذا المفتاح في جدول تجزئة. وأبسط مفتاح هو أحرف الكلمة بعد ترتيبها؛ فالكلمات «eat» و«tea» و«ate» تتحول كلها إلى «aet». إذا كانت السلاسل قصيرة، فترتيب أحرف كل كلمة حل بسيط وموثوق. أما إذا اقتصرت الأبجدية على الأحرف الإنجليزية الصغيرة وكانت السلاسل طويلة، فقد يكون مفتاح التكرارات المكوّن من 26 عدّادًا أسرع، لأنه يتجنب ترتيبًا بتكلفة O(k log k) لكل كلمة. التعقيد الزمني مع الترتيب هو O(n * k log k)، حيث يمثل n عدد السلاسل، ويمثل k متوسط طول السلسلة. ومع العدّ على أبجدية ثابتة، يمكن أن ينخفض إلى O(n * k). والتعقيد المكاني O(n * k) للمخرجات والمفاتيح معًا. ومن الحالات الحدية: السلاسل الفارغة، والتكرارات، وقواعد التعامل مع الأحرف الكبيرة والصغيرة، والأحرف غير الإنجليزية.

المنهجية: ثلاثة مؤشرات: previous، current، next

نستخدم ثلاثة مؤشرات: يبدأ previous بالقيمة null، ويبدأ current من رأس القائمة. ولكل عقدة، نخزّن next = current.next، ثم نوجّه current.next إلى previous، وبعدها ننقل previous إلى current، ثم current إلى next. وعندما تصبح قيمة current هي null، يكون previous هو الرأس الجديد. الشرط الثابت هنا أن previous يشير إلى الجزء الذي عُكس بالفعل، وأن current يشير إلى أول عقدة لم تُعكس بعد. ومن الضروري تخزين next قبل تغيير current.next، وإلا ضاع باقي القائمة. التعقيد الزمني O(n)، والتعقيد المكاني O(1). ومن الحالات الحدية: القائمة الفارغة، والعقدة الواحدة، والتأكد من أن الرأس الأصلي أصبح الذيل وأن قيمة next فيه هي null.

المنهجية: حدود النطاق المسموح

من الأخطاء الشائعة الاكتفاء بالتحقق من أن كل عقدة أكبر من ابنها الأيسر وأصغر من ابنها الأيمن. وهذا غير كافٍ، لأن الشجرة الفرعية بأكملها يجب أن تلتزم بالقيود التي تفرضها العقد الأسلاف. نستخدم البحث بالعمق (DFS) مع حد أدنى وحد أعلى. فلكل عقدة نتحقق من أن lower < node.value < upper. يحصل الابن الأيسر على الحد الأدنى نفسه، وتصبح القيمة الحالية حده الأعلى. ويحصل الابن الأيمن على القيمة الحالية حدًّا أدنى مع الحد الأعلى نفسه. وإذا خرجت أي عقدة عن نطاقها، نُرجع false. التعقيد الزمني O(n) لأن كل عقدة تُزار مرة واحدة. والتعقيد المكاني O(h) لعمق الاستدعاء العودي، حيث يمثل h ارتفاع الشجرة. ومن الحالات الحدية: القيم المكررة، والحدان الأدنى والأعلى للأعداد الصحيحة، والشجرة الفارغة، والأشجار المنحرفة. ومن المهم الاستفسار عما إذا كانت القيم المكررة مسموحة، وفي أي جهة توضع إن كانت كذلك.

المنهجية: البحث بالعرض حسب طبقات المسافة

نمثّل كل خلية مفتوحة كعقدة في رسم بياني، وكل حركة إلى الأعلى أو الأسفل أو اليسار أو اليمين كضلع بوزن متساوٍ. ولأن لكل حركة التكلفة نفسها، فإن البحث بالعرض (BFS) يعطي أقصر مسار. نبدأ من خلية المصدر، ونضيفها إلى الطابور بمسافة 0، ونعلّمها كخلية تمت زيارتها. ولكل خلية نسحبها من الطابور، نستكشف جيرانها الصالحين الذين لم تتم زيارتهم، والواقعين داخل حدود الشبكة ولا يمثلون عوائق. وأول مرة نصل فيها إلى الهدف تكون المسافة هي الأقصر. تنبع صحة الحل من أن BFS يعالج العقد بترتيب تصاعدي للمسافة. فبمجرد زيارة خلية ما، لا يمكن أن يؤدي الوصول إليها لاحقًا إلى مسار أقصر في رسم بياني غير موزون. التعقيد الزمني O(rows * cols)، أي عدد الصفوف مضروبًا في عدد الأعمدة، لأن كل خلية تُزار مرة واحدة على الأكثر. والتعقيد المكاني O(rows * cols) للطابور ومجموعة الخلايا المزارة. ومن الحالات الحدية: انسداد خلية البداية أو النهاية، وتطابق المصدر مع الهدف، وعدم وجود مسار، وما إذا كانت الحركة القطرية مسموحة.

المنهجية: جدول للعقد المزارة يربط كل عقدة أصلية بنسختها

نستخدم جدول تجزئة يربط كل عقدة أصلية بالعقدة المنسوخة منها. وأثناء الاجتياز بأسلوب DFS أو BFS، عند زيارة عقدة أصلية، ننشئ نسختها إن لم تكن موجودة. ثم ننسخ كل جار لها، بالاستدعاء العودي أو بالتكرار، ونضيف الجار المنسوخ إلى قائمة الجوار الخاصة بالعقدة المنسوخة. يحل جدول العقد المزارة مشكلتين: يمنع الحلقات اللانهائية في الرسوم البيانية الدورية، ويحافظ على المراجع المشتركة بحيث تكون للرسم المنسوخ البنية نفسها التي للرسم الأصلي. التعقيد الزمني O(V + E)، حيث يمثل V عدد العقد، ويمثل E عدد الأضلاع. والتعقيد المكاني O(V) للجدول ولمكدس الاجتياز أو طابوره، دون احتساب الرسم البياني الناتج. ومن الحالات الحدية: المدخل الفارغ (null)، والحلقات الذاتية، والرسوم البيانية غير المتصلة إذا كانت المسألة تتوقع النسخ انطلاقًا من عقدة بداية فقط، وتكرار الجار نفسه في قائمة الجيران.

المنهجية: برمجة ديناميكية تصاعدية (Bottom-up DP) على المبلغ

نعرّف dp[a] بأنه أقل عدد من العملات يلزم لتكوين المبلغ a. نهيّئ dp[0] = 0 وبقية القيم باللانهاية. ولكل مبلغ من 1 حتى المبلغ المستهدف، نجرب كل عملة: إذا كانت قيمة a - coin غير سالبة، فإن dp[a] = min(dp[a], dp[a - coin] + 1). وفي النهاية، إذا ظلت قيمة dp[target] لانهائية، نُرجع -1. تنجح علاقة التكرار لأن العملة الأخيرة في أي حل أمثل لا بد أن تكون إحدى الفئات المتاحة. فإذا كانت قيمة هذه العملة الأخيرة c، فالمبلغ المتبقي هو target - c، ويجب أن يُحل هو الآخر على النحو الأمثل. التعقيد الزمني O(A * C)، حيث يمثل A المبلغ، ويمثل C عدد فئات العملات. والتعقيد المكاني O(A). ومن الحالات الحدية: المبلغ 0، والمبالغ التي يستحيل تكوينها، ووجود عملة بقيمة 1، وتكرار الفئات، والمبالغ المستهدفة الكبيرة.

المنهجية: برمجة ديناميكية بحسب موضع النهاية، ثم التحسين بالبحث الثنائي

يعرّف حل البرمجة الديناميكية الواضح dp[i] بأنه طول أطول متتالية جزئية متزايدة تنتهي عند الفهرس i. ولكل i نفحص كل j سابق له: إذا كان nums[j] < nums[i]، فبإمكان العنصر nums[i] أن يمدّ المتتالية المنتهية عند j، ومن ثم dp[i] = max(dp[i], dp[j] + 1). والإجابة هي max(dp). ويستغرق هذا الحل زمنًا O(n^2) وذاكرة O(n). أما النهج المحسَّن بتعقيد O(n log n) فيحتفظ بمصفوفة tails، حيث يمثل tails[length - 1] أصغر قيمة نهائية ممكنة لمتتالية متزايدة بهذا الطول. ولكل عدد، نبحث بحثًا ثنائيًا عن أول عنصر في tails أكبر منه أو يساويه، ونضع العدد في مكانه. ويكون طول tails هو طول أطول متتالية جزئية متزايدة (LIS). في المقابلة، من المعقول تقديم حل البرمجة الديناميكية بتعقيد O(n^2) أولًا إذا كان الوقت محدودًا، ثم مناقشة النسخة المحسّنة. ومن الحالات الحدية: القيم المكررة، والمصفوفات المتناقصة، والمدخلات الفارغة، وما إذا كان يجب أن تكون المتتالية متزايدة تزايدًا صارمًا.

المنهجية: بناء البادئات الصحيحة فقط

نستخدم التتبع العكسي مع عدّادين: الأول open لأقواس الفتح المستخدمة، والثاني close لأقواس الإغلاق المستخدمة. في كل خطوة، يمكننا إضافة قوس فتح إذا كان open < n، وإضافة قوس إغلاق إذا كان close < open. وهذا الشرط الثاني يضمن بقاء كل بادئة صحيحة، فلا نولّد أبدًا سلاسل غير صحيحة نضطر إلى تصفيتها لاحقًا. عندما يصل طول السلسلة الحالية إلى 2n، نضيفها إلى النتيجة. وبهذه الطريقة لا نستكشف إلا البادئات الصحيحة، ونقلّم الحالات المستحيلة مبكرًا. عدد المخرجات الصحيحة هو عدد كاتالان رقم n (Catalan number)، لذا يهيمن حجم المخرجات على زمن التنفيذ. ويشمل التعقيد المكاني عمق الاستدعاء العودي O(n) إضافةً إلى المخرجات. ومن الحالات الحدية: n = 0 أو n = 1، بحسب تعريف المسألة.

المنهجية: المتطلبات ← API ← توليد المعرّفات ← التخزين ← مسار إعادة التوجيه ← التوسع

المتطلبات: يرسل المستخدم رابطًا طويلًا ويحصل على رابط قصير، وعندما يزور أي شخص الرابط القصير، يجب إعادة توجيهه بسرعة. ومن الميزات الاختيارية: الأسماء المستعارة المخصصة، وانتهاء الصلاحية، والتحليلات، وكشف الرسائل المزعجة، وحسابات المستخدمين. واجهتا API الأساسيتان: الأولى createShortUrl(longUrl, optionalAlias, expiration)، والثانية redirect(shortCode). أما نموذج البيانات فيضم: shortCode، longUrl، userId، createdAt، expiresAt، status، إضافةً إلى بيانات وصفية للتحليلات عند الحاجة. لتوليد المعرّفات عدة خيارات: معرّفات تتزايد تلقائيًا (auto-increment) مرمّزة بنظام base62، أو رموز base62 عشوائية مع التحقق من التصادمات، أو توليد موزع للمعرّفات. التزايد التلقائي بسيط، لكنه يكشف حجم الاستخدام ما لم يُموَّه. والمعرّفات العشوائية سهلة التوزيع، لكنها تحتاج إلى معالجة التصادمات. وعلى نطاق متوسط، يُعد استخدام رموز base62 عشوائية مع قيد التفرّد في قاعدة البيانات خيارًا مقبولًا. مسار القراءة هو الأهم. يجب أن تكون إعادة التوجيه سريعة: تحميل shortCode من ذاكرة التخزين المؤقت، والرجوع إلى قاعدة البيانات عند عدم وجوده، والتحقق من انتهاء الصلاحية والحالة، ثم إرجاع HTTP 301 أو 302. يُستخدم 302 إذا كانت التحليلات أو تغيير الوجهة مهمة، ويُستخدم 301 لإعادة التوجيه الدائمة مع تخزين مؤقت أقوى في المتصفح. التوسع: تخزين الرموز القصيرة الأكثر طلبًا مؤقتًا في Redis أو في ذاكرة تخزين مؤقت على الحافة (edge cache)، وتقسيم البيانات (sharding) حسب shortCode عند الحاجة، وتخزين التحليلات بشكل غير متزامن عبر طابور، وتحديد معدل إنشاء الروابط، وإجراء فحوصات للرسائل المزعجة والبرمجيات الخبيثة. كما ينبغي مراقبة زمن استجابة إعادة التوجيه، ونسبة الإصابة في ذاكرة التخزين المؤقت (cache hit rate)، ومعدل الأخطاء، وبلاغات إساءة الاستخدام، وتشبّع قاعدة البيانات.

المنهجية: المستخدمون ← المنشورات ← التوزيع (fanout) ← الترتيب ← القراءة ← الاتساق

أبدأ بتوضيح نوع الموجز: موجز اجتماعي قائم على المتابعة، أو موجز توصيات، أو موجز مختلط. ولنفترض أنه موجز متابعة، ينشئ فيه المستخدمون منشورات يراها متابعوهم مرتبة حسب الصلة أو الأحدث. الكائنات الأساسية: المستخدمون، وعلاقات المتابعة، والمنشورات، والوسائط، وعناصر الموجز، والإعجابات والتعليقات، وخصائص الترتيب (ranking features). ومن واجهات API المطلوبة: createPost، getFeed، followUser، unfollowUser، interactWithPost. هناك نموذجان شائعان لتوليد الموجز. الأول هو التوزيع عند الكتابة (fanout-on-write)، ويدفع المنشورات الجديدة إلى مخازن موجزات المتابعين لحظة إنشاء المنشور. وهذا يجعل القراءة سريعة، لكنه يجعل الكتابة مكلفة للمستخدمين أصحاب العدد الكبير من المتابعين. والثاني هو التوزيع عند القراءة (fanout-on-read)، ويحسب الموجز عند طلبه بجلب منشورات الحسابات المتابَعة. وهذا يجعل الكتابة رخيصة، لكن القراءة أبطأ. والشائع هو النهج الهجين: التوزيع عند الكتابة للمستخدمين العاديين، والتوزيع عند القراءة أو معالجة خاصة لحسابات المشاهير. البنية المعمارية: خدمة المنشورات تكتب المنشورات، وخدمة الرسم البياني الاجتماعي تخزن علاقات المتابعة، وخدمة الموجز تدير الخطوط الزمنية للموجزات، وخدمة الترتيب تقيّم المنشورات المرشحة، وذاكرة التخزين المؤقت تحفظ الموجزات الأكثر طلبًا، والوسائط تُحفظ في تخزين الكائنات وتُقدَّم عبر CDN. وتُستخدم الطوابير لتنفيذ التوزيع وتحديثات الترتيب بشكل غير متزامن. المفاضلات: حداثة الموجز مقابل جودة الترتيب، واتساق تغييرات المتابعة، والتعامل مع حسابات المشاهير، وإبطال ذاكرة التخزين المؤقت، والرسائل المزعجة، وقيود الحظر والخصوصية، وإعادة ملء البيانات (backfill) بعد أعطال الطوابير. كما ينبغي مراقبة زمن تحميل الموجز، وحداثته، وتأخر التوزيع، والتفاعل، ونسبة الإصابة في ذاكرة التخزين المؤقت، وأخطاء الترتيب، وبلاغات إساءة الاستخدام.

المنهجية: الاتصالات ← تدفق الرسائل ← الحفظ الدائم ← التسليم ← الموثوقية

المتطلبات: رسائل فردية وجماعية، والتسليم للمستخدمين المتصلين وغير المتصلين، وسجل الرسائل، وإشعارات القراءة، ومؤشرات الكتابة، والإشعارات الفورية (push). ومن المهم توضيح ما إذا كان التشفير التام بين الطرفين، والمرفقات، والمزامنة بين أجهزة متعددة من المتطلبات. يحافظ العملاء على اتصالات WebSocket مع خدمة بوابة (gateway). وعندما يرسل المستخدم رسالة، تتحقق البوابة من هويته، وتعيّن مفتاح منع التكرار (idempotency key) أو تستلمه، وتكتب الرسالة في تخزين دائم، وتنشر حدثًا، ثم تسلّم الرسالة للمستلمين المتصلين عبر اتصالاتهم النشطة. أما المستخدمون غير المتصلين فيتلقون إشعارات فورية، ويمكنهم جلب السجل لاحقًا. نموذج البيانات: المحادثة، والمشارك، والرسالة، وحالة التسليم، وحالة القراءة، والجهاز أو الجلسة. ويحتاج التخزين إلى قراءات فعالة حسب المحادثة والوقت. ويمكن لقاعدة بيانات علائقية أن تفي بالغرض على نطاق متوسط، بينما تُستخدم أنظمة التخزين الموزعة على نطاق أكبر. ويجب أن تذهب المرفقات إلى تخزين الكائنات، لا إلى قاعدة بيانات الرسائل. تحديات الموثوقية: تكرار الإرسال، ووصول الرسائل بغير ترتيبها، وإعادة الاتصال، والرسائل الفائتة، والتوزيع في المجموعات الكبيرة، ودقة حالة الاتصال. وتُعالَج باستخدام مفاتيح منع التكرار، وأرقام تسلسلية متزايدة باطّراد لكل محادثة، وإشعارات الاستلام (acknowledgements)، ومنطق إعادة المحاولة، وواجهات API للمزامنة بدءًا من آخر رسالة تمت رؤيتها. تجب مراقبة زمن إرسال الرسائل، ونسبة نجاح التسليم، وعدد اتصالات WebSocket، ومعدل إعادة الاتصال، وتأخر الطوابير، وإخفاقات الإشعارات الفورية، وأخطاء الكتابة في التخزين.

المنهجية: التحقق ← تحديد النطاق ← التغييرات الأخيرة ← تحليل التبعيات ← احتواء المشكلة

أبدأ بالتحقق من صحة المؤشر نفسه: هل تظهر الزيادة في زمن الاستجابة في أكثر من نظام مراقبة؟ وهل تؤثر في p50 أو p95 أو p99، أم في نقطة نهاية (endpoint) محددة فقط؟ ثم أتأكد مما إذا كان المستخدمون يلاحظونها. بعد ذلك أحدد نطاق المشكلة حسب نقطة النهاية، والمنطقة، ومنطقة التوافر (availability zone)، وشريحة العملاء، والإصدار، والخادم، والخدمة التابعة، ونوع الطلب. فالزيادة الشاملة تشير إلى خدمة تابعة مشتركة أو عملية نشر، أما الزيادة المحدودة فتشير إلى مسار أو استعلام أو عميل أو منطقة بنية تحتية بعينها. ثم أفحص التغييرات الأخيرة: عمليات النشر، وتغييرات الإعدادات، وترحيل قواعد البيانات، وارتفاعات حركة المرور، ومفاتيح الميزات (feature flags)، وتغييرات ذاكرة التخزين المؤقت، وحوادث الخدمات التابعة. وأحلل زمن الاستجابة حسب أجزاء الخدمة (spans) باستخدام التتبعات (traces). وأتحقق من زمن استعلامات قاعدة البيانات، ونسبة الإصابة في ذاكرة التخزين المؤقت، وتأخر الطوابير، واستخدام المعالج (CPU) والذاكرة، وجمع البيانات المهملة (garbage collection)، ومجمّعات الخيوط (thread pools)، ومجمّعات الاتصالات، وواجهات API الخارجية. إذا كان المستخدمون متأثرين، فاحتواء المشكلة يأتي قبل الوصول إلى السبب الجذري الكامل: التراجع عن النشر (rollback)، أو تعطيل مفتاح ميزة، أو زيادة السعة، أو تجاوز خدمة تابعة بطيئة، أو زيادة مدة صلاحية ذاكرة التخزين المؤقت (TTL) إن كان ذلك آمنًا. وبعد التعافي، أوثّق السبب الجذري، والثغرة في آليات الرصد، وخطة منع التكرار.

المنهجية: حالات الوحدة ← الحدود ← المدخلات غير الصالحة ← الشروط الثابتة

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

المنهجية: الصحة ← قابلية الصيانة ← المخاطر ← الوضوح

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

المنهجية: السياق ← الخيارات ← المفاضلات ← القرار ← النتيجة

يُفضَّل اختيار قرار ينطوي على مفاضلات حقيقية: التطوير الداخلي مقابل الشراء، أو SQL مقابل NoSQL، أو النظام الموحّد (monolith) مقابل الخدمات المستقلة، أو الإصلاح السريع مقابل إعادة هيكلة أعمق، أو الاتساق القوي مقابل التوافر. والبداية تكون بالسياق والقيود، ثم شرح الخيارات التي درستها. الإجابة القوية تحدد المفاضلة بوضوح. على سبيل المثال: «الخيار A سمح لنا بالإطلاق خلال أسبوع، لكنه زاد العبء التشغيلي. أما الخيار B فاستغرق ثلاثة أسابيع، لكنه أزال نقطة اختناق كانت تعيق التوسع». بعد ذلك يأتي شرح الأدلة التي استند إليها القرار: حجم حركة المرور، أو موعد نهائي لعميل، أو سجل الحوادث، أو قدرة الفريق، أو خارطة الطريق طويلة المدى. وفي الختام، تُعرض النتيجة وما تعلمته منها. وإذا لم يكن القرار مثاليًا، فمن المهم ذكر ما كنت ستفعله بشكل مختلف. فالمحاورون يقدّرون النضج في التقدير أكثر من التظاهر بأن كل قرار كان بديهيًا.

المنهجية: العطل ← الأثر ← الاستجابة ← السبب الجذري ← الوقاية

يُفضَّل الحديث عن عطل حقيقي إن أمكن. والبداية تكون بأثره على المستخدمين: ما الذي تعطل، ومن تأثر، وما مدى خطورته. ثم شرح دورك في الاستجابة: الرصد، أو الفرز وتحديد الأولويات، أو التراجع عن النشر، أو احتواء المشكلة، أو التواصل، أو تحليل السبب الجذري. أفضل الإجابات تُظهر هدوءًا في ترتيب الأولويات. فأثناء العطل، استعادة الخدمة أهم من إثبات نظرية. ومن المفيد ذكر كيفية استخدامك للسجلات، والمقاييس، والتتبعات، ومفاتيح الميزات، والتراجع عن النشر، أو فحص الخدمات التابعة. بعد احتواء المشكلة، يأتي شرح السبب الجذري وإجراءات الوقاية. ومن أمثلة الوقاية الجيدة: اختبارات أفضل، وطرح أكثر أمانًا، ومراقبة، وضبط التنبيهات، وأدلة التشغيل (runbooks)، وقواطع الدائرة (circuit breakers)، والضغط العكسي (backpressure)، وضمانات لعمليات الترحيل. ومن المهم تجنّب إلقاء اللوم على الأشخاص؛ فالفرق القوية تحسّن الأنظمة بحيث يصعب تكرار الخطأ نفسه.

المنهجية: الهدف المشترك ← القيود ← الخيارات ← المفاضلات ← القرار

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