<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های محمدرضا امینی</title><link>https://virgool.ir/feed/@amino</link><description></description><language>fa</language><pubDate>2026-11-11 19:35:20</pubDate><image><url>https://files.virgool.ir/upload/users/40209/avatar/XzW2yC.png</url><title>محمدرضا امینی</title><link>https://virgool.ir/@amino</link></image><item><title>ابهام زدایی Dependency Injection</title><link>https://virgool.ir/@amino/dependency-injection-kbozbmyolefi</link><description>stackifyوقتی اولین بار اسم «Dependency Injection» رو شنیدم با خودم فکر کردم چه چیز پیچیده‌ایه. اما وقتی فرصتش رو پیدا کردم که ببینم مردم راجع به چی صحبت می‌کنن، با خودم گفتم همش همینه؟ا Dependency Injection لفظ سنگینیه برای یه مفهوم ساده. یه اسم بد برای یه ابزار خوب. اما مقالات برتر گوگل از الفاظ و روش های پیچیده‌ای برای توضیح این مفهوم استفاده کردن. به نظرم اومد بهتره این موضوع رو به صورت ساده‌تر بیان کنم.نسخه خیلی کوتاها Dependency Injection به این معنیه که به یک آبجکت اینستنس متغیرهاش رو پاس بدیم. همین!نسخه کمی بلندتر، قسمت ۱: اینجکت نکردن دیپندنسیکلاس‌ها چیزهایی دارن که بهشون می‌گیم متد. بیاید اسمشون رو بذاریم «Dependency». بیشتر مردم بهشون می‌گن متغیر.public class Example {&#xA;  private DatabaseThingie myDatabase;&#xA;&#xA;  public Example() {&#xA;    myDatabase = new DatabaseThingie();&#xA;  }&#xA;&#xA;  public void DoStuff() {&#xA;    ...&#xA;    myDatabase.GetData();&#xA;    ...&#xA;  }&#xA;}اینجا ما یک متغیر، چیز، Dependency داریم به اسم myDatabase. که توی کانستراکتور مقداردهی اولیه‌ش می‌کنیم.نسخه کمی بلندتر، قسمت ۲: دیپندنسی اینجکشناگر می‌خواستیم می‌تونستیم متغیر رو به کانستراکتور پاس بدیم. در این صورت dependency رو به کلاس inject می‌کردیم. حالا وقتی که از متغیر (dependency) استفاده می‌کنیم، داریم به جای اونی که ساختیم از اونی که بهمون داده شده استفاده می‌کنیم.public class Example {&#xA;  private DatabaseThingie myDatabase;&#xA;&#xA;  public Example() {&#xA;    myDatabase = new DatabaseThingie();&#xA;  }&#xA;&#xA;  public Example(DatabaseThingie useThisDatabaseInstead) {&#xA;    myDatabase = useThisDatabaseInstead;&#xA;  }&#xA;&#xA;  public void DoStuff() {&#xA;    ...&#xA;    myDatabase.GetData();&#xA;    ...&#xA;  }&#xA;}و این همه‌ی چیزیه که وجود داره. بقیه‌ی ماجرا تفاوت‌های ساختاری و شکل و شمایله. شما می‌تونید dependency (متغیر) رو توی یک متد setter مقداردهی کنید. شما می‌تونید dependency رو با صدا زدن یک متد setter که توی یک اینترفیس به خصوص تعریف شده مقداردهی کنید. شما می‌تونید dependency رو یک اینترفیس کنید و بعد به صورت پلی مورفیسم مقادیر رو پاس بدید. هرچی.نسخه کمی بلندتر، قسمت ۳: چرا این‌کار رو می‌کنیم؟علاوه بر چیزهای دیگه، این کار برای ایزوله کردن کلاس‌ها زمان تست به درد می خوره.public class ExampleTest {&#xA;  TestDoStuff() {&#xA;    MockDatabase mockDatabase = new MockDatabase();&#xA;&#xA;    // MockDatabase is a subclass of DatabaseThingie, so we can&#xA;    // &#34;inject&#34; it here:&#xA;    Example example = new Example(mockDatabase);&#xA;&#xA;    example.DoStuff();&#xA;    mockDatabase.AssertGetDataWasCalled();&#xA;  }&#xA;}&#xA;&#xA;public class Example {&#xA;  private DatabaseThingie myDatabase;&#xA;&#xA;  public Example() {&#xA;    myDatabase = new DatabaseThingie();&#xA;  }&#xA;&#xA;  public Example(DatabaseThingie useThisDatabaseInstead) {&#xA;    myDatabase = useThisDatabaseInstead;&#xA;  }&#xA;&#xA;  public void DoStuff() {&#xA;    ...&#xA;    myDatabase.GetData();&#xA;    ...&#xA;  }&#xA;}همینه. Dependency injection در واقع پاس دادن یک اینستنس متغیره.اطلاعات بیشترراه‌های زیادی هست که بشه این موضوع ساده رو پیچیده کرد. (راه‌‌های زیادی هست که بشه هر موضوعی رو پیچیده کرد! سادگی سخته.) بعضی زمان‌ها همچین پیچیدگی‌ای لازمه... و این هیچ‌وقت اتخاب اول من نیست. من تصمیم گرفتم که این پیچیدگی‌ها رو اینجا عنوان نکنم، اما اگه شما واقعا می‌خواید بدونید، این منابع رو چک کنید:Inversion of Control Containers and the Dependency Injection PatternA Beginner’s Guide to Dependency Injection</description><category>محمدرضا امینی</category><author>محمدرضا امینی</author><pubDate>Mon, 31 Jan 2022 15:01:39 +0330</pubDate></item><item><title>برنامه نویس هایی که دیگه دوست ندارم باهاشون کار کنم</title><link>https://virgool.ir/@amino/the-types-of-programmers-i-dont-want-to-work-with-again-rxwuxqo6kx31</link><description>تصویر از آنسپلش در طول سال‌های کارم با تعداد زیادی از برنامه‌نویس‌ها کار کردم و اینجا می‌خوام بعضی از الگوهایی رو بهتون بگم که بارها دیدمشون و هیچ‌وقت از شدت آزاردهندگیشون کم نشده!دو قدم جلوترپس از دو ماه کارآموزی فهمیدم دنیای برنامه نویسی از دو جریان جداگانه تشکیل شده: جریانی که من به شوخی اونو برنامه نویسی تو دنیای واقعی می‌نامم که از اونچه دارن بهترین استفاده رو می‌کنن و جریانی که مبتنی بر نوآوریه و فناوری جدید رو پیش روش می‌بینه و سعی می‌کنه مجوز دور ریختن کل معماری و از نو ساختنش رو بگیره. البته هر دو این افراط‌ها دارای نقص هستن، نقطه تعادل هم در وسط به طور مداوم تغییر می‌کنه.یک همکار داشتم که حداقل یک بار در روز به شوخی بهمون می‌گفت: «همتون مثل حیوون وحشی کد می‌زنین.» که البته کم‌کم لحن طنزش رو از دست داد و خیلی جدی می‌گفتش؛ در نهایت دیگه چیزی در این مورد نگفت.چون من کارم رو از پایه شروع کردم، می‌دونم اونطرف این دسته بودن چه حسی داره. این که دائما در حال دنبال کردن دنیایی باشی که بسیار دور از واقعیته باعث می‌شه مجبور بشی همیشه در حال کار باشی.این روش درست ایجاد نوآوری نیست.تنبل نخود هر آشاین نوع با مهارت از کلمات قلمبه سلمبه برای جبران بازده بسیار کم خود استفاده می‌کنن. همه ما گاهی جلساتمون رو با چرت و پرت گفتن از سر می‌گذرونیم، هممون گاهی در اون زمان‌های نادری که کوهی از کار جلومونه و همه چیز به مانع برخورد می‌کنه نیاز به کشتن زمان و «ران کردن کوئری‌های دیتابیس» داریم.اما این نوع برنامه‌نویس‌ها در زندگی فقط یک وظیفه دارن: مصرف بیشترین زمان و انجام کمترین کار بدون اخراج شدن. این افراد به سرعت شروع به از بین بردن روحیه‌ی تیم می‌کنن چون همه به فکر فرو می‌رن چرا باید سخت کار کنن در شرایطی که به نظر میاد نیازی نیست.تیم لید نابلدبهترین رئیس‌ها به تجربه‌ی من برنامه‌نویس‌های سابقی هستن که پذیرفتن زمانی که کد زدن رو کنار بذارن دنیا ادامه پیدا می‌کنه. این یعنی فردی که دانش فنی داره اما فکر نمی‌کنه همه چیز رو می‌دونه و از شما سوالاتی درمورد دنیای واقعی می‌پرسه و یا شما رو با خودش به جلسات می‌بره تا در صورت لزوم اطلاعات دقیق ارائه بدید. این می‌تونه یه تیم رویایی رو بسازه و چون من با همچین افرادی کار کردم می‌دونم که وجود دارن.و همچنین برنامه‌نویس‌های سابقی رو داریم که فکر می‌کنن همه چیز رو می‌دونن - که می‌تونه برای چند وقت جواب بده - و خب سمت دیگه‌ی ماجرا افرادی هستن که هیچ ایده‌ای ندارن چه اتفاقی داره میوفته.کمال‌گرای غیر طبیعیهمه این نوع رو می‌شناسن و گاهی اوقات همان چیزی هستن که نیاز داریم. یک معمار نرم‌افزار که کمال‌گرا نیست فریمورک‌هایی رو انتخاب می‌کنه که همه رو برای سال‌ها دچار مشکل می‌کنه.اما برنامه‌نویس‌های دیگه‌ای وجود دارن که تو زمانی که بقیه کل برنامه رو می‌نویسن، یک تابع رو می‌نویسن و اغلب کارشون به مقداری ارزشمنده که انگار سهم اون‌ها کل پروژه رو نجات داده.آن‌ها پول ریکوئست‌ها رو روزها نگه می‌دارن، و سپس براتون یه پیشنهاد کاملا از نو نوشته شده می‌فرستن که جذاب‌تر از کد شماست و راهی ندارید جز این که اون‌ها رو بپذیرید و سپس بالاخره می‌تونید کثافتی رو که پشت سرتون با یک باگ رفع نشده جا گذاشتید برطرف کنید.انحصارگراانواع دیگه‌ای که در ادامه توضیح می‌دم آزار دهنده هستن، اما همچنین می‌تونن افراد خوبی برای تیم باشن. انحصارگرا تنها نوعیه که به طور مداوم باعث می‌شه من خشونت رو در نظر بگیرم، چون اونا بدون هیچ رحمی به همه آزار می‌رسونن.مثلا انحصارگرای لینوکس/ویندوز یا اون‌هایی که اصرار دارن که یک تکست ادیتور به دیگری برتره و بهتون کمک نمی کنن تا وقتی که همون رو روی سیستمتون نصب کنین.نمی دونید چقدر عصبانی می‌شم هر زمانی که به صورت از خود راضی یکیشون نگاه می‌کنم که نسبت به انتخاب های ناچیزی که انجام دادن احساس غرور می کنن.رازداریک سوال بپرسید و چیزی که می‌شنوید -- سکوت. درخواست کمک کنید و اونها بهتون می‌گن کجا می‌تونید داکیومنتیشن مناسب رو پیدا کنید و خودتون انجامش بدید، اونا نمی‌تونن همه کار رو براتون بکنن!باید به زور این نوع افراد رو مجبور به دادن اطلاعات کنید. زمان‌هایی بودن که مجبور بودم رئیسم رو با خودم ببرم تا بتونم یه مکالمه راحت درباره رفع کردن یک مشکل هزینه‌بر داشته باشم.من به این معتقدم که شفافیت یکی از بهترین قسمت‌ها در مورد برنامه نویسیه، نه بدترین. من مشکلات زیادی رو برطرف کردم دقیقاً به این دلیل که می‌تونم به مخازن بقیه دسترسی داشته باشم و منبع خطایی رو که در برنامه من ظاهر شده بود پیدا کنم.درنهایت: استخدام شدن به عنوان برنامه‌نویس قدرت و انتخاب‌های زیادی رو در اختیار شما قرار می‌ده، از اون هوشمندانه استفاده کنیدامیدوارم این یک مرور جالب درباره برخی از برنامه‌نویس‌ها باشه که حداقل تا حدی به تلاش تیمی آسیب می رسونن.وقتی شرایط سخت می‌شه این افراد بد باعث می‌شون افراد خوب تیم خود را عوض کنن یا حتی بدتر از اون تا پایان کار همونجا بمونن.برگرفته از مدیوم</description><category>محمدرضا امینی</category><author>محمدرضا امینی</author><pubDate>Mon, 01 Mar 2021 16:51:10 +0330</pubDate></item></channel></rss>