هل سبق أن واجهت ملفات كود مخيفة، تلك التي يخشى الفريق بأكمله فتحها سرًا؟ ربما يكون لديك ميثود `build()` واحدة مسؤولة عن جلب البيانات وتنسيقها والتحقق منها ورسم الشاشة بأكملها—كل ذلك في مكان واحد! قد تعمل هذه الميثود، ولهذا لا أحد يريد لمسها. ولكن عندما تحتاج إلى إصلاح خطوة دفع صغيرة، تضطر إلى التمرير عبر ثلاث ميزات غير ذات صلة فقط للعثور على السطر الوحيد الذي تحتاج إلى تعديله. هل يبدو هذا مألوفًا؟

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

تتكون قطعة الليغو من جزأين رئيسيين: ما هي (شكلها، لونها، هدفها) وأزرارها (نقاط الاتصال القياسية التي تتيح ربطها بقطع أخرى). في البرمجة، «مكعباتك» هي الوحدات المستقلة لتطبيقك—قد تكون أداة (widget)، أو فئة (class)، أو خدمة (service)، أو حتى ميزة كاملة. و«الأزرار» هي العقود أو الوعود التي تقدمها وحدة الكود الخاصة بك للعالم الخارجي. وغالبًا ما تكون هذه فئات مجردة (abstract classes)، أو واجهات (interfaces)، أو توقيعات دالة (function signatures).

النقطة القوية هي: «ربط قطعتين في الكود يعني أن جزءًا واحدًا من تطبيقك يعتمد على جزء آخر *فقط* من خلال ذلك العقد، وليس عن طريق التدخل واستخدام الطريقة التي تم بها بناء الجزء الآخر داخليًا.» فكر في أداة `Padding` التي تستخدمها كل يوم. `Padding` هي «مكعب» مثالي. إنها تقوم بشيء واحد فقط، ولا تهتم بما ترسله إليها كـ `child`—سواء كان `Text` أو `Image` أو `Column`. يعتبر المعامل `child` هو «زرها». أنت لا تعلم `Padding` أبدًا كيفية رسم النص أو الصورة، ولا تحتاج هي إلى معرفة ذلك. يجعل هذا النهج كودك أنظف وأكثر نمطية وأقل إرهاقًا بكثير للصيانة. إنه يجعل تصحيح الأخطاء أسهل والتعاون مع فريقك أمرًا سلسًا.