من مشروع خاوي لأول ميزة كتخدم

إلى عرفتي تشعل Spring Boot، جاوبتي على سؤال تقني: كيفاش نخدم هاد framework؟ ولكن باش تبدا application، خاصك تجاوب على سؤال آخر: شنو النتيجة المفيدة اللي غادي نورّي، وشنو خاصني نتعلم قبل ما نختار التصميم؟ المشروع الخاوي كيولي واضح ملي كتكتب هاد القرارات.

اختار نتيجة صغيرة تقدر تورّيها

واحد الورشة جمعوية باغية تنظم مواعيد الإصلاح. الوصف الأول فيه calendrier، comptes ديال الزبناء، rappels، paiement و planning ديال المتطوعين. هادو إمكانيات، ماشي أول حاجة خاصنا نسلّموها.

نختارو هاد النتيجة: الزائر كيقترح موعد وكيشد référence، والمتطوع كيقدر يشوف الطلب. الـ référence غير كتأكد بلي توصلنا بالطلب؛ ما كتضمنش البلاصة فالوقت المقترح. المتطوع باقي كيأكد الموعد بيدو. هاد الفرق كيخلّي prototype صغير ما يوعدش بنظام ديال planning ما كاينش فيه.

فالنسخة الأولى، ما غاديش ندخلو paiement، توزيع المواعيد أوتوماتيكيا ولا استرجاع comptes. خاصنا نكتبو هاد الحدود. هادي غير حدود ديال هاد iteration، ماشي حكم بلي هاد الميزات عمرها ما غادي تكون مهمة.

فرّق بين المعلومة المؤكدة والافتراض والحاجة اللي ما عارفينهاش

قبل ما تصاوب tables، كتب ورقة قصيرة ديال الأسئلة:

النوع	الفكرة	الخطوة الجاية
مؤكدة	المتطوع محتاج وصف الحاجة ومعلومات التواصل	ندخلوها فالـ démonstration
افتراض	الزائر يقدر يتسنى تأكيد يدوي	نسولو المسؤول وشي زائر محتمل
ما واضحةش	جوج متطوعين يقدرو يقبلو نفس الطلب	نشوفو كيفاش كيتقسم العمل قبل ما نصممو التوزيع
شرط	معلومات زبناء حقيقيين ما تبانش فالـ démo العمومية	نستعملو معلومات خيالية

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

خلّي النجاح قابل للملاحظة

كتب أمثلة ديال القبول اللي شي واحد يقدر يجربهم:

• طلب فيه معلومات التواصل ووصف الحاجة وتاريخ مقترح فالمستقبل كيشد référence وكيبان عند المتطوع.
• إلا ما كانش الوصف، كيبان message مفهوم وما كيتزادش طلب ناقص.
• رسالة التوصل كاتقول بلي باقي خاص التأكيد.
• من بعد restart ديال application ديال démo، الطلب اللي توصلنا بيه باقي نقدروا نشوفوه.

هاد الأمثلة كتوصف السلوك اللي خاصنا نشوفو. ما كتفرضش framework، شكل tables ولا status HTTP. هاد القرارات كتجي من بعد. وحتى إلى دازو الأمثلة، ماشي دليل بلي التطبيق واجد يتحل للعموم فـ production.

جرّب الحاجة اللي تقدر تبدل الخطة

الـ spike تجربة صغيرة عندها سؤال وحدّ فين خاصها تحبس. هنا السؤال المهم هو واش التأكيد اليدوي كيسد الخدمة ديال الورشة. نورّيو رسالة توصل ولائحة للمتطوع فوق الورق قبل ما نكتبوهوم فالكود. إلا هاد التفاعل مناسب، تجربة تقنية قصيرة أخرى تقدر تشوف واش الاستضافة المختارة كتحافظ على الطلب من بعد restart.

إلى بقيتي أيام كتجرب framework بلا سؤال محدد، ماشي بالضرورة درتي spike. حدد الدليل اللي باغي، جمعو وكتب النتيجة. والكود التجريبي ما خاصوش يبقى فالمشروع إلا كان غادي يعقد النسخة الحقيقية.

سلّم مسار كامل وخذ الملاحظات

أول vertical slice كيدوز من إدخال الزائر للقرار ديال application، للتخزين، لرسالة التوصل وللمشاهدة عند المتطوع. طبقة DB كاملة بلا مسار يخدم عند الزائر ما كتسلمش النتيجة. وحتى formulaire زوين بلا تخزين دائم ما كيدوزش مثال restart.

الخطة فصفحة وحدة: نتأكدو من طريقة الخدمة اليدوية، نجربو الافتراض التقني اللي فيه خطر، نصاوبو إرسال طلب بسيط، نورّيو أمثلة القبول ونجمعو الملاحظات. فالعرض، نسولو واش référence واللائحة كيسهلو الخدمة. نكتبو التغييرات بلا ما نبقاو ندافعو على أول تصميم.

قرارات architecture خاصها تكون قدّ المخاطر اللي عارفين. Application وحدة تقدر تكفي فالأول؛ شرط ديال الخصوصية ولا حاجة ناقصة فالاستضافة يقدرو يطلبو قرار بنيوي بكري. لا التصميم ديال كلشي قبل البداية ولا الكود نيشان كيعطيو جواب صالح لكل مشروع.

تمرين: اختار الخطوة الجاية من حاجة لاحظناها

المسؤول لاحظ بلي الزبناء كيتاصلو بزاف باش يعرفو واش الموعد تأكد. واش نزيدو paiement، moteur ديال planning أوتوماتيكي، ولا طريقة يشوفو التأكيد؟

التحقق: بدا بفهم مشكل التأكيد. مشاهدة status تقدر تكفي، ولكن خاص نعرفو شكون يقدر يشوفو وشنو المعلومات اللي ممكن تبان. كتب مثال ديال القبول على طلب توصلنا بيه ومن بعد تأكد، قبل ما تختار الكود. الحاجة اللي لاحظنا هي اللي كتحدد الخطوة الجاية، ماشي التقنية اللي كتعجبنا كثر.