بعد از وردپرس عمیق تر وارد توسعه وب مدرن شدم. دو پروژه، یکی با NestJS و یکی با React، هیچ وقت لانچ نشدند. اما بیشتر از هر محصول منتشرشده ای نگاه من را به ساختار بک اند، پیچیدگی فرانت اند، APIها، state و scope تغییر دادند.
دو پروژه ای که لانچ نشدند
اولی یک سرویس بک اند با NestJS بود. دومی یک رابط React بود که قرار بود روی آن بنشیند. هیچ کدام به production نرسیدند، اما هر دو چیزهایی یادم دادند که از پروژه ای که از اول موفق می شد یاد نمی گرفتم.
شکست وقتی مفید است که به دلیلش دقت کنی. در هر دو پروژه، ایده قبل از شروع کدنویسی به اندازه کافی روشن نبود. قبل از تعریف مسئله feature ساختیم و scope سریع تر از فهم ما رشد کرد.
NestJS درباره ساختار چه یادم داد
NestJS معماری ماژولار را تحمیل می کند: controller، service، provider و module. اول شبیه تشریفات بود. اما وقتی پروژه بزرگ تر شد، همین ساختار نشان داد کجا فکر ما ناقص است. سرویس هایی که از مرزهای زیادی عبور می کردند. ماژول هایی که چون فکر می کردیم شاید لازم شوند ساخته شده بودند، نه چون واقعا لازم بودند.
معماری مشکل نبود. مشکل این بود که نمی دانستیم دقیقا چه می سازیم تا بفهمیم کدام مرزها مهم هستند. ساختار وقتی کمک می کند که intent روشن باشد. بدون شفافیت فقط سردرگمی را مرتب تر می کند.
پیچیدگی React بدون محصول
فرانت React جایی بود که پیچیدگی خودش را نشان داد. مدیریت state، اتصال API، routing، caching و optimistic update؛ هر بخش به تنهایی منطقی بود. کنار هم، هزینه ترکیبی می ساختند که هر تغییر را کند می کرد.
- هر صفحه جدید از چند endpoint داده می خواست
- هر تغییر state باید cache را هم بروزرسانی می کرد
- هر فرض optimization وقتی شکل داده عوض می شد می شکست
بدون محصول زنده برای اعتبارسنجی، برای مسئله هایی بهینه سازی کردیم که شاید هیچ وقت وجود نداشتند. این هزینه واقعی ساختن قبل از روشن شدن ایده است.
معماری، scope و هزینه حدس زدن
آن دو پروژه من را محتاط تر کردند. حالا قبل از انتخاب stack می خواهم شکل مسئله را ببینم. می دانم کدام بخش ها نامطمئن هستند و کدام بخش ها خوب فهمیده شده اند. می خواهم نازک ترین نسخه ای را بسازم که فرض ها را تست کند.
هر پروژه لازم نیست لانچ شود تا ارزشمند باشد. اما هر پروژه باید دلیلی برای وجود داشته باشد که از «ببینیم چه می شود» دقیق تر باشد.