مهندسی بکاند
طراحی و توسعه سیستمهای بکاند مناسب محیط عملیاتی، با قراردادهای روشن، یکپارچهسازیهای مقاوم و مرزبندی قابل نگهداری بین سرویسها.
GoLaravel / PHPREST APIsData Modeling
آماده گفتوگو درباره چالشهای مهندسی
مهندس نرمافزار · مهندسی بکاند · رهبری فنی
سیستمهایی میسازم
که بتوانند رشد کنند.
سیستمهای بکاند مقیاسپذیر میسازم، نرمافزارهای قدیمی را نوسازی میکنم و نیازهای پیچیده محصول را به معماری قابل نگهداری تبدیل میکنم.
+۱۰سال تجربه توسعه وب
Goتوسعه بکاند و سرویس
Leadمعماری و جهتدهی فنی
رامین اسماعیلزادمهندس نرمافزار و رهبر فنیچیزی که برایم مهم است
نرمافزار خوب باید در برابر تغییر دوام بیاورد؛ قابلیتهای جدید، یکپارچهسازیهای تازه، اعضای جدید تیم، الگوهای ترافیکی متفاوت و محدودیتهای جدید کسبوکار.
تخصصهای اصلی
از کد بکاند تا سیستمی که اطراف آن شکل میگیرد.
تمرکز من جایی است که مهندسی بکاند، معماری، نوسازی، آمادگی Production و رهبری فنی به هم میرسند.
معماری سیستم
معماری عملی که وابستگیها را کاهش میدهد، مسئولیتها را شفاف نگه میدارد و بدون پیچیدگی غیرضروری از رشد محصول پشتیبانی میکند.
Modular MonolithMicroservicesIntegration DesignS3-compatible Storage
نوسازی سیستمهای قدیمی
نوسازی مرحلهای سیستمهای موجود با حفظ رفتار معتبر، قراردادهای API و تداوم کسبوکار.
RefactoringMigration StrategyBackward CompatibilityRisk Reduction
مهندسی محیط عملیاتی
نرمافزار با Merge شدن تمام نمیشود؛ تحویل، مشاهدهپذیری، آمادگی سرویس، پیکربندی و مدیریت وابستگیها بخشی از طراحی هستند.
DockerCI/CDRedisRabbitMQ
رهبری فنی
اتصال هدف محصول به اجرای فنی از طریق تصمیمهای معماری، استانداردهای مهندسی، منتورینگ و برنامهریزی تحویل.
Team LeadershipTechnical DirectionCode QualityDelivery
مهندسی محصول
تبدیل نیازهای مبهم محصول به مدل داده، جریانها، APIها، نقاط عطف و نقشه راه فنی قابل اجرا.
Product DiscoveryAPI ContractsRoadmappingSystem Design
رویکرد مهندسی
اول اصول، بعد الگوها.
تصمیمهایی را ترجیح میدهم که فهم، نگهداری، عملیات و تغییر نرمافزار را آسانتر کنند؛ حتی اگر گزینه مد روز در نگاه اول سریعتر به نظر برسد.
اول سازگاری با نسخههای قبلی
هنگام نوسازی یک سیستم موجود، تا جای ممکن قراردادها و رفتارهای معتبر را حفظ میکنم تا تغییر کنترلشده بماند و ریسک مهاجرت قابل اندازهگیری باشد.
محیط عملیاتی بخشی از مهندسی است
Docker، health check، readiness، CI/CD، مدیریت وابستگی، پیکربندی و رفتار در زمان خطا باید از ابتدا بخشی از گفتوگوی مهندسی باشند.
معماری به مرزهای روشن نیاز دارد
معماری خوب به معنی اضافه کردن لایههای بیشتر نیست؛ یعنی مسئولیتها روشن باشند، وابستگی ناخواسته کم شود و فضای امنی برای تغییر ایجاد شود.
قبل از بازنویسی اندازه بگیر
پیش از انتخاب بازنویسی کامل، قراردادها، هزینه مهاجرت، ریسک عملیاتی و حالتهای شکست را بررسی میکنم. در بسیاری از موارد تغییر مرحلهای تصمیم مهندسی قویتری است.
حوزههای منتخب
مسائلی که از حل کردنشان لذت میبرم.
تمرکز من کمتر روی صنعت خاص و بیشتر روی سیستمهایی با محدودیت واقعی است؛ کاربران موجود، یکپارچهسازیها، داده، استقرار و تیمی که باید همزمان به حرکت ادامه دهد.
نوسازی سرویسهای قدیمی
ریفکتور سرویسهای قدیمی به سمت پیادهسازیهای تمیزتر مبتنی بر Go، زیرساخت تحویل قویتر، قراردادهای روشنتر و رفتار عملیاتی امنتر.
معماری پلتفرم محصول
طراحی سیستمهای ماژولار برای محصولاتی با چند دامنه تا قابلیتهای جدید بدون بیثبات کردن مداوم هسته رشد کنند.
طراحی API و یکپارچهسازی
طراحی قراردادهای قابل پیشبینی API، یکپارچهسازیهای غیرهمزمان، جریانهای پیاممحور، استراتژیهای Cache و مرزهای Object Storage.
توسعه فنی محصول
تبدیل پیچیدگی محصول به مدل داده، مرز سرویسها، فازهای تحویل و برنامه اجرایی که تیم مهندسی بتواند آن را پیاده کند.
یادداشتهای مهندسی
ایدههایی از ساخت و نوسازی نرمافزار.
سازگاری با نسخههای قبلی یک قابلیت محصول است
چرا حفظ قراردادهای معتبر میتواند یکی از مهمترین تصمیمها در نوسازی یک سیستم قدیمی باشد.
مطالعه یادداشت ←محیط عملیاتی بخشی از مهندسی است
چرا health check، پیکربندی، CI/CD، وابستگیها و حالتهای شکست باید همزمان با خود برنامه طراحی شوند.
مطالعه یادداشت ←معماری به مرز نیاز دارد، نه لایههای بیشتر
نگاهی عملی به ماژولاریتی، coupling و انتخاب ساختار بر اساس تغییر، نه مد روز.
مطالعه یادداشت ←با یک سیستم پیچیده روبهرو هستید؟
بیایید تغییر دادنش را سادهتر کنیم.
نوسازی بکاند، معماری، طراحی API، زیرساخت Production یا جهتدهی فنی؛ از خود مسئله شروع کنیم.
شروع گفتوگو ↗