سلام. موضوع آموزش امروز من “آموزش ساخت برنامه فشرده ساز فایل در سی شارپ + سورس کد” است که این آموزش رو تو یک فایل تصویری فشرده کردم. تو این شیوه آموزش هیچ توضیحاتی داده نمی شه و تنها تصاویر گویای تمام مراحل انجام کار خواهد شد. همراه این فایل تصویری سورس کد هم قرار گرفته. پس اگر مشکلی تو این آموزش داشتین یا جایی از این آموزش براتون گنگ بود ، می تونین به سورس کدها مراجعه کنین.
در دنیای مدیریت نرمافزار یک موقعیت ناخوشایند به نام “جهنم وابستگی” وجود دارد. هر چه سیستم شما بزرگتر می‌شود و هر چه کتابخانه‌های بیشتری به نرمافزار خود می‌افزایید، به همان میزان احتمال گرفتار شدن شما در این دام بیشتر خواهد شد.
در سیستم‌هایی با وابستگی بسیار زیاد، انتشار نسخه جدید کم کم تبدیل به یک کابوس می‌شود. اگر وابستگی شما به کتابخانه‌ها بسیار زیاد و پیچیده باشد، شما در معرض خطر قفل شدن انتشار نسخه جدید قرار می‌گیرید (عدم توانایی برای بروزرسانی یک کتابخانه بدون انتشار نسخه جدید کتابخانه‌های وابسته). اگر وابستگی شما به کتابخانه‌ها خیلی بی‌قاعده و کم باشد، شما ناگزیر توسط نسخه‌های بی‌قاعده درگیر می‌شوید. هنگامی که مشکل قفل شدن انتشار نسخه جدید و/یا انتشار نسخه‌های بی‌قاعده شما را از حرکت مناسب و خوب برای تکمیل پروژه‌تان بازمی‌دارد، در واقع شما در “جهنم وابستگی” قرار دارید.
به عنوان یک راه حل برای حل این مشکل، یک مجموعه ی ساده از قوانین و الزامات که چگونگی طراحی شماره های نسخه و افزایش آن را دستور میدهد را پیشنهاد می‌کنیم. برای کار کردن این سیستم، شما ابتدا نیاز به اعلام API عمومی دارید. این خود ممکن است شامل مستندات و یا اجرای کد باشد. علی رغم آن، مهم است که این API روشن و دقیق باشد. هنگامی که API عمومی خود را تعیین کردید، تغییرات برنامه شما بر روی نسخه API عمومی تاثیر خواهد داشت و آنرا افزایش خواهد داد. بر این اساس، این مدل نسخه‌بندی را در نظر بگیرید: X.Y.Z یعنی (Major.Minor.Patch). رفع حفره‌هایی که بر روی API عمومی تاثیر نمی‌گذارند، مقدار Patch را افزایش می‌دهند، تغییرات جدیدی که سازگار با نسخه قبلی است، مقدار Minor را افزایش می‌دهند و تغییرات جدیدی که کاملا بدیع هستند و به نحوی با تغییرات قبلی سازگار نیستند مقدار Major را افزایش می‌دهند.
واژه‌های “باید”، “نباید”، “الزامی”، “بهتر است”، “توصیه می‌شود”، “می‌تواند” و… در این سند مورد استفاده است و توضیحات کامل آن در RFC2119 داده شده است.
این یک ایده‌ی جدید یا انقلابی نیست. در حقیقت ممکن است کارهایی شبیه به آن را قبلا انجام داده باشید. موضوع این است که شباهت به این کار به اندازه‌ی کافی خوب نیست. شماره بندی نسخه‌ها بدون تطبیق با برخی کلاس بندی نسخه‌ها، برای مدیریت وابستگی بی فایده می‌باشد. با اسم گذاری و تعریف روشنی از ایده فوق، به راحتی میتوانید منظور خود را به کاربران نرمافزار خود منتقل کنید. هنگامی که این مفاهیم روشن باشند، شما میتوانید جزئیات وابستگی‌های خود را مشخص کنید.
یک مثال ساده دقیقا می‌تواند بیانگر این موضوع باشد. یک نرمافزار به نام “Firetruck” را در نظر بگیرید. این نرمافزار نیاز به یک کتابخانه به نام “Ladder” دارد که از نسخه بندی معنایی پیروی می‌کند. وقتی Firetruck ایجاد می‌شود، Ladder در نسخه‌ی ۳٫۱٫۰ است. از آنجایی که Firetruck خواصی که در ابتدا در ۳٫۱٫۰ معرفی شد را استفاده می‌کند، میتوانید با آرامش خاطر از نسخه‌های بزرگتر از ۳٫۱٫۰ و کمتر از ۴٫۰٫۰ استفاده کنید. حال وقتی Ladder نسخه‌ی ۳٫۱٫۱ و ۳٫۲٫۰ در دسترس باشد، شما می توانید به راحتی آن‌ها را منتشر کنید و بدانید با نرم‌افزارهایی که با آن وابسته هستند سازگاری کامل دارد.
دنیای واقعی پیچیده است، نمی‌توان کاری کرد اما باید گوش به زنگ بود. آنچه شما میتوانید انجام دهید آن است که اجازه دهید نسخه بندی معنایی شما را به یک راه عاقلانه برای انتشار و به روز رسانی بسته‌ها مجهز کند، این کار در وقت و انرژی شما صرفه جویی می‌کند.
اگر تمام این‌ها مطلوب به نظر برسد، تمام آن چیزی که شما احتیاج دارید برای شروع استفاده از نسخه بندی معنایی این است که اول مشخص کنید می‌خواهید از آن استفاده کنید و سپس از قوانین مشخص شده پیروی نمایید!
بهترین و آسان‌ترین راه برای ایجاد و تعریف نسخه اولیه نرم‌افزارتان این است که با نسخه ۰٫۱٫۰ شروع کنید و سپس در هر گسترش با توجه به قوانین تعریف شده اقدام به افزایش نسخه کنید.
اگر نرمافزار شما در مرحله استفاده کاربردی است و بصورت محصول ارائه شده است، احتمالا در نسخه ۱٫۰٫۰ قرار دارید. اگر یک API بی‌عیب و نقص دارید که مشتریانی از آن استفاده می‌کنند و یا به آن وابستگی دارند، شما در نسخه ۱٫۰٫۰ قرار دارید. اگر نسبت به سازگاری نرمافزار خود با بسترهای قدیمی حساسیت زیادی دارید، پس احتمالا در وضعیت نسخه ۱٫۰٫۰ قرار دارید.
به این نکته توجه کنید که نسخه Major صفر (۰) دقیقا به توسعه سریع اشاره دارد و با توسعه سریع همراه است. اگر API شما دائما تغییر می‌کند، یا در حال کار بر روی نسخه ۰٫x.x هستید یا اینکه در حال کار بر روی نسخه بعدی نرمافزار، در یک شاخه (Branch) توسعه دیگر هستید.
این سوال بسیار مهمی است، بهتر است کمی دقیق‌تر به اصل موضوع توجه کنیم. در واقع، تغییرات ناسازگار نباید به راحتی در یک نرمافزار با وابستگی‌های بسیار زیاد ایجاد شود. هزینه‌ای که برای بروزرسانی پرداخت می‌شود واقعا قابل توجه است. افزایش دادن نسخه Major به منظور ارائه برخی تغییرات ناسازگار در یک نرمافزار باید با توجه میزان، اهمیت و تاثیرگذاری تغییرات ایجاد شده باشد نه هر تغییر کوچک.
این در حقیقت عکس‌العمل شما به عنوان یک برنامه‌نویس حرفه‌ای است که به استفاده کنندگان از برنامه شما کمک می‌کند تا راحت‌تر بتوانند با برنامه شما کار کنند. مدیریت کردن یک نرمافزار یکی از مهم‌ترین بخش‌ها در جهت حفظ کارایی یک پروژه است، و این بسیار سخت و پیچیده خواهد بود اگر کسی نداند که چطور با برنامه شما کار کند، کدام method برای صدا زدن بهتر است یا چه بخش‌هایی از برنامه منقرض شده‌اند. در طی زمان و با بالا رفتن عمر پروژه، نسخه بندی معنایی و پافشاری بر تهیه یک API عمومی استاندارد و طبق قوانین تعیین شده، به ادامه پروژه یا پروژه‌های که از برنامه شما استفاده می‌کنند کمک می‌کند که به راحتی و بدون مشکل کار کنند.
به محض اینکه متوجه شدید قوانین نسخه بندی معنایی را زیر پا گذاشته‌اید، سریعا مشکل را برطرف سازید و یک نسخه Minor جدید منتشر کنید که مشکل در آن برطرف شده است. به خاطر داشته باشید، این اصلا قابل پذیرش نیست که نسخه‌های منتشر شده را ویرایش یا اصلاح کنید، حتی در یک حالت بحرانی. در هر صورت اگر در حالتی خاص مجبور به انجام این کار شدید، باید آن را مستند کنید و نسخه‌ای که اصلاح شده را در مستندات ذکر کنید تا مشتریان و کاربران نرمافزار از مشکل بوجود امده مطلع گردند و از استفاده نسخه دچار مشکل پرهیز کنند.
اگر بروز کردن وابستگی‌های نرم‌افزارتان بر روی API عمومی تاثیر گذار نباشد، هنوز میتوانید بدون تغییر به کارتان ادامه دهید. اینکه بعد از بروز رسانی وابستگی‌های پروژتان، باید چه نسخه‌ای منتشر شود دقیقا مرتبط به این است که شما به چه دلیل وابستگی‌هایتان را بروز کرده‌اید. بروزرسانی برای ایجاد یک امکان جدید در نرمافزار انجام شده یا مشکل/حفره‌ای که از قبل وجود داشته را با این کار حل کرده‌اید؟
منقرض اعلام کردن یک قابلیت یا فعالیت، روال طبیعی تولید نرمافزار است که گاهی اوقات برای ادامه بهتر و سریع‌تر پروژه لازم است. زمانی که بخشی از API عمومی را می‌خواهید منقرض شده اعلام کنید، باید دو عمل مهم را انجام دهید:
توصیه می‌شود قبل از انتشار نسخه Major به منظور حذف کامل قسمت منقرض شده، حداقل یک نسخه Minor قبل از انتشار این نسخه وجود داشته باشد که به کاربران و ذی‌نفعان تغییر اعمال شده را اطلاع‌رسانی کند تا بتوانند راحت‌تر به نسخه جدید API کوچ کنند و از آن استفاده کنند.
