معمولاً وقتی کد یک پروژه را می‌خوانم، می‌توانم بفهمم چه کاری انجام می‌دهد. سؤال سخت‌تر این است که چرا به این شکل نوشته شده.
چرا یک API به این صورت طراحی شده و نه شکل دیگری؟ چرا یک ابزار CLI بسته به نحوهٔ استفاده، رفتار متفاوتی دارد؟ چرا در بخشی از یک سیستم از یک لایهٔ انتزاعی استفاده کرده‌ایم، اما در بخش دیگری ترجیح داده‌ایم کد صریح‌تر باشد و چیزی پشت abstraction پنهان نشود؟
جواب این سؤال‌ها همیشه از روی کد مشخص نیست.
از سال ۱۳۹۲ به‌صورت حرفه‌ای برنامه‌نویسی می‌کنم و در این سال‌ها با توسعهٔ Backend، زیرساخت و ابزارهای توسعه‌دهندگان سروکار داشته‌ام. یکی از چیزهایی که در این مسیر یاد گرفته‌ام این است که فهمیدن دلیل یک تصمیم فنی، اغلب از فهمیدن نحوهٔ پیاده‌سازی آن ارزشمندتر است.
مهندسی نرم‌افزار پر از trade-off است.
یک abstraction خوب می‌تواند کار با سیستم را ساده‌تر کند، اما ممکن است جزئیات مهمی را هم پنهان کند. یک رفتار پیش‌فرض مناسب می‌تواند تجربهٔ توسعه‌دهنده را بهتر کند، ولی در عین حال فهمیدن بعضی رفتارهای سیستم را دشوارتر کند. راه‌حلی که برای یک تیم عالی کار می‌کند، ممکن است برای تیم دیگری انتخاب مناسبی نباشد.
به‌ندرت می‌توان یک راه‌حل کاملاً بی‌نقص پیدا کرد. بیشتر تصمیم‌ها به شرایط، محدودیت‌ها و چیزهایی بستگی دارند که حاضریم در ازای رسیدن به نتیجه از آن‌ها صرف‌نظر کنیم.
این‌ها موضوعاتی هستند که می‌خواهم در این وبلاگ درباره‌شان بنویسم.
گاهی دربارهٔ مشکلی فنی که با آن روبه‌رو شده‌ام می‌نویسم، گاهی دربارهٔ ابزاری که ساخته‌ام یا تصمیمی که هنگام طراحی یک سیستم گرفته‌ام. بعضی نوشته‌ها کاملاً فنی خواهند بود و بعضی دیگر دربارهٔ یک آزمایش، یک تصمیم طراحی یا حتی چیزی که قبلاً به آن اعتقاد داشته‌ام و حالا نظرم تغییر کرده است.
احتمالاً بخش زیادی از این نوشته‌ها به Go، طراحی API، Platform Engineering، Kubernetes و ابزارهای توسعه‌دهندگان مربوط می‌شوند. اما همیشه خود فناوری مهم‌ترین بخش ماجرا نیست.
چیزی که برایم اهمیت بیشتری دارد، دلایل پشت انتخاب‌هاست.
چرا یک راه را به راه دیگری ترجیح داده‌ام؟ چه گزینه‌های دیگری وجود داشته؟ چه چیزی خوب پیش رفته، چه چیزی نه، و اگر امروز دوباره با همان مسئله روبه‌رو شوم، چه تصمیمی می‌گیرم؟
نوشتن برای خودم هم فرصتی است تا دقیق‌تر فکر کنم. وقتی تلاش می‌کنم دلیل یک تصمیم را توضیح بدهم، گاهی متوجه فرض‌هایی می‌شوم که قبلاً چندان به آن‌ها توجه نکرده بودم.
دوست دارم این وبلاگ جایی باشد برای ثبت همین مسیر؛ همراه با اشتباه‌ها، تجربه‌ها، چیزهایی که یاد گرفته‌ام و گاهی تغییر دیدگاهم نسبت به یک موضوع.
اگر این نوشته‌ها به مهندس دیگری هم کمک کنند که مسئله‌ای مشابه را از زاویهٔ متفاوتی ببیند، چه بهتر.