نوشته های Farhad Adeli

چطور دو اپلیکیشن بسیار مشابه را یکی کنیم، بدون اینکه یک کابوس نگهداری بسازیم؟

Farhad Adeli — Mon, 13 Jul 2026 07:40:04 +0330

بسیاری از تیم‌ها دیر یا زود به این وضعیت می‌رسند:یک پروژه داریم که به‌خوبی کار می‌کند. برای راه‌اندازی محصول دوم، همان پروژه را کپی می‌کنیم، چند بخش را تغییر می‌دهیم و آن را به‌عنوان یک محصول مستقل منتشر می‌کنیم.در ابتدا این تصمیم سریع و منطقی به نظر می‌رسد.اما با گذشت زمان، مشکلات شروع می‌شوند:هر قابلیت جدید باید دو بار پیاده‌سازی شود.هر باگ باید در دو پروژه برطرف شود.تغییرات دیتابیس باید در هر دو پروژه هماهنگ شوند.کدهای دو پروژه به‌تدریج از هم فاصله می‌گیرند.هزینه تست، توسعه و نگهداری بیشتر می‌شود.ما نیز با شرایط مشابهی روبه‌رو بودیم:دو محصول بسیار مشابهفرانت‌اند با Next.js، React و TypeScriptبک‌اند با NestJS و TypeScriptقابلیت‌های مشترک مانند احراز هویت، محصولات، کاربران و بازارهاتفاوت‌هایی در برخی فرایندهای کسب‌وکارپیاده‌سازی دوباره هر قابلیت جدید در هر دو پروژههدف مشخص بود:تفاوت‌های واقعی محصولات را حفظ کنیم، کدهای تکراری را حذف کنیم و توسعه قابلیت‌های بعدی را ساده‌تر کنیم.راه‌حل وسوسه‌انگیز اما خطرناکاولین ایده معمولاً این است:دو پروژه را مستقیماً با هم ادغام کنیم و به یک اپلیکیشن واحد برسیم.این راه در ظاهر ساده است، اما ریسک زیادی دارد.دو پروژه‌ای که از یک کد پایه شروع شده‌اند، ممکن است به‌مرور زمان تغییرات متفاوتی پیدا کرده باشند:باگ‌فیکس‌های متفاوتتغییرات متفاوت دیتابیسقوانین اعتبارسنجی متفاوترفتارهای متفاوت در رابط کاربرینیازهای متفاوت در استقرارIntegrationهای اختصاصیقوانین کسب‌وکاری که در ظاهر مشخص نیستنداگر یکی از پروژه‌ها را مبنا قرار دهیم و پروژه دیگر را روی آن ادغام کنیم، احتمال زیادی وجود دارد که بخشی از رفتارهای معتبر یا قابلیت‌های مهم از بین بروند.بنابراین بهتر است کار را با یکی‌کردن اپلیکیشن‌ها شروع نکنیم.بهتر است ابتدا زیرساخت و بخش‌های مشترک را یکی کنیم.معماری پیشنهادیاولین قدم مناسب، انتقال هر دو پروژه به یک Monorepo است، بدون اینکه استقلال آن‌ها در Build و Deploy از بین برود.ساختار پیشنهادی می‌تواند شبیه زیر باشد:platform/ ├── apps/ │ ├── project-a-web/ │ ├── project-b-web/ │ ├── project-a-api/ │ └── project-b-api/ │ └── packages/ ├── domain/ ├── frontend/ ├── backend/ ├── contracts/ └── config/پوشه apps شامل اپلیکیشن‌های اجرایی و قابل استقرار است.پوشه packages شامل کدهایی است که میان پروژه‌ها به اشتراک گذاشته می‌شوند.با این ساختار، می‌توانیم بیشتر کد را مشترک کنیم، بدون اینکه هر دو محصول را مجبور کنیم در یک Runtime یا یک Pipeline استقرار قرار بگیرند.برای پیاده‌سازی این معماری می‌توان از ابزارهای زیر استفاده کرد:pnpm workspaceNxTypeScript Project Referencesتنظیمات مشترک Lint، Test و BuildNx در این معماری انتخاب مناسبی است، چون وابستگی میان پروژه‌ها را درک می‌کند و می‌تواند فقط بخش‌هایی را Build یا Test کند که تحت تأثیر یک تغییر قرار گرفته‌اند.چه چیزهایی باید مشترک شوند؟همه چیز نباید Shared باشد.قبل از استخراج کدها، بهتر است هر بخش را در یکی از چهار گروه زیر قرار دهیم.۱. کدهای کاملاً یکساننمونه‌ها:ابزارهای احراز هویتDTOهای مشترکTypeهای APISchemaهای اعتبارسنجیکامپوننت‌های پایه UILoggingزیرساخت‌های مشترکاین بخش‌ها معمولاً بدون تغییر خاصی قابل انتقال به Packageهای مشترک هستند.۲. کدهای مشترک با تفاوت در تنظیماتگاهی رفتار اصلی یکسان است، اما تنظیمات محصولات فرق می‌کند.برای مثال:عنوان یک صفحه متفاوت است.صدور فاکتور در یکی از محصولات فعال است.یک ماژول فقط در یکی از پروژه‌ها نمایش داده می‌شود.منوی هر محصول متفاوت است.برندینگ یا متن‌ها با هم فرق دارند.این نوع تفاوت‌ها بهتر است با Configuration مدیریت شوند.export interface ProductConfig { name: string; features: { invoices: boolean; preOrders: boolean; payments: boolean; }; }هر پروژه می‌تواند تنظیمات خودش را ارائه دهد:export const projectAConfig: ProductConfig = { name: 'Project A', features: { invoices: true, preOrders: false, payments: true, }, };export const projectBConfig: ProductConfig = { name: 'Project B', features: { invoices: false, preOrders: true, payments: false, }, };۳. مفاهیم مشترک با رفتار متفاوتگاهی مفهوم در هر دو محصول وجود دارد، اما رفتار آن متفاوت است.برای مثال، هر دو محصول ممکن است فرایندی به نام سفارش داشته باشند، اما:در محصول اول سفارش واقعی ثبت می‌شود.موجودی رزرو می‌شود.فاکتور تولید می‌شود.در محصول دوم فقط پیش‌سفارش ثبت می‌شود.موجودی رزرو نمی‌شود.فاکتور صادر نمی‌شود.در اینجا Configuration به‌تنهایی کافی نیست.برای چنین تفاوت‌هایی بهتر است از Strategy یا Policy استفاده کنیم.export interface OrderWorkflow { submit(order: Order): Promise; approve(order: Order): Promise; cancel(order: Order): Promise; }هر محصول Implementation مخصوص خودش را دارد:export class ProjectAOrderWorkflow implements OrderWorkflow { async submit(order: Order) { // Reserve inventory and create invoice return order; } }export class ProjectBOrderWorkflow implements OrderWorkflow { async submit(order: Order) { // Save as preorder without reserving inventory return order; } }این ساختار بسیار بهتر از پراکنده‌کردن شرط‌های متعدد در کل کد است:if (projectType === 'a') { // ... } else { // ... }استفاده محدود از شرط مشکلی ندارد، اما وقتی منطق کسب‌وکار در ده‌ها نقطه به نوع پروژه وابسته باشد، معماری به‌مرور غیرقابل نگهداری می‌شود.۴. کدهای کاملاً اختصاصیبرخی قابلیت‌ها واقعاً فقط متعلق به یکی از محصولات هستند.این بخش‌ها باید داخل همان App باقی بمانند.هدف این نیست که تمام کدها را به زور Shared کنیم.هدف این است که فقط بخش‌هایی را مشترک کنیم که واقعاً رفتار و مسئولیت یکسانی دارند.معماری مشترک در فرانت‌اندیکی از اشتباهات رایج این است که فقط کامپوننت‌های ساده مانند Button، Input و Modal را مشترک کنیم.این کار مفید است، اما مشکل اصلی را حل نمی‌کند.اگر هر Feature همچنان در هر دو پروژه جداگانه نوشته شود، بخش عمده Duplication باقی می‌ماند.بهتر است Featureهای کامل را Shared کنیم.برای مثال:packages/frontend/products/ ├── components/ ├── hooks/ ├── api/ ├── schemas/ ├── state/ └── index.tsاین Package می‌تواند شامل موارد زیر باشد:ProductListProductFormProductFiltersuseProductsAPIهای محصولSchemaهای اعتبارسنجیPermissionهای مربوط به محصولسپس هر دو اپلیکیشن Next.js از همین Feature استفاده می‌کنند:export default function ProductsPage() { return ; }در این معماری، هر App بیشتر مسئول موارد زیر خواهد بود:RoutingBrandingConfigurationصفحه‌های اختصاصیترکیب Featureهای مشترکمعماری مشترک در بک‌انددر بک‌اند نیز می‌توان ماژول‌های مشترک NestJS را در Packageهای مستقل قرار داد.packages/backend/ ├── auth/ ├── users/ ├── products/ ├── markets/ ├── database/ └── observability/سپس هر پروژه فقط ماژول‌های موردنیاز خود را Compose می‌کند.@Module({ imports: [ AuthModule, ProductsModule, MarketsModule, OrdersModule.register({ workflow: ProjectAOrderWorkflow, }), ], }) export class ProjectAAppModule {}پروژه دوم نیز Workflow مخصوص خودش را ارائه می‌دهد:@Module({ imports: [ AuthModule, ProductsModule, MarketsModule, OrdersModule.register({ workflow: ProjectBOrderWorkflow, }), ], }) export class ProjectBAppModule {}در نتیجه، پیاده‌سازی مشترک Backend فقط یک‌بار نوشته می‌شود، اما تفاوت‌های رفتاری هر محصول همچنان مستقل باقی می‌مانند.قراردادهای مشترک بین فرانت‌اند و بک‌اندیکی دیگر از منابع Duplication، تعریف جداگانه Typeها در فرانت‌اند و بک‌اند است.برای مثال، فرانت‌اند یک نسخه از CreateOrderRequest دارد و بک‌اند نسخه دیگری از آن را تعریف می‌کند.با گذشت زمان، این دو Type ممکن است با هم ناسازگار شوند.برای جلوگیری از این مشکل، می‌توان یک Package مشترک برای Contractها ایجاد کرد:packages/contracts/ ├── orders/ ├── products/ ├── users/ └── common/این Package می‌تواند شامل موارد زیر باشد:DTOهاSchemaهای APIEnumهاResponse TypeهاEvent Payloadهامثال:import { z } from 'zod'; export const CreateOrderSchema = z.object({ customerId: z.string(), items: z.array( z.object({ productId: z.string(), quantity: z.number().positive(), }), ), }); export type CreateOrderRequest = z.infer< typeof CreateOrderSchema >;اکنون فرانت‌اند و بک‌اند هر دو از یک Contract استفاده می‌کنند.برنامه مهاجرت مرحله‌به‌مرحلهاین مهاجرت باید تدریجی انجام شود.تلاش برای انتقال همه چیز در یک مرحله، ریسک پروژه را بسیار زیاد می‌کند.مرحله ۱: ایجاد Monorepoیک Workspace جدید با pnpm و Nx ایجاد کنید.مرحله ۲: انتقال پروژه‌های فعلی بدون تغییر رفتارapps/ ├── project-a-web/ ├── project-b-web/ ├── project-a-api/ └── project-b-api/در این مرحله فقط محل پروژه‌ها تغییر می‌کند.هر چهار App باید همچنان مستقل Build، Test و Deploy شوند.مرحله ۳: تحلیل و دسته‌بندی کدهاهر Feature را در یکی از این گروه‌ها قرار دهید:کاملاً مشترکمشترک با تفاوت تنظیماتمشترک با تفاوت رفتاریکاملاً اختصاصیمرحله ۴: استخراج تنظیمات مشترکتنظیمات TypeScript، ESLint، Prettier و Build را به مسیر زیر منتقل کنید:packages/config/مرحله ۵: استخراج Contractهای مشترکDTOها، Schemaها، Enumها و API Typeها را به مسیر زیر منتقل کنید:packages/contracts/مرحله ۶: استخراج کامپوننت‌های پایه UIابتدا از بخش‌های کم‌ریسک شروع کنید:ButtonInputTableDialogFormLayoutمرحله ۷: استخراج Featureهای کامل فرانت‌اندFeatureهایی مانند موارد زیر را یکی‌یکی منتقل کنید:AuthenticationProductsUsersMarketsPermissionsمرحله ۸: استخراج منطق مشترک کسب‌وکارقوانین، محاسبات و تغییر وضعیت‌های مشترک را به مسیر زیر منتقل کنید:packages/domain/مرحله ۹: استخراج ماژول‌های مشترک NestJSاز ماژول‌هایی شروع کنید که در هر دو پروژه تقریباً یکسان هستند.مرحله ۱۰: اضافه‌کردن Product Configتفاوت‌های کوچک را با Configuration و Feature Flag مدیریت کنید.مرحله ۱۱: اضافه‌کردن Strategy و Policyبرای تفاوت‌های مهم رفتاری، Implementationهای مجزا ایجاد کنید.مرحله ۱۲: حذف کدهای تکراریپس از استخراج هر Package مشترک، کد قدیمی را از هر دو پروژه حذف کنید.مرحله ۱۳: اضافه‌کردن تست‌های مشترکبرای Packageهای Shared، Unit Test و Integration Test بنویسید.مرحله ۱۴: حفظ تست‌های End-to-End مستقلهر محصول باید همچنان تست‌های E2E مخصوص فرایندهای حیاتی خودش را داشته باشد.مرحله ۱۵: به‌روزرسانی CI/CDفقط پروژه‌هایی را Build و Test کنید که تحت تأثیر تغییرات هستند:nx affected -t lint test buildمرحله ۱۶: مهاجرت Feature به Featureکل سیستم را در یک Release مهاجرت ندهید.هر بار یک Feature را منتقل، تست و پایدار کنید.مرحله ۱۷: بازبینی معماری نهاییپس از حذف بخش عمده Duplication، بررسی کنید که آیا هنوز به موارد زیر نیاز دارید:دو فرانت‌اند جدادو بک‌اند جدادو Pipeline استقراردو دیتابیس مستقلدر این مرحله، تصمیم‌گیری بسیار ساده‌تر خواهد بود، چون تفاوت‌های واقعی دو محصول به‌صورت شفاف مشخص شده‌اند.چه کارهایی نباید انجام دهیم؟ساختن یک پوشه بزرگ Sharedیک پوشه عمومی مانند shared معمولاً به‌مرور تبدیل به محل انباشته‌شدن انواع کدهای نامرتبط می‌شود.بهتر است Packageها مرز و مسئولیت مشخص داشته باشند:packages/frontend/products packages/backend/auth packages/domain/ordersاستفاده بیش از حد از شرط‌های مربوط به محصولوجود چنین شرط‌هایی در نقاط متعدد یک علامت هشدار است:if (product === 'a') { // ... }اگر این شرط‌ها در همه‌جای پروژه دیده شوند، یعنی تفاوت محصولات به‌درستی در معماری ایزوله نشده است.رفتن زودهنگام به سمت Microserviceوجود دو محصول مشابه به‌معنای نیاز به Microservice نیست.در بسیاری از موارد، Modular Monolith انتخاب مناسب‌تری است.Microservice پیچیدگی‌های زیادی ایجاد می‌کند:پیچیدگی DeploymentDistributed Transactionخطاهای شبکهپیچیدگی Observabilityمشکلات Data Consistencyفقط زمانی یک ماژول را به سرویس مستقل تبدیل کنید که دلیل عملیاتی یا مقیاس‌پذیری مشخصی داشته باشید.Shared کردن همه چیزهر فایل مشابهی الزاماً نباید به Package مشترک منتقل شود.یک بخش زمانی باید Shared شود که:رفتار آن واقعاً یکسان باشد.مسئولیت آن مشخص باشد.مرز پایداری داشته باشد.اشتراک‌گذاری باعث کاهش هزینه نگهداری شود.Coupling غیرضروری ایجاد نکند.آیا در نهایت باید دو پروژه به یک اپلیکیشن تبدیل شوند؟شاید.داشتن یک Frontend و یک Backend زمانی منطقی است که:هر دو محصول هم‌زمان منتشر شوند.زیرساخت آن‌ها یکسان باشد.بیشتر Workflowها مشابه باشند.تفاوت‌ها با Configuration قابل مدیریت باشند.مالکیت هر دو محصول با یک تیم باشد.اما حفظ Appهای جدا زمانی بهتر است که:Deployها باید مستقل باشند.نیازهای امنیتی متفاوت باشند.مشتریان به محیط‌های جدا نیاز داشته باشند.مسیر توسعه محصولات در حال جداشدن باشد.خرابی یک محصول نباید محصول دیگر را تحت تأثیر قرار دهد.Monorepo به‌معنای یک Deployment نیست.می‌توان بخش عمده کد را مشترک کرد و همچنان Docker Image و Pipeline جداگانه داشت.جمع‌بندیاز همان ابتدا تلاش نکنید دو محصول را به یک اپلیکیشن بزرگ تبدیل کنید.ابتدا یک Monorepo بسازید که شامل این بخش‌ها باشد:دو اپلیکیشن فرانت‌انددو اپلیکیشن بک‌اندFeatureهای مشترک Frontendماژول‌های مشترک BackendContractهای مشترکمنطق مشترک Domainتنظیمات مشترکتفاوت‌های کوچک را با Configuration مدیریت کنید.تفاوت‌های رفتاری را با Strategy و Policy جدا کنید.مهاجرت را Feature به Feature انجام دهید.پس از پایدارشدن Shared Core، بررسی کنید که آیا ادغام نهایی Runtime و Deployment واقعاً ارزش انجام‌دادن دارد یا نه.هدف اصلی فقط داشتن یک Repository نیست.هدف اصلی این است که هر قابلیت جدید فقط یک‌بار پیاده‌سازی شود.

کامپوننتهای قابل استفاده مجدد را خیلی زود نسازید

Farhad Adeli — Wed, 08 Jul 2026 15:35:53 +0330

کامپوننتهای قابل استفاده مجدد یکی از جذابترین ایدهها در توسعه فرانتاند هستند.در نگاه اول، کاملاً منطقی به نظر میرسند.چرا یک UI را دو بار بنویسیم؟چرا یک کامپوننت انعطافپذیر نسازیم و همهجا از آن استفاده نکنیم؟چرا از همان ابتدا یک design system تمیز نسازیم؟ایده خوبی است.اما یک دام مهم دارد.خیلی از تیمهای فرانتاند تلاش میکنند کامپوننتها را بیش از حد زود reusable کنند.وقتی یک کامپوننت قبل از اینکه نیازمندیها واضح شوند reusable میشود، معمولاً از همان duplication سادهای که قرار بود حذف کند پیچیدهتر میشود.Reusability هزینه داردیک کامپوننت reusable بهصورت خودکار بهتر از یک کامپوننت تکراری نیست.کد reusable مسئولیت دارد.باید چند use case مختلف را پشتیبانی کند.باید propهای انعطافپذیر داشته باشد.باید naming واضح داشته باشد.باید مرزهای مشخص داشته باشد.باید مستند شود.باید طوری تغییر کند که همه جاهایی که به آن وابستهاند خراب نشوند.یعنی reusable بودن هزینه دارد.وقتی یک کامپوننت reusable میسازیم، فقط یک کامپوننت نمینویسیم.در واقع داریم یک API میسازیم.مثلاً:} fullWidth ={handleClick} > Create این ممکن است برای یک button واقعی در design system کاملاً مناسب باشد.اما برای یک دکمه مخصوص یک feature، این همه انعطافپذیری ممکن است غیرضروری باشد.گاهی سادهترین نسخه بهتر است:مشکل، کامپوننت reusable نیست.مشکل این است که قبل از اینکه الگوی واقعی را بفهمیم abstraction میسازیم.Duplication همیشه دشمن نیستتوسعهدهندهها معمولاً یاد گرفتهاند از duplication دوری کنند.اصل DRY یا “Don’t Repeat Yourself” مفید است.اما گاهی آن را خیلی زود اعمال میکنیم.دو تکه کد ممکن است امروز شبیه هم باشند، اما فردا در مسیرهای متفاوتی تغییر کنند.مثلاً دو کارت را تصور کنید:ProductCard CustomerCardدر ابتدا هر دو ممکن است این موارد را داشته باشند:title subtitle status actionsپس یک InfoCard عمومی میسازیم.اما یک هفته بعد:ProductCard به هشدار موجودی نیاز دارد. CustomerCard به risk label نیاز دارد. ProductCard به قوانین قیمتگذاری نیاز دارد. CustomerCard به منطق وضعیت حساب نیاز دارد.حالا کامپوننت generic شروع میکند به بزرگ شدن:در این نقطه، کامپوننت reusable است، اما تمیز نیست.زیادی میداند.موارد نامرتبط زیادی را پشتیبانی میکند.و هر نیازمندی جدید آن را بدتر میکند.یک مقدار duplication ارزانتر بود.شکل مشابه به معنی abstraction مشترک نیستیکی از مهمترین درسها در معماری فرانتاند این است:چیزهایی که شبیه هم هستند، همیشه یکی نیستند.دو کامپوننت میتوانند UI مشابهی داشته باشند، اما معنی بیزینسی متفاوتی داشته باشند.این تفاوت مهم است.مثلاً:OrderStatusBadge PaymentStatusBadge DeliveryStatusBadge UserStatusBadgeهمه آنها ممکن است شبیه badgeهای کوچک باشند.اما قوانینشان ممکن است کاملاً متفاوت باشد.یکی ممکن است به وضعیت پرداخت وابسته باشد.یکی دیگر به وضعیت ارسال.یکی دیگر به permissionهای کاربر.اگر خیلی زود همه را مجبور کنیم داخل یک StatusBadge عمومی قرار بگیرند، ممکن است کامپوننتی بسازیم که از نظر فنی reusable است، اما از نظر معنایی گیجکننده است.سؤال بهتر این نیست:آیا این کامپوننتها شبیه هم هستند؟سؤال بهتر این است:آیا این کامپوننتها به یک دلیل تغییر میکنند؟اگر جواب نه است، احتمالاً نباید در یک abstraction مشترک قرار بگیرند.Reusability زودهنگام API بد میسازدهر کامپوننت reusable یک API ارائه میدهد.در React، این API معمولاً همان props است.هرچه کامپوننت انعطافپذیرتر شود، API آن بزرگتر میشود.در ابتدا:بعد:} footer={} loading={isLoading} error={error} emptyState={} variant="dashboard" collapsible defaultCollapsed={false} />بخشی از اینها ممکن است کاملاً معتبر باشد.اما سؤال این است:آیا این کامپوننت هنوز ساده و قابل فهم است؟یک کامپوننت reusable با propهای زیاد، درست استفاده کردن را سخت میکند.توسعهدهندهها شروع میکنند به پرسیدن این سؤالها:کدام propها با هم کار میکنند؟ کدام propها با هم conflict دارند؟ اگر loading و error هر دو true باشند چه میشود؟ آیا footer همراه emptyState قابل استفاده است؟ آیا variant فقط style را تغییر میدهد یا behavior را هم عوض میکند؟کامپوننت تبدیل به یک framework کوچک میشود.و frameworkهای کوچک نیاز به نگهداری دارند.کامپوننتهای reusable میتوانند business logic را پنهان کنندخطر دیگر این است که منطق مخصوص feature را داخل کامپوننتهای shared قرار دهیم.مثلاً:این ممکن است reusable به نظر برسد، اما حالا table درباره orders، payments، refunds و permissions میداند.یعنی کامپوننت shared دیگر واقعاً shared نیست.تبدیل شده به جایی مخلوط برای business logic.رویکرد بهتر معمولاً این است:Shared component: UI عمومی جدول Feature component: رفتار مخصوص سفارشهامثلاً:و بعد داخل feature سفارشها:کامپوننت shared فقط rendering عمومی را مدیریت میکند.کامپوننت feature معنی بیزینسی را مدیریت میکند.این جداسازی باعث میشود کامپوننت reusable تمیز بماند.Reuse معمولاً باید بعد از تکرار بیایدیک قانون عملی که دوست دارم:اول duplicate کن. بعداً abstract کن.نه برای همیشه.نه بیدقت.بلکه آگاهانه.بار اولی که چیزی را میسازید، معمولاً هنوز الگوی واقعی را نمیدانید.بار دوم، شباهتها را میبینید.بار سوم، الگو واضحتر میشود.به همین دلیل بعضی توسعهدهندهها از “rule of three” استفاده میکنند:استفاده اول: مستقیم بساز استفاده دوم: duplication را تحمل کن استفاده سوم: به abstraction فکر کناین به معنی آن نیست که همیشه باید دقیقاً منتظر سه نمونه بمانید.اما یادآوری خوبی است:قبل از پایدار شدن الگو abstraction نسازید.هزینه abstraction اشتباه معمولاً بیشتر از هزینه duplication موقت است.چه چیزی یک کامپوننت reusable خوب میسازد؟یک کامپوننت reusable خوب معمولاً چند ویژگی دارد.هدف واضحی دارد.API کوچکی دارد.زیادی درباره business logic نمیداند.تست کردنش ساده است.مستند کردنش ساده است.بدون خواندن کل سورس کدش قابل استفاده است.به یک دلیل اصلی تغییر میکند.نمونههای خوب:Button Input Modal Tooltip Dropdown Tabs Avatar DatePicker Toastاین کامپوننتها معمولاً رفتار عمومی UI را نمایش میدهند.گزینههای خوبی برای shared یا design system هستند.اما کامپوننتهایی مثل اینها متفاوتاند:OrderSummaryCard ProductInventoryWarning CustomerRiskBadge PaymentAttemptTimeline AdminPermissionPanelاین اسمها معنی بیزینسی دارند.ممکن است داخل یک feature reusable باشند.اما احتمالاً نباید خیلی زود به فولدر shared عمومی منتقل شوند.فولدر Shared نباید تبدیل به سطل زباله شودخیلی از پروژهها فولدرهایی شبیه این دارند:src/shared src/components src/commonاین فولدرها میتوانند مفید باشند.اما میتوانند خطرناک هم باشند.وقتی توسعهدهندهها نمیدانند چیزی کجا باید قرار بگیرد، آن را داخل shared میگذارند.به مرور، shared تبدیل میشود به سطل زباله همهچیز:UI عمومی UI مخصوص feature business logic formatterها API helperها permission logic کامپوننتهای قدیمی و استفادهنشدهبعد دیگر کسی نمیداند چه چیزی واقعاً reusable است.قانون بهتر:کد را داخل feature نگه دارید تا وقتی ثابت کند واقعاً باید shared شود.کد shared باید ارتقا داده شود.نه اینکه از اول shared فرض شود.Reusability باید از ownership پیروی کندقبل از انتقال یک کامپوننت به shared، بپرسید:مالک این کامپوننت کیست؟اگر فقط feature سفارشها از آن استفاده میکند، داخل orders نگهش دارید.اگر فقط feature پرداختها از آن استفاده میکند، داخل payments نگهش دارید.اگر چند feature غیرمرتبط از آن استفاده میکنند، شاید جای آن در shared باشد.مثلاً:features/orders/components/OrderStatusBadge features/payments/components/PaymentStatusBadge shared/components/Badgeدر این ساختار:Badge = building block بصری عمومی OrderStatusBadge = معنی مخصوص سفارش PaymentStatusBadge = معنی مخصوص پرداختاین ساختار به شما reuse میدهد، بدون اینکه business logic را قاطی کند.چکلیست مفید قبل از reusable کردن یک کامپوننتقبل از ساختن یک کامپوننت reusable، بپرسید:۱. آیا حداقل دو یا سه use case واقعی وجود دارد؟ ۲. آیا این use caseها به یک دلیل تغییر میکنند؟ ۳. آیا معنی بیزینسی آنها یکی است؟ ۴. آیا API میتواند کوچک بماند؟ ۵. آیا این کار complexity را کم میکند یا فقط پنهانش میکند؟ ۶. آیا تغییرات آینده سادهتر میشود یا سختتر؟ ۷. آیا این واقعاً shared است یا فقط از نظر ظاهری شبیه است؟ ۸. آیا business logic بیرون از کامپوننت shared میماند؟ ۹. آیا duplication فعلاً ارزانتر است؟ ۱۰. مالک این کامپوننت کیست؟اگر جوابها واضح نیستند، احتمالاً برای abstraction زود است.قانون سرانگشتی منکامپوننت reusable را فقط به خاطر reuse احتمالی آینده نسازید.کامپوننت reusable را وقتی بسازید که reuse واقعاً ظاهر شده باشد.ساده شروع کنید.کد مخصوص feature را داخل همان feature نگه دارید.اجازه دهید الگو کمی تکرار شود.بعد بخشهای پایدار را استخراج کنید.مقدار کمی duplication همیشه بد نیست.اما یک abstraction بد میتواند هر تغییر آینده را کند کند.کامپوننتهای reusable قدرتمند هستند.اما زمانبندی مهم است.هدف این نیست که از reusability فرار کنیم.هدف این است که از reusability زودهنگام فرار کنیم.معماری خوب فرانتاند به این معنی نیست که همهچیز reusable باشد.یعنی بدانیم چه چیزی باید reusable باشد، چه چیزی باید specific بماند، و چه زمانی الگو به اندازه کافی بالغ شده که استخراج شود.گاهی بهترین کامپوننت، انعطافپذیرترین کامپوننت نیست.بهترین کامپوننت، کامپوننتی است که مسئله فعلی را واضح حل میکند.

