چگونگی طراحی یک برنامه وب: معماری نرم‌افزار

در این پست به بررسی این موارد خواهیم پرداخت:

• معماری نرم‌افزار چیست؟
• چرا معماری نرم‌افزار مهم است؟
• تفاوت بین معماری نرم‌افزار و طراحی نرم‌افزار
• الگوهای معماری نرم‌افزار
• نحوه تصمیم‌گیری در مورد تعداد سطح هایی(tier) که برنامه شما باید داشته باشد
• مقیاس بندی افقی یا عمودی … کدامیک برای برنامه من مناسب است؟
• کدامیک Monolith یا Microservice؟
• چه زمانی باید از NoSQL و یا SQL استفاده کنید؟
• چگونگی تبدیل شدن به یک معمار نرم‌افزار
  

معماری نرم افزار چیست؟

معماری نرم‌افزار در واقع انتخاب یک ساختار کلی برای پیاده‌سازی یک پروژه نرم‌افزاری بر مبنای مجموعه‌ای از نیازهای کاربری و تجاری یک سیستم نرم‌افزاری است تا هم بتوان کاربردهای مورد نظر را پیاده‌سازی کرد و هم بتوان کیفیت نرم‌افزار، تولید آن و نگهداری آن را نیز بهینه کرد و سرعت بخشید.

معماری نرم‌افزار، اجزای اصلی، روابط آن‌ها و نحوه تعامل آن‌ها با یکدیگر را در یک سیستم توصیف می‌کند. اساسا به عنوان یک طرح کلی(blueprint) عمل می‌کند. این روش یک انتزاع برای مدیریت پیچیدگی سیستم(complexity) و ایجاد ارتباط(communication) و هماهنگی(coordination) میان اجزا(components) فراهم می‌کند.

به عبارتی دیگر: معماری نرم‌افزار یک برنامه یا سیستم محاسباتی، ساختار یا ساختارهای آن سیستم محاسباتی است که خصوصیات قابل رویت از بیرون، عناصر و ارتباطات بین آن‌ها را نشان می‌دهد.

در اینجا چند نکته کلیدی وجود دارد:

• معماری به تعریف راه‌حلی برای برآورده کردن تمام الزامات فنی و اجرایی، با هدف مشترک بهینه‌سازی عملکرد و امنیت کمک می‌کند.
• طراحی معماری شامل تقاطع نیازهای سازمان و همچنین نیازهای تیم توسعه است. هر تصمیم می تواند تأثیر قابل توجهی بر کیفیت(quality) ، قابلیت نگهداری(maintainability) ، عملکرد(performance) و غیره داشته باشد.

تعریف Ralph Johnson نویسنده کتاب Design Patterns: Elements of Reusable Object-Oriented Software از معماری نرم افزار:

این تصمیماتی است که شما می‌خواهید و آرزو میکنید در ابتدا در یک پروژه به دست آورید.

چرا معماری نرم‌افزار مهم است؟

عنصر کلیدی در ایجاد موفقیت در ایجاد هر چیزی درست ساختن پایه است. حالا خواه که ساختن یک ساختمان یا ساخت پیتزا باشد. اگر پایه را درست دریافت نکنیم، باید از ابتدا شروع کنیم؛ هیچ راه دیگری برای این کار وجود ندارد.

ساخت یک برنامه وب متفاوت نیست. معماری پایه و اساس آن است و باید دقیقا مورد بررسی قرار گرفته شود تا از تغییرات عمده در طراحی و تغییر شکل کد(code refactoring) در زمان بعدی اجتناب شود. بنابراین ، قبل از اینکه حتی کد را لمس کنیم و دستمان را کثیف کنیم ، باید معماری اساسی را درست کنیم.

اگر چه توسعه نرم‌افزار یک فرآیند تکراری و تکاملی است، اما ما همیشه در ابتدا همه چیز را کامل نمی‌کنیم. با این حال، این نمی‌تواند بهانه‌ای برای انجام ندادن تکالیف ما باشد.

تفاوت بین معماری نرم‌افزار و طراحی نرم‌افزار

اغلب بین طراحی نرم افزار و معماری سردرگمی وجود دارد ، بنابراین ما این مورد را برطرف خواهیم کرد.

