شروع پیاده‌سازی با GitHub Spec Kit
تا این مرحله، مسئله کسب‌وکار، نیازمندی‌های اصلی، محدودیت‌های زیرساخت، مدل اندازه‌گیری KPI و Goal و معماری اولیه سیستم مشخص شده بود. بنابراین وارد فاز پیاده‌سازی شدیم.
برای این مرحله از GitHub Spec Kit استفاده کردیم. Spec Kit یک چارچوب برای Spec-Driven Development است؛ یعنی به‌جای این‌که مستقیماً از مدل بخواهیم کد تولید کند، ابتدا مشخص می‌کنیم چه چیزی باید ساخته شود، سپس مسیر فنی پیاده‌سازی را طراحی می‌کنیم و در نهایت آن را به Taskهای قابل اجرا تبدیل می‌کنیم.
Spec Kit به ابزارهای کدنویسی مبتنی بر هوش مصنوعی که از آن پشتیبانی می‌کنند متصل می‌شود. پس از راه‌اندازی، مجموعه‌ای از Command یا Skill در اختیار Agent قرار می‌دهد تا فرایند توسعه را مرحله‌به‌مرحله پیش ببرد.
نکته مهم این است که Spec Kit جای تحلیل یا تصمیم‌گیری انسانی را نمی‌گیرد. ارزش آن برای من در این بود که تصمیم‌ها، محدودیت‌ها و خروجی هر مرحله را به سندی قابل ارجاع تبدیل می‌کرد و اجازه نمی‌داد مدل از همان ابتدا بدون Context کافی وارد کدنویسی شود.
چرخه توسعه در Spec Kit
چرخه اصلی Spec Kit به این شکل است:
Constitution
در ابتدا اصول حاکم بر پروژه تعریف می‌شوند. این اصول شامل استانداردهای کیفیت کد، نحوه تست، محدودیت‌های معماری، قواعد امنیتی، Performance و مواردی است که باید در تمام مراحل توسعه رعایت شوند.
Specify
در این مرحله مشخص می‌شود که چه چیزی باید ساخته شود و چرا. خروجی این مرحله یک Specification است که شامل نیازمندی‌ها، User Storyها، سناریوها، محدودیت‌ها و معیارهای پذیرش است. در این بخش تمرکز بر نیاز محصول است، نه جزئیات فنی پیاده‌سازی.
Clarify
پیش از طراحی فنی، بخش‌های مبهم، متناقض یا ناقص Specification بررسی می‌شوند. این مرحله کمک می‌کند پرسش‌هایی که ممکن است بعداً به تغییر طراحی یا بازنویسی کد منجر شوند، زودتر مشخص و پاسخ داده شوند.
Plan
پس از تثبیت نیازمندی‌ها، طراحی فنی انجام می‌شود. در این مرحله مشخص می‌شود قابلیت موردنظر با چه معماری، تکنولوژی، مدل داده، API، ساختار Frontend و روش تستی پیاده‌سازی خواهد شد.
Tasks
Plan فنی به Taskهای کوچک، قابل اجرا و قابل پیگیری تبدیل می‌شود. هر Task باید تا حد ممکن مستقل، قابل بررسی و دارای خروجی مشخص باشد.
Analyze
قبل از شروع اجرا، می‌توان Specification، Plan و Taskها را از نظر تناقض، پوشش نیازمندی‌ها و رعایت اصول Constitution بررسی کرد. این مرحله برای پروژه‌های بزرگ اهمیت زیادی دارد، چون بعضی تناقض‌ها قبل از ورود به کد مشخص می‌شوند.
Implement
در این مرحله Taskها به‌ترتیب اجرا می‌شوند و قابلیت موردنظر پیاده‌سازی می‌شود.
Converge و Validation
پس از پیاده‌سازی، کد و رفتار واقعی سیستم دوباره با Specification، Plan و Taskها مقایسه می‌شوند. اگر بخشی ناقص باشد یا با نیاز اولیه تطابق نداشته باشد، Task جدید ایجاد می‌شود و چرخه تا رسیدن به خروجی قابل‌قبول ادامه پیدا می‌کند.
تبدیل مستندات قبلی به مسیر پیاده‌سازی
در پروژه ما، مستنداتی که در مراحل قبل آماده شده بودند، ورودی مرحله Specify شدند؛ شامل مسئله اصلی، نیاز تیم داده، مدل دریافت سگمنت از Data Providerها، محدودیت نبود Tracking مستقیم، مدل UTM، Goal و KPI و همچنین نیازهای مقیاس‌پذیری.
سپس این نیازها به Specification تبدیل شدند تا مشخص شود سیستم دقیقاً چه قابلیت‌هایی باید داشته باشد و هر قابلیت تحت چه شرایطی قابل قبول است.
بعد از آن، طراحی اولیه سیستم با جزئیات فنی‌تر در Plan قرار گرفت؛ از ساختار Backend با C# و Frontend با React.js تا ارتباط با منابع داده، مدیریت Campaign Runها، کانال‌های ارسال و ذخیره خروجی‌های لازم برای تحلیل KPI.
در نهایت، Plan به مجموعه‌ای از Taskهای کوچک‌تر تبدیل شد. به‌جای این‌که از مدل بخواهیم کل سیستم را یک‌جا پیاده‌سازی کند، هر بخش به واحدهای قابل کنترل تقسیم شد؛ مانند ایجاد ساختار داده، پیاده‌سازی یک API، طراحی یک صفحه، اتصال یک Provider، افزودن تست یا بررسی یک سناریوی خطا.
این نقطه، شروع واقعی توسعه نرم‌افزار بود؛ اما همان‌طور که در ادامه توضیح می‌دهم، داشتن Specification و Task به‌تنهایی تضمین نمی‌کرد که خروجی مدل همیشه دقیقاً مطابق نیاز، Constraintها و طراحی اولیه باشد