اپلیکیشن فرانت‌اند را فقط بر اساس نوع فایل مرتب نکنید

Farhad Adeli — Mon, 06 Jul 2026 08:51:54 +0330

یکی از ساده‌ترین راه‌ها برای اینکه یک پروژه فرانت‌اند در ابتدا تمیز به نظر برسد، مرتب کردن فایل‌ها بر اساس نوع آن‌هاست.مثلاً:src/ components/ hooks/ services/ utils/ pages/ types/ stores/در نگاه اول منطقی است.کامپوننت‌ها داخل components.هوک‌ها داخل hooks.سرویس‌ها داخل services.تایپ‌ها داخل types.ساده و مرتب.اما وقتی پروژه بزرگ‌تر می‌شود، این ساختار می‌تواند کم‌کم دردسرساز شود.نه به این خاطر که این فولدرها ذاتاً اشتباه هستند.مشکل اینجاست که پروژه را بر اساس دسته‌بندی فنی مرتب می‌کنند، نه بر اساس فیچرهای محصول.و اپلیکیشن‌های واقعی معمولاً با فیچرها رشد می‌کنند.مشکل ساختارهای مبتنی بر نوع فایلفرض کنید روی یک داشبورد فروشگاهی کار می‌کنید.فیچرهایی مثل:احراز هویت محصولات سفارش‌ها مشتریان پرداخت‌ها تخفیف‌ها گزارش‌هااما ساختار پروژه این است:components/ hooks/ services/ utils/ stores/ types/حالا هر بار که روی فیچر orders کار می‌کنید، باید بین فایل‌های مختلف جابه‌جا شوید:components/OrderTable.tsx components/OrderStatusBadge.tsx hooks/useOrders.ts services/orderService.ts stores/orderStore.ts types/order.ts utils/formatOrderStatus.tsاز نظر فنی فایل‌ها مرتب هستند.اما خود فیچر در کل پروژه پخش شده است.این باعث می‌شود درک کدبیس سخت‌تر شود، چون ساختار فولدرها به شما نمی‌گوید محصول چه کار می‌کند.فقط می‌گوید چه نوع فایل‌هایی وجود دارد.نوع فایل معماری نیستیک اشتباه رایج این است که فکر کنیم فولدرهایی مثل components، hooks و services خودشان معماری خوب ایجاد می‌کنند.این‌طور نیست.این فولدرها فقط فایل‌ها را دسته‌بندی می‌کنند.معماری درباره مرزها، مالکیت، جهت وابستگی‌ها و جدا کردن تغییرات است.سؤال بهتر این نیست:این فایل کامپوننت است، هوک است، سرویس است یا تایپ؟سؤال بهتر این است:این کد متعلق به کدام فیچر است؟این سؤال ما را به ساختار متفاوتی می‌رساند.ساختار مبتنی بر فیچردر ساختار feature-based، فایل‌های مرتبط نزدیک به هم قرار می‌گیرند.مثلاً:src/ features/ orders/ components/ OrderTable.tsx OrderStatusBadge.tsx hooks/ useOrders.ts api/ orderApi.ts types/ order.types.ts utils/ formatOrderStatus.ts stores/ orderStore.tsحالا وقتی روی orders کار می‌کنید، بیشتر چیزهایی که لازم دارید در یک جا قرار دارد.فیچر خانه مشخصی دارد.این کار باعث می‌شود کدبیس راحت‌تر قابل جستجو، حذف، refactor و واگذاری به یک توسعه‌دهنده باشد.چرا این موضوع در پروژه‌های واقعی مهم است؟در پروژه‌های کوچک، تقریباً هر ساختاری جواب می‌دهد.می‌توانید همه‌چیز را بر اساس نوع فایل مرتب کنید، بر اساس فیچر مرتب کنید یا حتی خیلی چیزها را کنار هم نگه دارید و باز هم مشکلی نداشته باشید.مشکل از جایی شروع می‌شود که پروژه رشد می‌کند.وقتی تعداد توسعه‌دهنده‌ها بیشتر می‌شود، صفحه‌های بیشتری اضافه می‌شود، APIهای بیشتری ساخته می‌شود و قوانین بیزینسی پیچیده‌تر می‌شوند، هزینه مالکیت نامشخص خودش را نشان می‌دهد.کم‌کم این سؤال‌ها پیش می‌آیند:این منطق کجا باید باشد؟ آیا می‌توانم این فایل را با خیال راحت تغییر دهم؟ این کامپوننت فقط همین‌جا استفاده شده یا همه‌جا؟ این هوک مخصوص یک فیچر است یا shared است؟ آیا می‌توانم این فیچر قدیمی را حذف کنم بدون اینکه جای دیگری خراب شود؟ساختار feature-based کمک می‌کند سریع‌تر به این سؤال‌ها جواب دهیم.کد Shared باید واقعاً Shared باشدیکی از خطرهای ساختارهای مبتنی بر نوع فایل این است که همه‌چیز کم‌کم shared به نظر می‌رسد.وقتی یک کامپوننت داخل src/components قرار می‌گیرد، توسعه‌دهنده‌ها ممکن است فکر کنند یک کامپوننت عمومی و قابل استفاده مجدد است.اما همیشه این‌طور نیست.گاهی آن کامپوننت فقط برای یک فیچر خاص معنی دارد.مثلاً:OrderStatusBadge ProductVariantSelector CustomerRiskLabel PaymentAttemptTimelineاین‌ها شاید شبیه کامپوننت‌های reusable به نظر برسند، اما معمولاً معنی بیزینسی خاصی دارند.قرار دادن آن‌ها داخل فولدر global components می‌تواند باعث ابهام شود.قانون بهتر:کد مخصوص فیچر را داخل همان فیچر نگه دارید. فقط وقتی چیزی واقعاً مشترک است، آن را به shared منتقل کنید.کد shared باید آگاهانه shared شود.نه به صورت پیش‌فرض.یک ساختار عملی برای پروژه‌های فرانت‌اندساختاری که برای بسیاری از اپلیکیشن‌های فرانت‌اند دوست دارم، شبیه این است:src/ app/ providers/ routes/ layouts/ features/ auth/ orders/ products/ customers/ shared/ components/ hooks/ utils/ types/ lib/ api/ config/ constants/اسم دقیق فولدرها به اندازه ایده اصلی مهم نیست.یک جداسازی خوب می‌تواند این‌طور باشد:app → تنظیمات و ترکیب‌بندی اصلی اپلیکیشن features → فیچرهای بیزینسی shared → UI و utilityهای واقعاً قابل استفاده مجدد lib → زیرساخت‌ها و helperهای فنیاین مدل ذهنی پروژه را واضح‌تر می‌کند.فولدر app نشان می‌دهد اپلیکیشن چطور compose شده است.فولدر features نشان می‌دهد محصول چه کار می‌کند.فولدر shared چیزهایی را نگه می‌دارد که واقعاً reusable هستند.فولدر lib helperها و زیرساخت‌های فنی را نگه می‌دارد.چه چیزی باید داخل shared باشد؟فولدر shared باید با دقت استفاده شود.گزینه‌های مناسب برای shared:Button Input Modal DatePicker formatDate helperهای className هوک generic مثل useDebounce API client عمومی validation helperهای عمومیگزینه‌های نامناسب برای shared:OrderStatusBadge CustomerPaymentSummary ProductInventoryWarning AdminUserPermissionPanelاین اسم‌ها معمولاً معنی بیزینسی دارند.یعنی احتمالاً متعلق به یک فیچر هستند.یک تست ساده:اگر این فیچر را حذف کنم، آیا این فایل هم باید حذف شود؟اگر جواب بله است، آن فایل را داخل همان فیچر نگه دارید.Feature-based یعنی هر duplication بد نیستبعضی توسعه‌دهنده‌ها خیلی زود کد را shared می‌کنند، چون از duplication می‌ترسند.اما duplication کوچک گاهی بهتر از abstraction زودهنگام است.اگر امروز دو فیچر کامپوننت‌های مشابه دارند، لزوماً به این معنی نیست که همین الان باید یک abstraction مشترک ساخته شود.شاید این شباهت موقتی باشد.شاید قوانین بیزینسی هفته بعد از هم جدا شوند.شاید مجبور کردن دو فیچر به استفاده از یک کامپوننت مشترک، تغییر هر دو را سخت‌تر کند.قانون خوب:اگر معنی بیزینسی متفاوت است، اول duplication را بپذیرید. وقتی الگو ثابت شد، بعداً abstraction بسازید.اشتراک‌گذاری زودهنگام coupling ایجاد می‌کند.و coupling معمولاً از duplication گران‌تر است.جهت وابستگی‌ها مهم استساختار feature-based وقتی بهتر کار می‌کند که جهت وابستگی‌ها واضح باشد.مثلاً:features/orders می‌تواند از shared استفاده کند features/products می‌تواند از shared استفاده کند shared نباید به features وابسته باشد features نباید بی‌دلیل به هم وابسته شونداین نکته مهم است.اگر هر فیچر از هر فیچر دیگری import کند، دوباره کدبیس درهم‌تنیده می‌شود.قانون ساده:کد shared می‌تواند توسط فیچرها استفاده شود. فیچرها بهتر است مستقیماً به فیچرهای دیگر وابسته نشوند.اگر دو فیچر باید با هم ارتباط داشته باشند، معمولاً بهتر است از application-level state، routing، event یا یک abstraction مشترک استفاده شود، نه import عمیق از داخل همدیگر.چه زمانی ساختار مبتنی بر نوع فایل هنوز خوب است؟ساختار type-based همیشه بد نیست.برای موارد زیر می‌تواند کاملاً قابل قبول باشد:پروژه‌های کوچک prototypeها landing pageهای ساده admin panelهای کوچک پروژه‌های آموزشیهمچنین داخل خود یک فیچر هم می‌تواند خوب کار کند.مثلاً داخل features/orders داشتن فولدرهای components، hooks، api و types کاملاً منطقی است.مشکل استفاده از فولدرهای مبتنی بر نوع فایل نیست.مشکل این است که از آن‌ها به‌عنوان معماری top-level برای یک محصول در حال رشد استفاده کنیم.قانون سرانگشتی مندر سطح top-level، پروژه را بر اساس فیچرهای بیزینسی مرتب کنید.داخل هر فیچر، اگر کمک می‌کند، بر اساس نوع فایل مرتب کنید.مثلاً:features/orders/components features/orders/hooks features/orders/api features/orders/typesاین مدل بهترین بخش هر دو رویکرد را دارد.پروژه بر اساس معنی محصول مرتب می‌شود.و هر فیچر هم ساختار داخلی خودش را دارد.جمع‌بندییک ساختار فولدر خوب باید به توسعه‌دهنده‌ها کمک کند محصول را بفهمند.نه فقط نوع فایل‌ها را.وقتی یک اپلیکیشن فرانت‌اند رشد می‌کند، سؤال مهم این می‌شود:مالک این کد کیست؟معماری feature-based مالکیت را واضح‌تر می‌کند.فایل‌های مرتبط را نزدیک هم نگه می‌دارد.تغییر، حذف و refactor فیچرها را ساده‌تر می‌کند.جلوی shared شدن تصادفی کد را می‌گیرد.به تیم‌ها کمک می‌کند مستقل‌تر کار کنند.و باعث می‌شود کدبیس با رشد محصول قابل فهم‌تر بماند.نوع فایل مفید است.اما مالکیت فیچر معماری است.اگر اپلیکیشن فرانت‌اند شما در حال رشد است و برای هر تغییر باید بین ده فولدر نامرتبط جابه‌جا شوید، شاید وقتش رسیده باشد که فقط بر اساس نوع فایل سازمان‌دهی نکنید.بر اساس فیچر سازمان‌دهی کنید.