از معماری نرم افزار برای تعریف اسکلت و اجزای سطح بالای یک سیستم و نحوه کار همه آنها با هم استفاده می شود. به عنوان مثال ، آیا شما به معماری serverless نیاز دارید که برنامه را به دو جز BaaS و FaaS تقسیم کند؟ یا آیا شما به چیزی مانند معماری microservice نیاز دارید که در آن ویژگی ها / وظایف مختلف به واحدهای مربوطه مجزا تقسیم می شوند؟

انتخاب یک معماری نحوه برخورد شما با عملکرد(performance)، تحمل خطا(fault tolerance) ، مقیاس پذیری(scalability) و قابلیت اطمینان(reliability) را مشخص می‌کند.

الگوهای معماری نرم‌افزار

الگوی Client-server

این معماری یک مدل request-response را ارائه می کند. مشتری درخواست را برای اطلاعات به سرور ارسال می کند و سرور با آن پاسخ می دهد.

کامپوننت سرور برای چند مؤلفۀ کلاینت سرویسی را ارائه می‌دهد؛ کلاینت‌ها هم می‌توانند برای دستیابی به سرویس مد نظر خود، ریکوئستی را به سرور ارسال کنند که سرور نیز در پاسخ به این ریکوئست، سرویس درخواستی را برای آن کلاینت‌ها فراهم می‌کند. علاوه بر این، سرور همواره در آمادگی کامل برای دریافت ریکوئست از سمت کلاینت و ارائۀ سرویس به آن‌ها است.

هر وب سایتی که شما مرور می‌کنید، یک وبلاگ wordpress یا یک برنامه وب مانند Facebook، Twitter یا برنامه بانکداری شخصی شما در معماری Client-server ساخته شده‌است.

الگوی Peer-to-Peer

شبکه P2P شبکه ای است که در آن رایانه هایی که به آنها گره نیز می گویند می توانند بدون نیاز به سرور مرکزی با یکدیگر ارتباط برقرار کنند. فقدان سرور مرکزی احتمال خرابی یک نقطه را منتفی می داند. تمام رایانه های موجود در شبکه از حقوق برابر برخوردارند. یک گره به طور همزمان به عنوان seeder و leecher بازی می کند. بنابراین ، حتی اگر بعضی از رایانه ها / گره ها خراب شوند ، شبکه و ارتباطات همچنان برقرار است.

شبکه P2P پایه فناوری بلاکچین است.

الگوی Model-View-Controller (MVC)

معماری MVC یک الگوی معماری نرم‌افزاری است که در آنمعماری اپلیکیشن را به سه مولفه براساس کارکرد تقسیم میکند. این مولفه‌ها عبارتند از: Models - نشان می‌دهند که چگونه داده‌ها در پایگاه‌داده ذخیره می‌شوند. View- اجزایی که برای کاربر قابل‌رویت هستند، مانند خروجی یا کنترل‌کننده‌های واسط گرافیکی. Controller- اجزایی که به عنوان یک رابط بین Models و Views عمل می‌کنند.

از معماری MVC نه تنها برای برنامه های دسکتاپ بلکه برای برنامه های موبایل و وب نیز استفاده می شود.

Microservices

در معماری microservice، ویژگی‌ها / وظایف مختلف به ماژول های مربوطه مجزا تقسیم می‌شوند که در ارتباط با یکدیگر کار می کنند و تشکیل یک سرویس بزرگ به عنوان یک کل را می دهند.

الگوی Event driven

معماری Non-blocking به عنوان معماری Reactive یا Event-based نیز شناخته می شود. معماری های مبتنی بر رویداد در توسعه برنامه های وب مدرن بسیار محبوب هستند.

آنها قادر به مدیریت تعداد زیادی از اتصالات همزمان با حداقل مصرف منابع هستند. برنامه های مدرن برای مقیاس گذاری به یک مدل کاملاً ناهمزمان نیاز دارند. این چارچوب های مدرن وب رفتار قابل اعتماد تری را در یک محیط توزیع شده ارائه می دهند.

الگوی Layered

این الگو را می توان برای ساخت برنامه‌هایی بکار برد که می‌توانند به گروه‌هایی از وظایف فرعی تجزیه شوند، که هر کدام در یک سطح خاص از انتزاع قرار دارند. هر لایه خدمات را به لایه بالاتر بعدی ارایه می‌دهد.

اینها رایج‌ترین لایه‌ها هستند:

