Every new project whispers the same temptation: open the editor, pick a framework, and start typing. For MaxOS, creator

كل مشروع جديد يهمس بنفس الإغراء: افتح المحرر، اختر إطار عمل، وابدأ في الكتابة. بالنسبة لـ MaxOS، شعر المبتكر Max Paardekam بهذا الانجذاب بشدة. قبل بضعة أسابيع، لم يكن المشروع سوى أفكار مبعثرة في ملاحظاته. كانت غريزته الفورية هي قضاء ساعة تلو الأخرى في كتابة TypeScript داخل Cursor، تاركاً ذاكرة العضلات والإكمال التلقائي يبنيان الزخم. لكنه قاوم ذلك. فبدلاً من كتابة كود التطبيق، أنتج شيئاً أندر وأكثر هشاشة: بنية هندسية مكتملة.

بدا ذلك القرار وكأنه ركود في البداية. فعندما تكون الأدوات جاهزة ويتم تثبيت الملفات الأساسية (boilerplate) في ثوانٍ، قد يبدو التوقف لرسم المربعات والأسهم أمراً عبثياً. لكن MaxOS لا يتشكل ليكون مجرد غلاف Electron بسيط حول عرض ويب (web view). الهدف هو بناء شيء يصمد لسنوات من الاستخدام، وإعادة الهيكلة (refactoring)، والتوسع. الأنظمة التي تمتلك هذا النوع من العمر الافتراضي تتطلب شيئاً أعمق من مجرد بداية سريعة؛ إنها تحتاج إلى تفكير متماسك قبل كتابة أول جملة استيراد (import statement).

لماذا يمكن لبيئة التطوير المتكاملة (IDE) أن تنتظر

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

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

التفكير في الأنظمة، لا الميزات

لم يكن التحول الأبرز خلال هذه الأسابيع تقنياً، بل كان إدراكياً. فعندما تؤخذ هندسة البرمجيات على محمل الجد، فإنها تعيد صياغة الأسئلة التي تطرحها. توقف Paardekam عن التعامل مع المشروع بعقلية الميزات؛ فلم يعد يسأل عن كيفية إضافة قدرة معينة، بل واجه سؤالاً أصعب: ما هي البنية الأساسية التي ستجعل إضافة كل قدرة مستقبلية أمراً أسهل؟

هذا التمييز مهم. عقلية الميزات تعامل البرمجيات كقائمة مهام؛ تنفذ البحث، ثم الإشعارات، ثم زر التصدير. أما عقلية الأنظمة فتسأل كيف يمكن للبحث والإشعارات والتصدير أن يتشاركوا في نفس نموذج البيانات، ونفس ناقل الأحداث (event bus)، ونفس طبقة الأذونات. وهذا يعني تصميم قواعد لغة التطبيق قبل كتابة جملها. التكلفة المسبقة أعلى، لكن المكافأة هي أن العمل المستقبلي سيتوقف عن كونه مجرد عملية تجميع، ليبدأ في كونه عملية تركيب متناغم.

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

مساحة العمل، لا نظام التشغيل

كان Paardekam صريحاً بشأن حدود طموحه. لن يحل MaxOS محل Windows أو macOS، فهو لا يطمح لإدارة برامج التشغيل (drivers)، أو تخصيص الذاكرة، أو طبقات تجريد الأجهزة. الهدف هو شيء أكثر قرباً: مساحة العمل.

يعيش معظم العاملين في مجال المعرفة داخل بيئة مجزأة؛ حيث تنتقل من عميل البريد الإلكتروني إلى التقويم، ومن تطبيق الملاحظات إلى الطرفية (terminal)، ومن أداة التصميم إلى منصة المراسلة. كل قفزة تحمل معها احتكاكاً، حيث يضيع السياق وتتشتت الانتباه. يوفر نظام التشغيل المسرح، لكنه لا يخرج المسرحية.

يهدف MaxOS إلى توحيد تلك التجربة في بيئة واحدة تفهم مسار عملك وتساعدك بنشاط على التحرك بشكل أسرع. هذا تحدٍ هندسي مختلف عن بناء نظام تشغيل تقليدي؛ فهو يتطلب تعاطفاً عميقاً مع سير العمل، وتحريراً صارماً للنطاق، وواجهات تتكيف مع القصد بدلاً من إجبار المستخدم على التكيف مع الأداة. إن استبدال مساحة العمل يعني استبدال العادات، والعادات لا تتغير إلا عندما يبدو البديل مريحاً وليس مجرد منحنى تعلم جديد.

ما تم بناؤه في الأسابيع الهادئة

أنتجت مرحلة التصميم المعماري لـ Paardekam مخرجين ملموسين. أولاً، تحديد واضح للرؤية والرسالة. هذا ليس مجرد كلام تسويقي فارغ؛ فبالنسبة لمؤسس تقني يعمل بمفرده، يعمل هذا التحديد كحارس نهائي لنطاق العمل. فعندما تواجه قراراً بشأن ما إذا كنت ستضيف شريطاً جانبياً للدردشة أو سوقاً للإضافات، فإن بيان الرسالة إما أن يدعم ذلك أو يرفضه. ثانياً، أكمل مخططاً كاملاً للمشروع (blueprint).

إن رؤية الخطة بأكملها من البداية إلى النهاية غيرت سيكولوجية المشروع. فالأفكار في الدفاتر تبدو افتراضية، أما المخطط فيبدو حتمياً. فهو يكشف الثغرات بينما لا تزال تكلفة إصلاحها منخفضة، ويكشف أين تختبئ أصعب المخاطر. في هذه المرحلة، تهم الوثيقة الدقيقة حقاً أكثر من أسطر الكود؛ إذ يمكن إعادة هيكلة الكود (refactored)، أما الفرضية المشوشة فتتصلب لتصبح ديناً تقنياً (technical debt) لا يمكن لأي قدر من تصحيح الأخطاء (debugging) في وقت متأخر من الليل أن يمحوه.

من الورق إلى الـ Monorepo

مع انتهاء مرحلة التصميم المعماري، بدأت المرحلة التالية. ينتقل Paardekam من الوثائق إلى الكود، بدءاً بتهيئة الـ monorepo. يحمل هذا الانتقال قلقه الخاص؛ فالمخطط هو وعد، أما قاعدة الكود فهي الدليل. لقد اعترف بشعوره بالتوتر حيال ما إذا كان التصميم سيصمد عند مواجهة التنفيذ الفعلي. ويعكس هذا الصدق احتراماً صحياً للمجهولات التي لا تظهر إلا عندما تلتقي النظرية بإصدارات المكتبات، والحالات الحدية (edge cases)، وواقع السلوك عبر المنصات المختلفة.

إن تهيئة الـ monorepo هي أكثر من مجرد إجراء شكلي لـ git init. فهي تضع الهيكل المادي الذي سيعكس المعمارية المنطقية. فمكان وجود الحزم (packages)، وكيفية اعتمادها على بعضها البعض، وأين تقع الحدود بين الطبقات، سيعكس أسابيع من التخطيط. إذا تم الأمر بشكل جيد، فإن هيكل المجلدات الأول وسلسلة عمليات البناء (build pipeline) سيوجهان المساهمات المستقبلية. أما إذا تم بشكل سيئ، فسيُعاقب كل مطور يلمس المشروع بصمت لسنوات.

الخلاصة الحقيقية

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

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