بیشتر باگ‌های فرانت‌اند در واقع باگ‌های مالکیت State هستند

Farhad Adeli — Wed, 01 Jul 2026 14:14:19 +0330

بیشتر باگ‌های فرانت‌اند به خاطر UI بد نیستند.مشکل اصلی معمولاً از مالکیت نامشخص State شروع می‌شود.ممکن است باگ خودش را در ظاهر رابط کاربری نشان دهد، اما ریشه مشکل معمولاً جای دیگری است:مالک این State کیست؟ چه کسی اجازه دارد آن را تغییر دهد؟ چه بخش‌هایی به آن وابسته هستند؟ چه زمانی باید reset شود؟ آیا باید بعد از تغییر صفحه باقی بماند؟ آیا باید با سرور sync شود؟وقتی جواب این سؤال‌ها مشخص نباشد، نگهداری یک اپلیکیشن فرانت‌اند به مرور سخت‌تر می‌شود.در ابتدا همه‌چیز ساده به نظر می‌رسد.یک useState اینجا اضافه می‌کنید.یک prop آنجا پاس می‌دهید.بعد Context اضافه می‌کنید چون prop drilling اذیت‌کننده شده.بعدتر شاید Zustand، Redux، React Query یا یک ابزار دیگر برای مدیریت state اضافه شود.و برای مدتی همه‌چیز کار می‌کند.اما وقتی اپلیکیشن بزرگ‌تر می‌شود، باگ‌های عجیب شروع می‌شوند:فیلترها بی‌دلیل reset می‌شوندمودال‌ها از جای اشتباه باز می‌شوندفرم‌ها مقدارهای قدیمی را نگه می‌دارندداده‌های API داخل local state کپی می‌شوندچند کامپوننت یک مقدار مشترک را تغییر می‌دهندیک تغییر کوچک سه صفحه مختلف را خراب می‌کنددر این نقطه، مشکل معمولاً React نیست.مشکل، مالکیت نامشخص state است.مدیریت State فقط انتخاب ابزار نیستوقتی توسعه‌دهنده‌ها درباره مدیریت state صحبت می‌کنند، بحث خیلی سریع به سمت ابزارها می‌رود.آیا باید از Redux استفاده کنیم؟آیا باید Zustand استفاده کنیم؟آیا Context API کافی است؟آیا باید React Query داشته باشیم؟Jotai، Recoil، MobX یا ابزارهای دیگر چطور؟همه این ابزارها مفید هستند.اما هیچ ابزاری به‌تنهایی طراحی بد state را درست نمی‌کند.اگر اپلیکیشن قوانین واضحی برای محل زندگی state نداشته باشد، حتی بهترین کتابخانه مدیریت state هم می‌تواند تبدیل به یک آشفتگی شود.Global store می‌تواند تبدیل به سطل زباله همه‌چیز شود.Context می‌تواند بیش از حد استفاده شود.Local state می‌تواند تکراری شود.Server data می‌تواند داخل client state کپی شود و stale بماند.سؤال اصلی این نیست:از کدام کتابخانه مدیریت state استفاده کنم؟سؤال بهتر این است:مالک این مقدار چه کسی باید باشد؟این سؤال معمولاً ما را به معماری بهتری می‌رساند.سه نوع رایج Stateدر بیشتر اپلیکیشن‌های فرانت‌اند، state معمولاً در سه دسته کلی قرار می‌گیرد:server state local UI state shared client stateهرکدام مالک متفاوت و lifecycle متفاوتی دارند.اشتباه گرفتن این‌ها با هم یکی از ساده‌ترین راه‌ها برای ساختن باگ‌های فرانت‌اند است.۱. Server StateServer state داده‌ای است که متعلق به بک‌اند است.مثال‌ها:کاربران سفارش‌ها محصولات دسترسی‌ها اعلان‌ها پیام‌ها تاریخچه پرداخت اطلاعات پروفایلاین داده معمولاً از API می‌آید.ممکن است cache شود.ممکن است نیاز به refetch داشته باشد.ممکن است بین چند کاربر مشترک باشد.ممکن است خارج از session فعلی مرورگر تغییر کند.ممکن است stale شود.به همین دلیل، server state معمولاً باید متفاوت از state معمولی UI مدیریت شود.مثلاً اگر لیست کاربران را از بک‌اند می‌گیرید، کپی کردن آن داخل useState و sync نگه داشتن دستی آن می‌تواند دردسرساز شود.رویکرد بهتر معمولاً استفاده از ابزارهای server-state است، مثل:TanStack Query / React Query SWR Apollo Client Relayاین ابزارها برای مسائلی مثل موارد زیر ساخته شده‌اند:caching refetching loading states error states pagination invalidation background updates stale dataServer state باید به این سؤال جواب دهد:بک‌اند در حال حاضر چه داده‌ای را می‌شناسد؟نباید با state باز یا بسته بودن یک dropdown یکسان دیده شود.۲. Local UI StateLocal UI state متعلق به یک کامپوننت یا یک بخش کوچک از UI است.مثال‌ها:آیا این dropdown باز است؟ آیا این modal نمایش داده شود؟ کدام tab انتخاب شده؟ مقدار فعلی input چیست؟ آیا tooltip فعال است؟ آیا accordion باز شده؟این نوع state معمولاً نیازی به global شدن ندارد.نیازی ندارد در کل اپلیکیشن باقی بماند.نیازی ندارد به‌صورت پیش‌فرض داخل Redux یا Zustand ذخیره شود.در بسیاری از موارد، state ساده React کافی است:const [isOpen, setIsOpen] = useState(false);اشتباه زمانی اتفاق می‌افتد که توسعه‌دهنده‌ها local UI state را خیلی زود global می‌کنند.مثلاً state باز یا بسته بودن یک dropdown معمولاً به global store تعلق ندارد.یک draft موقت فرم هم لزوماً نباید در global store باشد، مگر اینکه لازم باشد بعد از navigation باقی بماند یا بین چند بخش مستقل از اپلیکیشن shared شود.Local UI state باید به این سؤال جواب دهد:این بخش از رابط کاربری همین الان به چه چیزی نیاز دارد؟اگر جواب فقط داخل یک کامپوننت اهمیت دارد، آن را local نگه دارید.۳. Shared Client StateShared client state داده‌ای است که متعلق به اپلیکیشن فرانت‌اند است و چند بخش مستقل از UI به آن نیاز دارند.مثال‌ها:session کاربر لاگین‌شده theme زبان وضعیت باز یا بسته بودن sidebar فیلترهای global سبد خرید workspace انتخاب‌شده تعداد اعلان‌ها state یک wizard چندمرحله‌ایاین نوع state ممکن است به یک shared store نیاز داشته باشد.بسته به اپلیکیشن، این store می‌تواند یکی از این‌ها باشد:Context API Zustand Redux Toolkit Jotai MobX custom storeاما shared state باید آگاهانه استفاده شود.هر prop chain به Context نیاز ندارد.هر مقدار تکرارشونده‌ای global store نمی‌خواهد.هر مشکل ارتباط بین کامپوننت‌ها نباید تبدیل به global state شود.Shared client state باید به این سؤال جواب دهد:آیا چند بخش غیرمرتبط از اپلیکیشن واقعاً به این مقدار نیاز دارند؟اگر جواب نه است، احتمالاً این state نباید global باشد.اشتباه رایج: کپی کردن Server State داخل Local Stateیکی از رایج‌ترین code smellها در فرانت‌اند، کپی کردن داده API داخل local state بدون دلیل مشخص است.مثلاً:const { data: user } = useQuery({ queryKey: ["user", userId], queryFn: () => fetchUser(userId) }); const [localUser, setLocalUser] = useState(user);این کار معمولاً دو منبع حقیقت ایجاد می‌کند.حالا اپلیکیشن باید به این سؤال‌ها جواب دهد:کدام درست است؟ داده API؟ کپی local؟ وقتی داده سرور تغییر کند چه می‌شود؟ بعد از mutation چه اتفاقی می‌افتد؟ بعد از refetch چه می‌شود؟گاهی اوقات داشتن کپی local منطقی است، مخصوصاً برای draftهای قابل ویرایش.مثلاً یک فرم ممکن است با داده سرور پر شود، اما کاربر قبل از ذخیره آن را ویرایش کند.اما در این حالت، state باید به‌عنوان draft دیده شود، نه نسخه دوم server state.مدل ذهنی بهتر:Server state = منبع حقیقت از سمت بک‌اند Form state = draft موقت ساخته‌شده از آن منبعاین تفاوت مهم است.اشتباه رایج دیگر: Global State به‌عنوان پیش‌فرضGlobal state در ابتدا راحت به نظر می‌رسد.از هر جایی می‌توانید به آن دسترسی داشته باشید.از هر جایی می‌توانید آن را تغییر دهید.می‌توانید از prop drilling فرار کنید.اما این راحتی هزینه دارد.اگر همه‌چیز بتواند یک state را بخواند و تغییر دهد، فهمیدن سیستم سخت‌تر می‌شود.کم‌کم این سؤال‌ها پیش می‌آید:چه کسی این مقدار را تغییر داد؟ چرا این کامپوننت دوباره render شد؟ چرا این صفحه reset شد؟ چرا این modal باز است؟ چرا این فیلتر روی صفحه دیگری اثر گذاشت؟Global state نباید حالت پیش‌فرض باشد.باید یک تصمیم آگاهانه باشد.قبل از global کردن state، بپرسید:آیا این مقدار باید توسط بخش‌های غیرمرتبط اپلیکیشن استفاده شود؟ آیا باید بعد از تغییر route باقی بماند؟ آیا نشان‌دهنده رفتار سطح اپلیکیشن است؟ آیا پاس دادن آن واقعاً کد را بدتر می‌کند یا فقط کمی ناخوشایند است؟گاهی global state کاملاً درست است.اما global کردن همه‌چیز coupling پنهان ایجاد می‌کند.Lifecycle State مهم استیک state variable فقط درباره محل زندگی‌اش نیست.درباره مدت زنده بودنش هم هست.بعضی stateها باید هنگام unmount شدن کامپوننت reset شوند.بعضی stateها باید هنگام تغییر route reset شوند.بعضی stateها باید بعد از navigation باقی بمانند.بعضی stateها باید بعد از refresh هم باقی بمانند.بعضی stateها باید داخل URL ذخیره شوند.بعضی stateها باید داخل local storage persist شوند.مثلاً:فیلترهای جستجو ممکن است به URL تعلق داشته باشند. state باز بودن modal ممکن است local component state باشد. authentication state ممکن است در shared store باشد. داده API ممکن است در server-state cache باشد. فرم چندمرحله‌ای ممکن است نیاز به persistence داشته باشد.اگر lifecycle واضح نباشد، احتمال باگ بالا می‌رود.برای همین من دوست دارم این سؤال را بپرسم:این state چه زمانی باید بمیرد؟این سؤال به اندازه سؤال زیر مهم است:این state کجا باید زندگی کند؟URL State دست‌کم گرفته می‌شودبعضی stateهای فرانت‌اند باید در URL زندگی کنند.مثال‌ها:عبارت جستجو صفحه pagination ترتیب مرتب‌سازی فیلترهای انتخاب‌شده tab فعال در بعضی صفحاتچرا؟چون URL state قابل اشتراک‌گذاری است.بعد از refresh باقی می‌ماند.از browser navigation پشتیبانی می‌کند.صفحه را bookmarkable می‌کند.debug کردن را ساده‌تر می‌کند.مثلاً این معمولاً بهتر است:/products?category=laptops&page=2&sort=priceتا اینکه تمام state فیلترها را داخل یک کامپوننت یا global store پنهان کنیم.همه UI stateها به URL تعلق ندارند، اما برای فیلترهای سطح صفحه و stateهای مرتبط با navigation، URL اغلب مالک مناسبی است.یک چک‌لیست ساده برای تصمیم‌گیریقبل از اضافه کردن یک state variable جدید، من معمولاً این سؤال‌ها را می‌پرسم:۱. آیا این داده از بک‌اند می‌آید؟ ۲. آیا فقط در یک کامپوننت استفاده می‌شود؟ ۳. آیا چند بخش غیرمرتبط از اپلیکیشن به آن نیاز دارند؟ ۴. آیا باید بعد از navigation باقی بماند؟ ۵. آیا باید بعد از refresh باقی بماند؟ ۶. آیا باید از طریق URL قابل اشتراک‌گذاری باشد؟ ۷. آیا یک draft موقت است؟ ۸. چه کسی اجازه دارد آن را تغییر دهد؟ ۹. چه زمانی باید reset شود؟ ۱۰. منبع حقیقت چیست؟این سؤال‌ها ساده هستند، اما جلوی بسیاری از باگ‌ها را می‌گیرند.قانون سرانگشتی مناز server state برای داده‌ای استفاده کنید که متعلق به بک‌اند است.از local state برای رفتار UI داخل یک کامپوننت یا یک بخش کوچک استفاده کنید.از shared client state فقط زمانی استفاده کنید که چند بخش غیرمرتبط از اپلیکیشن واقعاً به یک مقدار مشترک نیاز دارند.از URL state زمانی استفاده کنید که state مربوط به navigation، فیلترها، جستجو یا تنظیمات قابل اشتراک‌گذاری صفحه است.Server state را داخل local state کپی نکنید، مگر اینکه عمداً در حال ساختن یک draft باشید.State را فقط به این دلیل که پاس دادن prop کمی آزاردهنده است global نکنید.و مهم‌تر از همه:قبل از اضافه کردن یک state variable جدید، بپرسید چه کسی باید مسئول این مقدار باشد.همین یک سؤال می‌تواند جلوی بسیاری از باگ‌های آینده را بگیرد.جمع‌بندیتوسعه فرانت‌اند در سطح senior فقط دانستن hookها، کتابخانه‌های state management یا APIهای فریم‌ورک نیست.موضوع اصلی این است که بدانیم state کجا باید زندگی کند.و کجا نباید زندگی کند.یک معماری فرانت‌اند تمیز معمولاً مالکیت مشخصی دارد:بک‌اند مالک server data است کامپوننت مالک local UI behavior است app store مالک shared client state واقعی است URL مالک navigation state قابل اشتراک‌گذاری استوقتی مالکیت واضح باشد، فهمیدن اپلیکیشن ساده‌تر می‌شود.وقتی مالکیت نامشخص باشد، حتی featureهای ساده هم شکننده می‌شوند.بیشتر باگ‌های فرانت‌اند واقعاً باگ UI نیستند.آن‌ها باگ‌های مالکیت هستند.