• لایه Presentation
• لایه Application
• لایه Business logic
• لایه Data access

الگوی Hexagonal

الگوی Hexagonal در واقع یک روش تصور شده برای توصیف هسته‌ی یک اپلیکیشن است که توسط دامین آبجکت‌ها، usecase هایی که آن‌ها را عملیاتی می‌کنند و پورت‌های ‌input و output که یک رابط برای دستیابی به دنیای بیرون می‌باشند، است.

این معماری از سه جز زیر تشکیل شده است:

• ساختن Ports
• ساختن لایه Adapters
• ساختن یک Domain Object

نحوه تصمیم‌گیری در مورد تعداد سطح هایی(tier) که برنامه شما باید داشته باشد

اپلیکیشن های Single tier

مزایا:

تاخیر در شبکه وجود ندارد

داده‌ها به سرعت و به راحتی در دسترس هستند

معایب:

کنترل کمی بر روی برنامه وجود دارد؛ پیاده سازی ویژگی های جدید یا تغییرات کد پس از ارسال سخت است.

تست باید بسیار دقیق و با کمترین جای اشتباه باشد.

برنامه های تک لایه در برابر اصلاح یا مهندسی معکوس آسیب پذیر هستند.

اپلیکیشن های Two-tier

مزایا:

فراخوانی شبکه کم‌تر از زمانی است که کد و رابط کاربر در همان ماشین هستند

سرور پایگاه‌داده و منطق تجاری از نظر فیزیکی نزدیک هستند، که عملکرد بالاتری را ارایه می‌دهد.

معایب:

از آنجا که مشتری بیشتر منطق برنامه را در اختیار دارد ، در کنترل نسخه نرم افزار و توزیع مجدد نسخه های جدید مشکلاتی بوجود می آید.

فاقد مقیاس پذیری است زیرا فقط تعداد محدودی از کاربران را پشتیبانی می کند. هنگامی که چندین درخواست مشتری افزایش می یابد ، عملکرد برنامه می تواند کاهش یابد ، زیرا مشتری برای ادامه کار نیاز به اتصالات جداگانه و حافظه CPU دارد.

از آنجا که منطق برنامه با مشتری همراه است ، استفاده مجدد از منطق دشوار است.

اپلیکیشن های Three-tier

مزایا:

خرابی داده ها از طریق برنامه های مشتری می تواند برطرف شود زیرا داده های ارائه شده در سطح میانی برای بروزرسانی پایگاه داده ، اعتبار آن را تضمین می کند

قرار دادن منطق کسب و کار در یک سرور متمرکز باعث امنیت بیشتر داده ها می شود.

با توجه به استقرار توزیع شده سرورهای برنامه ، مقیاس پذیری سیستم افزایش می یابد زیرا اتصال جداگانه ای از هر سرویس گیرنده مورد نیاز نیست در حالی که اتصالات از چند سرور برنامه کافی است.

معایب:

معمولاً هنگام ایجاد برنامه های three-tier باید تلاش بیشتری انجام شود زیرا نقاط ارتباطی افزایش می یابد.

اپلیکیشن های N-Tier

مزایا:

تمام مزایا و معایب معماری three-tier

عملکرد به دلیل حذف بار از database tier و client tier افزایش می‌یابد، که آن را قادر می‌سازد تا متناسب با صنایع متوسط تا حجیم باشد.

معایب:

به دلیل پیچیدگی tier ، پیاده‌سازی یا حفظ ساختار پیچیده مشکل است.

نتیجه‌گیری

• هنگامی که تأخیری در شبکه ندارید ، باید یک معماری تک tier انتخاب کنید
• هنگامی که نیاز دارید تاخیر شبکه را به حداقل برسانید و به کنترل بیشتری بر داده ها در برنامه خود نیاز دارید ، یک برنامه two tier را انتخاب کنید
• هنگامی که به کنترل کد / منطق تجاری برنامه خود نیاز دارید و می خواهید از امنیت برخوردار باشد ، باید معماری three tier را انتخاب کنید.
• هنگامی که به برنامه خود برای مقیاس بندی و مدیریت مقادیر زیادی از داده ها نیاز دارید ، باید یک معماری N tier انتخاب کنید.

مقیاس بندی افقی یا عمودی … کدامیک برای برنامه من مناسب است؟

