ملاحظة قبل القراءة: هذا المقال في أصله أفكار وملاحظات صوتية سجّلتها بنفسي — تولّى «كلود» كتابتها وتحريرها والتحقّق من أرقامها وإضافة مصادرها. الجوهر رأيي أنا؛ والصياغة شراكة بيني وبينه. أنشر الفكرة وهي حيّة بدل أن أنتظرها حتى تكتمل.
أعود إلى كودٍ كتبته قبل عام، فأشعر بالانقباض.
ليست المشكلة أنّه سيّئ — بل أنّني أرى، بوضوحٍ لم يكن متاحاً لي وقتها، أين تصدّع التصميم من أساسه. أفتح التطبيق الذي كنت مبسوطاً به يوم أنجزته، فأجد أنّ إعادة النظر فيه تعني إعادة بناء التصميم من الصفر. لا إصلاح سطرٍ هنا وسطرٍ هناك — بل هدمٌ وبناء. والسؤال الذي يطاردني في كلّ مرة هو نفسه: كيف لم أنتبه لهذا وأنا أبنيه؟
بعد سنواتٍ من تكرار هذا المشهد، وصلتُ إلى تشخيصٍ لا أزعم أنّه نهائيّ، لكنّي لم أرَ ما ينقضه حتى الآن: العيب لم يكن في مهارتي يوم كتبت الكود. العيب كان في نقطة البداية.
المصيدة التي يسمّونها نصيحة
الجميع يكرّر النصيحة نفسها: «ابدأ بأيّ شيء، ثمّ طوّره لاحقاً». وهي نصيحةٌ مفهومة في ظاهرها — تحرّرك من شلل الكمال، وتدفعك للحركة بدل التنظير. حتى هنا، لا خلاف.
لكنّ السؤال الذي لا تجيب عنه هذه النصيحة هو: تطوّر ماذا، بالضبط؟ وكيف تعرف أنّك بلغت المرحلة التي صرت فيها قادراً على رؤية التطويرات التي يحتاجها العمل؟
هنا تكمن المصيدة. حين تبدأ بـ«الفكرة العامة» — النظام كاملاً بأطرافه المتعدّدة — وأنت تظنّ أنّك «قريبٌ من الكمال، متعلّمٌ بما يكفي لتعرف ما ستطوّره» — فإنّك في الحقيقة تبني تصميماً كاملاً على أرضٍ لم تفهمها بعد. وحين تعود إليه لتطوّره، تكتشف أنّ التطوير يعني هدم التصميم. لقد وقعت في الفخّ الذي حذّرتك منه النصيحة نفسها، من حيث ظننت أنّك تتّبعها.
فالمشكلة ليست في «ابدأ». المشكلة في ما الذي تبدأ به.
اقلب السؤال
بدل أن أسأل «كيف أبدأ ثمّ أطوّر؟»، قلبتُ السؤال إلى صيغةٍ تبدو مستحيلة:
كيف أصنع شيئاً لا أحتاج إلى تطويره لاحقاً؟
أعلم أنّ الجواب الحرفيّ مستحيل — كلّ شيءٍ يتطوّر. لكنّ قلب السؤال يكشف المتغيّر الحقيقيّ: قدر التعقيد في الشيء الذي تبنيه.
الشيء الذي فيه أكثر من سيناريو — أكثر من طريقة استخدام، أكثر من حالة، أكثر من مسارٍ محتمل — يستحيل أن تبنيه مثاليّاً من أوّل نسخة، لأنّك لا تملك بعدُ الخبرة التي تكشف لك تلك السيناريوهات كلّها. وكلّما زادت السيناريوهات، ازدادت استحالة الكمال من البداية.
اقلب المعادلة إذن: لا تبدأ بشيءٍ فيه سيناريوهات. ابدأ بشيءٍ بلا سيناريوهات.
خذ مثالاً بسيطاً: أن تكتب حرف الألف. ورقةٌ وقلمٌ وخطٌّ واحد. لا سيناريوهات، لا حالاتٌ متعدّدة، لا مسارات. النسخة الأولى هي أفضل نسخة — بل هي النسخة الوحيدة الممكنة. لا مجال هنا لأن تعود بعد عامٍ وتنقبض.
أصغر وحدةٍ يمكن أن تبلغ الكمال
من هذا القلب خرجت القاعدة التي أعمل بها اليوم:
ابنِ الوحدة التي أنت متأكّدٌ مئة بالمئة أنّها لن تتغيّر. صغِّر المهمّة إلى الحدّ الذي يجعلك واثقاً هذه الثقة الكاملة. ثمّ ابنِ عليها.
لاحظ الكلمة الأخيرة: ابنِ عليها، لا فيها. لا تُثقل الوحدة نفسها بالإضافات. اتركها مثاليّةً كما هي، ثمّ اصنع وحدةً ثانيةً مثاليّةً، ثمّ اربط الأولى بالثانية:
هذه العملية تُنجَز أوّلاً؛ وناتجها يدخل هذه العملية؛ وناتج الثانية يدخل الثالثة. وكلّ عمليةٍ مثاليّةٌ في موضعها.
هذه ليست فكرةً وليدة. إنّها العمود الفقريّ لفلسفة يونكس منذ سبعينيّات القرن الماضي. صاغها دوغ ماكلروي — مخترع الـ pipe — في جملةٍ صارت قانوناً: «اكتب برامج تفعل شيئاً واحداً وتتقنه. اكتب برامج تعمل معاً.» لم تُبنَ يونكس كبرنامجٍ واحدٍ ضخمٍ يفعل كلّ شيء، بل كأدواتٍ صغيرةٍ كلٌّ منها يتقن مهمّته الواحدة، ثمّ تُوصَل ببعضها عبر أنابيبٍ تنقل ناتج الواحدة إلى مدخل التالية.
والقاعدة نفسها لها اسمٌ في هندسة البرمجيات: مبدأ المسؤولية الواحدة. صاغه روبرت مارتن في جملةٍ حاسمة: «ينبغي أن يكون للوحدة سببٌ واحدٌ فقط للتغيير.» وحدةٌ بسببٍ واحدٍ للتغيير هي، بالضبط، وحدةٌ بلا سيناريوهاتٍ متزاحمة. حين تُجمِّع المسؤوليّات في مكانٍ واحد، تُجمِّع معها أسباب التغيير — وتضمن أن تعود إليها لاحقاً لتهدمها.
التعقيد يعيش في الروابط، لا في القطع
هنا المفارقة التي غيّرت طريقتي: حين تبني القطع مثاليّةً وتفصلها عن بعضها، لا يختفي التعقيد — بل ينتقل. ينتقل من داخل القطعة إلى الرابط بينها وبين القطعة التالية. وهذا في صالحك، لأنّ الرابط أوضح من الفوضى المبعثرة داخل قطعةٍ متضخّمة.
خذ مثالاً حيّاً من عملي: بناء نظام agent.
بدل أن أبدأ بتصميم النظام كاملاً، أبدأ بأصغر وحدةٍ لا سيناريو فيها: مربّع المحادثة، موصولاً بنموذج ذكاءٍ واحد. يرسل، يردّ. هذا كلّ شيء. أثق مئة بالمئة أنّه لن يتغيّر.
ثمّ أبني عليه. أريد نماذج أخرى؟ تسجيل دخولٍ وخروج؟ لا أحشرها في مربّع المحادثة. أصنع وحدةً منفصلة — قائمة إعداداتٍ — وأربطها. وحين تكتمل الإعدادات، ألاحظ اختصاراً: لست بحاجةٍ إلى زرٍّ لتبديل الـ agent من واجهة المحادثة؛ يكفي أن أفعلها من الإعدادات مباشرة. فأنقل الكود من هنا إلى هناك.
وكلّ نقلةٍ من هذا النوع تحتاج إلى اختبار. تتأكّد أنّ ما نقلته من موضعه القديم يعمل تماماً في موضعه الجديد. الوحدة تبقى مثاليّة؛ الرابط هو ما تختبره. هكذا يُبنى النظام «بشكلٍ طبيعيّ» — حبّةً حبّة — بدل أن يُولد ضخماً هشّاً.
متى تنتقل من القطعة إلى النظام؟
النتيجة النهائيّة التي تطمح إليها تتكوّن أحياناً من عدّة أنظمة، لا وحداتٍ فقط. وهنا — وهنا فقط — يدخل التعقيد المتعدّد السيناريوهات مشروعاً: نظام التطوير نفسه. الـ roadmap، الـ change logs، الـ debugging. هذه أنظمةٌ من طبيعتها متعدّدة السيناريوهات، فلا تُبنى في اليوم الأوّل. تُبنى حين تصبح الوحدات المثاليّة كثيرةً بما يكفي لتحتاج إلى تنظيمٍ يربطها.
بعبارةٍ أخرى: تبدأ بلا سيناريوهات، وتُدخل السيناريوهات في اللحظة التي يفرضها فيها الربط بين الوحدات — لا قبلها.
إذن، «ابدأ» أم لا؟
فلنُنهِ التوتّر الذي فتحنا به: هل هذا نقضٌ لنصيحة «ابدأ وطوّر لاحقاً»؟
لا. أنا لستُ ضدّ أن تبدأ. أنا ضدّ أن تبدأ على شيءٍ متعدّد السيناريوهات.
«ابدأ» صحيحة تماماً — بشرط أن تبدأ على أصغر شيءٍ لا يمكن أن يتغيّر. حينها لا تكون قد بدأت بشيءٍ ركيكٍ لتحسّنه لاحقاً؛ بل بدأت بشيءٍ مثاليٍّ لتبني عليه. الفرق ليس في متى تبدأ، بل في حجم ما تبدأ به. صغِّره إلى أن يستحيل عليه أن يخيّب ظنّك بعد عام.
قد يتغيّر رأيي يوماً — إن رأيتُ نظاماً وُلد دفعةً واحدةً، متعدّد الأطراف، وظلّ ممتازاً. حتى اليوم، بعد تطبيقاتٍ كثيرةٍ صغيرةٍ وكبيرة، لم أرَ ذلك. الوحدة الصغيرة المثاليّة لم تخذلني مرّة.
أسئلة كلود
هذا القسم من إعداد «كلود». بعد كتابة المقال، اختبر محرّكُ الذكاء الاصطناعي الذي أبني به عملي الحجّةَ، وطرح ما قد يطرحه القارئ الفطن من أسئلة. لم أُجب عنها بعد — سأجيب حين أتفرّغ، في تحديثٍ للمقال أو في التعليقات. هذا الحوار بيننا جزءٌ من الفكرة نفسها.
١. هذا الطرح يناقض «ابدأ الآن وطوّر لاحقاً» — وهنا صار الفخّ نفسه. اذكر المصالحة بصوتٍ عالٍ: ابدأ، لكن فقط على وحدةٍ بلا سيناريوهات؟ قد تكون هذه هي المقالة كلّها.
سيجيب ياسر عندما يتفرّغ — تابعوا تحديث المقال أو التعليقات.
٢. بعض أعظم المنتجات كانت رهاناً واحداً ضخماً ومتكاملاً (آيفون الأوّل مثالاً). كيف توفّق بين هذا وبين «أصغر وحدةٍ مثالية»؟
سيجيب ياسر عندما يتفرّغ — تابعوا تحديث المقال أو التعليقات.
٣. كيف تتعرّف على الوحدة الخالية من السيناريوهات قبل أن تبنيها؟ أعطنا اختبار اليوم الأوّل.
سيجيب ياسر عندما يتفرّغ — تابعوا تحديث المقال أو التعليقات.