AI Writes Code. Engineers Build Software.

Farhad Adeli — Mon, 29 Jun 2026 16:42:39 +0330

AI can help us write code faster.A lot faster.It can generate React components, create API endpoints, suggest database schemas, write validation logic, generate unit tests, explain errors, and even refactor messy code.That is powerful.But writing code is not the same as building software.There is a big difference between:Can this code run?and:Should this solution exist in this form?That second question is where engineering judgment matters.AI is very good at syntaxModern AI tools are excellent at producing code.You can ask for a component, a function, a service, a SQL query, a form validator, or a test case, and you will often get something useful in seconds.For many daily development tasks, AI can remove a lot of friction.It can help with:boilerplate syntax quick examples refactoring ideas debugging hints test generation documentation code explanation library comparisonsThis is why I believe developers should use AI.Ignoring it completely is not a good strategy.But there is a trap.Because AI can generate something that looks correct, it is easy to confuse speed with quality.Fast code is not always good software.Engineering is not only syntaxSoftware engineering is about tradeoffs.It is about context.It is about understanding the product, the team, the user, the deadline, the risks, and the future cost of today’s decisions.AI can generate an API endpoint.But the engineer still needs to ask:Should this endpoint exist? Who is allowed to call it? What should happen on invalid input? What should the response shape be? Should this be cached? How will we version it later? What happens if the database is slow? What should be logged? What should not be exposed?AI can generate a React component.But the engineer still needs to ask:Should this state be local or global? Is this component doing too much? Is this reusable or page-specific? Will this re-render too often? Is this accessible? Is this easy for another developer to maintain?AI can generate a database schema.But the engineer still needs to ask:Does this model reflect the real business rules? Will this scale? What should be indexed? What should be normalized? What should not be stored? How will migrations be handled? What happens when requirements change?These questions are not just syntax questions.They are engineering questions.Junior use of AI vs senior use of AIA junior developer may ask AI:Build this feature for me.A more experienced developer asks:What are the edge cases? Where can this fail? What are the tradeoffs? Is there a simpler solution? What should be tested? What are the security risks? How will this behave under load? How will another developer understand this later?The difference is not only experience.The difference is the quality of the questions.AI is most useful when the developer already understands the problem well enough to guide it.Without that, AI can produce code that looks polished but hides bad assumptions.The danger of confident wrong codeOne of the biggest risks with AI-generated code is that it often sounds confident.The code may be formatted well.The explanation may sound reasonable.The names may look clean.But the solution may still be wrong for your actual project.It may ignore edge cases.It may introduce security issues.It may use outdated patterns.It may over-engineer a simple feature.It may create abstractions that make the code harder to maintain.It may solve the wrong problem beautifully.That last one is dangerous.A clean implementation of the wrong idea is still the wrong idea.AI increases the value of fundamentalsSome people say AI will make programming fundamentals less important.I think the opposite.AI makes fundamentals more important.When AI can generate code quickly, the valuable skill becomes knowing whether that code is good.To judge that, you need fundamentals:HTTP state management database design security basics asynchronous programming system design testing strategy performance error handling architecture maintainabilityWithout fundamentals, you may accept whatever AI gives you.With fundamentals, AI becomes an accelerator.You can use it to move faster while still keeping control over quality.AI speed without judgment creates technical debt fasterBefore AI, writing bad code took time.Now bad code can be generated very quickly.That means AI can help good engineers move faster, but it can also help weak engineering decisions spread faster.The output speed increased.The need for review did not disappear.In fact, review became more important.Every AI-assisted solution still needs to be checked against the actual context of the project:Does this match our architecture? Does this fit our coding style? Does this introduce hidden coupling? Is this secure? Is this testable? Is this simple enough? Is this the right level of abstraction?If we skip those questions, AI does not remove technical debt.It accelerates it.The best use of AI is collaboration, not delegationI do not like using AI as a blind code generator.I prefer using it as a technical assistant.For example:Give me three possible approaches. Compare the tradeoffs. Show me the simplest version first. Find edge cases. Review this code. Suggest tests. Explain the performance risks. Make this easier to maintain.This kind of workflow keeps the engineer in control.The developer provides direction.AI provides speed.The developer makes the final decision.That is the right balance.Product thinking still mattersGood software is not only technically correct.It also needs to solve the right problem.AI may generate a beautiful implementation, but it does not always know the business context.It may not know:what the user actually needs what the product goal is what the deadline is what the team can maintain what the company can afford what should be built now what should be delayedThis is where product thinking matters.Sometimes the best engineering decision is not the most advanced solution.Sometimes the best solution is the simplest one that solves the real problem and keeps the product moving.AI can help you build.But you still need to decide what is worth building.My rule of thumbUse AI to move faster.Do not use AI to stop thinking.AI is great for:speed syntax drafting exploration boilerplate explanation comparisonEngineers are still responsible for:architecture security tradeoffs maintainability product fit testing strategy long-term consequencesThe future does not belong to developers who ignore AI.It also does not belong to developers who blindly trust AI.The future belongs to engineers who can combine:AI speed + engineering fundamentals + product thinkingAI makes coding faster.Judgment makes software better.

