https://virgool.io/avansoft/feed شرکت مشاوران نرم‌افزاری اعوان، یک شرکت دانش بنیان در زمینه مهندسی نرم‌افزار و تولید راه‌حل‌های نرم‌افزاری است. مدیران و همکاران شرکت اعوان به ایران و ایرانیان عشق می‌ورزند. آرمان اعوان تلاش برای زندگی شیرین‌تر، پرنشاط‌تر و پرمعناتر برای ایرانیان است. https://asta.ir fa 2026-06-16 23:38:56 https://files.virgool.io/upload/publication/3w6v5ebwjd6l/x3yhfh.png https://virgool.io/avansoft 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%A9%D8%A7%D8%B1-%D8%B9%D9%85%DB%8C%D9%82-%D8%A8%D8%A7-%D8%B0%D9%87%D9%86-%D8%AD%D9%88%D8%A7%D8%B3-%D8%AC%D9%85%D8%B9-b4kgj9nl8qeu در این نوشتار سعی میکنم به مسئله حواس‌پرتی و عدم تمرکز نگاهی اجمالی داشته باشم. امیدوارم بعد از خواندن این مطلب انگیزه کافی برای شروع مقابله با عدم تمرکز را داشته باشید. هسته اصلی این نوشتار برداشت من از سه کتابی است که در این حوزه خوانده‌ام.‫کار عمیق (deep work)، نوشته Cal Newport - انتشار در سال 2016‫‫‫مینیمالیسم دیجیتال، نوشته Cal Newport - انتشار در سال 2019‫ذهن حواس‌جمع (Indistractable)، نوشته Nir Eyal - انتشار در سال 2019اطلاعات لازم برای دسترسی به بهترین ترجمه کتاب‌ها، خلاصه و سایر مطالب مرتبط را می‌توانید در انتهای مطلب ملاحظه کنید.(۱)قبل از سال ۱۳۹۷ به معنای واقعی کلمه، عدم تمرکز در زندگی کاری و شخصی خود را احساس می‌کردم. کار من به عنوان یک برنامه‌نویس احتیاج به تمرکز بالایی دارد. دلایل زیر به طور عمده باعث می‌شد حین کار مدام از این شاخه به آن شاخه بپرم و هر از گاهی سر در گوشی و چشم در سایت‌های مختلف خبری داشته‌ باشم.علاقه زیاد به مطالب سیاسی و ورزشیبرخی نارضایتی‌ها از کارهای جاریوسوسه‌های ناشی از حضور در فضای مجازیروزگار گذشت تا این که به پیشنهاد یکی از دوستانم با کتاب کار عمیق آشنا شدم و سیر مطالعه و تمرین من در این حوزه آغاز شد.بعد از چهار سال مطالعه و تمرین در خصوص موضوع تمرکز، این اطمینان را به شما می‌دهم که هیچ کتاب و مقاله و توصیه‌ای وجود ندارد که بتواند در وجود شما معجزه کند. همکارانی که با من کار می‌کنند همگی اذعان دارند که از یک زمانی به بعد تمرکز من روی کار به طرز چشم‌گیری افزایش پیدا کرد. اما من همچنان مقهور وسوسه‌های فضای مجازی هستم. کاملا محتمل است حین کار به توییتر و تلگرام سر بزنم و سر از سایت‌های خبری در بیاورم. اما با آدم چهار سال پیش تفاوت‌های عمده‌ای دارم. مثلا:هیچ برنامه کاربردی حق ندارد به من اعلان (notification) ارسال کند. (مگر موارد کاری و شخصی کاملا استثناء)تعداد برنامه‌های کاربردی بر روی گوشی همراهم حدودا ۳۵ عدد است که از نصف بیشتر آن‌ها سالی چند بار بیشتر استفاده نمی‌کنم. در حالی که تا همین دو سال گذشته بیش از ۱۰۰ برنامه روی آن نصب داشتم.مطالب کمی را در فضای مجازی به اشتراک می‌گذارم. این کار باعث می‌شود پیام‌های کمتری دریافت کنم و مدیریت حضورم در این فضا راحت‌تر شود.اشتراکات ایمیلی دوست‌داشتنی و مهم جایی در صندوق ورودی من ندارند و با برچسب‌های مشخصی بایگانی می‌شوند تا در وقت مشخصی به آن‌ها سر بزنم.سعی میکنم، دقت کنید! سعی میکنم که در زمان‌های از پیش‌تعیین‌شده‌ای به شبکه‌های اجتماعی سر بزنم. از خدا پنهان نیست که خیلی وقت‌ها هم در این امر ناموفقم.خب این‌ها فقط چند توصیه ابتدایی (۲) بود که در زندگی من جواب داده است و من را به نسبت به چهار سال قبل به آدم بهتری تبدیل کرده است. اجرا و تمرین روش‌هایی از این دست باعث شده که بتوانم بیشتر برای ارزش‌های زندگی خود وقت بگذارم. مثلا وقتی می‌دانم قرار است زمان مشخصی در شب به حضور در فضای مجازی اختصاص دهم؛ وقتی به منزل میرسم احساس آرامش بیشتری دارم و با خیال راحت‌تری برای خانواده خویش وقت می‌گذارم. به جای حضور بی برنامه و اتلاف‌‌کننده در فضای مجازی، اوقات فراغت خود را به مطالعه و گوش دادن پادکست اختصاص می‌دهم.نکته مهم این است که این تکنیک‌ها شخص به شخص متفاوت است و هرکسی باید بر اساس زندگی خود تکنیک‌های متفاوتی را اجرا کند. هیچ قانون کلی وجود ندارد. نمی‌توان با چند توصیه ساده در برابر سرمایه‌گذاری میلیارد دلاری غول‌های دره سیلیکون تاب آورد. هر کسی که احساس می‌کند در کارهای شخصی، روابط خانوادگی و کاری خود نیاز به تمرکز دارد باید برای این موضوع وقت بگذارد. مطالعه کتاب‌هایی مثل کار عمیق و ذهن حواس‌جمع تکنیک‌هایی را به شما می‌آموزد که باید برای اجرای آن‌ها برنامه‌ریزی کرده و برای بومی‌سازی آن‌ها وقت صرف کنید.به سراغ دیدگاه‌های افراطی نرویدجالب است بدانید کال نیوپورت، نویسنده کتاب کار عمیق، با گوشی‌های هوشمند بیگانه است. در هیچ یک از شبکه‌های اجتماعی عضو نیست. دسترسی به او در فضای مجازی (مثلا از طریق ایمیل) بسیار بسیار سخت است. او توانسته‌است یک روش کاملا افراطی را برای کسب تمرکز در زندگی‌اش اجرا کند. این استاد علوم کامپیوتر روش‌های افراطی و معتدل‌اش را در کتاب‌های کار عمیق و مینیمالیسم دیجیتال شرح داده است. مشابه این روش‌ها در کتاب ذهن حواس جمع و سایر کتاب‌های این حوزه آمده است. به تجربه عرض می‌کنم تکنیک‌های این چنینی در کوتاه مدت تاثیر فوق‌العاده‌ای بر روی تمرکز و احساس رضایت شما خواهند داشت. اما معمولا بیشتر افراد پس از مدتی مقاومت خود را از دست می‌دهند و دوباره بی‌حساب و کتاب اسیر عوامل مزاحم و پرت‌کننده‌های حواس می‌شوند. اشکال آقای کال این است که به مسئله عدم تمرکز به صورت ریشه‌ای نپرداخته‌ است. او فکر میکند فضای مجازی و حواس‌پرتی ناشی از آن‌ علت اصلی عدم تمرکز انسان امروز است. غافل از اینکه دنیای ما همیشه پر از چیزهایی بوده که برای پرت کردن حواس ما طراحی شده‌اند. تلفن و تلویزیون هم زمانی قدرتی جادویی داشته‌اند و افراد بسیاری از آن‌ها شاکی بودند. عقب‌تر برویم؟! سقراط نوشتن را مقصر فراموشی در روح یادگیرنده می‌دانسته است. قبول دارم مقایسه خنده‌داری است ولی قبول کنید عوامل حواس‌پرتی همیشه واقعیت زندگی بوده و خواهند بود. امروزه این عوامل متفاوت از گذشته شده است و صد البته که آسان‌تر از همیشه تاریخ.با اینکه می‌دانیم سرمایه‌گذاری غول‌های نرم‌افزاری دنیا برای "اقتصاد توجه" است و اتفاقا آن‌ها تمرکز ما را هدف گرفته‌اند، باز هم نمی‌توان آن‌ها را علت ریشه‌ای عدم تمرکز دانست. نیر ایال در کتاب فوق‌العاده‌ی ذهن حواس جمع این مسئله را به خوبی توضیح می‌دهد و سعی می‌کند به واکاوی علت ریشه‌ای مشکل بپردازد. او معتقد است برای حل مسئله علاوه بر محرک‌های بیرونی بایستی نگاه ویژه‌تری به محرک‌های درونی داشت.البته دقت کنید! هیچ‌کس ادعا ندارد که باید سهم عوامل مزاحم و محرک‌های بیرونی برای حمله به تمرکز را ناچیز شمرد. اتفاقا اکثر راهکارهای کتاب ذهن حواس‌جمع هم اختصاص به مقابله با این محرک‌ها دارد. اما حرف جدید آقای ایال مطرح ساختن محرک‌های درونی است. چیزی که تاکنون کمتر از آن‌‌ها شنیده‌ایم.افسار محرک‌های درونی را در دست بگیریدمعمولا وقتی حواس‌مان از کاری که می‌کنیم پرت می‌شود باید ببینیم در لحظه حواس‌پرتی چه احساسی داشتیم یا انگیزه‌ی ما چه بوده است. نویسنده معتقد است در آن لحظه ما معمولا احساس‌هایی همچون تنهایی، کسالت، ناراحتی، حوصله سر رفتن و... را داریم و انگیزه ما از حواس‌پرتی، کمتر کردن رنج و درد درونی‌ ما است. مثلا یک دلیل شایع، عدم رضایت از کاری است که داریم انجام می‌دهیم یا وجود ناراحتی که به هر دلیلی در وجود ما رخنه کرده است. با حواس‌پرتی به چنین محرک‌هایی پاسخ می‌دهیم و از احساسات منفی فرار می‌کنیم. اما باید توجه کنیم که این پاسخ‌ها سالم نیستند. انگیزه بسیاری از رفتارهای ما فرار از رنج و ناراحتی است. هرچیزی که ناراحتی را از بین می‌برد بالقوه اعتیادآور است، ولی می‌توان در برابر آن مقاومت کرد. باید عوامل هدایت‌کننده رفتارمان را بشناسیم تا آن‌ها را مدیریت کنیم. در کتاب ذهن حواس‌جمع راهکارهایی برای مقابله با این محرک‌ها ارائه شده است. پیشنهاد می‌کنم حتما آن‌ها را دنبال کنید.به عنوان حسن ختام این جمله فوق‌العاده از نیر ایال را گوش جان بسپاریم: ‌((اگر می‌خواهیم حواس‌پرتی را مهار کنیم باید یاد بگیریم با ناراحتی کنار بیاییم. مدیریت تمرکز چیزی نیست به جز مدیریت رنج.))--------------------------------------------------------------------------------------------------------------------------------------------------------۱- لینک‌ها و مطالب مرتبطمی‌توانید خلاصه کتاب کار عمیق و ذهن حواس‌جمع را در پادکست فوق‌العاده بی‌پلاس گوش دهید.ترجمه‌های متعددی از کار عمیق وجود دارد که بهترین آن‌ها مربوط به نشر نوین (ترجمه خانم ناهید ملکی) و انجمن انفورماتیک ایران (ترجمه آقای ابراهیم نقیب‌زاده مشایخ) است. بنده ترجمه دوم را بیشتر می‌پسندم.کتاب مینیمالیسم دیجیتال را نشر نوین با ترجمه خانم ناهید ملکی منتشر کرده است.کتاب ذهن حواس‌جمع را نشر آموخته با ترجمه خانم فاطمه علی پور منتشر کرده است.هر سه کتاب در اپلیکیشن‌های کتاب الکترونیک در دسترس هستند.۲- هدف این نوشتار بیشتر ایجاد انگیزه برای افزایش تمرکز در زندگی شخصی و کاری مخاطبان است. ان‌شاءالله سعی میکنم در پست جداگانه‌ای به معرفی و مرور تکنیک‌های ارائه‌شده در این کتاب‌ها بپردازم. شرکت مشاوران نرم‌افزاری اعوان سجاد جعفری Sat, 06 Nov 2021 09:34:03 +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 https://virgool.io/avansoft/git-vs-tfvc-trwvg1v2hbos مقدمهدر حال حاضر، یکی از الزامات و از حیاتی‌ترین پیش‌نیازها در توسعه نرم‌افزار، استفاده از یک سیستم کنترل نسخه مناسب و استاندارد است. هدف و کارکرد اصلی سیستم‌های کنترل نسخه را می‌توان در دو مورد بیان کرد: ۱- امکان دسترسی همه افراد تیم به آخرین نسخه از نرم‌افزار و توسعه نرم‌افزار به صورت هم‌زمان ۲- رصد تغییرات نرم‌افزار در طی زمان و داشتن کنترل کامل بر روی نسخه‌های مختلف. سیستم‌های کنترل نسخه مختلف، امکانات متعدد و بعضا متفاوتی برای این موارد فراهم کرده‌اند.سیستم‌های کنترل نسخه به دو دسته متمرکز و توزیع‌شده تقسیم می‌شوند. یکی از معروف‌ترین سیستم‌های کنترل نسخه متمرکز، TFVC یا Team Foundation Version Control است و یکی از معروف‌ترین سیستم‌های کنترل نسخه توزیع‌شده، Git نام دارد.در سیستم‌های کنترل نسخه متمرکز، مخازن کد بر روی یک سرور مرکزی ذخیره شده‌اند و توسعه‌دهندگان برای کار کردن با مخزن کد یک نسخه کاری (working copy) را check-out می‌کنند. هر نسخه کاری، در واقع یک snapshot از کد در یک زمان مشخص است.در سیستم‌های توزیع‌شده، توسعه‌دهندگان برای کار کردن با مخزن کد، کل مخزن کد را در ماشین‌ خود کپی می‌کنند. یعنی هر توسعه‌دهنده بدون نیاز به تعامل با مخزن کد و به صورت local به کل تاریخچه کد دسترسی دارد و می‌تواند بداند چه تغییراتی در چه زمانی و توسط چه افرادی در کد داده شده است.در پروژه‌های بزرگ و پیچیده، استفاده از سیستم کنترل نسخه مناسب، اهمیت بسیار بالایی پیدا می‌کند و می‌تواند هم‌زمان جنبه‌های مختلفی از کیفیت توسعه نرم‌افزار را تحت تاثیر قرار دهد.ما در تیم چکاپ شرکت اعوان با هدف کمک به ارتقای سطح کیفی نرم‌افزارها، سامانه‌های نرم‌افزاری و تیم‌های نرم‌افزاری، در کنار تیم‌های مختلف قرار می‌گیریم و با شناسایی نقاط تاثیرگذار در کاهش کیفیت توسعه نرم‌افزار، به آن‌ها کمک می‌کنیم با آگاهی بیشتر گزینه‌های مختلف را بررسی کرده و بهترین راه‌کارها را به منظور بهبود کیفیت توسعه و معماری نرم‌افزار انتخاب و اعمال کنند.در یکی از این همکاری‌ها، حدس زدیم که سیستم کنترل نسخه‌ مورد استفاده در تیم، یکی از نقاط تاثیرگذار در کاهش کیفیت توسعه است. بنابراین تصمیم گرفتیم این فرضیه را دقیق‌تر بررسی کنیم و سیستم‌های کنترل نسخه مختلف را به خوبی شناخته و بر مزایا و معایب هر کدام اشراف کامل پیدا کنیم.در شرکت اعوان سال‌هاست که از Git استفاده می‌شود و در واقع دید خوبی نسبت به کارکردها و ویژگی‌های این سیستم کنترل نسخه داشتیم. اما تجربه کار با سیستم‌های متمرکز مثل TFVC را نداشتیم و باید بررسی می‌کردیم که چه ویژگی‌ها، محدودیت‌ها، مزایا و معایبی دارند تا در نهایت در خصوص ادامه روال استفاده از TFVC در آن تیم خاص و یا پیشنهاد تغییر رویه و مهاجرت به Git به جمع‌بندی برسیم.در این مقاله قصد داریم به بررسی ویژگی‌ها و تفاوت‌های سیستم‌های کنترل نسخه متمرکز و توزیع‌شده بپردازیم. در نهایت اهمیت استفاده از سیستم‌های توزیع شده و همچنین دلایل مهاجرت از سیستم‌های متمرکز به سیستم‌های توزیع‌شده را بیان می‌کنیم.از TFVC به‌عنوان نماینده سیستم‌های کنترل نسخه متمرکز و از Git به‌عنوان نماینده سیستم‌های کنترل نسخه توزیع‌شده که معروف‌ترین و پرکاربردترین سیستم‌های کنترل نسخه هستند استفاده می‌کنیم.سیستم‌های کنترل نسخه متمرکزدر سیستم‌های کنترل نسخه متمرکز، مخازن کد بر روی یک سرور مرکزی ذخیره شده‌اند. توسعه‌دهندگان یک نسخه کاری (working copy) را check-out می‌کنند. هر نسخه کاری، در واقع یک snapshot از کد در یک زمان مشخص است.معروف‌ترین سیستم کنترل نسخه متمرکز، TFVC یا Team Foundation Version Control نام دارد که در واقع سیستم کنترل نسخه‌ TFS است. TFS یک سیستم راه‌حل جامع (total solution) است و از زیرسیستم‌های مختلفی تشکیل شده. مثل سیستم issue tracking و version control و ...بنابراین مصطلح است که سیستم کنترل نسخه‌ای که بر روی TFS قرار دارد را به جای TFVC با همان TFS خطاب می‌کنند. البته در این مقاله سعی می‌کنیم از این دو عبارت در جای درستشان استفاده کنیم.معایبمفهوم check-in کردن محلی در این سیستم‌ها تعریف‌نشده است. یعنی امکانش وجود ندارد که توسعه‌دهنده بتواند بدون تعامل با مخزن کد اصلی و صرفا به صورت local کد خود را check-in کند.امکانات مربوط انشعاب (branching) و ادغام (merging) در این سیستم‌ها ضغیف است. فرض کنید که به یک پایگاه‌داده رابطه‌ای درست حسابی نیاز دارید. ابتدا Sql server و Oracle و MS Access را بررسی می‌کنیم و در نهایت Access را انتخاب می‌کنیم. چرا؟ چون بهترین GUI را دارد اما به این حقیقت که Access مقیاس‌پذیر نیست و referential integrity را به خوبی اعمال نمی‌کند و مورادی از این دست، توجهی نکرده‌ایم. انشعاب و ادغام از ارکان اصلی یک سیستم کنترل نسخه به شمار می‌روند و نقش گوشت و سیب‌زمینی را در غذا دارند. در حالی که بقیه ویژگی‌ها صرفا نقش دورچین غذا را دارند و متاسفانه افرادی هستند که بر اساس دورچین، غذا را انتخاب می‌کنند.درباره TFS: همانطور که گفته شد، در واقع TFS یک Total Solution است و جدا از امکانات مربوط به کنترل نسخه، امکانات گسترده دیگری هم دارد. مثلا issue tracking.بدی راه‌حل‌های جامع این است که اگر واردشان شوید، تمام و کمال درگیرشان می‌شوید. همه امکاناتی که در اختیارتان می‌گذارد، در سطح متوسط است و ظاهرا چاره‌ دیگری هم ندارید. اما مهم است که بدانیم در هر زمینه‌ای مانند ردیابی کارها، مدیریت پروژه، گزارش‌گیری و ...، ابزارهای خیلی خیلی بهتری وجود دارد.Azure DevOpsاز چندسال پیش (سال ۲۰۱۹)، Visual Studio Team Foundation Server (TFS) به Azure DevOps تغییر نام داده است. در Azure DevOps این امکان وجود دارد که سیستم کنترل نسخه خود را Git انتخاب کنید یا TFS. در این مقاله اطلاعات کامل برای چگونگی استفاده از گیت به عنوان سیستم کنترل نسخه در Azure DevOps توضیح داده شده است.سیستم‌های کنترل نسخه توزیع‌شدهدر سیستم‌های توزیع‌شده، توسعه‌دهندگان کل مخزن کد را در ماشین‌شان کپی می‌کنند. این کپی شامل کل تاریخچه تعامل با کد هم هست. یعنی هر توسعه‌دهنده بدون نیاز به تعامل با مخزن کد و به صورت local به کل تاریخچه کد دسترسی دارد و می‌تواند بداند چه تغییراتی در چه زمانی و توسط چه افرادی در کد داده شده است.گیت یک سیستم کنترل نسخه توزیع‌شده است که در سال‌های اخیر بسیار مورد توجه قرار گرفته است. برای مطالعه و آشنایی بیشتر با Git می‌توانید از این لینک استفاده بفرمایید.در بخش‌ بعدی، سعی می‌کنیم مقایسه کاملی بین نماینده سیستم‌های کنترل نسخه متمرکز یعنی TFVC و نماینده سیستم‌های کنترل نسخه توزیع‌شده یعنی Git داشته باشیم.یکی از مزایای داشتن کل مخزن (و نه فقط یک snapshot از آن) بر روی ماشین شخصی، این است که در صورتی که برای سرور مخزن کد مشکلی پیش بیاید، هر توسعه‌دهنده یک کپی از مخزن کد دارد و به راحتی مخزن کد از روی نسخه‌هایی که بر روی ماشین‌های افراد وجود دارد، بازیابی می‌شود. پس در حین کار با سیستم کنترل نسخه توزیع‌شده، به صورت خودکار در حال بکاپ‌گیری از مخزن کد هستیم. هر زمانی که کسی از مخزن مرکزی چیزی را pull کند، تاریخچه تغییرات پروژه را هم به صورت کامل دریافت می‌کند. پس هر فردی که با مخزن تعامل داشته باشد، یک نسخه کامل از مخزن را دارد و اگر یک زمانی مخزن به هر دلیلی از دست برود، به راحتی قابل ریکاوری است (یک نسخه بکاپ از مخزن روی کامپیوتر تمام اعضای تیم وجود دارد).مزیت دیگر این سیستم‌ها این است که می‌توانید نسخه کاری خود را بین revisionهای مختلف جابجا کنید، بدون اینکه لازم باشد با سرور حرف بزنید. این امکان در صورتی که سرور پایین یا به هر دلیلی غیرقابل دسترس باشد، بسیار کمک‌کننده است. پس در این سیستم‌ها به صورت آفلاین به مخزن کد دسترسی داریم. در شرایط دورکاری (یا حتی کارکردن از داخل هواپیما و قطار)، به تاریخچه تغییرات و تک‌تک checkinها به صورت کامل دسترسی داریم. بدون اینکه نیاز به استفاده از VPN برای ارتباط با شبکه محل کار باشد و انگار در داخل شرکت هستیم، هر کاری مثل checkin و checkout و ساخت انشعاب و ... را می‌توانیم انجام دهیم.یک مزیت مهم این است که بدون صحبت با سرور یا تحمیل تغییرات بالقوه ناپایدار به تیم، می‌توان مجموعه تغییرات را در مخزن محلی commit کرد. برای مثال، اگر در حال کار بر روی یک فیچر بزرگ هستیم، ممکن است که یک هفته زمان ببرد تا به طور کامل کدش را بزنیم و کامل تست کنیم. در این شرایط، قطعا مطلوب نیست که کد ناپایدار را در وسط هفته به مخزن کد check-in کنیم و با احتمال بالا یک build شکست‌خورده داشته باشیم. اما در مقابل چه می‌شود اگر در اواخر هفته، به صورت تصادفی کل نسخه کاری‌ لوکال‌‌مان را از دست بدهیم؟ اگر در طول این مدت و به مرور کدمان را commit نکرده باشیم، ریسک از دست رفتن کاری که انجام دادیم وجود دارد. چنین ابزار کنترل نسخه‌ای، کارا و مطمئن نیست و امثال TFVC مستعد این مشکل هستند.با وجود سیستم‌های کنترل‌نسخه توزیع‌شده (DVCS)، بدون نگرانی برای شکست build، می‌توانیم مرتبا کدمان را کامیت کنیم. چرا که تغییراتمان را به صورت محلی کامیت می‌کنیم.چرا باید به جای TFVC از Git استفاده کنیم؟نگارنده در حین جست‌وجو برای درک تفاوت این دو سیستم کنترل نسخه، فقط و فقط به مزایای گیت و معایب TFVC برخورد کرد و هیچ مقاله‌ای پیدا نکرد که برای TFVC نسبت به گیت مزایایی را ذکر کرده باشند. بلکه در تمام مقالات و بحث و گفت‌وگوها این اجماع دیده می‌شد که استفاده از گیت بسیار منطقی‌تر است و گیت مزایای مهم و زیادی نسبت به TFVC دارد.بسیاری از مقالات هم توسط افرادی نوشته شده بود که سال‌ها با TFS و TFVC کار کرده بودند ولی در نهایت تصمیم گرفته بودند به سمت گیت مهاجرت کنند. به دلیل آشنایی کامل این افراد با اکوسیستم TFVC و گیت، به نظر مقایسه‌های دقیق و کاملی انجام دادند و در نتیجه در این بخش به جای بررسی گیت و TFVC به صورت مستقل و بیان مزایا و معایب هر کدام، سوار بر موج شده و به مرور دلایل مهاجرت از TFVC به سمت گیت می‌پردازیم. به همین دلیل هم هست که بیشتر ادامه این مقاله از زبان کسانی هست که همچنان از مایکروسافت و Azure DevOps استفاده می‌کنند ولی از TFVC به گیت مهاجرت کرده‌اند.۱. پیشنهاد مایکروسافتجالب است که سیستم کنترل نسخه پیش‌فرض در Azure DevOps، گیت است و خودشان تاکید کرده‌اند که بهتر است از گیت استفاده کنید مگر اینکه دلیل خاصی برای استفاده از سیستم‌های کنترل نسخه متمرکز داشته باشید و مجبور شوید از TFS استفاده کنید. البته استفاده هم‌زمان گیت و TFS هم ممکن است. برای مقایسه کامل امکانات Git و TFVC در Azure DevOps، به این لینک مراجعه کنید.Git is the default version control provider for new projects. You should use Git for version control in your projects unless you have a specific need for centralized version control features in TFVC۲. سرعت بالای مهاجرت از TFVC به گیتهمانطور که در نمودار مشخص است مشتریان TFVC و Subversion و دیگر سیستم‌های کنترل نسخه با سرعت زیادی درحال مهاجرت به سمت Git هستند.البته دقت کنید که این مهاجرت به این معنی نیست که مشتریان Azure DevOps (یا همان TFS سابق) را ترک می‌کنند، بلکه همانطور که اشاره شد، در حال حاضر در پروژه‌های Azure DevOps به صورت پیش‌فرض مخازن گیت قرار دارند و توسط خود مایکروسافت هم استفاده از آن‌ها پیشنهاد می‌شود.3. جریان‌های کاریزمانی که یک پروژه جدید را شروع می‌کنیم، خیلی راحت‌تر است که یک جریان کاری محبوب را انتخاب کرده و مطابق با نیاز‌های خودمان سفارشی‌سازی‌اش کنیم حتی ممکن است در نهایت به یک جریان کاری کاملا متفاوتی برسیم.گیت جریان‌های کاری محبوب زیادی دارد و کامیونیتی قوی‌ای حول خودکارسازی این جریان‌های کاری ساخته است. اما ‌TFVC اینطور نیست.جریان‌های کاری موجود، مزایای زیادی دارند که در ادامه آمده‌اند:جریان‌های کاری معمولا در بلاگ‌های کاربری زیادی همراه با سفارشی‌سازی‌های مرسوم مستند شده‌اند.جنبه‌های سخت و بدقلق‌شان همراه با توضیحات و راه‌حل به وفور به صورت آنلاین مستند شده است.کاربران زیادی از سایت‌هایی مانند StackOverflow دانش زیادی در این زمینه دارند و مشتاق هستند که به سوالات مرتبط با جریان‌های کاری پاسخ دهند.۴. ترند جهانیKnowledge of Git is increasingly expected of developers and IT staff in the industryاستفاده از گیت به قدری مرسوم است که اکثر توسعه‌دهندگان و DBAها آشنایی کامل با آن را به عنوان یک پیش‌نیاز برای پیشرفت در کارشان می‌بینند. اما در مقابل، به TFVC به طور فزاینده‌ای به چشم یک سیستم کنترل نسخه از رده‌ خارج‌شده نگاه می‌شود.۵. استاندارد سازمانیIt’s best to standardize on a single type of VCS in an organizationاز نظر دانش فنی و فهم فرایندها و جریان‌های کاری، توسعه‌دهندگان و افراد فعال در حوزه IT باید جزییات بسیار زیادی را به خاطر بسپارند، حال درک بیش از یک سیستم کنترل نسخه و جریان‌های کاری وابسته به آن‌ها، درخواست زیادی از افراد است.به همین دلیل، بیشتر سازمان‌ها تصمیم می‌گیرند که روی یک سیستم کنترل نسخه واحد تمرکز کنند. به این معنی که:مهندسان می‌توانند روی چندین پروژه مختلف کار کنند بدون این‌که نیاز باشد با چند نوع سیستم کنترل نسخه مختلف سر و کار داشته باشند.سربار زمانی انتقال افراد بین تیم‌های مختلف، کمتر است.تعامل تیم‌ها با یکدیگر برای به اشتراک‌گذاری دانش، جریان کاری و کد راحت‌تر است.برای افراد IT مرکزی، در صورت self-hosting، پشتیبانی از یک نوع مخزن کد و در صورت cloud-hosting، مستندسازی و مدیریتی سطوح دسترسی برای یک نوع مخزن کد راحت‌تر است.هر روزه در سازمان‌های مختلف (چه مایکروسافتی و چه غیرمایکروسافتی) سهم گیت به عنوان سیستم‌ کنترل نسخه استاندارد رو به افزایش است.۶. مدل انشعاب سبک‌ترگیت مدل انشعاب واقعا سبکی دارد. به طوری که هر شاخه‌ای که ساخته می‌شود، واقعا سبک‌وزن و به جای این‌که یک کپی از کل پروژه باشد، مثل یک لینک به یک کامیت خاص است. این موضوع باعث می شود که ایده ساخت یک شاخه که برای هر فیچر مجزایی که به سامانه اضافه می‌کنید نه تنها ممکن، بلکه توصیه‌شده باشد. با این کار، بسته به ساختار ادغام‌ها (در حالت ایده‌آل با کمک Pull Request) خواندن تاریخچه (history) راحت‌تر می‌شود. در سمت دیگر TFVC، روش سنگینی برای برخورد با انشعاب‌ها دارد. چرا که هر شاخه‌ای که ساخته می‌شود، یک کپی کامل از پروژه همراه با تمام وابستگی‌هایش است.۷. بروکراسی بسیار کمتردر TFVC بیشتر بر روی سناریوهای سلسه‌مراتبی معمولی تمرکز وجود دارد. چیزهایی مثل ایجاد یک شاخه معمولا به عنوان کاری دیده می‌شود که تنها افراد سطح بالاتر باید اجازه آن را داشته باشند. در مورد حذف شاخه نیز محدودیت‌های بیشتری وجود دارد. همین مساله باعث می‌شود که ایده یک شاخه به ازای هر فیچر، اصلا ایده خوبی در TFVC نباشد. همچنین حتی زمانی که توسعه‌دهنده دسترسی ساخت و حذف شاخه را داشته باشد، این کار آنقدری زمان‌بر هست که ارزش انجام آن برای هر فیچر را ندارد.در سمت دیگر گیت، رویکرد کاملا متفاوتی دارد. هر کس می‌تواند هر چقدر که می‌خواهد برحسب نیاز شاخه‌های محلی ایجاد کند. محدودیت‌ها فقط برای زمانی‌هایی وجود دارند که بخواهید شاخه‌های روی سرور را حذف کنید یا شاخه‌ای را بر روی سرور push کنید.روش خوب این است که شاخه master را همیشه با استفاده از pull request محافظت کنید. به این ترتیب، هر کس می‌تواند شاخه‌های دل‌خواهش را بسازد و هر کاری که دوست دارد با آن‌ها انجام دهد. اما هنگامی که می‌خواهد تغییراتش را با master ادغام کند، باید حتما به صورت کنترل‌شده باشد و در حال ایده‌آل توسط سایر توسعه‌دهندگان تغییراتش مرور شود.۸. امکان کار به‌صورت آفلاین‌نکته این است، هر زمان که TFS پایین باشد، کار کل تیم می‌خوابد و در واقع ویژوال استودیو کل تیم را بلاک می‌کند تا هیچ کاری نتوانند انجام دهند. زیرا برای یک تغییر کوچک در یک فایل هم شما مجبورید حتما به سرور اطلاع دهید. البته ظاهرا در Azure DevOps این مساله کمتر است. فقط پایین بودن سرور نیست که دردسر ایجاد می‌کند. حتی کند شدن آن هم بهره‌وری تیم را کاهش می‌دهد. اما در گیت این مساله مشکلات خیلی کمتری را ایجاد می‌کند. اگر سرور پایین باشد، فقط CI/CD از کار می‌افتد و نمی‌توانیم تغییرات را بر روی سیستم deploy کنیم اما می‌توانیم به صورت عادی کارمان را ادامه دهیم و تغییرات را به صورت محلی کامیت کنیم.9. ویرایش سریع‌تر فایلبه نظر می‌رسد که TFVC هر بار که یک فایل را به یک پوشه‌ای اضافه می‌کنید، ابتدا چک می‌کند که آیا فایل باید ردیابی شود یا خیر. این موضوع فرایندهایی که با تعداد زیادی فایل سر و کار دارند را بسیار کند می‌کند. مثل نصب بسته‌های NuGet. اولین باری که بخواهید تغییری در یک فایل بدهید، باید در سرور check-in شود و تا زمانی که پاسخ برگردد، ویرایش فایل بلاک می‌شود.اما گیت از استراتژی دیگری استفاده می‌کند. به جای این‌که هر بار که یک فایلی تغییر کرد، notify شود، فقط زمانی که ازش درخواست شود، وضعیت فعلی را چک می‌کند. به این ترتیب، هر بار که شما (یا یک برنامه‌ای مثل ویژوال استودیو) بخواهید وضعیت فعلی فایل را بروز کنید، عملیات git status (که بسیار سریع است) را انجام می‌دهید تا چک شود که آیا چیزی تغییر کرده است یا نه. این کار نه تنها از روش TFVC سریع‌تر بلکه بسیار امن‌تر هم است.10. سریع‌تر بودن عملیات مربوط به کنترل نسخههزینه اجرای عملیات کنترل نسخه معمولا نادیده گرفته می‌شود. چرا که این عملیات خیلی به طور مکرر انجام نمی‌شوند (مخصوصا در TFVC). مساله این است که در زمان بروز مشکل، حتما به این عملیات نیاز دارید و در آن زمان‌ها هم هر دقیقه اهمیت دارد.اگر بعد از تغییر در کد، باگی پیدا شود، سعی می‌کنیم که ریشه بروز باگ را پیدا کنیم. کاری که معمولا انجام می‌دهیم این است که تمام تغییراتی که در کد داده‌ایم را به نوعی غیرفعال می‌کنیم (stash) و چک می‌کنیم که آیا باگ همچنان وجود دارد یا نه. اگر باگ همچنان دیده می‌شود یعنی منشا آن، تغییرات ما نبوده و از کدهای دیگران ناشی می‌شود. ولی اگر دیگر نتوانیم آن باگ را تولید کنیم، یعنی باید کد خود را دقیق‌تر بررسی کنیم و ببینم چه اشتباهی مرتکب شده‌ایم (معمولا با تست واحد راحت‌ مشخص می‌شود که باگ از کجای آمده است).چک کردن تاریخچه کد هم گاهی به ما کمک می‌کند که قوانین کسب‌وکاری عجیبی که بیشتر شبیه به باگ هستند را بهتر درک کنیم. می‌توانیم چک کنیم که کد با کدام کامیت اضافه شده‌است و از آنجا هم می‌توانیم Pull Requestای که منجر به اضافه شدن این کد به شاخه master شده است را پیدا کنیم. این Pull Request معمولا نشان می‌دهد که درخواست ادغام از سمت چه کسی بوده و تغییرات کد به چه منظور و هدفی بوده است. همه این کارها با گیت بسیار بسیار ساده‌تر است. در حالی که در TFVC خیلی سخت است که این سطح از تعاملات با سیستم کنترل نسخه را داشته باشیم. چرا که معمولا خیلی کند است و آن‌چنان قابل اعتماد هم نیست.در آخر هم می‌توان گفت که یک ویژگی بدیهی و به نظر ناقابل در گیت (مثل اجرای دستور git checkout [commit-id])، در TFVC چیزی است که همه از آن می‌ترسند (زیرا بسیار کند است و احتمال بالایی وجود دارد که مشکلاتی را ایجاد کند). در گیت می‌توان تمام فایل‌ها را از روی نسخه‌ای که حتی بیش از یک‌سال از انتشارش گذشته ردیابی کرد و در عرض چند ثانیه به جدیدترین نسخه بازگشت.11. راهی آسان و صریح برای نادیده گرفتن فایل‌هاانجام این مورد در گیت خیلی ساده و آسان است ولی هیچ وقت واقعا نفهمیدم که چرا اینقدر طول کشید تا فیچرش به TFVC هم اضافه شود (و چرا وقتی که فیچرش اضافه شد هم هیچ‌وقت آن‌طور که انتظار می‌رفت کار نمی‌کرد). ایده‌اش خیلی ساده است: یک جایی یک لیستی داشته باشیم که بگوید سیستم کنترل نسخه چه فایل‌ها و پوشه‌هایی را باید نادیده بگیرد. در واقع این فایل‌ها هیچ وقت نباید اضافه یا ردیابی شوند. مگر اینکه خلافش را صریحا ذکر کنیم. این فیچر مثلا برای NuGet بسیار مفید است. چرا که راهی است که پوشه packageها را بشود ignore کرد (زیرا باید هر وقت لازم بود دانلود شوند).در گیت این کار با فایل gitignore. انجام می‌شود. این فایل باید اولین فایلی باشد که روی هر پروژه جدید چک می‌شود و در واقع هر بار که یک پروژه را به سیستم کنترل نسخه اضافه کنید، ویژوال استودیو این فایل را برای شما کامیت می‌کند. خوبی این فایل این است که کاملا صریح و شفاف است: هر فایل، پوشه یا الگویی از فایل‌ها که باید نادیده گرفته شوند، در این فایل ذکر شده باشد و هر تغییری هم که در محتوای آن داده شود، بلافاصله اعمال می‌شود.در واقع، TFVC هم تلاش می‌کرد که این کار را با فایل tfignore. انجام دهد. تلاش قابل توجهی است اما طبق تجربه، مساله را کامل حل نمی‌کند و حفره‌های زیادی دارد. مثلا اینکه فقط برای workspaceهای محلی کار می‌کند (فایل tfignore. هنگام استفاده از فضای کاری سرور، نادیده گرفته می‌شود) و حتی در فضای کاری محلی هم مواردی به چشم خورده که که فایل‌هایی که باید نادیده گرفته می‌شدند، نادیده گرفته نشدند!12. مجموعه‌ ابزار و ویژگی‌های بهتر حتی در داخل Azure DevOpsدر حال حاضر بیشتر ویژگی‌های جدید مرتبط با کنترل نسخه، فقط به گیت اضافه می‌شوند، گاهی به خاطر این‌که اصلا روی TFVC معنی ندارند. برای مثال فیچر «New Branch» را که به work itemهای برد کانبان اضافه شده است را در نظر بگیرید. اگر از گیت استفاده کنیم، این فیچر به ما اجازه می‌دهد مستقیما از روی تسک بتوانیم شاخه جدید بسازیم و وقتی که درخواست ادغام این شاخه به master را بدهیم، آن تسک به صورت خودکار به Pull Request لینک می‌شود. هم‌چنین هر وقت کسی بخواهد پیشرفت تسک را بررسی کند، می‌تواند خیلی راحت کامیت‌های آن شاخه را از روی خود تسک مشاهده کند.حالا TFVC را در نظر بگیرید. اصلا امکان ساخت یک شاخه به ازای هر تسک وجود دارد؟ بسته به سایز پروژه، زمان ساخت شاخه روی TFVC بیشتر از زمان تکمیل درخواست و push کردن آن به master در گیت طول خواهد کشید.ماهیت جریان کاری‌ای که حول Pull Requestهای گیت در TFS و Azure DevOps وجود دارد، به تنهایی یک دلیل محکم برای مهاجرت به سمت آن است. واقعا هیچ چیز نزدیک و مشابهی در TFVC وجود ندارد.این موضوع در مورد مرور کد هم صدق می‌کند. در TFVC اصلا این امکان وجود ندارد که بتوانید در حالی که درخواست‌دهنده اصلی مشکلات پیداشده را حل می‌کند، همچنان تغییرات را مرور و ردیابی کنید. اما Pull Request در گیت، این امکان را به شما می‌دهد که شاخه فیچر را مرتب بروز کنید تا زمانی که مرورکنندگان کاملا راضی شوند. تمام تغییرات هم ردیابی می‌شوند و افراد دیگر هم از تمام تغییرات مطلع می‌شوند. در کنار همه این‌ها، امکان کامنت‌گذاری با ارجاع مستقیم به کد هم وجود دارد.13. استفاده بر روی سایر پلتفرم‌هاTFVC یک محصول ویندوزی است و ایجاد شده تا داخل ویژوال استودیو استفاده شود. البته مشتریانی هم بر روی سایر پلتفرم‌ها دارد ولی آن‌ها نمی‌توانند بدون دردسر از آن استفاده کنند. حتی extensionهای موجود هم نتوانسته‌اند این دردسرها را کم کنند و نظرات منفی بسیار زیادی حول آن وجود دارد. حتی دیده شده که برخی از توسعه‌دهندگانی که روی اکلیپس(Eclipse) کار می‌کنند، به صورت مجزا و صرفا برای کار با سیستم کنترل نسخه، از ویژوال استودیو استفاده می‌کردند زیرا از سر و کله زدن با Team Explorer استرس کمتری دارد.حقیقت این است که خارج از استک مایکروسافت، گیت سال‌هاست که انتخاب مطلق و قطعی برای سیستم کنترل نسخه است و این روزها مایکروسافت هم به خوبی آن را در آغوش کشیده است.جمع‌بندیدر هر صورت ممکن است که TFVC همچنان بهترین گزینه شما باشد. اگر یک دلیل کاملا محکم برای استفاده از آن داشته باشید (مثلا آیین‌نامه‌هایی که از شما انتظار دارند در هر زمان دسترسی هر توسعه‌دهنده‌ به هر فایلی را متوجه شوید و توانایی قطع دسترسی یک گروه از افراد را به یک فایل خاص داشته باشید). اما در بیشتر موارد، همچنان بهتر است که از TFVC به سمت گیت مهاجرت کنید.البته مهاجرت به گیت ممکن است در ابتدا شما را سردرگم و ناراحت کند. چرا که از ناحیه امن‌تان خارج شده‌اید و منحنی یادگیری گیت هم خیلی هموار نیست. با این وجود هنوز کسی را ندیدم که به صورت حرفه‌ای با TFVC و گیت کار کرده باشد و ترجیح بدهد که به TFVC برگردد (با وجود اینکه اولش در مقابل پیشنهاد مهاجرت به گیت مقاوت شدیدی داشتند). و حالا همان توسعه‌دهندگانی که به شدت مخالف تغییر بودند، اذعان دارند که با گیت زندگی‌شان راحت‌تر شده است.منابعgit vs team foundation serverAzure DevOpsChoosing the right version control for your projecta simple tutorial for migration to gitwhy to use git instead of tfsTFS version control is dead شرکت مشاوران نرم‌افزاری اعوان تیم چکاپ Tue, 17 Aug 2021 17:57:03 +0430