ساختار کد

قسمت نهم – 1400/7/26

در قسمت قبلی راجع به ساختار تیم صحبت کردم. اینجا می‌خواهم در ادامه همان موضوع راجع به ساختار کد و ابزارها صحبت کنم. البته فقط کد Back-end.

کل Back-end با دات نت توسعه داده شده. با اینکه پروژه نهایتاً دو سال پیش شروع شده، اما با .Net Core 2.1 توسعه داده شده که البته خیلی هم بد نیست. چون در زمان شروع پروژه چیزی حدود شش ماه از انتشار 2.1 گذشته بوده. اما عجیب این است که ارتقا به .Net 5 تازه همین دو روز پیش انجام شد، در زمانی کمتر از یک ماه مانده به .Net 6. همین ارتقا به .Net 5 هم خیلی تر و تمیز نیست. چون package ها داخلی Entity Framework هنوز روی 2.1 باقی‌مانده اند.

معماری نسبتاً به روز است. حدود 30 میکروسرویس داریم. به ازای تقریباً هر کاری، یک میکرسرویس داریم. بعضی میکرسرویس ها دیتابیس ندارند بعضی‌ها یک دیتابیس در حد یک یا سه جدول دارند. ارتباط بین میکرسرویس ها بر خلاف تصور من با HTTP است. از هیچ message broker مثل Kafka یا RabbitMQ استفاده نمی شود. میکروسرویس ها آنقدر زیاد هستند که کسی نمی‌تواند پروژه را روی local خودش بالا بیاورد. مگر اینکه بتواند صد تا VS باز کرده و همه را با هم Run کند. برای تست و اجرای آن‌ها از component test استفاده می شود. گاهی هم روی سرور QA یا Dev پابلیش شده و از آنجا به طور دستی چک می شود.

هر کدام از میکرسرویس ها یک solution کامل دات نت هستند. بین 5 تا 8 پروژه. یکی به عنوان REST API، یکی یا دو تا برای Test و الباقی به شکل library های مختلف. هر میکرسرویس ها به یک سری REST request های جواب می‌دهد و خودش هم یک سری REST request ارسال می کند. این ساختار و حتی نام گذاری ها، عیناً در همه میکرسرویس ها تکرار شده. یعنی یاد گرفتن یکی از میکرسرویس ها باعث می‌شود بقیه را هم یاد بگیرید. یک سری میکروسرویس ویژه داریم که با الگوی Facade رابط دنیای بیرون و میکرسرویس های داخلی هستند. استفاده از test تقریباً روزمره هست. انجام تسک ها معمولاً با یک سری component test همراهی می شود.

برای نگهداری کد از Bitbucket استفاده می شود. برای انجام هر کاری یک Branch ویژه آن Task ایجاد می شود. پس از تکمیل تسک یک pull request ایجاد می شود. سپس یک نفر کد را review می کند. بعدش مراحل deploy انجام می شود. این کار با Jenkins و یک سری docker image انجام می شود. تازه اینجاست که تغییرات به دست QA می رسد. بعد از تأیید QA، تغییرات به دست مشتری نهایی خواهد رسید.

همکارم از Visual Studio 2019 روی Mac استفاده می کند. من فعلاً VS Code هستم روی ویندوز. ولی حالا که روی .Net 5 رفته ایم، احتمالاً به زودی به لینوکس بر می گردم. دیتابیس ها روی MySQL هستند. فعلاً هیچ استفاده‌ای از Redis نداریم. از یک تعداد ابزار جانبی مثل jaegar و kibana برای کارهای متفرقه استفاده می شود.

برای مدیریت Task ها از Jira استفاده می شود. استفاده خیلی جدی از google calendar و zoom داریم. همه تماس ها ویدیویی هستند. از Confluence به عنوان یک wiki برای نگهداری اطلاعات پروژه استفاده می‌شود که البته خیلی هم جدی و مفید است. مثلاً من برای اینکه آدرس فلان سرور را بفهمم لازم نیست که با شش نفر تماس بگیرم، فقط صفحه مربوطه را در Confluence بررسی می کنم. تا آنجا که متوجه شده ام، نتایج همه sprint retro های گذشته در Confluence موجود است. خیلی راحت می‌شود فهمید در هر دوره زمانی در تیم چه خبر بوده. اطلاعات داخل Task و Issue ها به همین نسبت جامع هستند. دیاگرام های متعددی از معماری پروژه و دیگر بخش در داخل Confluence موجود هستند. برای messaging از Slack استفاده می کنیم. البته ایمیل شرکتی هم هست.

تا بعد.