A Good Developer Does Not Marry a Framework

Farhad Adeli — Thu, 25 Jun 2026 15:24:07 +0330

A good developer does not marry a framework.React, Angular, Vue, Next.js, NestJS, Laravel, .NET — they all matter.They are useful tools. They help us build faster, organize code better, and solve real business problems. But after working with different technologies for some years, you start noticing something important:The syntax changes.The ecosystem changes.The mental models repeat.Most modern software stacks are solving very similar problems:state management routing rendering data fetching caching validation authentication authorization error handling testing deployment architectureThe names are different.The patterns are often familiar.Frameworks are tools, not identitiesI see many developers define themselves only by one framework:React developer Angular developer Vue developer Node.js developer Laravel developer .NET developerThere is nothing wrong with specialization. In fact, deep knowledge of a framework is valuable.But I think there is a danger when a developer’s entire identity depends on one tool.Frameworks change.Market demand changes.Best practices change.New libraries appear.Old libraries disappear.A few years ago, a specific framework or library might have looked like the future. Today, it might be considered legacy in some companies.That does not mean learning frameworks is useless.It means we should learn them as tools, not as permanent identities.A stronger identity is:I build reliable software systems.That mindset survives framework changes.The same problems appear in different formsOnce you understand component architecture, moving between React, Vue, and Angular becomes much easier.The syntax is different, but the questions are familiar:How should components communicate? Where should state live? What belongs in a reusable component? What should stay page-specific? How do we avoid unnecessary coupling? How do we keep the UI predictable?Once you understand API design, moving between Node.js, Laravel, .NET, or NestJS becomes less scary.Again, the syntax changes, but the core questions remain:What should the API expose? How do we validate input? How do we handle errors? How do we separate business logic from transport logic? How do we avoid leaking database internals? How do we keep the system maintainable?Once you understand clean separation of concerns, the language becomes less important than people think.Not unimportant.Just less scary.Switching frameworks is not starting from zeroWhen a junior developer learns a new framework, it often feels like starting from zero.When a more experienced developer learns a new framework, the process is different.You are not really learning software development again.You are mapping familiar concepts into a new ecosystem.For example:React state → Angular signals/services/RxJS Vue composables → React hooks Express middleware → NestJS guards/interceptors/pipes Laravel services → .NET services or Node.js service classesOf course, every framework has its own philosophy.You still need to learn the details.You still need to respect the ecosystem.You still need to write idiomatic code.But you are not lost.You already understand the problems the framework is trying to solve.That is a huge advantage.Fundamentals compoundFramework knowledge is useful.Fundamentals are reusable.Things like:data structures HTTP browser behavior security basics database design API contracts state management asynchronous programming performance optimization testing strategy deployment and monitoring software architectureThese skills compound over time.A framework may help you get a job today.Fundamentals help you survive multiple changes in the industry.This is why I believe developers should go deep enough into their current stack to be productive, but not so narrow that they become afraid of everything outside it.AI makes adaptability even more importantAI tools are making it easier to learn new frameworks quickly.But AI does not remove the need for engineering judgment.In fact, it makes judgment more important.AI can help you generate code.AI can explain syntax.AI can compare libraries.AI can help you move faster.But you still need to know whether the generated solution is clean, secure, maintainable, and appropriate for the project.If you understand architecture, AI becomes a powerful accelerator.If you only know syntax, AI can easily lead you into messy code that looks correct at first glance.That is why adaptability is not just about learning faster.It is about having enough fundamentals to evaluate what you are learning.Specialization is still valuableThis does not mean every developer should become a generalist with shallow knowledge.Deep specialization is valuable.A great React engineer is valuable.A great Angular engineer is valuable.A great backend engineer is valuable.A great Laravel, .NET, or Node.js engineer is valuable.The point is not:Do not specialize.The point is:Do not become dependent on one tool for your entire engineering identity.There is a difference between being specialized and being trapped.The best engineers I have worked with usually have both:deep expertise in their current stack + strong fundamentals that transfer across stacksThat combination is powerful.My rule of thumbLearn frameworks seriously.Use them properly.Respect their patterns.Understand their ecosystems.But do not let your whole career depend on one framework.Frameworks are temporary.Engineering fundamentals compound.A good developer should be able to say:I know this framework well. But I am not limited by it.That is the mindset that keeps you useful when the industry changes.And the industry always changes.