اگر برنامه شما یک برنامه یا ابزار است که انتظار می‌رود حداقل ترافیک هماهنگ را دریافت کند، ممکن است برای ماموریت مهم نباشد. به عنوان مثال ، یک ابزار داخلی یک سازمان یا چیزی مشابه آن. مقیاس گذاری عمودی با بهبود کارایی هر یک از تراکنش ها انجام می شود، بنابراین می توانید مقیاس گذاری عمودی را انجام دهید وقتی می دانید بار ترافیک به طور قابل توجهی افزایش نمی یابد.مقیاس گذاری عمودی مستلزم گسترش شبکه با اضافه کردن توان و حافظه ی بیشتر به واحد پردازش هسته ای سیستم است

اگر برنامه شما یک برنامه اجتماعی عمومی مانند شبکه اجتماعی ، برنامه تناسب اندام یا موارد مشابه است ، انتظار می رود که در آینده نزدیک میزان بازدید به طور چشمگیری افزایش یابد. در این حالت هم قابلیت دسترسی بالا و هم مقیاس پذیری افقی برای شما مهم است.مقیاس پذیری افقی شامل اضافه کردن گره های بیشتر (یعنی دستگاه ها) به چارچوب یک سیستم موجود است.

هنگام پرداختن به موضوع قابلیت مقیاس پذیری ، مهم است که درک کنیم وقتی کسی به دنبال افزایش ظرفیت معاملات یک پلتفرم خاص است ، معمولاً از این مفهوم استفاده می شود.

کدام گزینه Monolith or Microservice

بیایید بررسی کنیم که چه زمانی باید یکی از آن‌ها را انتخاب کنید

چه موقع باید از معماری Monolithic استفاده کرد

برنامه های Monolithic در مواردی که نیازها کاملاً ساده است ، مناسب است و انتظار می رود این برنامه میزان محدودی از ترافیک را کنترل کند. یک نمونه از این موارد ، یک برنامه محاسبه مالیات داخلی یک سازمان است.

اینها مواردی هستند که در آن کسب‌وکار اطمینان دارد که رشد نمایی در پایه کاربر و ترافیک در طول زمان وجود نخواهد داشت.

همچنین مواردی وجود دارند که در آن تیم‌های توسعه دهنده تصمیم می‌گیرند با یک معماری Monolithic شروع کنند و بعد از آن به یک معماری Microservices توزیعی تبدیل شوند.

این امر به آنها کمک می کند مرحله به مرحله با پیچیدگی برنامه کنار بیایند. این دقیقاً همان کاری است که LinkedIn انجام داد.

فواید Monolith

• نگرانی کمتر در رابطه با قطعی‌ها: بیشتر اپلیکیشن‌ها دارای تعدادی قطعی‌ها و قسمت‌های متفاوت از یکدیگر هستند. به عنوان مثال عملیات وارد شدن، ویژگی‌های امنیتی، محافظت‌ها و... . یکی از بزرگ‌ترین مزیت‌های این معماری آن است که به دلیل وجود تمام این نکات در یک اپلیکیشن، مشاهده کردن اختلالات در این زمینه‌ها بسیار ساده‌تر خواهد بود.
• وجود عملیات‌های کمتر: داشتن یک اپلیکیشن بزرگ بدان معناست که تنها یک اپلیکیشن برای تست کردن، نظارت و وارد شدن وجود دارد. به همین دلیل عملیات‌های کمتری انجام می‌شود. نگه‌داری از این سیستم‌ها پیچیده‌گی کمتری نیز دارد.
• کارایی: از آنجایی که دسترسی به حافظه اشتراکی سریع‌تر از ارتباطات داخل پردازش سریع‌تر است، بنابراین کارایی در این معماری نیز بیشتر است.

معایب Monolith

• محکم به هم بسته بودن: در این سیستم معماری همه چیز به شدت با همدیگر ارتباط دارند و به همین دلیل جدا کردن آن‌ها کار سختی است. بنابراین وقتی بخواهید قسمتی را به صورت مستقل توسعه و یا نگه‌داری کنید کار سختی است.
• درک سخت‌تر: معماری Monolithic درک‌پذیری سخت‌تری دارد، به این دلیل که وقتی مشکلی اتفاق می‌افتد ممکن است پیدا کردن آن در یک قسمت سخت باشد.

