مهندس نرم‌افزارپاسخ‌های مصاحبه

رویکرد من به مسائل فنی پیچیده از یک چارچوب ساخت‌یافته پیروی می‌کند که طی سال‌ها کار مهندسی آن را پالایش کرده‌ام. مرحلهٔ 1 — قبل از کدنویسی واضح‌سازی. سوالاتی می‌پرسم تا دامنهٔ کامل را بفهمم: محدودیت‌ها، نیازمندی‌های مقیاس، معیارهای موفقیت و حالت‌های لبه. مسئله‌ای که به‌درستی درک نشده باشد منجر به راه‌حل‌های زیبا برای موضوع اشتباه می‌شود. وقتی وضوح به‌دست آمد، من: - مسئله را به اجزای کوچک‌تر و مستقلاً قابل حل تقسیم می‌کنم - الگوها، کتابخانه‌ها یا سابقه‌های موجود که کاربرد دارند را شناسایی می‌کنم - قبل از نوشتن هر کد، طراحی سطح‌بالایی را روی کاغذ یا تخته رسم می‌کنم - برای اعتبارسنجی منطق، شبه‌کد می‌نویسم قبل از پیاده‌سازی - به‌صورت افزایشی پیاده‌سازی می‌کنم و در هر مرحله تست‌ها را اجرا می‌کنم مثال واقعی: وقتی ماموریت داشتم که زمان پاسخ API ما را از 2.4 ثانیه به زیر 500ms کاهش دهم، فوراً وارد بهینه‌سازی نشدم. ابتدا چرخهٔ کامل درخواست را پروفایل کردم و متوجه شدم 80% تاخیر از سه پرس‌وجوی دیتابیس N+1 ناشی می‌شود. اصلاح همین موارد به‌تنهایی زمان پاسخ را به 340ms رساند — بدون دست زدن به لایهٔ اپلیکیشن. قاعده من: مهندسی نرم‌افزار خوب 60% تفکر و 40% تایپ کردن است. پس از پیاده‌سازی، با نیازمندی‌های اولیه اعتبارسنجی می‌کنم، بازبینی همتا انجام می‌دهم و تصمیمات کلیدی را برای تیم مستندسازی می‌کنم. مسائل پیچیده همچنین فرصت‌های یادگیری‌اند — من یادداشت‌های کوتاه پساکار (post-mortem) می‌نویسم تا آنچه دفعهٔ بعد متفاوت انجام می‌دهم ثبت شود.

کیفیت کد در یک تیم یک چالش سیستمی است، نه صرفاً یک موضوع شخصی. رویکرد من در سه سطح عمل می‌کند: فرآیند، ابزار و فرهنگ. فرآیند: - بازبینی همتا اجباری برای هر pull request — بدون استثنا، حتی برای مهندسان ارشد - بازبینی‌هایی که مشخص و سازنده هستند، نه صرفاً تایید: «این حلقه O(n²) است — این‌جا چگونه آن را به O(n) کاهش دهیم» - توسعه مبتنی بر تست در موارد مناسب؛ حداقل، تست‌ها همزمان با کد نوشته شوند، نه به‌عنوان بعداً - بازبینی پس از رخداد (post-incident reviews) برای ساخت دانش مشترک وقتی چیزی در تولید خراب می‌شود ابزار: - linters (ESLint, Pylint) و formatterها (Prettier, Black) که در CI اعمال می‌شوند — اختلافات سبک یک شبه از بین می‌روند - تحلیل ایستا و اسکن امنیتی در pipeline (SonarQube, Snyk) - آستانه‌های پوشش تست که اگر پوشش واحد از حد توافق‌شده پایین‌تر بیاید، build را ناموفق می‌کنند مثال واقعی: در شرکت قبلی‌ام، نرخ باگ در تولید 23% بود. من بازبینی‌های اجباری PR با یک چک‌لیست بازبینی معرفی کردم، ESLint و یک pre-commit hook اضافه کردم، و جلسه‌ای درباره نوشتن کد قابل تست برگزار کردم. ظرف دو sprint، نرخ باگ به 7% کاهش یافت و فرکانس استقرار افزایش پیدا کرد. بخش فرهنگی به همان اندازه مهم است — من بازبینی کد را به‌عنوان مربی‌گری (mentoring) نه انتقاد قاب‌بندی می‌کنم، که مهندسان را پذیراتر به جای دفاعی نگه می‌دارد.

