Prototype جواب داد؛ چه وقت باید Vibe Coding را متوقف و Refactor کنی؟
با promptهای سریع محصول رشد کرده اما حالا هر درخواست کوچک باعث اضافهشدن شرط، helper و state جدید در چند فایل میشود.
وقتی یک مفهوم سه بار تکرار شد، فایلها نقش مبهم گرفتند یا هر feature جدید چند جای نامرتبط را میشکند، وقت تثبیت معماری است.
چطور دقیقتر به موضوع نگاه کنیم؟
- قبل از feature بعدی سه درد تکرارشونده را بنویس: duplication، state مبهم یا coupling.
- یک refactor با هدف رفتاری صفر تعریف کن؛ یعنی خروجی کاربر تغییر نکند.
- مرزهای domain، data access و UI را فقط جایی جدا کن که تغییرات واقعی آن را توجیه میکند.
- بعد از refactor یک خلاصه معماری کوتاه در repo ثبت کن تا sessionهای AI بعدی همان الگو را ادامه دهند.
چرا این موضوع مهم است؟
سرعت prototype بدهی ساختاری ایجاد میکند. اگر بدهی را قبل از رشد بعدی نپردازی، مدل هم از الگوهای بد موجود تقلید و آنها را تکثیر میکند.
سؤالهایی که معمولاً بعدش پیش میآید
چه وقت rewrite بهتر است؟
وقتی مرز مسئله کوچک، تست/رفتار مرجع روشن و هزینه مهاجرت قابل کنترل است؛ نه صرفاً از سر خستگی.
AI refactor کند؟
میتواند کمک کند، اما Scope را کوچک و رفتار مورد انتظار را ثابت نگه دار.