یکی از ابعاد تاثیرگذار و کمک‌کننده در فرایند توسعهٔ محصول، تعامل و فهم مشترک طراحان و توسعه‌دهندگان است. بهبود این تعامل و ایجاد فهم مشترک، باعث همدلی بیشتر بین اعضای تیم میشود؛ تاثیر این همدلی در فرایند تحویل طرح به توسعه‌دهنده (Hand-off) بسیار چشم‌گیر است. این فهم مشترک ایجاد شده بین طراح و توسعه‌دهنده نهایتا منجر به ارائهٔ تجربهٔ کاربری مطلوب و بهینه‌ای خواهد شد که حاصل نگاه و تلاش یک تیم همدل بوده است. به عنوان یک طراح محصول یکی از گام‌هایی که می‌توانیم برای بهبود این تعامل برداریم، فهم و درک اصطلاحات فنی مورد استفاده در مکالمات روزمرهٔ اعضای تیم است.
این مقاله، قسمت دوم از مجموعه مقالات آشنایی با اصطلاحات فنی است. این مجموعه مقالات، چکیده‌ای از جلسات ما در چپتر طراحی «بله» است که در آن میزبان آقای مهندس محمدامین پایدار بودیم. قسمت اول این مجموعه مقالات را می‌توانید از اینجا بخوانید.
سیستم عامل (Operating System)
سیستم عامل یک نرم‌افزار پایه‌ای است که منابع نرم‌افزاری و سخت‌افزاری را مدیریت کرده و سرویس‌های متداول برنامه‌های کامپیوتری را فراهم می‌کند.
نرمافزارهای کاربردی (Software Application)
این نرم‌افزارها بسته به نوع برنامه‌نویسی انجام شده روی یک سیستم عامل خاصی قابل اجرا هستند.
با توجه به این نکته که این برنامه روی سرور یا دستگاه‌های کاربر نهایی اجرا میشود یک تقسیم‌بندی صورت می‌گیرد:
- تعریف Front-end به کارهایی که سمت کاربر نهایی قابل اجراست اشاره می‌کند.
- تعریف Back-end به کارهایی که سمت سرور قابل اجراست اشاره می‌کند.
این تقسیم‌بندی‌ها براساس کاربری هر برنامه صورت می‌گیرد. اصولا برنامهٔ Front-end دارای طراحی رابط کاربری (UI) است. برنامه‌هایی که برای وب، اندروید و ios نوشته می‌شوند در دستهٔ Front-end قرار می‌گیرد.
برنامه‌هایی که با زبان جاوا، پایتون، گلنگ (Golang) و … نوشته می‌شوند برنامهٔ Back-end هستند.
برنامه‌های Back-end به تنهایی برای کاربر نهایی معنایی ندارند. این برنامه‌ها سرور یک برنامهٔ Front-end می‌شوند تا برنامهٔ فرانت بتواند دیتاهای مورد نیاز خود را از سرورش دریافت کند.
توسعهٔ نرمافزارهای کلاینت‌ها با مدل‌های گوناگونی صورت می‌گیرد.
اپلیکیشن Native
این مدل بدین صورت است که از SDKای که شرکت سازندهٔ سیستم عامل مورد نظر در اختیارمان قرار داده استفاده کنیم و نرم‌افزار را توسعه دهیم. مثلا برای توسعهٔ یک اپلیکیشن اندرویدی از SDK شرکت گوگل استفاده میشود.
ویژگی مدل Native این است که ما نزدیک‌ترین دسترسی ممکن به سخت‌افزار را داریم. برای مثال در Rendering بالاترین عملکرد ممکن را می‌توان داشت.
کیت توسعهٔ نرم افزار یا SDK مجموعه‌ای از کدها، کتابخانه‌ها و راهنماهاست که برنامه‌نویسان برای توسعهٔ نرم‌افزار از آن استفاده می‌کنند.
اپلیکیشن Hybrid
اپلیکیشن هیبریدی در واقع همان اپ وب است که ویژگی‌های محدودی از یک اپ Native را دارد؛ به این شکل که یک APK اندروید خواهیم داشت که در آن یک کد جاوا می‌زنیم که یک وب ویو داشته باشیم. در این وب ویو کد وب را قرار می‌دهیم. به این صورت اپلیکیشنی خواهیم داشت که صرفا یک وب ویو خواهد بود که توسعهٔ Native ندارد.
این مدل توسعه محدودیت‌هایی دارد و سیستم‌عامل بعضا اجازهٔ بعضی از دسترسی‌ها را فقط در اپلیکیشن Native می‌دهد و به وب ویو این دسترسی‌ها را نمی‌دهد. برای رفع این مشکل کتابخانه‌هایی هستند که محدودیت دسترسی به مرورگر را حل می‌کنند. در توسعه می‌توان از این کتابخانه‌ها استفاده کرد. چند نمونه از این کتابخانه‌ها Iconic، Cordova و … هستند.
اپلیکیشن Cross-Platform
اپلیکیشنهای Cross-Platform با یک Source-Code توسعه داده می‌شوند. سپس برای به‌کارگیری روی پلتفرم‌های مختلف خروجی متناسب با همان پلتفرم را می‌دهند.
برای مثال زبان React، یک کتابخانه‌ای متشکل از کامپوننت‌های مختلف UI در اختیار می‌دهد. بعد از توسعهٔ برنامه مورد نظر با استفاده از کتابخانه، می‌توان خروجی Native اندروید یا iOS گرفت و از آن استفاده کرد.
خروجی مدل Hybrid نهایتا HTML , CSS است، ولی در اپلیکیشن Cross-Platform خروجی حاصل کد Native مورد نیاز است.
معماری سرویس‌ها در Backend
دو مدل معماری را می‌توان نام برد:
یکپارچه (Monolit)
وقتی تمام بیزنس لاجیک‌ها و برنامه‌ها را در یک پروژه توسعه دهیم و روی یک ماشین مجازی اجرا کنیم و یک دیتابیس واحد داشته باشد و سرویس دیگری نیست که بخواهد با آن ارتباط برقرار کند، این معماری یکپارچه است.
میکروسرویس (Microservice)
در معماری میکرو سرویس برنامه ما به واحدهای مجزایی به نام سرویس شکسته میشود که هر یک به‌صورت مجزا دیتابیس خاص خود و یا حتی زبان برنامه نویسی خاص خود را دارد و با یکی از پروتکل‌های ارتباطی با سایر سرویس‌ها ارتباط برقرار می‌کند.
همچنین در مدل میکرو سرویس برای اجرا شدن کامل برنامه نیاز هست تمامی سرویس‌ها اجرا شوند و اجرا شدن یک سرویس به معنای اجرا شدن کامل برنامه نیست.
متریک‌های SRE
عبارت (Site Reliability Engineering) یا همان SRE ادبیاتی است که گوگل ابداع کرده است. در کتاب SRE منتشر شده ۴ متریک تعریف شده که برای سرویس‌های بکند باید آن‌ها را اندازه‌گیری کرد:
کافکا: کافکا برنامه‌ای است با هدف ایجاد خطوط انتقال داده‌های جریانی و به هنگامی که داده‌ها را میان سیستم‌ها و برنامه‌ها به صورت قابل اطمینانی انتقال داده و رد و بدل می‌کند.
کوبرنتیز:
کوبرنتیز ابزاری برای مدیریت کانتینرها است که علاوه بر مدیریت کانتینرها به ما قابلیت‌هایی از قبیل Load Balancing را می‌دهد.
میکرو سرویس و برنامه‌های ما داخل کانتینرها قرار گرفته و بر روی بستر کوبرنتیز اجرا میشود...
کوبرنتیز وظایف عملیاتی مدیریت کانتینر ابری یا ماشین‌های مجازی(Virtual Machine) که شامل دستورات داخلی برای استقرار اپلیکیشن‌ها، ایجاد تغییرات در اپلیکیشنهای شما، مقیاس‌گذاری اپلیکیشنهای شما متناسب با نیازهای در حال تغییر، نظارت بر اپلیکیشنهای شما و موارد دیگر را خودکار می‌کند که در نهایت منجر به مدیریت آسان‌تر اپلیکیشن‌ها میشود.
استراتژی دیپلویمنت (Deployment)
به فرایندی که برنامهٔ شما بر روی سرورها و ماشین‌های شما قرار می‌گیرد دیپلوی می‌گویند.
یعنی شما تغییراتی که در کد می‌دهید ابتدا Build میشود و سپس این فایل Build شده بر روی ماشین مجازی دیپلوی میشود و آن ماشین مجازی برنامه دیپلوی شده را اجرا می‌کند.
وقتی یه تغییری در سرویس داده شده و نسخه قرار است داده شود. ما یک دیپلویمنت به نام قناری داریم که ۲درصد کاربران روی آن هستند و بقیه ۹۸ درصد کاربران نسخه نهایی پروداکشن را دریافت می‌کنند. برای تست تغییرات ابتدا سرویس روی قناری دیپلوی میشود بعد از مانیتور کردن آن اگر مشکلی نبود بعد از مدت زمان محدودی، نسخه پروداکشن هم داده میشود.
یکی از استراتژی‌های دیپلویمنت Stage rollout است. در این استراتژی برنامهٔ بکند به صورت پله پله و درصدی برای کاربران باز میشود و در اختیارشان قرار می‌گیرد.
منتظر قسمت‌های بعدی این مجموعه باشید...