بازسازی کد قدیمی یکی از فعالیت‌های پرریسک و در عین حال پرفایده در مهندسی نرم‌افزار است. رویکرد من ایمنی را بر سرعت اولویت می‌دهد. وضعیت: به تیمی ملحق شدم که یک مونو‌لیث 7 ساله را نگهداری می‌کرد؛ پوشش تست صفر، وابستگی شدید بین ماژول‌ها و هیچ مستندسازی. هر تغییر چیزی غیرمنتظره را می‌شکست. رویکرد من: - ابتدا تست‌های تمیزکننده رفتار (characterisation tests) — قبل از تغییر هر چیز، تست‌هایی نوشتم که رفتار فعلی (گاهی اشتباه) را ثبت می‌کردند. این نِت ایمنی ایجاد کرد. - الگوی Strangler Fig — به جای بازنویسی «big bang»، یک ماژول را در هر بار جایگزین کردم در حالی که سیستم در تولید کار می‌کرد - Architecture Decision Records (ADRs) — هر تصمیم مهم را به‌همراه دلایلش مستندسازی کردم تا تیم «چرایی» تغییرات را بفهمد - feature flags — پیاده‌سازی‌های جدید پشت فلگ اجرا می‌شدند تا در صورت بروز مشکل بتوان فوراً بازگشت داد نتیجه: ظرف شش ماه از 0% به 75% پوشش تست رسیدیم، میانگین زمان استقرار را از 45 دقیقه به 8 دقیقه کاهش دادیم و دو دسته از باگ‌های تکرارشونده در تولید را حذف کردیم. در طول کل بازسازی، هیچ زمان خاموشی برنامه‌ریزی‌نشده‌ای نداشتیم. درس کلیدی: بازسازی را به‌عنوان یک انضباط مداوم در نظر بگیرید، نه یک پروژهٔ یک‌باره. ما 20% هر sprint را به کاهش بدهی فنی اختصاص دادیم که باعث شد پایگاه کد در هر چرخه به‌تدریج سالم‌تر شود.

به‌روز ماندن یک انضباط شغلی است — و در عین حال باید از «شینِی‌آبجکت سندروم» اجتناب کرد. رویکرد من بین یادگیری و ارزیابی انتقادی تعادل برقرار می‌کند. منابع منظم من: - بلاگ‌های مهندسی: Spotify Engineering، Netflix Tech Blog، GitHub Engineering — این‌ها تصمیمات دنیای واقعی در مقیاس را پوشش می‌دهند - پادکست‌ها: Software Engineering Daily، Changelog، و The Stack Overflow Podcast هنگام رفت‌وآمد - بحث‌های RFC و پروپوزال برای زبان‌ها و فریم‌ورک‌هایی که به‌صورت حرفه‌ای استفاده می‌کنم - مخازن trending در GitHub و release notes برای استک هسته‌ام (هفتگی) چطور تکنولوژی جدید را ارزیابی می‌کنم: - قبل از پیشنهادش در محل کار، یک پروژهٔ جانبی کوچک با آن می‌سازم — استفادهٔ واقعی محدودیت‌هایی را نشان می‌دهد که پست‌های وبلاگی نمی‌گویند - سلامت جامعه را بررسی می‌کنم: فعالیت روی GitHub، پاسخ‌ها در Stack Overflow، حامیان شرکتی، و فرکانس تغییرات مخرّب - سوال می‌پرسم: آیا این مشکل واقعی ما را حل می‌کند، یا فقط مشکلی است که جالب به‌نظر می‌رسد؟ مثال: وقتی edge computing روند شد، یک آخر هفته صرف ساخت یک دموی کوچک با Cloudflare Workers کردم قبل از پیشنهادش برای لایهٔ کش CDN. زمان دست‌زنی محدودیتی کلیدی نشان داد — دسترسی به سرویس احراز هویت داخلی‌مان ممکن نبود — که اگر مستقیماً به تولید می‌رفتیم، هفته‌ها طول می‌کشید تا کشف شود. همچنین هر فصل جلسات "tech radar" داخلی با تیم برگزار می‌کنم تا به‌صورت جمعی تکنولوژی‌ها را در دسته‌های adopt, trial, assess, یا hold ارزیابی و دسته‌بندی کنیم.

