نگاهی به گذشته: چرا نرم‌افزارها امروز با وجود افت کیفیت، باز هم از گذشته بهترند؟ — Software may be getting worse, but it used to be horrible
خلاصه
برخی معتقدند کیفیت نرم‌افزارها در حال افت است، اما مرور خاطرات دهه‌های گذشته نشان می‌دهد که نرم‌افزارهای قدیم بسیار ناپایدارتر و پر از باگ بودند. این مقاله با بررسی مشکلات تاریخی مثل صفحه آبی مرگ و خطاهای مدیریت حافظه، وضعیت فنی گذشته را با امروز مقایسه می‌کند.
بسیاری از برنامه‌نویسان و کاربران گمان می‌کنند که کیفیت نرم‌افزارها در سال‌های اخیر رو به افول بوده است. اگرچه افزایش سرعت تولید کد بدون کاهش همزمان نرخ خطاها می‌تواند برنامه‌ها را باگ‌دارتر کند، اما کسانی که کار با کامپیوتر را از دهه‌های گذشته (مانند سال ۱۹۹۰) تجربه کرده‌اند، گواهی می‌دهند که وضعیت نرم‌افزار در آن زمان به مراتب وحشتناک‌تر بود.
زمینه تاریخی و انحصار Wintel
در آن دوران، بازار کامپیوترهای شخصی به‌طور کامل در انحصار سیستم‌عامل Windows و سخت‌افزارهای مبتنی بر پردازنده‌های Intel و AMD (معروف به Wintel) قرار داشت. اگرچه سیستم‌عامل‌های دیگری مانند توزیع‌های مختلف Linux یا macOS وجود داشتند، اما سهم عمده کاربران از آن ویندوز بود.
یکی از ویژگی‌های ساختاری آن دوران این بود که شرکت‌ها معمولاً تنها یک فرصت برای انتشار نرم‌افزار خود داشتند. نرم‌افزارها روی دیسکت‌های فلاپی، سی‌دی یا حافظه‌های ROM رایت می‌شدند و برای مشتریان پست می‌شدند. از آنجا که امکان به‌روزرسانی آنلاین وجود نداشت، محصولات باید حداقل استانداردهای کارکرد را داشتند، اما با این حال مشکلات زیرساختی بیداد می‌کرد.
چالش‌های فنی و خاطرات تلخ مهندسی قدیمی
- صفحه آبی مرگ (BSOD): کرش‌های مداوم سیستم‌عامل به دلیل درایورهای ناپایدار سخت‌افزاری و نشتی حافظه (Memory Leak) یک امر عادی بود. نصب یک درایور بد برای یک جوی‌استیک ساده می‌توانست کل سیستم‌عامل را از کار بیندازد.
- نبود قابلیت Autosave و تومار خاطرات از دست رفته: برنامه‌ها فاقد سیستم ذخیره خودکار قابل اعتماد بودند. مهندسان و نویسندگان ساعت‌ها روی یک سند کار می‌کردند و ناگهان با یک کرش تمام داده‌های خود را از دست می‌دادند. پدیده جالب اینجاست که حتی سال‌ها بعد در Google Docs، کلید میانبر
Ctrl+sهمچنان یکی از پرکاربردترین کلیدها توسط کاربران تروماده‌شده از گذشته بود، در حالی که سیستم ابری خودکار تمام تغییرات را ذخیره می‌کرد. - امنیت ضعیف: احراز هویت‌ها و قفل‌های امنیتی به راحتی با ترفندهای ساده‌ای مثل استفاده از
Ctrl+Alt+Delو پایان دادن به تسک محافظ صفحه نمایش دور زده می‌شدند. بدافزارها و ویروس‌ها نیز بدون مانع جدی سیستم‌ها را آلوده می‌کردند. - قطعه‌قطعه شدن دیسک (Disk Fragmentation): هارد درایوهای مکانیکی قدیمی نیازمند اجرای ابزار Disk Defragmenter بودند تا فایل‌های تکه‌تکه شده را مرتب کنند؛ در غیر این صورت پس از مدتی سرعت کامپیوتر به شدت افت می‌کرد و بوت شدن سیستم‌عامل ممکن بود دقایق طولانی طول بکشد.
- محدودیت‌های شدید حافظه: توسعه‌دهندگان ناچار بودند برای ذخیره بایت‌ها بجنگند. خطاهای سرریز عدد (Overflow) مانند محدودیت مقدار متغیرها که به عدد ۲۵۵ ختم می‌شد، باعث کرش کردن بازی‌ها و نرم‌افزارها در شرایط خاص می‌شد.
- رسانه‌های فیزیکی آسیب‌پذیر: خش افتادن روی سی‌دی بازی‌ها یا زنگ زدن پایه‌های کارتریج‌های کنسول‌های قدیمی به معنا از دست رفتن دائمی داده‌ها بود.
دیدگاه کاربران در هکرنیوز
در بحث‌های پیرامون این موضوع در هکرنیوز، کاربران به نکات جالبی اشاره کرده‌اند:
- برخی اشاره می‌کنند که پایداری و قابلیت اطمینان نرم‌افزارها در مقایسه با گذشته هزاران برابر بهتر شده است، اما تجربه کاربری (UX) و حس کنترل روی سیستم‌ها طی دهه گذشته رو به افول بوده است.
- نمونه‌هایی از باگ‌های عجیب نرم‌افزارهای حرفه‌ای قدیمی مانند نرم‌افزار صفحه‌بندی Quark Xpress ذکر شده که باعث مهاجرت مهندسان به ابزارهای جایگزین مانند InDesign می‌شد.
- با اینکه ابزارهای مدرن بسیار پایدارترند، اما مشکلاتی مانند صفحه آبی مرگ هنوز به طور کامل ریشه‌کن نشده‌اند و کاربران ویندوز ۱۱ همچنان گاهی با آن مواجه می‌شوند.
چرا این موضوع برای مهندسان نرم‌افزار اهمیت دارد؟
بررسی تاریخچه توسعه نرم‌افزار به ما یادآوری می‌کند که مشکلات امروز صنعت ما (مانند کاهش کیفیت یا افزایش پیچیدگی کدهای تولید شده با هوش مصنوعی) جدید نیستند. درک این که زیرساخت‌های محاسباتی و فرآیندهای استقرار نرم‌افزار چه مسری طولانی و پرخطایی را طی کرده‌اند، به ما کمک می‌کند تا قدر ابزارهای مدرن امروزی نظیر سیستم‌های کنترل نسخه، تست خودکار، مدیریت پکیج‌ها و زیرساخت‌های ابری را بهتر بدانیم.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل