https://virgool.io/feed/@seyyedjamal دانش آموخته مهندسی کامپیوتر دانشگاه شریف و مدیر فنی شرکت مشاوران نرم افزاری اعوان. علاقه مند به معماری راه حلهای نرم افزاری fa 2026-06-16 01:48:32 https://files.virgool.io/upload/users/1243851/avatar/E9wFOZ.jpg?height=120&width=120 https://virgool.io/@seyyedjamal https://virgool.io/avansoft/%D9%82%D8%A7%D9%84%D8%A8-%D9%BE%DB%8C%D8%B4%D9%86%D9%87%D8%A7%D8%AF%D9%86%D8%A7%D9%85%D9%87-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-p4xdmv57tdul بسم الله الرحمن الرحیمدر گذشته گفتیم که سازمانها برای کمک گرفتن از شرکتهای نرم‌افزاری اقدام به « انتشار RFP» یا Request For Proposal می‌کنند. در ادامه داستان می‌خواهیم ببینیم مشتری دوست داره در پیشنهادنامه‌هایی که شرکتها بهش میدن چه چیزهایی ببینه. یکی از وظایف ما در تیم چکاپ شرکت اعوان، اینه که به سازمانها کمک کنیم مجری پروژه‌هاشون رو انتخاب کنند. در ماه‌های اخیر ده‌ها پیشنهاد رو برای چندین سازمان مختلف بررسی کردیم. طی این تجربه متوجه شدیم وجود بخشهایی زیر در پیشنهادنامه‌ها، روی امتیازدهی تاثیر قابل توجهی دارند. 1. خلاصه مدیریتیاین بخش در چند صفحه با بیان ویژگی‌های کلیدی طرح پیشنهادی و مزیت‌های پیشنهاد دهنده مشتری رو برای بررسی بیشتر متقاعد میکنه.2. بیان مسالهفهم پیشنهاد دهنده از مساله‌ای که قراره با این پروژه حل بشه رو نشون میده. در کنار پرداختن به دامنه مساله بیان «چالش ها و مخاطرات» پروژه و همین‌طور «عوامل و ملزومات موفقیت» پروژه می‌تونه عمق درک پیشنهاد دهنده رو نشون بده. کپی کردن بیان مساله از RFP مطمئناً جذابیتی برای مشتری نداره. 3. راهکار پیشنهادیاین بخش هسته اصلی پیشنهادنامه است و قراره بگه که پیشنهاد دهنده قراره چطوری مساله رو حل کنه. بهتره این بخش رو با یک «مدل مفهومی» شروع کنید و به نماهایی از «معماری نرم افزار» و لیستی از «فناوری‌های مورد استفاده» بپردازید.4. جدول تطبیقدر RFP مجموعه‌ای از خدمات، کارکردها (Functionalities) و ملزومات فنی مورد درخواست قرار گرفته. در جدول تطبیق پیشتیبانی از تک تک این موارد، تعیین وضعیت میشه. آیتم‌هایی که به طور کامل انجام خواهد شد با FC (مخفف Full Compliance) و مواردی که انجام نخواهد شد با NC (مخفف Non-Compliance) و مواردی که تا حدودی انجام می شوند با PC (مخفف Partial Compliance) برچسب می‌خورند. ذکر توضیح برای مواردی که کامل پوشش داده نمیشن (یعنی PCها) ضروریه. در سایر موارد هم اگر ابهامی در تفسیر بندهای RFP می‌بینید یا با پیش‌فرضهای خاصی اعلام وضعیت کردید از ذکر توضیح دریغ نکنید. 5. متدلوژیاین بخش مشخص می‌کنه پیشنهاد دهنده قراره با چه «رویه‌ها»، «ابزارها» و «ساختار تیمی» پروژه رو به پیش ببره. بیان ابعادی از متدلوژی که در «تعامل با مشتری» نقش دارند، از ذکر رویه‌های داخلی تیم، جذابیت و کاربرد بیشتری داره. بیان تعاریف و مفاهیم رایج متدلوژی‌ها لطف چندانی نداره و بهتره درصورت لزوم توضیح‌شون رو به منابع بیرونی یا پیوست‌ها واگذار کنید. 6. برنامه زمانیدر چه گام‌هایی قراره پروژه به ثمر برسه؟ در هر گام قراره چه فعالیت‌هایی انجام و چه خروجی‌هایی تحویل بشه. مشتری توقع داره که برنامه زمانی، قیود زمانی اعلام شده در RFP رو نقض نکنه. مثلاً اگر قید شده «بعد از ۳ ماه اولین نسخه زیر بار عملیاتی بره»، همه پیش‌نیازهای تحقق این هدف، باید قبل از ۳ ماه در برنامه گنجانده بشه.نکته: متاسفانه هنوزم که هنوزه بعضی‌ها برنامه‌ زمانی رو با الگوی آبشاری ارائه می‌کنند. اگر درماه های اول، بخش تاثیرگذاری از سیستم رو زیر بار نبردید و پروژه رو به نقطه غیر قابل بازگشت نرسوندید، آماده انواع حاشیه‌ها و مخاطرات باشید.7. نیروهای کلیدیافراد شاخصی که قراره بار پروژه رو به دوش بکشند اینجا معرفی میشن. بعضی‌ها اسم همه پرسنل شرکت یا حتی دوستان و آشنایان رو بدون اینکه ضرورتاً نقشی در پروژه آتی داشته باشند، ذکر می‌کنند که صادقانه و مفید نیست. لازمه راجع به هر کدوم از فراد «سمت در شرکت» و «مسئولیت در پروژه» مشخص شده باشه. هر فرد چقدر از وقتش رو در شرکت پیشنهاد دهنده حضور داره؟ چقدر از اون رو صرف این پروژه خواهد کرد؟ میزان «سابقه کاری» شخص و میزان «سابقه‌اش در شرکت» هم حس دقیق‌تری از وزن اون شخص در پروژه ایجاد میکنه.8. سوابق مرتبطدر این بخش، پروژه های قبلی شرکت که به این پروژه شباهت دارند رو لیست کنید. خوبه به ازای هر پروژه، «توضیحی مختصر»، «تاریخ‌های مهم» مثلاً تاریخ شروع، تاریخ پایلوت یا تاریخ عملیاتی‌سازی و «نقطه تماس با نماینده مشتری» رو ذکر کنید. تبعاً لازمه وجه شباهت هر کدوم از موارد با این پروژه شفاف بشه. مثلاً شباهت در موضوع، مقیاس یا فناوری.9. برنامه ریزی منابع انسانیدر این بخش مشخص میشه قراره در طول پروژه چه نقش‌هایی درگیر پروژه بشوند. نیاز به برخی نقش‌ها در ماه‌های مختلف کم و زیاد میشه. مثلاً اوایل پروژه کار تحلیل سنگین‌تره و نیروی بیشتری میخواد. در یک جدول مشخص کنید در هر ماه از هر نقش چند نفر مورد نیاز خواهد بود.10. هزینهعلاوه بر «مبلغ پیشنهادی»، «تحلیل هزینه» در این بخش آورده خواهد شد. هزینه هر یک از «خدمات درخواستی»، هزینه احتمالی «لایسنس‌» و دارایی‌های قبلی به تفکیک مشخص میشه. تحلیل هزینه نیروی انسانی هم بسیار مفید و کاربردیه و درک شما رو از موضوع و مقیاس پروژه نشان میده.11. معرفی شرکتاین بخش برخلاف بخش‌های قبل، اختصاص به یک پروژه و پیشنهاد جاری نداره. در واقع یک سری اطلاعات عمومی رو در مورد شرکت پیشنهاد دهنده ارائه می‌کنه.مشتری در این بخش علاقه‌منده از «خطوط تجاری» شرکت مطلع بشه و با یافتن جایگاه این پروژه در خطوط تجاری شرکت میزان انگیزه و جدیتش رو برای انجام این پروژه تخمین بزنه. همچنین «سن»، «سوابق»، «مقیاس» و «توان مالی» شرکت، دستاوردهای مهمش و مجوزها و جوایزی که دریافت کرده به تصمیم‌گیری مشتری کمک می‌کنه. سید جمال الدین پیشوایی سید جمال الدین پیشوایی Thu, 30 May 2024 20:59:39 +0330 https://virgool.io/avansoft/%D9%86%D9%82%D8%B4-%D9%88-%D8%A7%D9%87%D9%85%DB%8C%D8%AA-%D9%86%D8%B3%D8%AE%D9%87-%D8%B2%D8%AF%D9%86-%D8%AF%D8%B1-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-euus4gggaoys بسمه تعالینسخه آقا! نسخه! نسخه مهمه. اگر درست نسخه نزنیم، مدیریت چرخه حیات آرتیفکت‌های نرم‌افزاری از دست‌تون خارج میشه.1. چی رو نسخه بزنیم؟از همه مهمتر «کد» باید نسخه بخوره. وقتی کد به نقطه‌ای رسید که خواستیم release بدیم، اول نسخه می‌زنیم. شماره نسخه قاعدتاً یه جاهایی در کد منعکس میشه. ما جاواکارها در فایل تنظیمات maven یا gradle میگذرایمش. مثل این و این. در مرحله بعد باید شماره نسخه در نام آرتیفکت‌هایی که از روی اون کد ساخته شده ظاهر بشه. مثلاً در jar فایل یا داکر ایمیجی که از روی کد می‌سازید. مثل اینها.2. آرتیفکت Immutable یعنی چی؟اگر قرار باشه آرتیکفت‌هامون Immutable یا غیر قابل تغییر باشند، با کمترین تغییر کد، لازمه شماره نسخه رو تغییر بدیم. با شماره جدید، دوباره روی گیت تگ می‌زنیم و یک آرتیفکت با نام جدید می‌سازیم. اینطوری از روی نام آرتیفکت دقیقاً میشه فهمید با چه نسخه‌ای از کد طرف هستیم. دیگه دو جور نسخه x نداریم. کش کردن آرتیفکت‌ها هم امکان‌پذیر میشه.3. نسخه زدن به چه دردی می‌خوره؟کدها تغییر می‌کنند. با تغییر کدها، آرتیفکت‌های جدید ساخته میشه. آرتیفکت‌ها، نصب و اجرا میشن. وقتی همه چی نسخه داشته باشه، اگر باگی پیش بیاد خیلی راحت می‌تونیم کدی که باگ داره رو پیدا کنیم. در حالیکه ممکنه اون کد نسبت به چیزی که نصب شده، چندین بار تغییر کرده باشه. همین‌طور اگر بخواهیم روی آرتیفکت در حال اجرا تغییر و توسعه جزئی داشته باشیم، کد اون نسخه رو از روی تگ‌های گیت پیدا می‌کنیم، تغییر میدیم و دوباره نسخه می‌زنیم.4. نسخه رو چطور نامگذاری کنیم؟رایج‌ترین قالب نام‌گذاری نسخه‌ها Semantic Versioning نام داره. در این قالب اسم نسخه از سه بخش major version و minor version و patch version تشکیل میشه مثل 1.2.0 یا 9.2.20 . هر توسعه‌ای در کد اتفاق بیفته minor version افزایش پیدا می‌کنه و همزمان patch version برمیگرده روی صفر. مثلاً از 1.2.5 میریم روی 1.3.0. اگر توسعه خیلی اساسی باشه و مخصوصاً ‌Backward Compatible نباشه major version میره بالا و minor version و patch version ریست میشه روی صفر. مثلاً از 1.2.5 میره به 2.0.0. اگر تغییر کد فقط در راستای رفع باگ باشه یا به عبارتی specification کد تغییر نکنه و فقط implementation اصلاح بشه، عدد سوم زیاد میشه مثلاً از 1.2.5 میریم روی 1.2.6. 5. دیگه چی رو نسخه بزنیم؟یکی از جاهای مهم دیگه که نسخه ثبت میشه Issue ها هستند. نسخه‌های مختلف نرم‌افزار (مثل 1.9.1و 1.9.0) در Issue Tracker پروژه (مثل جیرا) تعریف میشه و به ازای هر Issue مشخص میشه که تغییرات روی چه نسخه‌ای (یا چه نسخه‌هایی) اعمال شده. برای ثبت این داده، جیرا فیلدی به نام Fix Version پیش‌بینی کرده. معمولاً رفع ‌باگ روی چندین نسخه (که تحت پشتیبانی فعال هستند) همزمان اعمال میشه و بنابراین در ایشوهای از نوع باگ، ثبت چند Fix Version طبیعیه. اگر Fix Version رو در Issue Tracker ثبت کنیم، به صورت خودکار برای هر نسخه‌ای که ترخیص کنیم Release Notes خواهیم داشت. 6. رابطه سیاست‌های پشتیبانی و نسخه‌هانرم‌افزارها و کتابخانه‌ها معمولاً همه نسخه‌های قبلی رو به صورت فعال پشتیبانی نمی‌کنند. یعنی اگر باگی پیدا بشه روی همه نسخه‌های قبلی فیکسش نمی‌کنند. یک یا چند بازه از نسخه‌ها تحت پشتیبانی هستند. یعنی میگن از فلان نسخه تا فلان نسخه تحت پشتیبانی هستند. مثلاً از 1.9 تا 1.10 به علاوه 2.1 تا 2.3. بعضی‌ها سیاست‌های از پیش تعیین شده دارند مثلاً از قبل اعلام می‌کنند شش ماه از هر major version پشتیبانی می‌کنند. برخی از نسخه‌ها به عنوان LTS (یا Long Time Support) معرفی میشن. یعنی دوره پشتیبانی‌شون طولانی‌تره مثلاً سه سال. یک نگاهی به برنامه پشتیبانی نسخ جاوا بیندازید.7. نسخه snapshot یا pre-release چیه؟وسط اسپرینت که مشغول کد زدن هستیم و قصد ترخیص و نصب نداریم، لازم نیست با هر تغییری نسخه زده بشه. پس شماره نسخه رو با پسوند SNAPSHOT مشخص می‌کنیم. در واقع میشه گفت نسخه SNAPSHOT یه جورایی immutable نیست. بنابراین قابل کش هم نیستند یا موقع کش کردن باید براشون سیاست به‌روزرسانی مشخص کنید. یعنی تعیین کنید روزی یه بار یا ساعتی یه بار یا حتی هر بار نسخه جدید دانلود بشه. 8. مرور همه چی کنار همفرض کنید که برای مخزن کد از گیت و برای مدیریت پروژه از جیرا استفاده می‌کنیم و یک پروژه جاوایی داریم که کار build اش رو به maven سپردیم. گامهای اول پروژه اینطور برداشته میشه:1) پروژه رو می‌سازیم. نسخه توی pom.xml رو برابر 1.0.0-SNAPSHOT مقدار میدیم. اولین فایلهای پروژه در شاخه master پوش میشه. 2) هر تسکی رو انجام دادیم کدش رو کامیت و پوش می‌کنیم. فعلاً در pom.xml، نسخه تغییر نمی‌کنه و هر تسکی که انجام میشه و کدش میاد داخل مخزن گیت، fix version اون تسک در جیرا رو 1.0.0 می‌گذاریم.3) وقتی تصمیم گرفتیم release بدیم، نسخه در pom.xml به 1.0.0 تغییر می‌کنه و کامیت و پوش میشه. یعنی پسوند SNAPSHOT حذف میشه. 4) روی مخزن گیت، از روی شاخه master تگ 1.0.0 ساخته میشه.5) از روی شاخه master، آرتیفکت با نسخه 1.0.0ساخته میشه مثلاً myapp-1.0.0. jar6) در شاخه master در فایل pom.xml نسخه رو یکی می‌بریم بالا. یعنی میریم روی نسخه 1.1.0-SNAPSHOT.7) در جیرای پروژه نسخه 1.0.0 رو release میدیم و نسخه 1.1.0 رو باز می‌کنیم. در ظاهر کار طولانی و سخت شد. ولی عمده کارها مثل ساخت تگ و تولید آرتیفکت‌ها رو میشه به پایپلاین CI/CD سپرد. ۹. اگر باگی روی 1.0.0 گزارش بشه چه کنیم؟ ۱) موقع ترخیص تگ 1.0.0 رو ساخته بودیم. از روی این تگ شاخه‌ای به نام 1.0.x می‌سازیم. در اسم شاخه به جای patch version از حرف x استفاده کردیم. چون برای patch version های بعدی هم از همین شاخه استفاده می‌کنیم. ۲) در فایل pom.xml مقدار نسخه رو از 1.0.0 به 1.0.1-SNAPSHOT تغییر میدیم.۳) اصلاحات رو در کدها اعمال و در شاخه 1.0.x کامیت و پوش می‌کنیم.۴) کار که تموم شد، نسخه رو در pom.xml به 1.0.1 تغییر میدیم (یعنی «SNAPSHOT» رو از تهش برمی‌داریم) و کامیت و پوش می‌کنیم. ۵) در مخزن گیت، تگ 1.0.1 رو از روی برنچ 1.0.x می‌سازیم.۶) آرتیفکت با نسخه 1.0.1 ساخته میشه مثلاً myapp-1.0.1. jar۷) در ایشوی رفع باگ در جیرا مقدار fix version رو برابر 1.0.1 قرار میدیم. ‫۱۰. از پایپ‌لاین CI/CD کمک بگیرید‫در ظاهر کار طولانی و سخت شد. ولی عمده کارها مثل ساخت تگ و تولید آرتیفکتها رو میشه به پایپلاین CI/CD سپرد. اینطوری هم سرعت بالاتر میره و هم مطمئن هستیم همه مراحل به صورت منظم انجام میشه. مثلاً مطمئن میشیم که هر آرتیفکتی ساخته شده حتماً روی گیت، تگ معادلش موجوده. سید جمال الدین پیشوایی سید جمال الدین پیشوایی Thu, 30 May 2024 19:28:15 +0330 https://virgool.io/avansoft/%D8%A8%D9%87-%D8%B9%D9%86%D9%88%D8%A7%D9%86-%D8%B4%D8%B1%DA%A9%D8%AA-%D9%BE%DB%8C%D8%B4%D9%86%D9%87%D8%A7%D8%AF-%D8%AF%D9%87%D9%86%D8%AF%D9%87-%D8%AF%D9%88%D8%B3%D8%AA-%D8%AF%D8%A7%D8%B1%DB%8C%D8%AF-%D9%85%D8%B4%D8%AA%D8%B1%DB%8C-%D8%AF%D8%B1-rfp-%DB%8C%DA%A9-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%DA%86%D9%87-%DA%86%DB%8C%D8%B2%D9%87%D8%A7%DB%8C%DB%8C-%D9%86%D9%88%D8%B4%D8%AA%D9%87-%D8%A8%D8%A7%D8%B4%D9%87-js3jzv2kdfox بسم الله الرحمن الرحیماصلاً RFP چیه؟قصه از این جا شروع میشه که سازمانها برای رفع برخی از نیازهای نرم افزاریشون باید از شرکتهای نرم افزاری کمک بگیرند. پس سندی که اصطلاحاً Request For Proposal یا با اختصار RFP نامیده میشه رو تنظیم و منتشر می کنند و منتظر میشن تا شرکتهای نرم افزاری بهشون پیشنهاد (Proposal) بدهند. برای سازمان مهمه RFP طوری تنظیم بشه کهنیازهای سازمان از هر جهت برای پیشنهاد دهندگان روشن بشه تا بتونند پیشنهادات دقیقی بدهند و هزینه و زمان پروژه رو به خوبی تخمین بزنند.مسیر انتخاب شرکت برتر رو هموار کنه.پیوست خوبی برای قرارداد با شرکت منتخب باشه و به خوبی محدوده وظایف رو شفاف کنه.حالا سوال چیه؟گاهی سازمانها از تیم چکاپ شرکت اعوان برای تنظیم RFP کمک میگیرند. شاید در سال گذشته بیش از ۱۰ بار درگیر چنین موقعیتی شدیم. سوال اینه که شما به عنوان یک شرکت نرم افزاری توقع دارید چه جور اطلاعاتی در RFP ذکر شده باشه؟ ترجیح میدید RFP چه بخشهایی داشته باشه؟نظر خودتون چیه؟ما در تیم چکاپ شرکت اعوان به مرور متوجه شدیم که خوبه در RFP این بخشها رو داشته باشیم؟خلاصه مدیریتیاین بخش در چند صفحه به مدیران شرکتها کمک میکنه تصمیمشون رو درباره پاسخگویی به RFP بگیرند. در این بخش «معرفی سازمان مشتری»، «معرفی پروژه» از جمله موضوع، جایگاه و مقیاس پروژه و همچنین «معرفی اهداف پروژه» صورت میگیره.بیان مسالهاین بخش روی تشریح مساله ای که قراره با وجود این پروژه حل بشه تمرکز میکنه. از جمله مفاهیم، دامنه مساله، قوانین مرتبط، وضع موجود و ذی نفعان در این بخش مورد اشاره خواهند بود.اهداف پروژهاین بخش از دو منظر به اهداف پروژه می پردازه. بخش اول با عنوان «اثرات پروژه» میگه که قراره بعد از اجرای این پروژه، عالم چه شکلی بشه. بخش دوم با عنوان «ویژگیهای کلی راهکار» توقعات کلی مشتری از ویژگی های راهکاری که قراره «اثرات پروژه» رو محقق کنه بیان خواهد شد.خدمات درخواستیاز مجری پروژه توقع داریم چه کارهایی برای مشتری انجام بده؟ تولید و نصب نرم افزار سفارشی، نصب و استقرار بسته نرم افزاری، پشتیبانی از نرم افزار و آموزش از خدمات درخواستی رایج هستند.کارکردهای محصولدر این بخش کارکردهای محصول مورد نظر (Functional Requirements) به صورت دسته بندی شده بیان میشه. از روی این بخش میشه متوجه ویژگی های ظاهری و رفتاری محصول شد.ملزومات فنیبر خلاف بخش قبلی این بخش روی لایه های پنهانتر پروژه و ساختار محصول دست میگذاره. از جمله «تحویلدادنی ها» شامل کد و انواع مستند و زمان و فرکانس تحویل و نحوه تحویل هر کدوم به تفصیل بیان میشه. «ویژگیهای کیفی» مثل نرخ دسترس پذیری، مقیاس قابل تحمل و غیره در این بخش قرار می گیرند. فناوریهای قابل استفاده، توپولوژی شبکه، زیرساختهای اجرای نرم افزار، ساز و کارهای کیفی مطلوب، روشهای آزمون، ساز و کارهای نصب و سایر مسائل فنی در این بخش مقید خواهند شد.ویژگیهای مطلوب پیشنهاد دهندگاناین بخش با اشاره به مجوزها، رتبه بندیها، مقیاس تیم، سوابق مورد نیاز، توان مالی و امثال آنها ویژگی های ضروری و ترجیحی پیشنهاد دهندگان رو بیان میکنه.ساختار پیشنهادنامهاین بخش ساختار پیشنهادات رو مشخص میکنه و به شرکتها میگه در پیشنهادشون چه بخشهایی داشته باشند و در هر بخش به چه مطالبی و در چه حد اشاره کنند. برای هر بخش، زیربخشها، قالبها و قیودی مشخص میشه. «خلاصه مدیریتی»، «بیان مساله» (از نگاه پیشنهاد دهنده)، «راهکار پیشنهادی»، «جدول تطبیق»، «معرفی افراد کلیدی تیم پروژه»، «متدلوژی»، «برنامه زمانی»، «پیشنهاد مالی» و «معرفی شرکت» از جمله بخشهای درخواستی رایج هستند.حالا ممنون میشم اگر شما مخاطب بالقوه RFP سازمانها هستید بفرمایید دوست دارید در این اسناد چی ببینید؟ یا اگر RFP خوبی سراغ دارید معرفی بفرمایید. سید جمال الدین پیشوایی سید جمال الدین پیشوایی Thu, 30 May 2024 11:21:18 +0330 https://virgool.io/avansoft/%D8%A7%D8%AC%D8%AA%D9%86%D8%A7%D8%A8-%D8%A7%D8%B2-vendor-lock-in-%DA%86%D8%B1%D8%A7-%D9%88-%DA%86%DA%AF%D9%88%D9%86%D9%87-qk6lnqiaoe4b بسم الله الرحمن الرحیمفرایند تامین نیازهای نرم‌افزاری سازمانشما مدیر فناوری اطلاعات (CIO) یک سازمان هستید؟ اگر باشید حتماً هر روز و هر شب واحدهای سازمان برای پیش‌برد بهتر کارهاشون از شما نرم‌افزار میخوان. در واقع یکی از وظایف اصلی CIO تامین نیازهای نرم‌افزاری سازمانه. شما باید تصمیم بگیرید چه نیازی رو چه جوری تامین کنید. کجا برید سراغ خرید بسته‌های نرم‌افزاری آماده؟ کی پروژه تولید نرم‌افزار سفارشی تعریف کنید؟ چه مواردی رو به تیم توسعه داخل سازمان بسپارید؟ کجا از سرویس‌های آماده (SaaS) استفاده کنید؟ تا کجا میشه به BPMS یا Low Code Platform اتکا کرد؟ کی از شرکتهای بزرگ و کجا از شرکتهای کوچک کمک بگیرید؟ مزیت دانشگاه‌ها و پژوهشگاه‌ها در چه جور کارهاییه؟ اگر چیزی فرایند تامین نیازهای نرم‌افزاری سازمان رو مختل کنه کارآمدی شما در انجام وظایف‌تون زیر سوال میره. طبق تجربه شما چه چیزهایی می‌تونند این فرایند رو مختل کنند؟ مهمترین عامل اختلال چی می‌تونه باشه؟ در ادامه میخوام پاسخ تیم چکاپ شرکت اعوان رو به این سوال بیان کنم. قفل شدن به فروشنده (Vendor Lock-in)به عنوان یک CIO دانش و تجربه ما دایماً در حال رشده. طبیعیه که به مرور متوجه برخی اشتباه‌مون بشیم. مثلاً ممکنه جایی که باید یک بسته نرم‌افزاری برای سازمانی می‌خریدیم یک پروژه سفارشی تعریف کرده باشیم. حتی اگر اشتباهی نکرده باشیم تغییر نیازهای سازمان، اقتضائات جدیدی ایجاد می‌کنه. خوب بسم‌الله. هر کاری لازم باشه برای بهتر کردن اوضاع انجام میدیم. هدف جدید و مسیر رسیدن بهش مشخص میشه و راه میفتیم. راه میفتیم مگر اینکه دست و پامون بسته شده باشه. محدودیت‌های متنوعی می‌تونند مانع حرکت ما بشن. بودجه،‌ بوروکراسی، تضاد منافع و غیره. یکی از این محدودیت‌ها هست که می‌تونه مستقیماً به میزان درایت CIO برگرده و اون چیزی نیست به جز «قفل شدن به فروشنده» یا به قول خارجی‌ها Vendor Lock-in. «قفل شدن به فروشنده» یعنی سازمان از ترس مخاطرات و هزینه‌های مهاجرت به یک محصول جدید، مجبور به ادامه استفاده از محصول فعلی میشه، حتی اگر از وضع موجود راضی نباشه. همیشه اینطوری نیست که فروشنده، سازمان رو در این وضعیت گیر بیندازه. گاهی فروشنده و خریدار با هم در این بن‌بست گرفتار و متضرر میشن. شاید باورش سخت باشه ولی مشاهدات ما در تیم چکاپ نشون میده برخی از مشکلات کلان اقتصادی کشور و زمینه‌های فساد یا ناکارآمدی سازمانها به Vendor Lock-in ارتباط دارند. در حدی که بعضاً کار به مجلس و سران قوا رسیده. آثار قفل‌شدن به فروشندهتامین نشدن برخی از نیازهای نرم‌افزاری: ممکنه سیستم موجود اساساً نتونه برخی از نیازهای امروز سازمان رو تامین کنه یا اینکه فروشنده مایل نباشه زیر بار بعضی از کارها بره. تحمیل هزینه و زمان بیشتر: قفل شدن باعث میشه بهینه‌ترین گزینه رو از دست بدیم یعنی بیشتر پرداخت کنیم و کمتر به دست بیاریم. ممکنه محصول فعلی نتونه با چیزی که سازمان امروز لازم داره، به راحتی تطبیق پیدا کنه.افت انگیزه و تغییر رفتار فروشنده: قفل شدن، این موقعیت رو به فروشنده بی‌انصاف میده که درخواست‌های شما رو دیرتر و گرانتر پاسخ بده. البته تغییر رفتار معمولاً به دلیل بی‌انصافی فروشنده نیست. شرکتها مجبورند هر از چندی خطوط تجاری‌شون رو تغییر بدهند. وقتی کار سازمان از خط تجاری فعلی شرکت خارج بشه برای انجام کارها، هزینه و زمان بیشتری به شرکت و سازمان تحمیل خواهد شد.افت کیفیت: همه دلایل بالا می‌تونه به افت کیفیت نرم‌افزار و کاهش رضایت بهره‌بردار منجر بشه. اگر قراره در فرایند تامین نیازهای نرم‌افزاری سازمان حواستون فقط به یک چیز باشه اون یک چیز «جلوگیری از قفل شدن به فروشنده» است. تکنیک‌های اجتناب از قفل شدن به فروشندهدر تیم چکاپ شرکت اعوان برای جلوگیری از قفل شدن به فروشنده تکنیک‌هایی رو به سازمانها پیشنهاد می‌کنیم. اینجا خیلی گذرا به چند مورد پرکاربرد اشاره می‌کنم. حفظ مالکیت داده: بدترین نوع قفل شدنی که مشاهده کردیم در شرایطی رخ داده که سازمان به داده خودش دسترسی نداشته. تولید یک نرم‌افزار مشابه سخته ولی تولید داده‌های قبلی معمولاً غیرممکنه. تحویل گرفتن کدهای منبع: اگر نرم‌افزار سفارشی تهیه کردید به شیوه مطمئنی کدهای منبع رو تحویل بگیرد، طوری که مطمئن باشید همیشه کد آخرین نسخه نصب شده رو دارید. همکاری موازی با چند فروشنده: برای برخی از موضوعات میشه همزمان از چند فروشنده استفاده کرد. مثلاً میشه همزمان از دو شرکت، سرویس زیرساخت ابری گرفت. استفاده از محصولات متن‌باز معتبر: احتمال اینکه بتونید برای یک محصول متن‌باز معتبر یک سرویس دهنده جدید پیدا کنید بیشتره تا یک محصول تجاری. مستقل بودن سرویس‌دهنده انباره داده و هوش تجاری: در این دوره زمونه سازمان بدون انباره داده و هوش‌تجاری مثل زنبور بی‌عسل می‌مونه. دغدغه‌های هوش تجاری رو از دل پروژه‌ها بیرون بکشید و یک پیمانکار مستقل براش انتخاب کنید. اینطوری یک کپی دیگه از داده‌ها خواهید داشت و تیم دیگری که نسبت به اونها شناخت داره. البته این کار مزایای دیگری هم داره که در این مقال نمی‌گنجه. مستقل بودن سرویس‌دهنده زیرساخت ابری: نگید که «معماری میکروسرویس» رو در تعریف همه پروژه‌هاتون نمی‌گنجونید. لازمه معماری میکروسرویس داشتن «زیرساخت ابری» هست. راه‌اندازی زیرساخت ابری رو از محدوده پروژه‌ها خارج کنید و به یک یا چند سرویس‌دهنده مستقل بسپارید که به تولیدکنندگان نرم‌افزار سرویس میده. اینطوری ضمن اینکه به تخصص‌گرایی،‌ کیفیت سرویس، کاهش هزینه‌ها و مدیریت بهینه‌تر منابع کمک میشه، با ایجاد یک برش افقی در مسئولیت‌ها موجب استاندارد شدن فرایند نصب و راه‌اندازی و شفاف شدن ابعادی از معماری خواهیم شد. البته مخاطراتی هم داره که باید کنترلش کنیم. استفاده از Low Code Platformها: برخی ابزارها، از توسعه سیستم با دانش کمِ برنامه‌نویسی (Citizen Development) پشتیبانی می‌کنند. با به کارگیری اونها می‌تونید برخی نیازهای سازمان رو به کارشناسان داخلی بسپارید. کوچک کردن پروژه‌ها: گاهی بهتره به جای یک پروژه بزرگ، چند تا پروژه کوچک‌تر با مرزهای شفاف تعریف کنیم. قطعات کوچکتر راحت‌تر قابل جایگزینی هستند. به همین دلیل معماری میکروسرویس رو به عنوان راهکار اجتناب از قفل شدن به فروشنده معرفی می‌کنند. البته تعدد پروژه‌ها سربار مدیریت رو بیشتر می‌کنه. مستندسازی و استاندارد کردن: لازمه که از همه فروشنده‌ها مستنداتی رو بخواهید و یک سری استانداردهای فنی رو طراحی کنید که همه ملزم به رعایت کردنش باشند. یکی از کمک‌هایی که ما در تیم چکاپ به سازمانها و پیمانکاران‌شون می‌کنیم کمک به مستندسازی، طراحی استانداردهای فنی و ارزیابی میزان رعایت اونهاست. از قفل شدن اجتناب کنید تا بتونید بیشتر با یک فروشنده ادامه بدید!تغییر فروشنده به هر حال گزینه دوست‌داشتنی، بدون مخاطره و کم‌هزینه‌ای نخواهد بود. هزینه‌ها و مخاطرات قابل کم کردن هستند ولی صفر نمیشن. با رعایت این تکنیک‌ها زمینه برای ادامه همکاری رضایت‌بخش بین فروشنده و خریدار در دوره طولانی‌تر فراهم میشه. دعوت به همکاریامیدوارم این مطلب مفید بوده باشه. اگر یک مهندس نرم‌افزار با تجربه هستید و دوست دارید به کارآمدی سازمانها کمک کنید، از حضورتون در تیم چکاپ استقبال می‌کنیم. با چند ساعت وقت در هفته می‌تونید تاثیرگذار باشید. در لینکدین منتظر پیام شما هستم. اگر در اوایل این مسیر هستید و دوست دارید تجربیات‌تون رو در تیم چکاپ تکمیل کنید ممنون میشم از اینجا شرح شغلی «کارشناس کیفیت نرم‌افزار» رو ملاحظه کنید. سید جمال الدین پیشوایی سید جمال الدین پیشوایی Thu, 07 Dec 2023 20:26:41 +0330 https://virgool.io/avansoft/arch-decision-nizoadqaro7j بسم الله الرحمن الرحیمروال تصمیم‌گیری در معماری نرم‌افزارروال تصمیم‌گیری چه جایگاه و اهمیتی در تدوین معماری نرم‌افزار دارد؟ روش تصمیم‌سازی و تصمیم‌گیری مطمئن چه ویژگیهای باید داشته باشد؟ چطور تصمیمات‌مان را مستند کنیم؟ جایگاه تصمیم‌گیری در عملیات معماری نرم‌افزارهمانطور که قبلاً شرح دادم من این تعریف را برای معماری نرم‌افزار بیشتر می‌پسندم:تعریف معماری نرم افزار: مجموعه تصمیمات مهم در فرایند توسعه نرم‌افزار با هدف مدیریت مخاطراتبا این تعریف تقریباً می‌توان گفت معماری نرم‌افزار چیزی جز تصمیم‌گیری نیست. بعد از آنکه درک اولیه از فضای مساله پیدا شد، طراحی فضای راه‌حل شروع می‌شود. در این نقطه با دو راهی‌های مختلفی مواجه می‌شویم. از چه جور پایگاه‌داده‌ای استفاده کنیم؟ چه زبان برنامه‌نویسی برای توسعه بک‌اند این محصول مناسب‌تر است؟ محصول را به چه مولفه‌هایی بشکنیم؟ اگر بخواهیم یک نرم‌افزار خوب داشته باشیم باید روال درست تصمیم‌گیری را بلد باشیم. استخراج سؤالات معماریبرای اینکه فکر خود را نظم دهیم، در ابتدا لیستی از سؤالات معماری استخراج می‌کنیم. این لیست اصطلاحاً ADL‌ (مخفف Architecture Decision Log) نامیده می‌شود. برخی از سؤالات ممکن است به هم وابسته باشند. یعنی پاسخ یک سؤال، گزینه‌های سؤال دیگر را محدود یا مقید کرده یا حتی پاسخ خاصی به یک سوال، یک سؤال دیگر را از موضوعیت خارج نماید. در نوشتن سؤالات دست و دل‌باز باشید و هر سوالی به ذهنتان رسید را بنویسید. سعی کنید سؤالات کاملاً شفاف و غیر کلی باشند. سؤالات را از جهت اهمیت و تاثیرگذاری اولویت‌بندی کنید. در ادامه مسیر هر جا خودتان را در یک دو راهی یا چند راهی دیدید،‌ آن را به صورت یک سؤال مستقل یادداشت نمایید. قالب پاسخگویی به سؤالات معماریبرای پاسخگویی صحیح به سؤالات معماری گامهای زیر پیشنهاد می‌شود. شرح سؤال: قبل از هر چیز باید سؤال به خوبی تبیین شود. ممکن است لازم باشد پیش‌فرضها و زمینه سؤال کمی توضیح داده شود. تعیین معیارها: نیاز به معیارهایی داریم که بتوانیم گزینه‌های مختلف را با آنها بسنجیم. مثل پوشش نیازهای کارکردی و کیفی، عدم نقض محدودیتهای معماری، قیمت خرید مجوز بهره‌برداری،‌ منحنی یادگیری، دسترسی به نیروی انسانی متخصص، هزینه‌های پشتیبانی و غیره. باید معیارها را وزن‌دهی کرده و خطوط قرمز را مشخص کنیم. طراحی گزینه‌ها: برای هر سؤال معماری چند گزینه پاسخ طراحی کنید. اگر فقط به یک گزینه پاسخ رسیدید به احتمال زیاد به اندازه کافی روی گزینه‌ها فکر نکردید. ارزیابی گزینه‌ها: گزینه‌هایی که طراحی کرده‌ایم را بر اساس معیارها سنجیده و مزایا و معایب هر یک را مشخص می‌کنیم. جمع‌بندی: نهایتاً با سبک و سنگین‌ کردن گزینه‌ها یک پاسخ را انتخاب می‌کنیم. در صورت نیاز می‌توانیم پاسخ انتخاب شده و تبعات و ملزومات آن را بیشتر شرح دهیم. اهمیت مستندسازی تصمیمات معماریاهمیت مستندسازی تصمیمات معماریتیم‌های نرم‌افزاری معمولاً در قالب «سند معماری نرم‌افزار» یا SAD ساختار محصول‌شان را مستند می‌کنند. ولی مستندسازی تصمیمات معماری رواج کمتری دارد. در سالهای اخیر روی مستندسازی تصمیمات معماری در قالب ADR (مخفف Architecture Decision Record) تاکید بیشتری می‌شود (مثل این و این و این). چرا که کمک می‌کند دلیل تصمیمات معماری را افراد بیرون تیم یا اعضای جدید تیم سریعتر درک کنند و حتی در طول زمان در بازنگری تصمیمات به تیم کمک می‌نماید. چند ADR‌ نمونه اینجا قابل مشاهده است. مستندسازی بخشی از فرایند تصمیم‌گیریدر شرکت اعوان تجربه بسیار مثبتی از مستندسازی تصمیمات معماری در حین فرایند تصمیم‌گیری داریم. یعنی به جای آنکه پس از انعقاد تصمیمات آنها را مستند کنیم، معمار نرم‌افزار در حین تصمیم‌گیری دست به قلم می‌شود. سؤالات را نوشته و پاسخها را در قالب مورد نظر وارد می‌کند. مهمترین دستاورد این روش آن است که ذهن معمار نرم‌افزار حین تصمیم‌گیری منظم‌تر شود. از طرفی بلافاصله می‌تواند مستند را با دیگر اعضای تیم به اشتراک گذاشته و قبل از انعقاد تصمیم نظر آنها را بگیرد. ما در سالهای اخیر برای مستندسازی از Confluence بهره‌ می‌گیریم. با این ابزار اعضای تیم می‌توانند نظرات خود را به صورت Inline Comment‌ با معمار نرم‌افزار تبادل کنند. یعنی مستند بخشی از فرایند تصمیم‌گیری است و نه فقط خروجی آن. البته این شیوه تبادل نظر برای برخی از موضوعات پیچیده و چند وجهی کارآمد نیست. در این موارد از جلسات تصمیم‌گیری گروهی استفاده می‌کنیم. ان شاء الله در آینده راجع به ملزومات و ساختار جلسات تصمیم‌گیری گروهی در زمینه معماری نرم‌افزار خواهم نوشت. سید جمال الدین پیشوایی سید جمال الدین پیشوایی Sun, 13 Feb 2022 03:00:53 +0330 https://virgool.io/avansoft/%DA%AF%D8%A7%D9%85-%D9%86%D8%AE%D8%B3%D8%AA-%D8%AF%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-b3axmtebmmvq گام اول در معماری نرم افزاربسم الله الرحمن الرحیمعملیات معماری یک نرم‌افزار چطور شروع می‌شود؟ گام اول برای معماری یک نرم‌افزار چیست؟ اصلاً «معماری نرم‌افزار» چه مفهومی دارد؟ تعریف مهندسی نرم افزاربرای اینکه بدانیم معماری نرم‌افزار چه معنایی دارد و گام نخست آن چیست، اول باید به معنای مهندسی نرم‌افزار دقت کنیم. «مهندس» در لغت به معنای محاسب یا شماردار است. هدف دانشمند دانستن آن است در حالیکه هدف مهندس به کار گیری دانسته‌هاست. هنرمند بر اساس ذوق عمل میکند ولی مهندس بر اساس محاسبه. و اما «نرم‌افزار»، محصول کار برنامه‌نویسان است. به آن «نرم» می‌گوییم چون قرار است انعطاف پذیر و قابل تغییر باشد. با این تفاصیل من این تعریف را برای مهندسی نرم افزار می پسندم:تعریف مهندسی نرم افزار: به کاربردن قواعد مهندسی برای اتخاذ رویکردی نظام مند و ساخت یافته در تولید محصول نرم افزاری مشخص با هزینه، زمان و کیفیت بهینهمتغیرهای اصلی یک پروژه (نرم افزاری یا غیر نرم افزاری)تعریف مخاطرهوظیفه مهندس نرم افزار آن است که با محاسبات دقیق، روندی را طراحی کند که یک پروژه نرم افزاری با هزینه، زمان و کیفیت مطلوب و قابل پیش‌بینی به ثمر برسد. مخاطره (یا ریسک) عاملی است که موجب افزایش پیش بینی نشده و خارج از کنترل هزینه و زمان پروژه یا کاهش کیفیت آن گردد. مثلاً عوامل زیر می‌تواند یک پروژه نرم‌افزاری را با مخاطره افزایش زمان و هزینه یا افت کیفیت مواجه نماید.انتخاب فناوری نامناسبدرک نادرست یا ناقص نیازهای محصولاز دست دادن برخی اعضای تیمچالشهای کیفی (امنیت، کارایی، ....)اهمیت یک مخاطره تابع احتمال وقوع آن و نیز دامنه یا شدت تاثیرگذاری آن می باشد. ماتریس ارزیابی اهمیت ریسکساختار و رفتار محصول نرم‌افزارییک محصول نرم‌افزاری در دو بعد قابل تعریف است:رفتار محصول: محصول چه کار می کند؟ساختار محصول: محصول چه طور کار می کند؟مشتری در نگاه اول رفتار محصول را مطالبه می‌کند. توجه بیش از حد به رفتار، موجب ساختار نامطلوب می‌شود. ساختار نامطلوب به مرور مانع پیاده‌سازی رفتارهای مطلوب می‌شود. ساختار همیشه مهم است ولی فوری نیست. رفتار معمولاً فوریت بیشتری دارد ولی همیشه مهم نیست. برای درک بهتر تفاوت امور فوری و امور مهم نگاهی به ماتریس آیزنهاور بیندازید. تعریف معماری نرم‌افزارتعاریف مختلفی برای معماری نرم‌افزار ارائه شده است. برخی ساختارهای کلی و کلان محصول را معماری و در مقابل ساختارهای جزئی محصول را «طراحی» می‌نامند. برخی معماری را معادل تصمیمات پر دامنه می‌دانند. یعنی تصمیماتی که در پیاده‌سازی تعداد زیادی از قابلیتهای محصول نمود دارند؛ مثل تصمیم انتخاب کتابخانه واسط کاربر. در مقابل تصمیمات کم دامنه که روی پیاده‌سازی یکی یا دو قابلیت محصول تاثیرگذار هستند را طراحی می‌نامند. این در حالی است که گاهی تصمیمات جزئی یا تصمیمات کم دامنه هم سرنوشت پروژه را تحت تاثیر قرار می‌دهند. بنابراین من این تعریف را برای معماری نرم افزار بیشتر می‌پسندم:تعریف معماری نرم افزار: مجموعه تصمیمات مهم در فرایند توسعه نرم‌افزار با هدف مدیریت مخاطراتگام نخست در معماری نرم‌افزارهمانطور که ملاحظه کردید، مفهوم «معماری نرم افزار» با مفهوم «مخاطره» گره خورده است. وقتی یک پروژه نرم‌افزاری شروع می‌شود در واقع از ما خواسته‌اند برای یک مساله، یک راه حل نرم‌افزاری ارائه کنیم. اولین گام یک پروژه نرم‌افزاری، درک مساله یا شناخت نیازهاست که توسط تیم تحلیل صورت می‌پذیرد. پس از شناخت نیازها، نوبت به طراحی راه حل می‌رسد. معمار نرم‌افزار اولین کسی است که طراحی راه حل را پایه‌گذاری می‌کند. خبر بد اینکه شناخت دقیق و جزئی نیازها در پروژه‌های نرم‌افزاری واقع‌بینانه و به‌صرفه نیست. در متدلوژیهای چابک رایج، به مستندسازی کلیاتی از نیازها بسنده می‌شود. بنابراین معمار نرم‌افزار با اتکا به خبرگی و تجربیات خود سعی می‌کند، زوایایی از نیازمندیها که بر روی چارچوب کلی راه حل تاثیرگذار هستند یا می‌توانند مخاطره‌آمیز باشند را شناسایی و شفاف نماید. این نیازمندیها ممکن است از جنس کارکردی (Functional) یا ویژگیهای کیفی (Quality Attributes) باشند. نخستین گام در معماری نرم‌افزار، استخراج لیستی از نیازهاست که می‌توانند چارچوب کلی راه حل را تعیین کنند یا زمینه‌ساز مخاطراتی گردند. اصطلاحاً این نیازها را Architecturally Significant Requirements یا به اختصار ASR می‌نامند. قالب 4 + 1 یکی از رایج ترین قالبهای مستندسازی معماری محصولات نرم‌افزاری است. قرار گرفتن نمای مورد کاربرد (Use Case View) در قلب این اسناد، اثبات دیگری بر محوریت شناخت نیازها در عملیات معماریست. برای آشنایی بیشتر با روش مستندسازی معماری محصولات نرم‌افزاری پیشنهاد می‌کنم این فیلم آموزشی ارزشمند از آقای دکتر علی‌اکبری را مشاهده فرمایید.مرور یک مثالاگر از یک معمار نرم‌افزار بخواهید، سرویسی برای برقراری تماسهای صوتی آنلاین را پایه‌گذاری کند، احتمالاً برای استخراج ASR ها با چنین سوالاتی مواجه خواهید شد:چند نفر قرار است از این سرویس استفاده کنند؟ باید از چند تماس همزمان پشتیبانی شود؟ به طور متوسط چند تماس صوتی در روز صورت می‌گیرد؟ هر تماس صوتی به طور متوسط چند ثانیه طول می‌کشد؟ آیا لازم است، فایل تماسهای صوتی آرشیو شود؟ اگر هست برای چه مدت؟ تماس گروهی در چشم‌انداز کوتاه‌مدت یا میان‌مدت این سرویس وجود دارد؟چه میزان از محرمانگی ضرورت دارد؟ آیا رمزنگاری سر به سر (end to end encryption) ضرورت دارد؟ سرویس در یک مرکز داده ارائه می‌شود یا چند مرکز داده موازی؟ ان شاء الله در پستهای بعدی راجع به گامهای بعدی در عملیات معماری نرم‌افزار خواهم نوشت. سید جمال الدین پیشوایی سید جمال الدین پیشوایی Fri, 08 Oct 2021 03:53:37 +0330 https://virgool.io/avansoft/%DA%A9%D9%85%D8%A7%D9%84-event-sourcing-%D8%A8%D8%A7-%D8%A7%DA%A9%D8%AA%D9%88%D8%B1-%D9%85%D8%AF%D9%84-fnnmusfwwaqz Event Sourcing with Akkaبسم الله الرحمن الرحیم‫ده سال پیش حاج مهران حیدرزاده گزارشی از معماری بستر مالی LMAX به قلم برادر مارتین فاولر را به گروه ایمیلی شرکت اعوان ارسال کردند. با خواندن گزارش پرام ریخت. ببخشید منظورم اینه که خیلی شگفت زده شدم. پردازش 6 میلیون سفارش در ثانیه آن هم فقط با یک thread. این گزارش به مفهوم Event Sourcing پرداخته بود.Event Sourcing means that the current state of the Business Logic Processor is entirely derivable by processing the input events. As long as the input event stream is kept in a durable store (which is one of the jobs of the input disruptor) you can always recreate the current state of the business logic engine by replaying the events.‫ راز رکورد شکنی LMAX این بود که اولاً آخرین وضعیت داده را به طور کامل در حافظه نگهداری میکرد. بنابراین دیگر نیازی به IO و مدیریت تراکنش برای خواندن و نوشتن داده نداشت. ثانیاً پردازش همه رویدادها را در یک thread انجام میداد. بنابراین دیگر نیازی به lock کردن thread ها جهت اجتناب از مشکلات همروندی نبود. فرض کنید یک سامانه بانکی موجودی حساب همه مشتریان را در حافظه موقت نگه دارد و هر برداشت یا واریزی را بلافاصله در حافظه موقت اعمال نماید.بسیار سریع و عالی. فقط یک مشکل کوچک! اگر سیستم خاموش شد، داده ها از حافظه موقت پاک می شوند. برای حل این‫ مشکل lmax رویدادهای ورودی به سامانه را در یک پایگاه داده فقط افزودنی (append-only) و غیر قابل تغییر(immutable) ثبت می کرد. مثل اینکه در سیستم بانکی همه دستورات برداشت و واریز را در یک فایل لاگ کنیم. اگر سیستم پایین و بالا شد، از ابتدای فایل لاگ، دوباره رویدادهای ورودی را اجرا (replay) میکنیم تا در حافظه موقت به وضعیت درست برسیم. خوب به سلامتی این مشکل حل شد.فقط یک مشکل دیگر! با گذشت زمان تعداد رویدادها زیاد میشود. در نتیجه پایین و‫ بالا شدن سیستم و بازسازی آخرین وضعیت در حافظه موقت، ساعتها یا روزها طول خواهد کشید. فرض کنید در مثال بانک قرار باشد، برای کشف موجودی هر حساب، همه برداشتها و واریزهای طول تاریخش را مجددا اجرا کنیم. برادرانمان در LMAX برای حل این مشکل هر از چندی از حافظه موقت Snapshot تهیه و در یک پایگاه داده مناسب ذخیره سازی می نمایند. در اینصورت بعد از پایین و بالا شدن سیستم، ابتدا آخرین Snapshot در حافظه موقت بارگزاری شده و سپس رویدادهای بعد از آن Snapshot اعمال میشوند.بسیار خوب. به نظر میرسد همه چیز مرتب است. ولی همیشه می شود اوضاع را بهتر کرد.اگر میتوانستیم در عین حالی که از درگیر شدن با مشکلات‫ همروندی اجتناب میکنیم، محدود به یک thread نباشیم. بلکه از تمام ظرفیت پردازنده یا حتی چند سرور موازی استفاده نماییم، بهتر بود.همچنین بهتر است محدود به حافظه یک سرور نباشیم. مثلاً بتوانیم موجودی برخی حسابهای بانکی را روی‫ حافظه موقت سرور یک داشته باشیم و برخی سرور دو.برای مصرف کمتر حافظه بهتر بود به جای بارگزاری موجودی همه حسابهای بانکی، هر حسابی را که رویدادی‫ روی آن حادث شد، مدتی وارد حافظه کرده و آخرین وضعیت او را بازسازی کنیم. سپس رویداد جدید را اعمال نموده و اگر مدتی رویدادی روی آن نیامد، آخرین snapshot آن رکورد را ذخیره و وی را از حافظه موقت خارج کنیم.‫بیایید مثال سیستم بانکی را با کمک «اکتور مدل» کمی بهتر کنیم. اگر با اکتور مدل آشنا نیستید، پیشنهاد میکنم این مقاله را‫ در مورد ضرورت آشنایی با «اکتور مدل» ملاحظه بفرمایید.به ازای هر حساب بانکی یک اکتور در نظر میگیریم. اکتور حساب، موجودی خود را در فیلدی در حافظه اش‫ نگه میدارد.‫رویدادهای برداشت و واریز هر حساب را در mailbox اکتور وی قرار میدهیم تا یکی یکی‫ اعمال شوند. چون میدانیم هیچگاه همزمان دو thread سراغ یک اکتور نمی آیند، مشکل همروندی و تداخل thread نداریم. ولی در کل محدود به یک thread نشدیم. چرا که دو اکتور مختلف می توانند همزمان با کمک دو thread به پیش بروند. بنابراین راحت می توانیم فیلد موجودی را کم و زیاد کنیم.‫‫اکتورها می توانند روی نودهای مختلف کلاستر توزیع شوند. بنابراین محدود به حافظه یک ماشین نیستیم.‫هر اکتور به سبک Event Sourcing رویدادهای وارده را در یک پایگاه داده لاگ میکند. هر از چندی هم از آخرین وضعیت خود اسنپ شات گرفته و در جای مناسبی ذخیره می کند.هر اکتوری که رویدادی به وی گزارش شود، به طور خودکار زنده شده و ابتدا وضعیت موجودی حساب را‫ از آخرین Snapshot بازخوانی میکند. سپس رویدادهای موجود در mailbox خود را اعمال می نماید. اکتوری که مدتی رویدادی نداشت را میکشیم. به این ترتیب برای حسابهای راکد حافظه ای اشغال نمی شود.خوشبختانه akka به عنوان یک بستر «اکتور مدل»، ساز و کار مناسبی برای پشتیبانی از Event Sourcing یا به‫ اصطلاح قدیمی ترش Akka Persistance دارد.‫اگر به مشارکت در یک پروژه چالشی مبتنی بر akka و اکتورمدل علاقه مند هستید، اینجا منتظر شما هستیم. سید جمال الدین پیشوایی سید جمال الدین پیشوایی Thu, 07 Oct 2021 23:46:00 +0330 https://virgool.io/avansoft/%DA%86%D8%B1%D8%A7-%D9%BE%D8%A7%D8%B1%D8%A7%D8%AF%D8%A7%DB%8C%D9%85-%D8%A7%DA%A9%D8%AA%D9%88%D8%B1-%D9%85%D8%AF%D9%84-%D9%85%D9%87%D9%85-%D8%A7%D8%B3%D8%AA-otvcawtazlel Actor Model with Akkaبسم الله الرحمن الرحیم‫همه ما با برنامه نویسی شیء گرا آشنا هستیم. کم و بیش با Aspect Oriented Programming آشنایی داریم. اخیراً Reactive Programming فراگیرتر شده است. ولی خیلی از ما چیز زیادی راجع به پارادایم Actor Model نمی دانیم. با اینکه در دوره دانشجویی اشاراتی به این پارادایم شد، ولی من درک خوبی از اهمیت و کاربرد آن پیدا نکردم. در سالهای بعد از دانشگاه هر از چندی گذارم به سایت akka می افتاد ولی زیاد بند نمی شدم. گویا برای یادگیری و استفاده از آن اینرسی داشتم.اواخر سال 96 مسئولیت پژوهش درباره «معماری مقیاس پذیر پیام رسان» به شرکت اعوان سپرده شد. در این مطالعات متوجه‫ شدیم بسیاری از پیام رسانهای معروف از «اکتور مدل» استفاده می کنند. عبرت آموز آنکه باز سعی داشتم، به جای استفاده از پلتفرمهای اکتوری با ترفندهایی خاصیت اکتورها را شبیه سازی کنم. در نهایت پس از بررسی پیام رسان متن باز actor.im مجاب شدم اکتور مدل را امتحان کنیم. اینجا بود که فهمیدم نسبت به یک پارادایم مهم برنامه نویسی غفلت کامل داشتم.‫ سعی میکنم برخی از خواص برنامه نویسی با مدل اکتور را توضیح دهم با این امید که توجه بیشتری به این پارادایم‫ مفید و پرکاربرد در ایران ایجاد شود.‫مزیت اول - راه حل متفاوتی برای مدیریت همروندی (Concurrency Management)از پیام رسان مثال میزنم. میخواهیم تعداد بازدیدهای یک پست در یک کانال پرمخاطب را بشماریم. در روش متعارف‫ اینطور عمل میکنیم.‫یک میکروسرویس مسئول شمردن تعداد بازدید پستهاست. برای مقیاس پذیری (scalability) و دسترسی پذیری (availability) چندین نمونه (instance) از این میکرسرویس بالا می آوریم. این میکروسرویسها کاملاً stateless هستند.‫تعداد بازدیدها را در یک پایگاه داده sql (مثل postgres) یا no-sql (مثل redis) نگه میداریم.‫برای اینکه چند نود یا چند thread مستقل با دستکاری همزمانِ «تعداد بازدید یک پست» خرابکاری نکنند، باید از یک قفل توزیع شده (distributed lock) استفاده شود. یعنی thread ای که میخواهد تعداد بازدید را زیاد کند باید block شود تا وقتی اختیار قفل توزیع شده را به دست بیاورد و مطمئن شود thread دیگری روی این رکورد فعال نیست. آنگاه می تواند عدد قبلی را بخواند و عدد جدید را بنویسد.حالا ببینیم این مساله با مدل اکتور چطور حل میشود.‫یک میکروسرویس اکتوری (مثلاً مبتنی بر akka) میسازیم و چند نمونه (instance) از آن بالا می آوریم. این نودها در یک کلاستر akka قرار می گیرند و با هم هماهنگ میشوند.‫به هر کانال در پیام رسان یک اکتور اختصاص می دهیم. هر اکتور کانال روی یکی از نودهای کلاستر جانمایی میشود. در واقع اکتور کانال یک شیء (Object) است که رفتار (Behavior) و وضعیت (State) آن کانال را در خود جای میدهد.‫اِعمال و پاسخگویی همه رویدادهای مربوط به یک کانال، به اکتور وی واگذار میشود. رویدادها در یک صف (Mailbox) قرار می­گیرند و یکی یکی برای پردازش تحویل اکتور میشوند.‫وضعیت اکتور، یک شیء معمولی با فیلدهای دلخواه است. مثلاً می تواند یک Map از «شناسه پستها» به «تعداد بازدید» داشته باشد. حتی به ConcurrentMap نیاز نیست. چون رویدادها یکی یکی از Mailbox خارج و اعمال میشوند، مشکل همروندی پیش نمی ­آید.‫هر وقت اکتور یک «رویداد بازدید» از Mailbox بردارد، در Map، تعداد بازدیدهای آن پست را بدون نگرانی از همروندی یکی زیاد میکند. راجع به ذخیره سازی این داده ها (Persistency) ان شاء الله در پست دیگری توضیح خواهم داد.‫در این مدل، مساله این است که بتوانیم اکتور مناسب را در کلاستر پیدا کنیم و رویداد را در Mailbox او قرار دهیم. در واقع مساله distributed lock در راه حل کلاسیک، تبدیل به مساله distributed actor lookup میشود. مزیت این مدل آن است که برای مدیریت همروندی نیازی به IO نیست و thread ها بلاک نمی شوند. موقع کد زدن نگران همروندی نیستیم. گویا برنامه Single Thread است.‫ ان شاء الله در پستهای بعدی به مزیتهای دیگر اکتور مدل خواهیم پرداخت.‫ برای آشنایی بیشتر با مدل اکتور اینجا را ملاحظه بفرمایید. اگر علاقه مند به کاری چالشی با akka هستید، اینجا منتظر شما هستیم. سید جمال الدین پیشوایی سید جمال الدین پیشوایی Thu, 07 Oct 2021 23:02:19 +0330