هر دو REST و GraphQL همان مشکل بنیادین را حل می‌کنند — فراهم کردن داده روی HTTP — اما معامله‌های بسیار متفاوتی انجام می‌دهند. REST (Representational State Transfer): - اندپوینت‌های مبتنی بر منابع: GET /users/42، POST /orders - پاسخ‌ها تعریف‌شده توسط سرور هستند — کلاینت همان چیزی را می‌گیرد که سرور تصمیم می‌گیرد بازگرداند - پشتیبانی عالی از کشینگ HTTP (ETags، Cache-Control به‌صورت طبیعی کار می‌کنند) - ساده برای درک، مستندسازی (OpenAPI/Swagger) و تست - ممکن است از over-fetching (دریافت دادهٔ بیش از حد) یا under-fetching (نیاز به چندین درخواست) رنج ببرد GraphQL: - یک اندپوینت؛ کلاینت دقیقاً فیلدهایی را که نیاز دارد تعریف می‌کند - over-fetching و under-fetching را در یک درخواست از بین می‌برد - schema با نوع‌بندی قوی مانند مستندات زنده عمل می‌کند - کشینگ HTTP سخت‌تر است؛ نیاز به کشینگ در سطح query یا persisted queries دارد - هزینهٔ راه‌اندازی اولیه بالاتر؛ مشکلات N+1 نیاز به الگوهایی مثل DataLoader دارند زمان انتخاب هر کدام: - REST: CRUD ساده، APIهای عمومی، میکروسرویس‌ها با قراردادهای مشخص، وقتی کشینگ حیاتی است - GraphQL: کلاینت‌های موبایل که باید اندازهٔ payload را کم کنند، داشبوردهایی با نیازهای دادهٔ ناهمگون، الگوهای BFF (Backend for Frontend)، و زمانی که نیازهای دادهٔ فرانتند سریع تغییر می‌کند تصمیم واقعی: برای اپ موبایل‌مان از REST به GraphQL مهاجرت کردیم و میانگین اندازهٔ payload را 62% کاهش دادیم، که زمان بارگذاری صفحه روی شبکهٔ 3G را 1.1 ثانیه کاهش داد — بهبود قابل‌توجه UX در بازار هدف ما (بازارهای در حال توسعه).

مدیریت خوب مسائل عملکردی در تولید اساساً دربارهٔ داشتن زیرساخت مشاهده‌پذیری قبل از وقوع مشکل و یک فرایند تشخیصی روشن هنگام بروز آنهاست. قبل از بروز مشکل — ابزارهای اندازه‌گیری: - tracing توزیع‌شده (Jaeger یا AWS X-Ray) برای ردیابی تاخیر در مرزهای سرویس - ابزارهای APM (Datadog یا New Relic) برای متریک‌ها و نرخ خطا در سطح اپلیکیشن - لاگ‌گذاری ساخت‌یافته با request IDها تا بتوانم مسیر یک کاربر واحد را در سیستم ردیابی کنم - SLOها با alerting — تا قبل از شکایت کاربران از تخریب آگاه شوم وقتی مسئلهٔ عملکردی ظاهر می‌شود: - ابتدا بازتولید کن — هرگز بدون یک کیس قابل بازتولید در تولید بهینه‌سازی نکن - پروفایل کن، حدس نزن — گلوگاه واقعی تقریباً هرگز جایی نیست که انتظار دارم. مقصرهای رایج: پرس‌وجوهای N+1، ایندکس‌های دیتابیس مفقود، I/O همزمان که کد async را بلاک می‌کند، نشت حافظه که فشار GC ایجاد می‌کند - علت ریشه‌ای را درست کن — نه یک علامت. یک کوئری 5× سریع‌تر بهتر از کشی است که کوئری کند را پنهان می‌کند - با متریک‌ها اعتبارسنجی کن — تغییر را deploy کن و با همان داشبوردهایی که مشکل را نشان دادند تایید کن مثال: یک API تسویه در هنگام یک رویداد فروش تاخیر P99 را به 4 ثانیه رساند. tracing نشان داد یک متد ORM 147 کوئری SQL تولید می‌کرد (N+1 روی variantهای محصول). افزودن eager loading P99 را به 180ms کاهش داد. اصلاح فقط 3 خط کد بود — اما فقط پروفایلینگ آن را نشان داد. پس از رخداد، یک post-mortem بدون سرزنش با جدول زمانی، علت ریشه‌ای و آیتم‌های عملی برای جلوگیری از تکرار می‌نویسم.

