https://virgool.io/feed/@vajihe.nikkhah توسعه دهنده backend، علاقمند به معماری نرم‌افزار fa 2026-06-16 11:59:59 https://files.virgool.io/upload/users/35664/avatar/GqWCnk.jpg?height=120&width=120 https://virgool.io/@vajihe.nikkhah https://virgool.io/codenevis/dependency-injection-%D9%88-dependency-inversion-coxbuyj3mmbk اصول dependency injection و dependency inversion، دو اصل مهم در طراحی نرم‌افزار به منظور تفکیک و جداسازی کلاس‌ها و وابستگی‌ها از یکدیگر است. بسیاری این دو را یکسان در نظر می‌گیرند ولی در واقع هر کدام با تکیه بر قواعدی متفاوت، تفکیک و انتزاعی‌سازی کد را جهت قابلیت استفاده مجدد و تست نویسی ساده‌تر، انجام می‌دهند.تکنیک Dependency Injection یا DI برای دستیابی به تفکیک چسبندگی بین کلاس‌ها و وابستگی‌هایشان استفاده می‌شود. در این تکنیک، وابستگی‌ها، به جای اینکه در داخل خود کلاس تعریف شوند، از بیرون تزریق می‌شوند.اصل Dependency Inversion Principle یا DIP یک اصل طراحی سطح بالا و پنجمین اصل SOLID است که به دنبال جداسازی ماژول‌های سطح بالا از ماژول‌های سطح پایین است. بر اساس این اصل، ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند؛ هر دو باید به انتزاعات وابسته باشند.یکی از نکات مهم برای استفاده از اصول مربوط به dependency، قابلیت تست نرم‌افزار است زیرا در صورت عدم استفاده از این اصول امکان استفاده از mock نیز به سادگی امکان پذیر نخواهد بود. هدف من از این نوشته، بیان تفاوت بین این دو اصل می‌باشد. در ادامه نحوه‌ی استفاده این قواعد در کنار یکدیگر در نمونه کدهای go، نشان داده می‌شود.در نمونه کد اول، هیچکدام از قواعد dependency injection و dependency inversion رعایت نشده است. Logger، به صورت مستقیم در تابع UserService تعریف شده که اصل dependency injection را نقض می‌کند و همچنین استراکت UserService، بجای وابستگی به یک interface، مستقیما به ماژول سطح پایین Logger وابسته شده است.نمونه کد اولدر نمونه کد دوم dependency injection رعایت شده، و Logger از بیرون برای تابع ارسال شده ولی dependency inversion رعایت نشده است.نمونه کد دومدر نمونه کد سوم، dependency injection و dependency inversion رعایت شده است. در واقع در این کد Logger از نوع اینترفیس ساخته شده و برای استفاده نیز از این اینترفیس استفاده می‌شود، در نتیجه کد به انتزاعات تکیه دارد. و همچنین برای استفاده از Logger در NewUserService، این اینترفیس به عنوان پارامتر ورودی تعریف شده و به طور مستقیم در تابع ساخته نشده است در نتیجه dependency injection نیز رعایت شده است.نمونه کد سوم وجیهه نیکخواه وجیهه نیکخواه Wed, 01 May 2024 15:28:48 +0330 https://virgool.io/codenevis/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%DA%A9%D8%AA%D8%A7%D8%A8-concurrency-in-go-pqrfojqnwpse در این مقاله قصد دارم به معرفی کتاب concurrency in go، نوشته‌ی Katherine Cox-Buday بپردازم. هدف من از معرفی این کتاب، آشنایی خواننده با بیان موارد کلی و جزئی‌تری است که در کتاب به آنها پرداخته شده تا توسعه دهنده در صورت نیاز بتواند فصل مربوطه را به صورت عمیق مطالعه کند.این کتاب، که در شش فصل نوشته شده، به تکنیک‌های همروندی یا concurrency و حل مسائل پیچیده‌تر همروندی در golang می‌پردازد. نویسنده تلاش کرده تا در هر فصل با استفاده از کدهای مناسب، تکنیک‌ها و چالش‌های پیش رو را توضیح دهد. کدهای توضیح داده شده نیز در گیت‌هاب موجود است.فصل اول: معرفی concurrencyاین فصل با توضیحاتی در مورد سابقه‌ی همروندی در دنیای کامپیوتر شروع شده و به تعریفی از concurrency می‌پردازد. concurrency، مباحث تئوری و عملی بسیاری دارد ولی در این کتاب همروندی را به صورت کاربردی و در قالب مثال‌هایی به زبان golang بیان می‌کند.نوشتن یک برنامه حاوی کدهای همروند بخصوص در زبان برنامه‌نویسی golang، چندان کار مشکلی نیست ولی همروندی چالش‌ها و مشکلاتی را در پی دارد که اجرای صحیح برنامه را با اختلال مواجه می‌کند. در این فصل چالش‌های مربوط به همروندی توضیح داده می‌شود. مواردی مانند:Race conditionsDeadlocklivelockstarvationفصل دوم: Communicating Sequential Processesاین فصل با تفاوت بین concurrency و parallel شروع می‌شود. توسعه‌دهندگان معمولا این دو کلمه را بجای یکدیگر استفاده می‌کنند ولی در واقع concurrency، ویژگی قطعه کد و parallelism ویژگی برنامه‌های در حال اجرا است. در ادامه نویسنده به تفاوت بین OS thread و goroutine در golang پرداخته و در مورد Communicating Sequential Processes یا CSP که goroutineها از آن الهام گرفته‌ شده‌اند توضیح می‌دهد.به منظور حل چالش حافظه‌ی اشتراکی بین threadها، از goroutine و channel استفاده می‌شود ولی همچنان با استفاده از پکیج sync و ویژگی‌های آن می‌توان از حافظه‌ی اشتراکی استفاده کرد. نویسنده برای تصمیم‌گیری بهتر در مورد استفاده از حافظه‌ی اشتراکی و یا channelها، سوالاتی را مطرح کرده تا توسعه‌دهنده بتواند با استفاده از آنها راه‌حل خود را برای همروندی انتخاب کند.فصل سوم: Go’s Concurrency Building Blocksدر این فصل نویسنده به مدل‌های مربوط به همروندی در گولنگ می‌پردازد. ابتدا goroutine را توضیح داده و نحوه‌ی ایجاد آن در کد را بیان می‌کند. در کد می‌توان یک تابع مستقل و یا یک تکه از کد را در قالب anonymous function، به صورت goroutine اجرا کرد.مدل دیگر برای اجرای همروند و نیز کنترل نقطه الحاق (joint point)، پکیج sync است که از waitgroup و متد done برای کنترل بیشتر goroutineها استفاده می‌کند. در اینجا mutex و RWmutex برای استفاده از حافظه‌ی اشتراکی نیز توضیح داده شده‌است. Poolها نیز در ادامه شرح داده شده که از این فیچر برای کنترل تعداد goroutineها، بخصوص مواردی که هزینه‌ی سنگینی دارند مانند اتصال دیتابیس، استفاده می‌شود. این نوع داده نیز در پکیج sync پیاده‌سازی شده‌است.سپس به شرح channel پرداخته که از موارد مشتق شده از CSP است. Channelها برای ارتباط goroutine ها به کار گرفته می‌شوند. ساخت یک channel، نوشتن و خواندن داده‌های channel و چالش‌های پیش‌آمده و موارد استفاده از دستور select از جمله مباحث مطرح شده در این فصل هستند.فصل چهارم: Concurrency Patterns in Goاین فصل از فصول مهم اصلی کتاب است که به بررسی و توضیح الگوهای همروندی در golang می‌پردازد. نویسنده ابتدا با توضیح در مورد بحث confinement شروع می‌کند.Confinement is the simple yet powerful idea of ensuring information is only ever available from one concurrent processو در ادامه آن را به صورت کاربردی با استفاده از کدهای همروند در golang توضیح‌ می‌دهد. سپس الگوهایی از همروندی در golang را شرح می‌دهد. الگوهایی مانند:For-select loopOr-channelPipelines, fan-in, fan-outOr-done channelTee channelBridge channelفصل پنجم: Concurrency at Scaleدر این فصل به استفاده از concurrency در برنامه‌هایی در مقیاس بزرگ می‌پردازد و چالش‌های پیش‌رو در اینگونه برنامه‌ها را شرح داده و راه‌حل ارائه می‌کند.ابتدا مبحث Error Propagation در بین goroutineها مدنظر است. در این قسمت توضیح می‌دهد که چگونه ارورها از لایه‌های پایینی به سمت لایه‌های بالاتر ارسال شوند تا بتوانند اطلاعات لازم را به توسعه‌دهنده ارائه دهند.مبحث دوم در این فصل، چالش timeout و cancalation است که چگونه و در چه مواردی نیاز است که در یک سیستم همروند time out اتفاق افتد و در صورت بروز چنین اتفاقی چگونه می‌توان پراسس همروند را متوقف کرد.مبحث سوم که در اینجا مطرح شده، مربوط به heartbeat برای فرآیندهای همروند است. Heartbeat ها، روشی برای اعلام حیات به لایه‌های بالاتر هستند. در این قسمت نیز نویسنده، با ترکیب channelها و for-select loop راه‌حلی را ارائه می‌دهد.مبحث چهارم، در مورد Replicated Requsts در سیستم‌هایی است که دریافت پاسخ در کوتاهترین زمان ممکن از اولویت‌های آنها محسوب می‌شود. که این کار با استفاده از فرآیندهای همروند انجام شده و نیاز به کنترل فرایندها پس از رسیدن به پاسخ است.در مبحث پنجم به Rate Limiting پرداخته که از لحاظ امنیتی نیز حائز اهمیت است. برای شرح این مبحث، ابتدا یک rate limiter ساده را پیاده سازی کرده و سپس به پکیج ratelimiter در گولنگ پرداخته است.و در آخرین مبحث از این فصل، Healing Unhealthy goroutine مطرح شده است که به درگیر شدن goroutineها در موقعیت‌های بد اشاره می‌کند.فصل ششم: Goroutines and the Go Runtimeدر آخرین فصل، نویسنده به مدیریت goroutine ها و نحوه‌ی پخش شدن آنها بر روی OS thereadها پرداخته است. او استراتژی work stealing را معرفی کرده و برای توضیح این الگوریتم مثال‌هایی را بیان کرده است.و در آخر با وجود اینکه استفاده از goroutine ها در گولنگ بسیار ساده به نظر می‌رسد، ولی نویسنده در این کتاب ۲۲۰ صفحه‌ای مباحث پایه و پیشرفته‌ای را در این حوزه بیان کرده و هر کدام را به صورت عمیق و کاملا فنی توضیح داده است. وجیهه نیکخواه وجیهه نیکخواه Sun, 31 Mar 2024 11:54:30 +0330 https://virgool.io/@vajihe.nikkhah/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%DA%A9%D8%AA%D8%A7%D8%A8-microservice-patterns-%D9%82%D8%B3%D9%85%D8%AA-%DB%8C%DA%A9-rau99nzkg9p0 کتاب Microservie Patterns، به طور جامع به مفاهیم، الگوها، و رویکردهای کلیدی معماری میکروسرویس می‌پردازد و به خوانندگان کمک می‌کند تا در طراحی و پیاده‌سازی سیستم‌های نرم‌افزاری مبتنی بر میکروسرویس موفق عمل کنند. نویسنده در این کتاب سعی کرده با بیان الگوهای مختلف، مضرات و مزیت‌های هر یک را بیان کرده و روش‌های حل ایرادات را نیز توضیح دهد.این کتاب شامل ۱۳ بخش است که در اینجا به توضیح در مورد سه بخش اول آن که نگاه کلی‌تری دارد، می‌پردازم. شروع این کتاب، در مورد مهاجرت یک برنامه سفارش غذا از معماری مونولوتیک به معماری میکروسرویس است که در تمامی فصل‌ها، مثال‌ها بر پایه‌ی این نمونه است. در این کتاب از تکنولوژی یا فریم ورک خاصی استفاده نشده و برخلاف آنچه که در عنوان کتاب گفته شده، یعنی استفاده از جاوا، کدها به راحتی قابل درک هستند.فصل اول: فرار از جهنم مونولیتیکنویسنده در فصل اول کتاب، معماری مونولیتیک را توضیح می‌دهد. مزیت‌های این نوع معماری بیان شده ولی از دید ریچاردسون، در این معماری هر چه اپلیکیشن بزرگتر و فیچر‌های بیشتری به آن افزوده شود تبدیل به جهنمی می‌شود که توسعه‌ی آن کاری بسیار دشوار و زمانبر خواهد بود. در ادامه‌ی این فصل مزیت‌ها و ایرادات معماری میکروسرویس نیز بیان می‌شود. سپس معماری میکروسرویس با معماری SOA مقایسه می‌شود. یکی از تفاوت‌های معماری SOA با میکروسرویس، در دیتابیس مورد استفاده‌ی سرویس‌ها است. دیتابیس SOA، به صورت اشتراکی است ولی در معماری میکروسرویس، هر سرویس یک دیتابیس مخصوص خود را دارد.از دیگر تفاوت‌های این دو نوع معماری، سایز و تعداد سرویس‌هاست. در معماری SOA، تعداد کمی سرویس وجود دارد که هر کدام سایز بسیاری بزرگی دارند و خود، یک سرویس مونولیتیک به شمار می‌رود، ولی معماری میکروسرویس، حاوی تعداد بسیار زیادی سرویس است که سایز کوچکی دارند.نویسنده اشاره می‌کند که معماری میکروسرویس، یک راه حل طلایی و کاملا درست برای تمامی پروژه‌های نرم‌افزاری نیست بلکه باید مزیت‌ها و مضرات این معماری با توجه به پروژه مورد نظر بررسی شود.فصل دوم: استراتژی تقسیم سرویس‌هادر این فصل، نویسنده استراتژی‌های تقسیم یک پروژه مونولیتیک به چندین سرویس، با استفاده از مثال مربوط به نرم افزار سفارش غذا را، شرح داده و موانع موجود و راه‌حل‌های برطرف کردن آنها را بیان می‌کند.قبل از معرفی استراتژی‌های تقسیم سرویس‌ها، به تعریف معماری نرم‌افزار می‌پردازد و معماری یک سرویس نرم‌افزاری را بیان می‌کند. پیشنهاد نویسنده برای معماری سرویس‌های موجود در میکروسرویس‌ها، معماری hexagonal است.پس از آن نویسنده با تعریف سرویس، نقش shared libraryها در معماری میکروسرویس و ساخت یک domain model در سطح بالا، به معرفی روش‌های تفکیک سرویس‌ها در یک نرم‌افزار می‌پردازد.در این کتاب دو روش برای تفکیک سرویس‌ها معرفی شده‌است.تفکیک سرویس به واسطه‌ی قابلیت‌های کسب و کار (capability business)تفکیک سرویس از طریق Domain Driven Designبا استفاده از نمونه مورد مطالعه کتاب، این دو روش با جزئیات بیان و شرح داده شده است.از دید نویسنده با استفاده از دو اصل Single Responsibility Principle و Common Closure Principle می‌توان سرویس‌های بهتری طراحی کرد. با استفاده از SRP، سرویس‌هایی طراحی می‌شود که تنها و تنها یک وظیفه داشته باشند که باعث کوچکتر شدن و بالا رفتن پایداری سرویس می‌شود.و با توجه به اصل CSP، اگر تغییر یک قاعده و قانون مربوط به کسب و کار باعث تغییر بیش از یک سرویس شود، احتمالا آن سرویس‌ها باید با یکدیگر ادغام شوند.و در نهایت، در ادامه‌ی این فصل موانع و مشکلاتی که در نتیجه‌ی جداسازی سرویس‌ها به وجود می‌آید بررسی می‌شود.فصل سوم: ارتباط بین سرویس‌هادر این فصل چگونگی ارتباط سرویس‌ها به صورت مفصل مورد بررسی قرار می‌گیرد. این ارتباط از دو بعد تقسیم‌بندی شده‌است. در یک بعد، ارتباط یک به یک سرویس‌ها و ارتباط یک به چند سرویس‌ها مد نظر قرار گرفته است. در بعد دیگر، ارتباط synchronous و asynchronous را بیان می‌کند.و در ادامه‌ی این فصل به توضیح هر کدام از موارد بیان شده در جدول می‌پردازد.در ارتباط synchronous، تکنولوژی‌های REST و gPRC مطرح می‌شوند و مزیت‌ها و ایرادات هر کدام به تفصیل بیان می‌شود.در ارتباطات sync، به service discovery نیاز است زیرا نمی‌توان آدرس‌های IP هر سرویس را به صورت استاتیک تنظیم کرد و نیاز به مکانیزم داینامیک می‌باشد. تکنولوژی‌های service discovery به صورت client-side و server-side هستند که هر کدام به صورت مختصر در کتاب توضیح داده شده‌اند.در ارتباطات async، تکنولوژی message broker معرفی شده است و ارتباطات broker-base و brokerless شرح داده شده است.این کتاب، از جامع‌ترین کتاب‌ها در حوزه‌ی میکروسرویس است و الگوهای کاملی را برای هرکدام از چالش‌های این معماری بیان می‌کند که می‌توان در معماری‌های مختلف دیگر نیز استفاده کرد. در ادامه‌ی این کتاب الگوهایی مانند Saga و CQRS، تست میکروسرویس‌ها و توسعه‌ی آنها به تفصیل شرح داده شده است. وجیهه نیکخواه وجیهه نیکخواه Tue, 26 Mar 2024 23:20:11 +0330 https://virgool.io/@vajihe.nikkhah/%DA%A9%D8%AA%D8%A7%D8%A8-unit-testing-principles-practices-and-patterns-hfuzsglncet1 کتاب unit testing, principles, practices and patterns نوشته‌ی Vladimir Khorikov، در زمینه تست نویسی، دید خوبی در این حوزه به من داد. به همین دلیل تصمیم گرفتم در این نوشته به صورت مختصر این کتاب را معرفی کنم. این کتاب به مباحث پایه‌ای ‌مهمی در حوزه‌ی تست نویسی می‌پردازد. کتاب شامل چهار بخش است و هر بخش شامل چند فصل کوچکتر است.بخش اول کتاب، دورنمایی از یونیت تست را ارائه می‌دهد. نویسنده ابتدا به اهداف تست نویسی اشاره کرده و معیارهای پوشش کد و test suit ها را توضیح می‌دهد و در ادامه در مورد دو رویکرد بحث برانگیز یونیت تست صحبت می‌کند.این دو رویکرد classical و London schools نام دارند.بحث طرفداران این دو رویکرد، بر سر مسئله‌ی isolation در یونیت تست می‌باشد.در رویکرد london schools که mockist نیز نامیده می‌شود، اگر کلاس X به یک یا چند کلاس دیگر وابستگی داشته باشد، برای تست کلاس X، باید تمامی کلاس‌های وابسته mock شوند. در واقع تست هر کلاس باید مستقل از تست کلاس‌های دیگر باشد.ولی در رویکرد classical یا detroit schools، بحث isolation در مورد تست‌ها می‌‌باشد و نیازی به mock کردن تمامی وابستگی‌های یک کلاس نیست بلکه تنها وابستگی‌هایی mock می‌شوند که بین تست‌ها مشترک باشند مانند دیتابیس.این نویسنده از طرفداران رویکرد classical unit testing می‌باشد و به نظر او برای نوشتن unit test باید بر روی عملکرد تمرکز کرد، نه چگونگی پیاده‌سازی کد و در نتیجه نیازی نیست که برای تمامی وابستگی‌های یک کلاس، mock تعریف کرد. در این راستا نوع وابستگی‌ها را در کتاب تعریف کرده و نحوه‌ی به کاربردن آنها در یونیت تست را توضیح می‌دهد.در ادامه‌ی این بخش، به طور مفصل آناتومی یک یونیت تست را توضیح داده است.بخش دوم که مهمترین بخش این کتاب به شمار می‌رود، به توضیح تست‌های خوب و باارزش می‌پردازد.یکی از نقاط تمرکز این کتاب، بر روی نوشتن تست خوب و توضیح در مورد شکنندگی تست‌ها می‌باشد. بر اساس این کتاب، یک تست خوب، چهار ویژگی دارد.Protection against regressionsبا افزون فیچر‌های جدید، تست بتواند باگ‌های احتمالی به وجود آمده در فیچر‌های قبلی را پیدا کند.Resistance to refactoringبا ریفکتور کردن کد تحت تست، تست‌های مورد نظر نیاز به تغییر نداشته باشند.Fast feedbackتست از سرعت اجرای بالایی برخوردار باشد.Maintainabilityتست قابلیت خوانایی بالا داشته باشد و به راحتی قابل اجرا باشد.برای باز کردن چنین مبحثی، به دسته بندی و توضیح mock پرداخته و شکنندگی تست‌ها را مورد بررسی قرار داده است. در نهایت نیز انواع مختلف یونیت تست با توجه به چهار اصل بالا را شرح داده است.در فصل سوم به معرفی integration test پرداخته و در مورد وابستگی‌های نیازمند mock شدن در تست به صورت مفصل توضیح داده است. تست دیتابیس نیز از مباحث مهم بیان شده در این فصل است.در فصل چهارم نیز الگوهای غلط در حوزه‌ی تست نویسی را توضیح می‌دهد.از دیدگاه نویسنده لزوما تست نویسی منجر به محصولی با کیفیت و بدون خطا نخواهد شد و پروژه‌های بسیاری وجود دارند که با وجود داشتن تست‌، با شکست مواجه شده‌اند. یکی از نقاط تمرکز این کتاب، بر روی نوشتن تست خوب است. وجیهه نیکخواه وجیهه نیکخواه Fri, 22 Mar 2024 17:45:29 +0330