چه موقع باید از معماری Microservice استفاده کرد

معماری Microservice برای موارد استفاده پیچیده مناسب است و برای برنامه‌هایی که انتظار می‌رود ترافیک در آینده به صورت نمایی افزایش یابد مانند یک برنامه کاربردی شبکه اجتماعی مناسب است.

یک شبکه اجتماعی معمولی دارای اجزای مختلفی مثل پیام گذاری، real-time chat، پخش ویدیویی زنده، بارگذاری تصویر، Like و ... را است.

در این سناریو، پیشنهاد می‌کنم که هر بخش را به طور جداگانه در نظر بگیریم که Single Responsibility و جداسازی قابلیت ها یا رفتارها(Separation of Concerns principle) را در ذهن داشته باشیم.

واقعیت این است که در مهندسی نرم‌افزار هیچ راه حل طلایی‌ای وجود ندارد! میکروسرویس‌ها به صورت جادویی تمام مشکلات scaling را حل نمی‌کنند و حتی بعضی وقت‌ها مشکلات جدیدی را هم به وجود می‌آورند

فواید Microservices

• سازمان‌دهی بهتر: معماری میکروسرویس‌ها معمولا بهتر دسته‌بندی و سازمان‌دهی می‌شوند. این بدان دلیل است که هر میکروسرویس یک کار منحصر به فرد را انجام می‌دهد و کاری به دیگر اجزا ندارد.
• جداسازی شده: سرویس‌های از هم جداشده برای برآورده کردن نیازهای مربوط به اپلیکیشن‌های دیگر قابلیت تغییر و پیکربندی مجدد ساده‌تری را ارائه می‌دهند. آن‌ها همچنین در یک سیستم یکپارچه بزرگ‌تر قابلیت تحویل قسمت‌های منحصر به فرد را به صورت سریع‌تری ارائه می‌دهند.
• کارایی: بسته به موقعیت درست میکروسرویس‌ها همچنین می‌توانند مزیت‌های خوبی را در زمینه کارایی ارائه دهند. برای مثال وقتی قرار است از یک قسمت منحصر به فرد باری دیگر در اپلیکیشن استفاده کرد، جدا کردن آن قسمت از دیگر اجزا کار ساده‌ای خواهد بود.
• اشتباهات کمتر: میکروسرویس‌ها به شما قابلیت توسعه موازی را می‌دهند. به همین دلیل احتمال انجام اشتباهات در این حالت کمتر می‌شود.

معایب Microservices

• نگرانی قطع شدن در ارتباط با هر سرویس: همانطور که شما یک معماری میکروسرویس جدید را ایجاد می‌کنید، ممکن است با قطع‌ شدن‌های مختلفی مواجه شوید که در زمان طراحی سیستم با آن‌ها برخورد نکرده‌اید. شما یا مجبور هستید که تمام این موارد را دوباره بررسی کنید و یا اینکه می‌توانید در یک لایه دیگر از سرویس‌ها با آن‌ها تعامل داشته باشید.
• انجام عملیات‌های بیشتر: میکروسرویس‌ها به صورت مکرر روی ماشین مجازی یا کانتینر خودشان اجرا می‌شوند. به همین دلیل میزان بیشتری را اشغال کرده و نیاز به کارهای بیشتری برای انجام دادن هستند. این وظایف معمولا توسط یک ابزار مدیریت خودکارسازی می‌شوند.

چه زمانی باید از NoSQL و یا SQL استفاده کنید؟

چه موقع می توان پایگاه داده SQL را انتخاب کرد؟

اگر در حال نوشتن معاملات سهام ، بانکداری یا برنامه ای مبتنی بر امور مالی هستید یا باید روابط زیادی را ذخیره کنید ، به عنوان مثال ، هنگام نوشتن یک برنامه شبکه های اجتماعی مانند فیس بوک ، باید یک پایگاه داده رابطه ای انتخاب کنید. به همین دلیل است:

Transactions & Data Consistency

اگر در حال نوشتن نرم افزاری هستید که ارتباطی با پول یا شماره دارد ، باعث می شود تراکنش ها و سازگاری داده ها برای شما بسیار مهم باشد. DB های رابطه ای وقتی صحبت از سازگاری داده ها و داده ها می شود ، می درخشند. آنها مطابق با قانون ACID هستند ، از دیرباز وجود داشته و مورد آزمایش قرار گرفته اند.

