مصطلحات البرمجيات التي ستسمعها

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

والخبر الجيد أن صورة واحدة تغطّي معظم الأمر. تكاد كل البرمجيات تكون جزأين يتحدّثان إلى بعضهما: شيء أمامك يقدّم طلبًا، وشيء في مكان آخر يجيب عنه. الـ browser لديك يسأل؛ وجهاز في مركز بيانات يجيب. هذا هو الـ client والـ server، وكل تبادل بينهما هو request وresponse — رحلة قصيرة ذهابًا وإيابًا تتكرّر عشرات المرات وأنت تقرأ صفحة واحدة. ومتى صرتَ ترى هذه الرحلات، يكفّ “الموقع معطّل” و”اتصالي ضعيف” عن أن يكونا الجملة نفسها، وهذا وحده يغيّر إلى مَن ينبغي أن تصعّد المشكلة.

وتقسيم frontend / backend هو الخط نفسه مرسومًا داخل منتج واحد. الـ frontend هو كل ما تستطيع رؤيته والنقر عليه، ويعمل على جهازك. والـ backend هو المنطق والقواعد والبيانات المخزَّنة، ويعمل على server لا ترى منه شيئًا. ولهذا تفاجئ التقديرات الناس. فـ “حرّك الزر” غالبًا frontend وغالبًا صغير. أما “أضِف حقلًا إلى النموذج” فيبدو مماثلًا لكنه في الغالب ليس كذلك — فالحقل يجب أن يُخزَّن، ويُتحقَّق منه، ويدخل في التقارير، ويُرحَّل لكل من سجّل قبل وجوده. وحين يقول لك زميل “هذا تغيير في الـ backend”، فهو يخبرك أن النصف غير المرئي داخلٌ في الأمر، والنصف غير المرئي هو حيث يذهب الوقت.

والـ API هو أنفع كلمة في هذه الصفحة لغير المهندس، لأنها الكلمة التي تحدّد ما إذا كان التكامل ممكنًا أصلًا. إنه القائمة المعلَنة بالأشياء التي يسمح نظامٌ لنظام آخر بأن يطلبها منه، مع الصيغة الدقيقة للطلب. فسؤال “هل نستطيع التكامل مع الـ CRM لدينا؟” هو في الحقيقة سؤالان أضيق: هل لذلك المنتج API، وهل يتيح تحديدًا الشيء الذي تحتاجه؟ كثير من الأدوات لديها API يستطيع قراءة السجلات لا إنشاءها، والمشروع كله يحيا أو يموت على هذه التفصيلة. وهذه، بالمناسبة، هي الفكرة نفسها التي يقوم عليها ربط Claude ببقية أدواتك — فالـ connector هو هذا الترتيب نفسه، لكن بنقرة.

والـ database هو المكان الذي تعيش فيه معلومات التطبيق بين زيارة وأخرى — طلباتك، ورسائلك، وحسابك. ويجدر أن تفصله في ذهنك عن الملف أو جدول البيانات، لأن الفرق يفسّر إحباطًا متكرّرًا. فإن كان الرقم الذي تريده موجودًا أصلًا في database، فغالبًا يستطيع أحدهم استخراجه بسرعة وبموثوقية. أما إن كان لا يوجد إلا داخل كومة من جداول البيانات المصدَّرة، فإن “أحضِر لي ذلك الرقم فقط” مشروع صغير، وتكراره شهريًا مشروع أكبر.

وكلمتان تفسّران لماذا البرمجيات أهشّ مما تبدو. الـ dependency هو كود من خارج مشروعك يعتمد عليه بدل أن يكتبه بنفسه، والبرمجيات الحديثة مصنوعة منها إلى حدّ ساحق — ولهذا قد يتعطّل شيء بسبب تغيير لم يُجرِه أحد في فريقك، ولهذا فإن “علينا إجراء ترقيات” عمل حقيقي لا مجرّد ترتيب بيت. أما الـ framework فهو الهيكل الجاهز الذي بُني عليه كل شيء؛ يُختار مبكرًا، ويصوغ كل ما يأتي بعده، وتغيير الرأي فيه مكلف. وحين يقول أحدهم إن الـ codebase “على framework قديم”، فهو يصف قيدًا على كل تقدير مستقبلي، لا تفضيلًا جماليًا.

وتبقى كلمتان ستسمعهما في لحظات مشحونة قليلًا. الـ bug ليس إلا كودًا يتصرّف على نحو خاطئ — كل برنامج فيه أخطاء من هذا النوع، والعثور عليها جزء طبيعي من العمل، ومعاملة الواحد منها كعيب في الشخصية هي كيف تتعلّم الفرق إخفاءها. أما الـ environment variable فهو إعداد يُحفظ خارج الكود، وغالبًا يكون سرًّا مثل API key أو كلمة مرور. ولهذا يتجهّم المهندس حين يعرض أحدهم لصق مفتاح في محادثة جماعية: فجوهر الترتيب كله أن السرّ لا يُكتب أبدًا في المكان المشترك، وهذا يجعلها مسألة بيانات وخصوصية بقدر ما هي مسألة تقنية.

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