کیپ چنجلاگ(keep a changelog) چیست؟ و چرا؟

وقتی صحبت از نگهداری و مدیریت نسخه‌های مختلف یک پروژه می‌شه، چیزی که معمولا نادیده گرفته می‌شه یا کم‌اهمیت به نظر میاد، چنجلاگ‌ها هستن. اما واقعیت اینه که یه چنجلاگ درست و خوب می‌تونه به میزان زیادی در سازماندهی و شفاف‌سازی تغییرات کمک کنه. و این سازماندهی و شفافیت باعث جلوگیری از هدر رفت زمان و حفظ منابع میشه، اینجاست که مفهوم Keep a Changelog مطرح می‌شه.

اگه دوست دارید در مورد چگونگی نوشتن خود چنجلاگ بدونید پیشنهاد پست "چنجلاگ چیست و چرا؟" رو حتما بخونید.

کیپ چنجلاگ (Keep a Changelog) در واقع یک استاندارد یا روشی برای نوشتن چنجلاگ‌هاست که هدفش نظم‌دهی و استانداردسازی این بخش از فرآیند توسعه است. در ادامه، میخواییم راجب این صحبت کنیم که چرا این روش کارآمده و چطور میتوینم به شکل موثری از اون استفاده کنیم.

چرا Keep a Changelog مهمه؟

اگه یک سیستم یا محصولی رو در طول زمان به‌روزرسانی می‌کنید، چه نرم‌افزار باشه، چه یک دیزاین سیستم، باید بتونید به روشنی به کاربران و تیم‌های دیگه نشون بدید که چه تغییراتی رخ داده. اینجاست که چنجلاگ می‌تونه یک ابزار عالی باشه.

اما چنجلاگ‌های غیرشفاف، پراکنده یا نامرتب می‌تونن بیشتر از اینکه راه‌حل باشن، مشکل‌ساز بشن. خیلی وقت‌ها چنجلاگ‌ها به شکل ناقص یا حتی بدون دسته‌بندی نوشته می‌شن و افراد به راحتی نمی‌تونن تغییرات رو دنبال کنن. فریمورک Keep a Changelog با استاندارد کردن ساختار چنجلاگ‌، این مشکلات رو رفع می‌کنه.

این روش به شما کمک می‌کنه تا تغییرات رو به صورت منظم، دسته‌بندی شده و قابل فهم ثبت کنید، به طوری که هر کسی بتونه به راحتی بفهمه چه چیزی تغییر کرده، چرا این تغییر اعمال شده و چه زمانی این تغییرات رخ دادن.

ساختار Keep a Changelog

کیپ چنجلاگ Keep a Changelog توصیه می‌کنه که تغییرات رو به بخش‌های مختلف تقسیم کنید تا خوانایی و پیگیری راحت‌تر بشه. به طور معمول دسته بندی های پیشفرض موارد زیر هستن:

١. (اضافه شده) Added:

در این بخش، هر چیزی که به پروژه اضافه شده باشه، ثبت می‌شه. برای مثال اضافه شدن یک کامپوننت جدید به دیزاین سیستم و یا افزوده شدن قابلیت جدیدی به نرم‌افزار.

یا اگه بخواییم مثال های واقعی تری داشته باشیم:

• اضافه شدن کامپوننت کارت اطلاعات با سایه و فاصله‌های استاندارد برای صفحات پروفایل.
• اضافه شدن آیکون‌های جدید دسترسی برای نمایش واضح‌تر برای کاربران با نیازهای ویژه.
• اضافه شدن تم جدید تیره و روشن برای انعطاف‌پذیری بیشتر در تجربه کاربری.

۲. (تغییر کرده) Changed:

برخی تغییرات هستن که بری روی اجزای موجود اعمال میشن، این تغییرات در این بخش قرار می‌گیرن. مواردی مثل تغییر رنگ دکمه‌ها ویا اصلاح استایل کارت‌های اطلاعاتی.

مثال‌های واقعی‌:

• تغییر ارتفاع خطوط (line-height) در متن‌های پاراگراف برای خوانایی بهتر در دستگاه‌های موبایل.
• تغییر رنگ‌های اولیه دیزاین سیستم از آبی تیره به آبی روشن برای بهبود هویت بصری.
• به‌روزرسانی استایل دکمه‌های CTA برای داشتن گوشه‌های گردتر و هماهنگی بیشتر با هویت برند.

۳. (منسوخ شده) Deprecated:

این بخش مربوط به ویژگی‌هاییه که قراره در آینده نزدیک حذف بشن. این اطلاعات به تیم‌ها و کاربران کمک می‌کنه که بدونن چه ویژگی‌هایی دیگه نباید استفاده بشه و باید به فکر جایگزینش باشن. مواردی مثل کلاس‌های CSS قدیمی که به زودی حذف خواهند شد. کامپوننت کارت قدیمی که به‌زودی با نسخه جدید با زاویه‌های گردتر جایگزین خواهد شد.

یا اگه بخواییم واقعی‌تر مثال بزنیم:

