كيف يكتب المطور الذي يقضي أسبوعين في التفكير بالتصميم كوداً يعمل اليوم فوراً
إن معالجة مواصفات البنية المعمارية ومحاكاة حالات الاستثناء في ذهنك أمر ممتع، فالكود الموجود في ذهنك خالٍ من الأخطاء ومثالي. ولكن إذا طال التفكير دون فتح محرر النصوص، فلن يكون ذلك حرصاً بل خوفاً، وتحديداً الخوف من الفشل. وثائق التصميم الضخمة التي تم إنشاؤها لتجنب عدم اليقين تنهار تماماً عند أول تغيير في المتطلبات بمجرد بدء التطوير.
من أجل المطورين الذين يعانون من شلل التحليل ويهدرون وقتهم، قمنا بترتيب منهجية عمل لكسر المثالية وتقديم نموذج أولي (Prototype) اليوم بالذات.
التكلفة التي يدفعها العقل عندما يطول التفكير
إن مجرد مقارنة مختلف أطر العمل والبنى المعمارية قبل كتابة سطر واحد من الكود يسبب عبئاً معرفياً عالياً. إن الهوس بمعالجة أخطاء تقل احتمالية حدوثها عن 0.1%، أو بناء طبقات تجريد (Abstraction layers) قبل ظهور المتطلبات حتى، هو استجابة نمطية لتجنب الخسارة.
وفقاً لدراسة أجرتها شركتا McKinsey وLeadership IQ على شركات قائمة في مؤتمر فورتشن 500، فإن الوقت المهدر بسبب تردد اتخاذ القرار والتحليل المفرط يتجاوز 53,000 يوم سنوياً. وإذا حسبناها كتكلفة عمالة، فهذا يعني أن 250 مليون دولار تتبخر في الهواء دون أي نتائج. كما تنخفض إنتاجية المطور الفرد بنسبة تزيد عن 40% بسبب التحسين المسبق.
إذا شعرت أن المحاكاة الذهنية طالت، يجب عليك إيقافها قسراً بالنظام. يمكنك تطبيق نمط حلول الذروة (Spike Solution Pattern) الخاص ببرمجة القصوى (XP) في روتينك اليومي:
- أعلن لنفسك قائلاً: "سأقوم بالتخلص من هذا الكود دون أي ندم بعد 30 دقيقة".
- قم بتشغيل خادم التطوير المحلي خلال دقيقة واحدة باستخدام أوامر CLI الخاصة بالهيكلة الأساسية (Boilerplate).
- توقف عن التفكير في الهيكلة وقم فوراً بتنفيذ كود التحقق التقني الأكثر غموضاً.
نتائج بنسبة 30% تم إنشاؤها عبر حصر الوقت في 30 دقيقة
إذا كنت عالقاً في مرحلة التخطيط لمدة أسبوعين، فهذا لا يعني نقصاً في المواصفات، بل نقصاً في سياق التنفيذ. في هذه الحالة، يجب إغلاق وثائق التصميم وتحديد إطار زمني مدته 30 دقيقة.
النموذج الأولي بنسبة اكتمال 30% يكون خالياً تماماً من معالجة الأخطاء، والربط بقواعد البيانات، ودقة واجهة المستخدم. نحن ننظر فقط فيما إذا كانت النتيجة المطلوبة تظهر عند إدخال القيم. ولهذا السبب تقوم فرق المنتجات في وادي السيلكون بالاجتماع بناءً على نماذج أولي تعمل مباشرة بدلاً من وثائق المتطلبات المجردة. إزالة عدم اليقين لا تحدث إلا بتجربة الشاشة بأنفسنا.
- بدلاً من استعلامات قاعدة البيانات أو ربط واجهات برمجة التطبيقات (APIs)، اكتب كائن JSON مباشرة داخل الدالة.
- احذف معالجة الأخطاء تماماً واجعل سيناريو النجاح الوحيد هو الذي يتم تنفيذه.
- استخدم قوالب الواجهة الأمامية لإنشاء شاشة قابلة للنقر خلال 60 ثانية.
دعنا نحسبها بناءً على تكلفة التأخير (Cost of Delay). إذا قام 4 مهندسين يتقاضون 2,025 دولاراً أسبوعياً بتكرار اجتماعات البنية المعمارية لمدة أسبوعين، فسنتكبد خسائر مباشرة وغير مباشرة بقيمة 16,200 دولار.
| عنصر التقييم |
التطوير المرتكز على المواصفات |
التطوير المرتكز على النماذج الأولية |
التأثير |
| تعريف المتطلبات الأولية |
من أسبوعين إلى 4 أسابيع (كتابة الوثائق) |
من 30 دقيقة إلى يوم واحد (كتابة حلول الذروة) |
تقليل الوقت بنسبة 90% |
| اجتماعات تعديل التخطيط |
من 8 إلى 12 اجتماعاً في المتوسط (نقاشات مجردة) |
اجتماع أو اجتماعان في المتوسط (قائم على العروض التوضيحية) |
تقليل الاجتماعات بنسبة 70% |
| تصحيح أخطاء الاتجاه |
إعادة بناء الهيكل بالكامل |
التخلص من المسودة ذات 30 دقيقة |
تقليل تكلفة إعادة العمل للحد الأدنى |
| سرعة مراجعة PR |
حدوث اختناقات (Bottlenecks) |
نشر مسودة PR مسبقاً (Draft PR) |
زيادة سرعة المراجعة بنسبة 30% |
الفصل بين وقت التفكير ووقت البناء
إذا اختلط التفكير بالتنفيذ، فسوف تستمر في الالتفات للوراء أثناء كتابة الكود. ولهذا السبب يتم تقسيم ساعات عمل اليوم بوضوح بين مرحلة التحليل ومرحلة التنفيذ حصرياً. وهذا يشبه مبدأ "الوقت الثابت والنطاق المتغير" الذي تتبعه منهجية Shape Up لشركة Basecamp. حدد الوقت أولاً، وإذا بدا أنك لن تنتهي خلاله، فتخلَ عن الميزات.
عندما تواجه قسماً مسدوداً، فإن معيار الالتفاف حوله دون الوقوع في تأملات عميقة يعتمد على مفهوم "الدين المتعمد والمدروس" من مصفوفة الديون التقنية لمارتن فاولر. إذا كان الكود قابلاً للتغيير بسهولة لاحقاً، فمن الأفضل اختيار أبسط طريق التفاف الآن والقيام بعمل Commit.
قال جيف بيزوس إنه يجب اتخاذ القرار والتحرك عندما يصل مستوى اليقين إلى حوالي 70%. الانتظار حتى تصبح الأمور مثالية بنسبة 90% أو أكثر هو أمر يقتل السرعة.
- استخدم ساعة ونصف فقط من أصل 8 ساعات يومياً لتحديد نطاق حلول الذروة وجمع المعلومات.
- قم بتقسيم الوقت المتبقي إلى فترتين مدة كل منهما 3.5 ساعات مخصصتان للتنفيذ حصرياً. يمنع إجراء إعادة الهيكلة (Refactoring) خلال هذا الوقت.
- قم بتدوين الأفكار الهيكلية التي تظهر أثناء العمل في مفكرة ومراجعتها بعد انتهاء الجلسة.
رمي الكود الضعيف والحصول على التعليقات
إذا أخفيت الكود بحجة أنه ليس مثالياً، فسيعود عليك ذلك بعمل أكبر لاحقاً. يقوم فريق الهندسة في Shopify برفع مسودات PR (Draft PR) ليس للحصول على مراجعة لكود مثالي، بل للتحقق من اتجاه العمل.
من الأفضل الحفاظ على حجم PR بحيث يكون أقل من 200 إلى 300 سطر. إذا قمت بإرفاق وسم WIP (جارٍ العمل) مع عبارة "نستقبل التعليقات حول اتجاه هيكل الخوارزمية فقط"، فسوف تقلل أيضاً من عبء المراجع.
الكود الأولي ليس عملاً فنياً بل هو مجرد فرضية تحتاج إلى تحقق. عندما تصل التعليقات، قم بتطبيقها بسرعة وانتقل لما بعدها.
- تصنيف التعليقات إلى 3 مراحل: "تطبيق فوري"، "مهام مستقبلية"، "رفض".
- اترك التنسيق والاختبارات الأساسية بالكامل لخط أنابيب CI وLinter.
- قم بتعديل عناصر التطبيق الفوري فقط لإنهاء العملية من إنشاء PR إلى الدمج (Merge) خلال 24 ساعة.
البنية المعمارية الافتراضية المثالية لا يمكنها مغادرة ذهنك أبداً. سطر واحد من المسودة الضعيفة التي تعمل والتي تكتبها اليوم يصبح مهارتك الحقيقية. يمكنك الخروج من مستنقع تكلفة التأخير عندما تتخلى عن عذر المثالية.