صورة بواسطة redcharlie على Unsplash
بعد سنوات من العمل في التكنولوجيا، سئمت من الجدال حول أطر العمل
M. Zakyuddin Munziri
@zakiego
كتب أصلاً بـ English.
أنا سئمت من تلك المعارك.
بعد سنوات من العمل في مجال التكنولوجيا، رأيت نفس الحجج تتكرر في حلقة مفرغة. الناس يعاملون أطر العمل (Frameworks) مثل الهوية. التغريدات تتحول إلى حروب. الاجتماعات تصبح مناظرات حول الذوق. وفي الوقت نفسه، المنتج والمستخدمون ينتظرون.
نعم، بعض أطر العمل أسوأ بشكل موضوعي. لكن معظم الأطر الشائعة متقاربة بما يكفي. الفروق الحقيقية تهم في السياق، وليس كفائزين مطلقين. إطار عمل قد يبدأ (bootstrap) بشكل أسرع. وآخر قد يوفر مرونة أفضل قليلاً لنمط معين. هذه مقايضات (tradeoffs) حقيقية، لكنها نادراً ما تكون الهاوية التي تقرر النجاح أو الفشل.
لماذا تحدث المعارك
نقاشات أطر العمل صاخبة لسببين رئيسيين. أولاً، الأدوات تصبح هوية. اختيار إطار عمل يشير إلى الخبرة، الذوق، أو الانتماء إلى قبيلة. ثانياً، الضجيج (Hype) يضخم الفروق الصغيرة. المكتبات الجديدة تعد بحل شعور يمتلكه الناس بالفعل. المكتبات القديمة تُلآم على مشاكل هي في الواقع مشاكل في العمليات.
عندما تظهر تلك الطبقة العاطفية، تترك المحادثة المقايضات وتدخل في الدين. هذا يضيع الوقت والروح المعنوية.
معظم أطر العمل هي 11 إلى 14 على مقياس من 1 إلى 20
في الممارسة العملية، تتقارب أطر العمل حول نفس المشاكل الأساسية: التوجيه (routing)، إدارة الحالة (state management)، التصيير (rendering)، دورة الحياة، وتدفق البيانات. تفاصيل التنفيذ تختلف. واجهات برمجة التطبيقات (APIs) تختلف. لكن بعد الأشهر الأولى من المشروع، العوامل المسيطرة ليست اسم إطار العمل.
ما يحرك النتائج فعلياً هو الأنظمة البشرية حول إطار العمل: كيف يراجع الفريق الكود، من يملك سلوك وقت التشغيل (runtime)، كيف يتم هيكلة الاختبار والمراقبة (observability)، وكيف يتم نشر التغييرات والتراجع عنها. هذه هي الأشياء التي تحدد السرعة والاستقرار، وليس ما إذا كانت المكتبة "أ" تستخدم hooks أو class components أو API توجيه مختلف.
التفضيل لا بأس به. الإلزام ليس كذلك
لدي مفضلاتي. سأشرح لماذا أفضلها. سأشير إلى الأنماط التي أحبها والأنماط المضادة التي أتجنبها.
لكن التفضيل لا يجب أن يصبح إلزاماً بدون سبب. الفرق الجيدة تختار افتراضياً (default) وتوثق السبب. يجعلون القرار قابلاً للعكس. يكتبون المقايضات ليفهم القادمون الجدد التكلفة. يسمحون باستثناءات بمسار موافقة قصير عندما تكون الحالة قوية.
هذا يبقي المحادثة عملية. ينقل الفريق من الجدال القبلي إلى المقايضات الهندسية.
أطر العمل يمكن تعلمها وترقيعها
أطر العمل هي أدوات، وليست عقائد. إذا كان إطار العمل يفتقر إلى ميزة تحتاجها، يمكنك القيام بواحد من ثلاثة أشياء واقعية. أولاً، اقبل المقايضة وتجنب النمط الذي يثير الضعف. ثانياً، أضف محولاً (adapter) صغيراً أو غلافاً (wrapper) يوفر العقد الذي تريده. ثالثاً، وثق النمط ليستخدم الفريق نهجاً متسقاً.
هذه خطوات هندسية. إنها مملة. إنها تعمل. إنها تتوسع (scale) بشكل أفضل بكثير من إقناع الشركة بأكملها بتغيير المكدس التقني من أجل فوز مريح بسيط.
كيف أنصح الفرق أن تقرر بسرعة وبدون دراما
اجعل عملية القرار صريحة. أجب عن ثلاثة أسئلة عملية ووثقها.
- ما المشكلة التي نحلها ولماذا يساعدنا هذا الإطار في حلها.
- ما هي التكاليف القابلة للقياس التي نقبلها إذا اخترنا هذا الإطار.
- كيف يمكننا عكس أو تخفيف الخيار إذا سبب مشاكل.
إذا كانت تلك الإجابات واضحة، فخيار إطار العمل عادة ما يكون جيداً. إذا لم تتمكن من الإجابة عليها، فالنقاش مجرد ضجيج.
متى يكون الجدال مستحقاً
هناك حالات حقيقية تستحق القتال. قيود الأداء القصوى، متطلبات الامتثال الصارمة، أو الديون القديمة الهائلة هي أسباب مشروعة للتصعيد. في تلك الحالات، جادل بالبيانات والمقاييس الواضحة. أظهر الفرق في تكلفة الصيانة، العبء التشغيلي، أو الكمون (latency) تحت الحمل الحقيقي. لكن تلك الحالات أقل شيوعاً مما تجعلها الحروب على تويتر تبدو.
ختاماً
لا زلت أهتم بالأدوات الجيدة. لا زلت أهتم بالمقايضات. لست غير مبالٍ. أنا فقط متعب من تحويل الذوق التقني إلى احتكاك في الفريق.
اختيار إطار العمل يتعلق بالسياق، وليس الشخصية. علم المقايضات، وثق الأنماط، رقع الثغرات. ثم توقف عن الجدال وعد لبناء أشياء مفيدة.
إذا استمر الجدال، جرب هذا مع فريقك: اختر افتراضياً، اكتب فقرة واحدة تشرح السبب، ضع نافذة مراجعة قصيرة، وامضِ قدماً. ستنجز المزيد.
