من محسن خلیلی هستم و نزدیک ده سال است که در حوزه توسعه نرم افزار فعالیت می‌کنم، یکی از چالش هایی که من همیشه درگیر اون بودم اضافه کردن یک فیچر جدید به یک محصول در حال توسعه است، البته معمولا این اضافه کردن چالش خاصی نداره و چالش اصلی بعد از اضافه کردن فیچر جدید رخ میده :)
در این مقاله سعی دارم به نحوه حل مشکل و شاید کمتر کردن مشکل سختی توسعه در تیم های بزرگ نرم افزاری و حتی کوچک اشاره کنم و راهکاری که می تونه به ما در حل این مشکل کمک کنه رو با هم بررسی کنیم. Feature Toggles یکی از راهکاری کم کردن این مشکل و همین طور کمک به بهبود TBD خواهد بود.
یکی از مشکلات بزرگی که توسعه دهندگان سیستم های نرم افزاری معمولا درگیر اون هستند توسعه یک سیستم در حال فعالیت است، معمولا به خاطر Rigidity و Fragility موجود در کدهای قبلی و نبود تست نویسی عمل توسعه به سختی و با تست انسانی بسیار انجام میشود.
فرض کنید که در یک تیم بزرگ کار می کنید که همزمان ۲-۳ تیم به صورت همزمان مشغول توسعه یک محصول نرم افزاری هستند کافی است که شما در یک گوشه کاملا بی ربط از کد یک خط کد را تغییر دهید تا مشاهده کنید که به خاطر تغییر بخشی از کد توسط شما نه تنها داد سایر تیم ها درآمده بلکه در کمال ناباوری مانیتور مدیرعامل شما نیز خاموش و حتی لیست بیمه شرکت نیز خود به خود حذف میشود و شما از کار اخراج می‌شوید!
در بسیاری از سیستم های بزرگ در حال حرکت عملا تغییر بخشی از کدهای فعال همانند تعمیر یک هواپیمای در حال پرواز می باشد و باید به نحوی این کار صورت گیرد که مسافران پرواز به هیچ وجه متوجه این عملیات نشوند.
عامل اصلی به وجود آمدن مشکلات سعی در تغییر کد فعال در حالت عملیاتی است، فرض کنید شما در تیم توسعه نسخه اندروید گوگل پلی فعالیت می کنید و از شما می‌خواهند نواری شامل یک سری دسته بندی به قسمت بالای صفحه نخست نرم افزار اضافه کنید.
قبل از شروع کار طرح گرافیکی فوق در اختیار شما قرار می گیرد که بدانید باید به چه نحو این کار صورت گیرد. احتمالا شما یک برنچ از مستر خواهید ساخت و بعد از کلی تلاش و گذشت چند روز قصد دارید آن را با برنچ مستر مرج کنید، احتمالا اولین مشکل شما همین جا خواهد بود و باید به خاطر این تلاش چند روزه و عقب افتادن از مستر بسیاری از مغایرت های به وجود آمده را رفع کنید.
بعد از حل این مشکلات به شما گزارش می شود که این بخش جدید اضافه شده توسط شما باعث خرابی اسکرول عمودی صفحه شده است و با توجه به خراب شدن نسخه مستر شما باید در تعطیلات این مشکل را حل کنید که برای بعد از تعطیلات آماده انتشار نسخه جدید باشیم.
احتمالا این داستان به تناوب در تمامی تیم ها در حال رخ دادن است، احتمالا شما هم به عنوان خواننده این مطلب باعث خرابی های این چنینی و کارهای خارج از روال معمول و آخر هفته ای شده اید.
حالا فرض کنید که شما دانش استفاده از Feature Flag را داشتید و اینگونه عمل می کردید:
قبل از شروع کار شما یک کلید روشن و خاموش (که در مطالب آینده در مورد نحوه پیاده سازی فنی آن برای شما خواهم نوشت) برای این قطعه کد خود تعریف می کنید و کلید را فقط برای خودتان باز می کنید به نحوی که اگر کسی جز شما وارد این صفحه شود این بخش از کد شما برای او اجرا نشود و صفحه را مانند قبل ببیند. البته منظور من حذف نمایش نخواهد بود و عملا باید آن قطعه کد جدید از اجرا کنار گذاشته شود. (در مورد نحوه پیاده سازی روش های متنوعی وجود دارد که در مطالب آینده در مورد آنها خواهم نوشت اما برای مطالعه بیشتر شما یکی از روش ها استفاده از branch by abstraction خواهد بود)
احتمالا در همان روز اول شما کلید را ساخته و با مستر مرج کرده اید و درگیر حل مغایرت ها نخواهید شد.
در روزهای آینده با توجه به اینکه کد شما عملا توسط کلید تعریف شده کنار گذاشته شده و باعث مشکل سایرین نخواهد شد شما می توانید هر روز بخشی از ویژگی های جدیدی را که مد نظر دارید با برنچ مستر مرج کنید بدون اینکه هیچ از اعضای تیمها نگران خراب شدن فیچر های خود باشد به همین خاطر برخلاف قبل نیازی به تمام شدن یک فیچر برای مرج شدن با مستر نخواهد بود شما عملا هر روز همه ی کدهای خود را با مستر مرج و با خیال راحت به منزل خود می روید.
بعد از مدتی خواهید دید به طور محسوسی می توانید کدهای بیشتر بنویسید و وقت شما درگیر حل مشکلات و مغایرت ها با تیم های دیگر نخواهد شد و شما دیگر کد بیات(!) نخواهید داشت.
بعد از تمام شدن کدنویسی می توانید فیچر را برای سایر هم تیم ها و افراد تستی باز کنید و همه می توانند این فیچر جدید را ملاحظه و تست کنند.
حالا حتی اگر مشکلی برای فیچر جدید شما به وجود آمده باشد و یا باعث به وجود آمدن مشکل برای سایر تیم ها شده باشد کافی است که کلید را خاموش کنید و با خیال راحت به تعطیلات آخر هفته خود بپردازید!
اگر تمامی تیم ها با استفاده از این روش به توسعه محصول بپردازند مدیر محصول قادر خواهد بود برای انتشار نسخه نهایی فقط فیچرهای جدید که به صورت کامل پیاده شده اند را منتشر و سایر کدها را خاموش کند و عملا دیگر نگرانی خرابی نسخه مستر مطرح نخواهد بود و در هر لحظه می توان بدون هیچ مشکلی از برنچ مستر نسخه داد.
این کلید هیچ تفاوتی با کلید روشن خاموش کردن اتاق شما ندارد و فقط به جای برق، کد شما را وصل و قطع می کند. روش های مختلفی برای پیاده سازی این کلید وجود دارد و عملا در بسیاری از سیستم های دارای پروفایل کاربری می توان از مشخصه منحصر به فرد کاربر استفاده و کلید های مختلفی برای هر او تعریف و فرآیند توسعه را تسهیل نمود. برای پیاده سازی این نوع از کلیدها نیاز به داشتن دانش فنی خاصی نیست و فقط کافی است که شرایطی فراهم کنید که بتوان به صورت ریموت کلید را روشن یا خاموش نمود.
شما حتی می توانید کلید های کامل ساده و بدون کنترل ریموت و به صورت هاردکد نیز استفاده نمایید، این کلید ها اولین گونه کلید ها بوده اند به عنوان مثال:
حتی استفاده از این کلیدها در خیلی از موارد جوابگوی بسیاری از نیاز ها خواهد بود ولی اگر نرم افزار شما شامل کلاینت های موبایلی و ویندوزی و امثالهم است که عملا به روز رسانی آنها به اراده کاربر وابسته است بهتر بتوانید به صورت ریموت این کار را انجام دهید تا در صورت بروز مشکل بتوانید بدون نیاز به نسخه کلیدی را خاموش یا روشن نمایید.
فرض کنید کلیدی برای روشن خاموش کردن یک ویژگی به اسم "Intro" طراحی کرده اید و شما علاوه بر نسخه اندروید، نسخه آی او اس، وب، … نیز در حال توسعه هستید.
بهتر است کلید ها به نحوی با استفاده از پلتفرم متمایز شوند و فقط اسم کلید مشترک باشد. به عنوان مثال نام گذاری کلید در پلتفرم های مختلف می تواند اینگونه باشد
در این حالت برای خاموش کردن کلید "Intro" مشکلی برای این کلید در یک پلتفرم دیگر به وجود نمی آید.
من سعی کردیم در این نسخه به صورت ساده مشکل رو مطرح و مزایایی که برای شما در استفاده از این روش خواهد بود رو شرح بدم، برای عملیاتی کردن این روش ها نیاز به نگاه فنی به موضوع خواهید داشت.
در مقاله آینده من به بررسی چند مدل پیاده سازی فنی این کلید های خاموش روشن خواهم پرداخت.
