لینک کوتاه مطلب : https://hsgar.com/?p=4688

عمو باب و گلوله های نقره ای • هیلل وین

چند وقت پیش نوشتم که رابرت مارتین با مهارت بیش از حد در برنامه نویسی نرم افزار را خراب می کند. قرار بود شوخی باشه از آن زمان، او تمام تلاش خود را کرده است که با گفتن اینکه به مردم این کار را اشتباه انجام می دهند، نرم افزار را از بین می برد. آخرین پاسخ او جایی که او فریاد می زند صحت نرم افزار نقطه شکست برای من بود، بنابراین من می خواهم ادامه دهم و آنچه را که بسیاری از ما فکر می کردیم بگویم:

عمو باب می دهد وحشتناک مشاوره دنبال کردن آن کد شما را بدتر می کند.

او شروع کرد ابزارها جوابگو نیستند با فهرست کردن برخی از ابزارهای “جدید” که “پاسخ” نیستند: Light Table، Model Driven Engineering و TLA+. در حال حاضر، من در اینجا بسیار مغرضانه، چه با نوشتن a راهنمای TLA+ و همه. اما من با آنچه (من فکر می کردم) انتقاد اصلی بود موافقم: هیچ گلوله نقره ای وجود ندارد. TLA+ موفقیت های حیرت انگیزی را در این زمینه نشان داده است آمازون و مایکروسافت، اما فقط مشخصات را تأیید می کند، نه کد. در حالی که برای طراحی سیستم ها باورنکردنی است، باید آن را با سایر تکنیک های صحت، مانند سیستم های نوع و تست ها ترکیب کنید. یک استدلال نسبتا خوب

اما معلوم شد که این بحث فقط در ذهن من بوده است، زیرا او آن را اینگونه دنبال می کند:

راه حل آخرالزمان نرم افزاری ابزار بیشتر نیست. راه حل، رشته برنامه نویسی بهتر است.

به هر حال «انضباط» چیست؟ عمو باب می‌گوید این به معنای انجام ندادن یک کار نیمه کاره است. عمو باب می گوید راه حل برای افرادی که کد بد می نویسند… این است که کد بد ننویسند. اگر برنامه نویسان نبودند برنامه های ما عالی بود!

یکی از مفروضات اصلی مهندسی سیستم های مدرن این است که یک جریان ثابت از نقص وجود دارد: که مردم اشتباه می کنند. شما نمی توانید به مردم تکیه کنید که خود به خود سر از پا در نیایند: به هر حال، ایالات متحده هنوز 30000 مرگ و میر خودرو در سال دارد. بلکه بهترین راه برای کاهش حجم و شدت اشتباهات تنظیم خود سیستم است. یا انجام آنها را سخت تر کنید، گرفتن آنها را آسان تر کنید، یا در صورت وقوع آسیب کمتری به آنها وارد کنید. فقط رانندگان را مقصر ندانید، به آنها جاده های امن بدهید! به آنها کمربند ایمنی بدهید!

یکی از راه های انجام این کار اضافه کردن یک بوروکراسی است روند، مانند بررسی کد. اگر کد شما با الزامات مطابقت ندارد (بدون تست، شما متغیرهای خود را نامگذاری کرده اید x و x2و غیره)، کد رد خواهد شد. که در سطح سیستمی، باگ ها را کاهش می دهد. وقتی ابزارهای مکانیکی مانند تست ها و IDE ها را به کار می گیریم، تمام کاری که انجام می دهیم خودکارسازی آن فرآیندها است. ما از روش ایجاد کد و نوع کدی که ایجاد می کنیم برای بررسی کار خود استفاده می کنیم. این حوزه گسترده ای از صحت نرم افزار است و همه چیز را از سیستم های تایپ گرفته تا طراحی زبان را در بر می گیرد.

عمو باب با درستی نرم افزار مشکلی ندارد: از این گذشته، او از عبارت “تست واحد” استفاده می کند، همانطور که یک اسمورف از “smurf” استفاده می کند. اما در مورد هر دیگر تکنیک درستی؟

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

function ceiling(num) {
    if (num == (num | 0)) {
        return num;
    }
    return Math.round(num + 0.5);
}

آیا سعی کردی -1e-100? شما آن را می دیدید ceiling(-1e-100) == 1 زمانی که باید باشد 0. این به دلیل نحوه عملکرد ممیز شناور است: 0.5 - 1e-100 == 0.5. اگر بسیاری از مردم به یاد داشته باشند که آن را بررسی کنند، شوکه می شوم، اگر حتی بدانند که ممیز شناور اصلاً عجیب و غریب است. اما یک تست مبتنی بر ویژگی آن را به راحتی می گیرد. بسیار خوب، تابع دو:

function clamp(min, x, max) {
    return Math.max(Math.min(max, x), min);
}

عملکرد کاملاً خوب است. باگ اصلا تو تابع نیست! این است که، در پایگاه کد 50 kLoC ما، یک مسیر واحد وجود دارد که در نهایت با فراخوانی به پایان می رسد. clamp با مقدار صفر آیا قصد دارید هر مسیر ممکن را آزمایش کنید؟ آیا این واقعا برتر از استفاده از یک سیستم نوع است؟ باشه آخری:

function append_to_body(type, text) {
    var d = document.createElement(type);
    d.innerHTML = text;
    document.body.appendChild(d);
}

این تابع به خوبی کار می کند، با این تفاوت که اکنون یک بردار XSS را باز کرده اید. به همین دلیل است که تحلیل استاتیک داریم. اینها فقط نمونه های اسباب بازی نیستند. اینها موضوعاتی با تحقیقات فراوان، توسعه فراوان و تاریخچه فراوان هستند. ما یاد گرفته ایم که آنها برای چه کاری خوب هستند و محدودیت های آنها چیست. ما از این ابزار استفاده می کنیم زیرا آنها کار می کنند. دقیقاً به همین دلیل که ما تست واحد و TDD داریم.

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

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

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

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.