چالش‌های پیش روی سیستم‌های نرم‌افزاری

توسعه دهندگان سیستم در طول زمان با چالش‌های متفاوتی روبرو خواهند شد که این چالش‌ها مستلزم ایجاد تغییراتی در سیستم‌های موجود یا تغییر رویه‌های طراحی و توسعه برای سیستم‌های جدید خواهد شد. شناخت هرچه بهتر و سریعتر این چالش‌ها و اهمیت دادن به آنها می‌تواند مشکلات ناشی از این چالش‌ها را در آینده برای ما کمتر و رفع آنها را کم هزینه‌تر کند. احتمالا اکثر سیستم‌ها از چالش‌هایی که تا کنون با آنها روبرو شده‌اند سربلند بیرون آمده‌اند اما مسئله مهم این است که بتوانیم با شناخت این چالش‌ها، آنها را به شکل proactive حل کنیم و به تغییرات reactive نیازی نشود. این امر قطعا در میزان رضایت مشتریان و کیفیت نرم‌افزارهایمان تاثیر مستقیم خواهد گذاشت.

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

چالش سال 2038 (Y38K)

مبدا تاریخ (Epoch) اشاره به نقطه‌ی مشخصی از زمان دارد که به عنوان مبنای محاسبه زمان مورد استفاده قرار می‌گیرد. به عنوان مثال میلاد مسیح یک مبدا تاریخی است و می‌دانیم امسال ۲۰۱۸ سال از آن روز می‌گذرد.

در سیستم‌های نرم‌افزاری نیز مبداهای تاریخ متفاوتی استفاده می‌شود. مثلا در ساعت یونیکس (Unix time یا Unix timestamp) که به صورت گسترده در سیستم عامل‌های شبه‌یونیکس و برخی دیگر از سیستم عامل‌ها و فایل فرمت‌ها مورد استفاده قرار می‌گیرد، مبدا تاریخ ساعت ۰۰:۰۰:۰۰ روز اول ژانویه سال ۱۹۷۰ میلادی (به وقت گرینویچ) است. ساعت یونیکس توسط تعداد ثانیه‌هایی که از مبدا تاریخش گذشته است مشخص می‌شود. به عنوان مثال در ساعت ۱۱:۳۰:۰۰ روز ۲۰ آگوست سال ۲۰۱۸ میلادی، ۱۵۳۴۷۶۲۸۰۰ ثانیه از تاریخ مبدا گذشته است و همین عدد به عنوان ساعت یونیکس مورد استفاده قرار می‌گیرد.

مشکل کجاست؟

در سیستم‌های ۳۲بیتی که از ساعت یونیکس استفاده می‌کنند، بزرگترین عدد قابل ذخیره در یک متغیر عددی صحیح علامت دارد (signed 32-bit integer)، عدد ۲۱۴۷۴۸۳۶۴۷ (دو به توان ۳۱ - ۱) است. این عدد برابر با ساعت ۰۳:۱۴:۰۷ در روز پنجشنبه، ۱۹ ژانویه ۲۰۳۸ میلادی است. عددهای بزرگتر به عنوان یک عدد منفی ذخیره خواهند شد (چرا؟ چون overflow رخ می‌دهد. فرم مکمل ۲ در ذخیره اعداد صحیح به صورت باینری را بررسی کنید) که به عنوان روز ۱۳ دسامبر ۱۹۰۱ تفسر خواهد شد و نه ۱۹ ژانویه ۲۰۳۸.

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

راه حل چیست؟

در جاهایی که محدودیت‌های سخت افزاری وجود دارد راه حل‌های زیادی وجود ندارد (اما به هر حال قابل حل است!) اما خبر خوب این است که سیستم‌های ۶۴بیتی تقریبا فراگیر شده و توسعه دهندگان سیستم می‌توانند با کمی توجه از این مشکل عبور کنند!

چالش سال ۱۴۰۰

خیلی از زبان‌های برنامه‌نویسی یا سیستم‌های مدیریت پایگاه داده و... از تاریخ شمسی به شکل توکار پشتیبانی نمی‌کنند. اما به هر حال ما به دلایلی تصمیم گرفته‌ایم در نرم‌افزارهایمان تاریخ‌ها را به شکل شمسی ذخیره کنیم و محاسباتی روی آنها انجام دهیم. چیزی که در سیستم‌ها به کرات دیده می‌شود، ذخیره تاریخ شمسی به شکل یک عدد صحیح شش رقمی است. مثلا ۹۷۰۵۲۸. عمده توابع تبدیل تاریخ که در زبان‌های برنامه‌نویسی مختلف در دسترس است نیز با همین فرمت کار می‌کنند و عمدتا الگوریتم‌های بکار رفته در آنها نیز تا سال ۱۳۹۹ را پشتیبانی می‌کنند.

مسئله این است که سال ۱۴۰۰ چه می‌شود؟ تاریخ‌ها چگونه ذخیره خواهند شد؟ ۰۰۰۱۰۱ روز اول سال ۱۴۰۰ است؟ توابع تبدیل تاریخ چه خواهند کرد؟

خیلی دور نیست زمانی که سال ۱۴۰۰ را جشن خواهیم گرفت و اگر امروز به فکر یک اصلاح پیشگیرانه (Preventive) برای حل این چالش نباشیم، نوروز ۱۴۰۰ برای مسئولان سیستم‌هایی که از چنین منطقی بهره می‌برند، جشن نخواهد بود!

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

چالش تغییر پول ملی

تکلیف تغییرات پول ملی مشخص نیست. n صفرش حذف می‌شود؟ ریال باقی خواهند ماند؟ تومان می‌شود؟ یا اسم دیگری خواهد داشت؟ مشخص نیست و مشخص نیست کی مشخص خواهد شد! اما ما مجبوریم به توسعه سیستم‌هایمان ادامه دهیم. ابعاد تغییرات ناشی از تغییر پول ملی ممکن است خیلی کم یا خیلی زیاد باشد. این چالش همانند چالش سال ۱۴۰۰ نیست که بدانیم دقیقا با چه روبرو خواهیم شد و ابعادش چیست و عقل سلیم می‌گوید باید برای بدترین سناریو آماده باشیم. مثلا چهار صفر حذف می‌شود و اسمش می‌شود «پارسی»و «دریک» که یک صدم یکای اصلی ارزش دارد!

یک طراح باهوش احتمالا با استفاده از یک الگوی طراحی مناسب (مثلا Factory Method یا حتی Proxy) سیستم‌هایش را به نحوی توسعه خواهد داد که با مشخص شدن ابعاد تغییرات و با یک تغییر انطباقیِ (Adaptive) نه چندان پیچیده بتواند مسئله تغییر پول ملی را حل نماید.

برای سیستم‌های موجود نیز فرصت برای یک تغییر تکمیلی (Perfective) وجود دارد که به محض تغییر پول ملی بتوان با یک تغییر انطباقی (Adaptive) نه چندان پیچیده مسئله را حل کرد.

به نظرتان چه چالش‌های دیگری وجود دارد که می‌تواند سیستم‌های نرم‌افزاری ما را تحت تاثیر قرار دهد؟