Simulcast: Manually Controlling Video Quality Layers in WebRTC

Farhad Adeli — Tue, 23 Jun 2026 21:10:24 +0330

Most developers misunderstand “manual layer selection” in WebRTC simulcast.They think the receiver simply says:“Give me 360p, 720p, or 1080p.”But in real production systems, it is usually more nuanced.With simulcast, the sender may produce multiple video layers:low → 360p medium → 720p high → 1080pThe important question is:Who decides which layer is actually delivered?In a simple peer-to-peer setup, the sender can control which encodings are active.But in an SFU-based architecture, the SFU usually receives multiple layers and forwards the most appropriate one to each participant.For example:active speaker → high qualitynormal participant → medium qualitysmall thumbnail → low qualityweak network → lower layerpinned user → higher layerThis is why simulcast is not just a “video quality feature.”It is a bandwidth management strategy.Manual layer selection can be useful when you want to let users choose quality, debug video behavior, or optimize layouts like gallery view vs pinned speaker view.The key lesson:Simulcast is not only about sending multiple qualities.It is about choosing the right quality at the right time for the right receiver.That is one of the things that separates a basic WebRTC demo from a production-grade video platform.Have you ever worked with simulcast, SFUs, mediasoup, Janus, or Jitsi?#WebRTC #Simulcast #JavaScript #FrontendDevelopment #NodeJS #RealTimeCommunication #SoftwareEngineering