• پالت رنگ قدیمی که به زودی پشتیبانی نمی‌شه؛ از پالت جدید با کنتراست بهتر استفاده کنید.
• استفاده از فونت Sans Serif نسخه 1 به زودی منسوخ می‌شه؛ لطفا از نسخه 2 با بهبود خوانایی استفاده کنید.

4. (حذف شده) Removed :

ویژگی‌ها یا کامپوننت‌هایی که به‌طور کامل از سیستم حذف شدن، تو این بخش قرار می‌گیرن. مواردی مثل حذف کامپوننت ناوبری قدیمی یا حذف کامپوننت “باکس‌های هشدار قدیمی” و جایگزینی اون‌ها با ورژن جدید که قابلیت‌های بیشتری مثل نمایش ایکون داره.

یا:

• حذف پشتیبانی از حالت “Hover” در موبایل به دلیل مشکلات عملکردی و تمرکز بر قابلیت‌های لمسی.
• حذف سایه‌های اضافی از دکمه‌های اصلی برای داشتن طراحی مینیمال‌تر و تمیزتر.

5.(رفع شده) Fixed :

این بخش مخصوص رفع باگ‌ها و مشکلاته. برای مثال:

• رفع مشکل فاصله بیش از حد بین تیترها و بدنه متن در کارت‌های اطلاعاتی.
• رفع باگ ناهمخوانی اندازه آیکون‌ها در کامپوننت‌های مختلف در صفحه داشبورد.
• رفع مشکل عدم تراز صحیح دکمه‌های CTA در نسخه موبایل.

6. (امنیتی) Security :

هر گونه به‌روزرسانی امنیتی یا اصلاحات مربوط به آسیب‌پذیری‌های امنیتی اینجا ثبت می‌شه. این بخش معمولا مربوط به بخش دیزاین نیست در نتیجه من از مثال های بخش دولوپ استفاده میکنم.(البته که در بخش های بالا هم بخش های فنی و دولوپ میتونن شامل بشن و چنجلاگ صرفا مربوط به بخش دیزاین و مربوط به تمامی بخش هاست) برای مثال:

• رفع مشکل نفوذپذیری در سیستم احراز هویت.
• رفع مشکل آسیب‌پذیری در سیستم احراز هویت که امکان حملات CSRF را فراهم می‌کرد.
• به‌روزرسانی کتابخانه OpenSSL به نسخه جدیدتر برای جلوگیری از حملات احتمالی.
• بهبود سیستم رمزگذاری اطلاعات کاربران به منظور افزایش امنیت داده‌ها.

نکات مهم برای نوشتن چنجلاگ با Keep a Changelog

حالا که ساختار کلی رو فهمیدید، چند نکته برای نوشتن یک چنجلاگ موثر به روش Keep a Changelog رو بررسی می‌کنیم:

1. شفافیت

یکی از مهم‌ترین اهداف Keep a Changelog اینه که چنجلاگ به‌صورت شفاف و قابل فهم نوشته بشه. باید از جملات ساده و واضح استفاده کنید تا هر کسی که چنجلاگ رو می‌خونه، به راحتی متوجه تغییرات بشه. از عبارات مبهم یا پیچیده خودداری کنید. برای مثال:

• به جای “ویژگی جدید اضافه شد”، بنویسید “قابلیت درگ و دراپ به صفحه پروفایل اضافه شد.”

2. دسته‌بندی منظم

با دسته‌بندی تغییرات، افراد به راحتی می‌تونن به بخشی از چنجلاگ که بهشون مربوطه دسترسی پیدا کنن. برای مثال دیزاینرها می‌تونن به بخش تغییرات دیزاین توجه کنن و توسعه‌دهنده‌ها به بخش فنی. این ساختار منظم باعث صرفه‌جویی در وقت و جلوگیری از سردرگمی می‌شه.

3. تاریخ انتشار هر نسخه

هر نسخه باید همراه با تاریخ انتشار ثبت بشه. این کار به کاربران کمک می‌کنه تا زمان تغییرات رو بدونن و بتونن نسخه خودشون رو با نسخه‌های قبلی مقایسه کنن. برای مثال:

نسخه 2.1.0 - 20 اکتبر 2024

4. تغییرات بزرگ رو برجسته کنید

اگه تغییرات بزرگی اعمال کردید که می‌تونه روی کاربران یا تیم‌ها تأثیر زیادی بذاره، حتما این تغییرات رو برجسته کنید. این می‌تونه با استفاده از فونت بولد یا نشانه‌گذاری ویژه باشه تا توجه بیشتری جلب کنه.

چرا باید از Keep a Changelog استفاده کنیم؟

استفاده از Keep a Changelog نه تنها به شما کمک می‌کنه تا تغییرات پروژه رو به‌صورت منظم و شفاف ثبت کنید، بلکه باعث می‌شه تا تیم‌های مختلف راحت‌تر با هم کار کنن و همه در جریان تغییرات باشن. این روش استاندارد یک ابزار ارزشمنده که می‌تونه ارتباطات داخلی تیم و همچنین ارتباط با کاربران رو بهبود بده.