تجربهٔ ابری من عمدتاً روی AWS است، با آشنایی به GCP و Azure برای بارهای کاری خاص. من با ذهنیت "زیرساخت به‌عنوان کد" کار می‌کنم — اگر در version control نباشد، وجود ندارد. خدمات AWS که به‌صورت منظم استفاده می‌کنم: - محاسبات: EC2 (شامل Spot برای بهینه‌سازی هزینه)، ECS/EKS برای ارکستراسیون کانتینرها، Lambda برای بارهای کاری event-driven - ذخیره‌سازی و دیتابیس‌ها: RDS (PostgreSQL, Aurora)، DynamoDB برای دسترسی key-value با تاخیر پایین، S3 با lifecycle policyها، ElastiCache (Redis) - شبکه و تحویل: ALB، CloudFront CDN، Route 53، طراحی VPC با subnetهای خصوصی و NAT gateway - مشاهده‌پذیری: CloudWatch متریک‌ها، آلارم‌ها و Log Insights؛ X-Ray برای tracing توزیع‌شده چطور به زیرساخت نزدیک می‌شوم: - Terraform برای تمام زیرساخت — ماژول‌ها برای اجزای قابل استفادهٔ مجدد، state ریموت در S3 با قفل DynamoDB - CI/CD با GitHub Actions یا Jenkins — تست خودکار، استقرار به staging و دروازه‌های ترفیع به production - Docker برای محیط‌های سازگار؛ EKS یا ECS برای ارکستراسیون بسته به آشنایی تیم - اصل کمترین امتیاز برای IAM — نقش‌ها، نه کاربران؛ هیچ credential هاردکدی‌شده‌ای وجود ندارد مثال: یک آرشیتکت multi-region active-passive روی AWS برای یک مشتری فین‌تک با RPO برابر 15 دقیقه و RTO برابر 30 دقیقه طراحی کردم. از Aurora Global Database، تکثیر S3 بین نواحی، و failover مبتنی بر health checkهای Route 53 استفاده شد. هزینهٔ اضافی ماهانه: £280 برای سیستمی که روزانه £2M تراکنش پردازش می‌کرد.

طراحی سیستم برای ترافیک بالا اساساً دربارهٔ فهمیدن گلوگاه‌ها قبل از وقوع و انجام معامله‌های سنجیده بین سازگاری، در دسترس بودن و هزینه است. روند من: - جمع‌آوری نیازمندی‌ها: کاربران هم‌زمان مورد انتظار، QPS اوج، نسبت خواندن/نوشتن، SLOهای تاخیر (P50/P99)، نیازمندی‌های سازگاری، توزیع جغرافیایی - برآورد ظرفیت: محاسبات سریع پیش از کشیدن دیاگرام — به‌عنوان مثال چقدر سرور برای اوج نیاز داریم؟ توان نوشتن دیتابیس چقدر است؟ - طراحی برای مقیاس افقی: سرورهای اپلیکیشن stateless پشت load balancer، تا هر سرور بتواند هر درخواست را هندل کند الگوهای رایجی که به‌کار می‌برم: - کشینگ: Redis برای داده‌های داغ (session state، رکوردهای پرخوانش)، CDN (CloudFront) برای دارایی‌های استاتیک — این کار سرورهای origin را آزاد می‌کند برای درخواست‌های داینامیک - مقیاس‌بندی دیتابیس: read replicaها برای بارهای خواندنی سنگین، connection pooling (PgBouncer)، و sharding برای مقیاس‌های بسیار بالا - پردازش غیرهمزمان: صف‌های پیام (SQS, Kafka) کارهای سنگین را از چرخهٔ درخواست جدا می‌کنند — پردازش تصویر، ایمیل‌ها، نوتیفیکیشن‌ها - circuit breaker و bulkhead: جلوگیری از شکست آبشاری وقتی یک وابستگی افت می‌کند - کاهش با رفتار جالب (graceful degradation): تعریف اینکه سیستم هنگام در دسترس نبودن یک سرویس پایین‌دستی چه کند — دادهٔ قدیمی ارائه شود؟ ویژگی غیرفعال شود؟ هرگز بی‌صدا خطا ندهد؟ مثال: برای یک سیستم flash-sale که 50,000 کاربر هم‌زمان را در طی یک پنجرهٔ 2 ساعته هندل می‌کرد، یک لایهٔ inventory Redis از پیش گرم‌شده طراحی کردم که تمام ترافیک خواندنی را جذب می‌کرد، یک write-ahead queue برای درخواست‌های خرید گذاشتیم تا از oversell جلوگیری شود، و تسک‌های ECS با auto-scaling که توسط عمق صف SQS فعال می‌شدند. سیستم 3× اوج پیش‌بینی‌شده را بدون هیچ درخواست از دست‌رفته‌ای هندل کرد.