What is Simulcast?

Farhad Adeli — Tue, 23 Jun 2026 21:10:02 +0330

Most developers think WebRTC video quality is only about internet speed.But in real-time video apps, especially group calls, there is another important concept:Simulcast.Instead of sending only one video stream, the sender can send multiple versions of the same video at different qualities.For example:Low quality → for weak networks / small thumbnails Medium → for normal participants High quality → for active speaker / large viewThen the receiver, SFU, or media server can choose the best layer depending on:available bandwidthdevice performancescreen sizeactive speaker layoutnetwork changesnumber of participantsThis is why in many video call apps, one person can appear in high quality when pinned, but lower quality when shown as a small thumbnail.The smart part is not just encoding video.The smart part is sending the right quality to the right user at the right time.Without this, large WebRTC rooms become expensive, unstable, and bandwidth-heavy very quickly.My simple explanation:Simulcast helps WebRTC apps avoid wasting bandwidth by sending multiple video layers and letting the system pick the most useful one.This is one of those concepts that separates a basic video call demo from a production-grade real-time communication system.Have you worked with WebRTC, mediasoup, Janus, Jitsi, or any SFU-based video system before?#WebRTC #JavaScript #FrontendDevelopment #RealTimeCommunication #SoftwareEngineering #VideoStreaming #NodeJS #WebDevelopment