همه دیتابیس‌های SQL، خواص ACID را دارا هستند. ACID مخففی برای (Atomicity, Consistency, Isolation, Durability) است که در زیر هرکدام را مختصراً توضیح می‌دهیم:

• تجزیه ناپذیری Atomicity: این ویژگی تضمین می‌کند که با هر تراکنش، چه با شکست روبه‌رو شود و چه موفق باشد،‌ به‌عنوان یک واحد تکی و غیرقابل تقسیم رفتار می‌شود. از این رو هیچ حالت میانه‌ای وجود ندارد.
• استحکام Consistency: اطمینان حاصل می‌کند که هر تراکنش، دیتابیس را از یک حالت معتبر به حالت معتبر دیگر می‌برد. به عبارت بهتر هر داده‌ی افزوده شده به دیتابیس باید از قوانین تعریف شده پیروی کند.
• ایزوله سازی Isolation: این خاصیت کنترل می‌کند اجرای همزمان تراکنش‌ها دیتابیس را در حالتی قرار دهد که اگر تراکنش‌ها یکی یکی انجام می‌شدند، قرار می‌گرفت.
• پایداری Durability: وقتی یک تراکنش انجام شود، حتی اگر سیستم با شکست رو‌به‌رو شود به روند خود ادامه می‌دهد؛ این وظیفه‌ی خاصیت Durability است.

Storing Relationships

اگر داده های شما روابط زیادی داشته باشد مانند اینکه کدام یک از دوستان شما در یک شهر خاص زندگی می کنند؟ کدام یک از دوستان شما قبلاً در رستورانی که امروز قصد بازدید از آن را دارید غذا خورده است؟ و غیره هیچ چیز بهتر از یک پایگاه داده رابطه ای برای ذخیره این نوع داده ها نیست.

محبوب ترین پایگاه های داده رابطه ای:

• MySQL
• Microsoft SQL Server
• PostgreSQL
• MariaDB

چه موقع می توان پایگاه داده NoSQL را انتخاب کرد؟

مدیریت تعداد زیادی از عملیات خواندن/نوشتن

زمانی که تعداد زیادی از عملیات خوانش در وب سایت شما وجود دارد و زمانی که با مقدار زیادی از داده‌ها سروکار داشته باشد، پایگاه‌های داده NoSQL در این سناریوها بهترین جا هستند. از آنجا که آن‌ها توانایی اضافه کردن گره‌ها را دارند، می‌توانند ترافیک همزمان و مقادیر زیاد داده را با حداقل تاخیر کنترل کنند.

اجرای تجزیه و تحلیل داده‌ها

پایگاه داده های NoSQL همچنین برای موارد استفاده از تجزیه و تحلیل داده ها ، جایی که ما باید با هجوم مقادیر گسترده ای از داده ها مقابله کنیم ، مناسب ترین است.

محبوب ترین پایگاه های داده NoSQL :

• MongoDB
• Redis
• Cassandra
• HBASE

چگونگی تبدیل شدن به یک معمار نرم‌افزار

ممکن است آرزو داشته باشید یک معمار نرم افزار باشید. اما شما از کجا شروع می کنید؟ خوب ، بسیار غیرمعمول است که کسی به عنوان یک معمار نرم افزار شروع به کار کند ، بنابراین بیشتر مهندسان نرم افزار قبل از اینکه طراحی معماری را شروع کنند ، چند سال کار می کنند.

یکی از بهترین راه های آشنایی با معماری نرم افزار ، طراحی برنامه های وب خاص خودتان است. این شما را مجبور خواهد کرد که از جنبه های مختلف برنامه خود از load balancing ، message queueing ، stream processing ، caching و موارد دیگر فکر کنید زمانی که شروع به درک این موضوع می‌کنید. به محض اینکه بفهمید این مفاهیم چگونه در برنامه شما جای می گیرند ، می توانید یک معمار نرم افزار شوید.

شما به عنوان یک معمار مشتاق نرم افزار ، باید دائماً دانش خود را گسترش داده و در بالای آخرین روند صنعت باقی بمانید. شما ممکن است با یادگیری یک یا چند زبان برنامه نویسی شروع کنید ، به عنوان یک توسعه دهنده نرم افزار کار کنید و کم کم راه خود را باز کنید.