تجربه من از Graphify: وقتی پروژه به نقشه تبدیل میشود
6 دقیقه مطالعه علی ارغیانی
graphifyهوش-مصنوعیگراف-دانشیnuxtابزارهای-توسعه
مدتی بود وقتی با هوش مصنوعی داخل یک پروژه واقعی کار میکردم، یک حس تکراری داشتم.
مدل میتوانست قوی باشد. پرامپت میتوانست دقیق باشد. ساختار پروژه هم میتوانست مرتب باشد. اما بعد از چند پیام، کیفیت کار هنوز به این وابسته بود که چقدر کانتکست وارد گفتوگو شده و دستیار چقدر توانسته شکل پروژه را در ذهنش نگه دارد.
اینجا بود که شروع کردم به تجربه کردن Graphify.
من دنبال یک فایل مستندات دیگر نبودم که آرامآرام قدیمی شود. چیزی میخواستم شبیه یک نقشه زنده از پروژه: فایلها، کامپوننتها، ارتباطها، جامعههای داخل کد و بخشهایی که بیسروصدا همهچیز را به هم وصل میکنند.
مسئله فقط سرچ کردن نبود
قبل از Graphify، مسیر معمول کار آشنا بود:
- فایلها را سرچ کن.
- چند کامپوننت مرتبط را باز کن.
- چند فایل مستندات را بخوان.
- مسیرهای صفحهها را بررسی کن.
- تایپها را چک کن.
- و بعد تازه تغییر اصلی را شروع کن.
این روش بد نیست. اتفاقا هنوز هم لازم است.
مسئله این است که هر تسک جدید با بازسازی مدل ذهنی پروژه شروع میشود. در یک پروژه کوچک این موضوع طبیعی است. اما وقتی پروژه بزرگتر میشود، این کار هزینه دارد؛ هم از نظر زمان، هم توکن، هم توجه، و هم احتمال جا انداختن یک ارتباط مهم.
Graphify قدم اول را عوض کرد.
بهجای اینکه بپرسم «از کجا باید شروع کنم؟»، از گراف پرسیدم.
اول چه چیزی ساختم؟
اولین قدم جدی، پاک کردن پروژه از یک روش قدیمیتر بود که دیگر نمیخواستم آینده پروژه بر اساس آن جلو برود.
یکسری فایل عامل، کامند، رول و خروجیهای تولیدشده مربوط به روش قبلی در پروژه مانده بود. اینها دیگر بخشی از مسیر آینده نبودند، پس قبل از اینکه Graphify تبدیل به لایه اصلی ناوبری پروژه شود، باید حذف میشدند.
بعد از پاکسازی، گراف را دوباره ساختم و جامعهها را نامگذاری کردم.
خروجی این شد:
- ۷۹۱ نود،
- ۹۳۸ ارتباط،
- ۷۶ جامعه نامگذاریشده.
نام این جامعهها بیشتر از چیزی که فکر میکردم مهم بود. فهرستی مثل «Community 0» یا «Community 1» از نظر فنی درست است، اما به فکر کردن کمک نمیکند. اما وقتی اسمهایی مثل «Blog Post Components»، «Portfolio Data Store»، «Bottom Nav Scroll» یا «Resume Section Components» میبینی، گراف ناگهان شکل انسانیتری پیدا میکند.
جزئیاتی که تجربه را عوض کرد
Graphify وقتی واقعا کاربردی شد که جامعههای گراف اسمهای معنادار گرفتند. از آن لحظه، گراف فقط داده نبود؛ تبدیل شد به نقشهای که میشد با آن حرکت کرد.
تفاوت توکنی که دیدم
برای همین تسک نوشتن مقاله، قبل از خواندن دستی فایلهای پروژه، از Graphify استفاده کردم.
کوئری گراف برای اینکه بفهمم پستهای دو زبانه در این پروژه Nuxt چطور اضافه میشوند، فقط ۱۰ نود مرتبط برگرداند. خروجی مفید آن کمتر از ۳۰۰ توکن بود.
برای مقایسه، فایل خام
graph.json
GRAPH_REPORT.md
این به این معنی نیست که Graphify در هر تسک «۱۵۸ هزار توکن» ذخیره میکند. چنین جملهای زیادی نمایشی و نادقیق است.
صرفهجویی واقعی این بود که لازم نبود کل گراف یا کل گزارش را وارد کانتکست کنم یا کورکورانه داخل پروژه بچرخم. Graphify مرحله کشف اولیه را به یک پاسخ کوچک و محدود تبدیل کرد. بعد از آن، هنوز فایلهای دقیق و لازم را خواندم: schema محتوا، راهنمای نویسندگی، صفحه بلاگ و چند نمونه از پستهای قبلی.
این همان روشی است که میخواهم نگه دارم:
- اول از گراف بپرس تسک کجا زندگی میکند.
- فقط فایلهایی را بخوان که گراف به آنها اشاره میکند.
- تغییر را انجام بده.
- بعد از تغییر، گراف را بهروز کن تا تسک بعدی از نقشه تازهتری شروع شود.
الان Graphify را چطور میبینم؟
Graphify جایگزین فهمیدن کد نیست.
ابزار جادویی هم نیست که خودش نرمافزار بهتری بسازد.
ارزش آن برای من مشخصتر از این حرفهاست: هزینه جهتیابی را کم میکند.
وقتی بعد از چند روز یک پروژه را باز میکنم، یا وقتی یک دستیار هوش مصنوعی باید بفهمد چیزی در کجای پروژه قرار میگیرد، گراف یک نقطه شروع ساختارمند میدهد. نودهای مهم، جامعهها و ارتباطهایی را نشان میدهد که وقتی فایلها را یکییکی میخوانیم، ممکن است راحت فراموش شوند.
این موضوع حس کار کردن با هوش مصنوعی را عوض میکند.
دستیار کمتر مجبور است حدس بزند. من کمتر مجبورم ساختار پروژه را دوباره و دوباره توضیح بدهم. خود پروژه شروع میکند بخشی از کانتکست خودش را حمل کند.
بزرگترین برد Graphify برای من سرعت نبود؛ این بود که لازم نبود هر بار ساختار پروژه را دوباره وارد ذهن خودم کنم.
روشی که میخواهم در پروژههای دیگر هم استفاده کنم
بعد از این تجربه، روش مورد علاقه من برای پروژههای دیگر ساده است.
اول، دستورالعملها و روشهای قدیمی یا متناقض را حذف میکنم. اگر پروژه رولهای قدیمی، فایلهای تولیدشده بیاستفاده یا مستندات فرایندی منسوخ دارد، قبل از ساختن گراف باید تمیز شود. وگرنه گراف همان نویز را هم با دقت نقشه میکند.
دوم، Graphify را روی پروژه اجرا میکنم و خروجی تصویری، فایل JSON و گزارش را میسازم.
سوم، جامعهها را نامگذاری میکنم. این مرحله تزئینی نیست. اسم واضح باعث میشود گراف برای انسان قابل استفاده شود.
چهارم، یک دستورالعمل کوچک در پروژه مینویسم که بگوید برای سؤالهای مربوط به کدبیس، اول از Graphify سؤال شود. این کار جلوی جستوجوی گسترده و پرهزینه در تسکهای بعدی را میگیرد.
پنجم، بعد از تغییر کد یا محتوا، گراف را بهروز میکنم.
این قدم آخر مهم است. گرافی که بهروز نشود، خودش تبدیل به یک مستند قدیمی دیگر میشود. اما گرافی که بهروز بماند، تبدیل میشود به حافظه پروژه.
هنوز باید مراقب چه چیزی باشم؟
Graphify محدودیت دارد.
اگر یک تسک به رفتار دقیق نیاز داشته باشد، هنوز باید سورس خوانده شود. اگر یک صفحه باید اعتبارسنجی شود، هنوز باید build اجرا شود و خروجی بررسی شود. اگر ادعایی داخل گراف وجود ندارد، نباید آن را از خودمان بسازیم.
Graphify به جهتیابی کمک میکند، نه بهانهای برای کنار گذاشتن مسئولیت.
این تفاوت مهم است.
یک workflow خوب با هوش مصنوعی یعنی سیستمی بسازیم که ابزار، کدبیس و انسان بتوانند همدیگر را کنترل کنند.
حرف آخر
این اولین تجربه جدی من از استفاده از Graphify بهعنوان نقشه اصلی پروژه بود، و نگاه من را به توسعه نرمافزار با کمک هوش مصنوعی تغییر داد.
هنوز میخواهم دستیار فایلها را دقیق بخواند. هنوز تست، اعتبارسنجی و تغییرات کوچک و مشخص میخواهم.
اما نمیخواهم هر تسک از یک صفحه ذهنی خالی شروع شود.
Graphify به پروژه حافظه میدهد. و وقتی پروژه حافظه داشته باشد، کار با هوش مصنوعی کمتر شبیه توضیح دادن دوباره یک اتاق ناآشناست و بیشتر شبیه حرکت کردن در جایی است که بالاخره روی دیوارهایش تابلو راهنما نصب شده.