چرا کدنویسی را کنار گذاشتم و طراحی را شروع کردم
قبلاً فکر میکردم توسعه نرمافزار یعنی نوشتن قابلیتها (features). تصور میکردم وظیفهام ایجاد موجودیتها (entities)، ساخت کنترلرها (controllers) و اتصال پایگاههای داده است.
یک پروژه اخیر دیدگاه من را تغییر داد. یاد گرفتم که کدنویسی تنها بخشی از راه حل است. کار واقعی پیش از آنکه حتی یک خط کد بنویسید، انجام میشود.
شما باید درباره معماری تصمیم بگیرید. باید بپرسید چرا این معماری مناسب است، چه هزینهای دارد و چه ریسکهایی را برطرف میکند.
در اینجا درسهای اصلی من آمده است:
• معماری باید با مرحلهی محصول همخوانی داشته باشد. وسوسهانگیز است که بلافاصله از microservices، Kubernetes و صفهای رویداد (event queues) پیچیده استفاده کنیم. برای پروژه خودمان، یک معماری لایهای (layered architecture) در یک فرآیند واحد (single process) را انتخاب کردیم. این کار به ما اجازه داد تا بدون درگیری با دردسرهای یک سیستم توزیعشده (distributed system)، مسئولیتها را از هم جدا کنیم. در شروع کار، سادگی اغلب بهتر است.
• برخی تصمیمات اکنون ارزان هستند اما بعداً گران تمام میشوند. ما از روز اول یک TenantId به مدل دادهای خود اضافه کردیم. با وجود اینکه فقط یک مشتری داشتیم، این کار انتقال به مدل SaaS را در آینده آسان کرد. اگر برای اضافه کردن قابلیت چندمستاجری (multi-tenancy) خیلی دیر اقدام کنید، مهاجرت به آن تبدیل به یک کابوس خواهد شد.
• طراحی از بنبستهای آینده جلوگیری میکند. برنامهنویسی یک مشکل فوری را حل میکند، اما طراحی مشکلی را حل میکند بدون اینکه درهای آینده را ببندد. ما از همان ابتدا از کانتینرها (containers) استفاده کردیم تا انتقال به زیرساختهای مختلف آسان باشد. همچنین از اینترفیسها (interfaces) استفاده کردیم تا تعویض ارائهدهندگان (providers) ساده شود.
• تغییرات کسبوکار، تغییرات فنی را به دنبال دارند. یک سیستم به دلیل رشد کسبوکار به سمت microservices حرکت میکند. مثلاً یک اپلیکیشن برای یک کلینیک، به یک پلتفرم SaaS برای صدها کلینیک تبدیل میشود. این تغییر، نحوه مدیریت صورتحسابها، اشتراکها و مقیاسپذیری (scaling) را تغییر میدهد.
• قابلیت اطمینان نیازمند الگوهای هوشمندانه است. ما از فراخوانیهای همگام (synchronous calls) به معماری رویداد-محور (event-driven architecture) مهاجرت کردیم. در یک سیستم پزشکی، یک سرویس اعلان (notification service) کند نباید باعث از کار افتادن رزرو نوبت شود. ما از الگوی Outbox استفاده کردیم تا اطمینان حاصل کنیم که حتی در صورت خرابی پیامرسان (message broker)، دادهها ایمن میمانند.
• الگوها باید با دامنه (domain) سازگار باشند. از الگوها کورکورانه استفاده نکنید. تشخیص پزشکی به سازگاری قوی (strong consistency) نیاز دارد. برای ایمنی بیمار، نمیتوانید به سازگاری نهایی (eventual consistency) تکیه کنید. اگر استفاده از کش (cache) باعث از بین رفتن ردپای بازرسی (audit trail) شما میشود، از آن برای دادههای حساس بالینی استفاده نکنید.
• DevOps یک موضوع جانبی نیست. استقرار (Deployment)، بررسی سلامت (health checks) و خطلولهها (pipelines) بخشی از طراحی اولیه هستند. شما باید هزینهها را تخمین بزنید و اجزایی را انتخاب کنید که واقعاً نیازهای شما را برآورده میکنند.
تفاوت بین یک برنامهنویس و یک طراح، در «چرا» است.
یک برنامهنویس میپرسد: «چطور این را به کار بیندازم؟» یک طراح میپرسد: «چرا این، راه حل مناسبی برای این مشکل خاص است؟»