What is one of the easiest ways to create a memory leak in an Angular app?

Farhad Adeli — Wed, 17 Jun 2026 01:41:53 +0330

Angular interview question:What is one of the easiest ways to create a memory leak in an Angular app?A very common answer is:“Forgetting to unsubscribe.”That is correct, but the real issue is usually deeper.The problem is not just the missing unsubscribe().The problem is uncontrolled subscriptions.For example:ngOnInit() { this.userService.getUser().subscribe(user => { this.user = user; }); } This may look harmless.But if the observable does not complete automatically, and the component gets destroyed, the subscription can stay alive.Now imagine this pattern repeated across:dashboardsfilterssearch inputsWebSocket streamsroute-based componentsreal-time notificationsSmall leaks become real production problems.A better approach is to avoid manual subscriptions when possible.Use the async pipe:

Or in newer Angular versions, use takeUntilDestroyed():this.userService.getUser() .pipe(takeUntilDestroyed(this.destroyRef)) .subscribe(user => { this.user = user; }); My rule of thumb:If the data is only used in the template, prefer async pipe.If you need side effects in TypeScript, make the subscription lifecycle explicit.Senior Angular development is not just knowing RxJS operators.It is knowing who owns the subscription — and when it dies.How do you usually manage subscriptions in Angular?#Angular #RxJS #FrontendDevelopment #TypeScript #WebDevelopment #SoftwareEngineering #InterviewQuestions

Why should your API not return database models directly?

Farhad Adeli — Sun, 14 Jun 2026 05:47:55 +0330

Backend interview question:Why should your API not return database models directly?A common junior answer is:“Because it works and it is faster to develop.”And honestly, for a small prototype, that might be fine.But in real production systems, returning database models directly can create problems very quickly.For example, your User table may have fields like:passwordHash resetToken internalNotes roleId createdBy deletedAtEven if you “hide” some fields today, the risk is still there.The bigger problem is coupling.When your API response is the same shape as your database model, every database change can accidentally become an API change.That means:Frontend becomes tightly coupled to backend internalsRefactoring the database becomes riskySensitive fields may leak by mistakeAPI versioning becomes harderYour response shape is designed around storage, not user needsA better approach is to use DTOs or response mappers.The database model answers:“How do we store this data?”The API response should answer:“What does the client actually need?”That small separation makes your system much easier to maintain as it grows.Senior backend development is not just about making the endpoint work.It is about protecting future changes.How do you usually structure API responses in your projects?#NodeJS #BackendDevelopment #APIDesign #TypeScript #SoftwareEngineering #FullStackDevelopment

When would you use container queries instead of media queries?

Farhad Adeli — Sun, 14 Jun 2026 05:34:36 +0330

Frontend interview question:A lot of developers answer:“Media queries are for responsive design.”True, but incomplete.Media queries respond to the screen size.Container queries respond to the actual size of the component’s parent/container.That difference matters a lot when you build reusable components.For example, imagine a ProductCard component.On one page, it is inside a 3-column grid.On another page, it is inside a narrow sidebar.On another page, it is inside a dashboard widget.The screen size may be the same, but the available space for the component is completely different.That is where container queries are much cleaner.Instead of asking:“Is the viewport smaller than 768px?”You ask:“How much space does this component actually have?”My rule of thumb:Use media queries for page-level layout.Use container queries for reusable components.This avoids a lot of layout bugs when the same component is reused in different places.Senior frontend development is not just about making things responsive.It is about making components survive real-world reuse.How would you explain this in an interview?#FrontendDevelopment #CSS #WebDevelopment #ReactJS #Angular #VueJS #SoftwareEngineering

React performance problems

Farhad Adeli — Fri, 12 Jun 2026 17:18:39 +0330

Most React performance problems are not fixed with useMemo.A lot of developers see a component re-rendering and immediately reach for:useMemo() useCallback() React.memo()But in many cases, that just makes the code more complex without solving the real problem.The better question is not:“How do I stop this component from re-rendering?”The better question is:“Why is this component receiving changes it does not actually need?”In my experience, most React performance issues come from:State living too high in the component treePassing unstable objects/functions as propsContext providers wrapping too much of the appComponents doing too many unrelated jobsRendering large lists without virtualizationuseMemo can help, but it should usually be the second or third solution — not the first one.A simple rule I use:Before optimizing a component, first fix the data flow.Clean architecture beats random memoization almost every time.What is your usual first step when a React component becomes slow?#ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #SoftwareEngineering