آشنایی با قوانین سخت‌گیرانهٔ NASA که دولوپرهای این سازمان مجبور به تبعیت از آن‌ها هستند!

آيا می‌دانید برنامه‌نویسان خبره‌ٔ سازمان ملی هوا و فضای آمریکا (NASA) چگونه پروژه‌های حیاتی و مهم را کدنویسی می‌کنند؟ برای نوشتن کدهایی با خوانایی و امنیت بالا و آسان بودن درک آن‌ها، آزمایشگاه موشک‌های پیشران ناسا قوانین ده‌گانه‌ای را برای توسعه‌ٔ برنامه‌ها و نرم‌افزار‌های کاربردی خود وضع کرده‌ است که تمامی دولوپرهای این سازمان باید از آن‌ها تبعیت کنند. 

به نوعی می‌توان گفت که کار در ناسا به عنوان یک برنامه‌نویس یکی از جذاب‌ترین و در عین حال چالشی‌ترین شغل‌ها در دنیای توسعهٔ نرم‌افزار محسوب می‌شود و نیاز به توضیح نیست که برنامه‌نویسان ناسا نرم‌افزارهایی را توسعه می‌دهند که حتی یک اشتباه کوچک می‌تواند منجر به هدر رفتن میلیون‌ها دلار سرمایه و حتی جان فضانوردان گردد!

برای پی بردن به اهمیت این نوع نرم‌افزارها، کافی است خودتان را به عنوان یک دولوپر ناسا تصور کنید به طوری که در چنین شرایطی مسلماً پیروی از یکسری قوانین و اصول کدنویسی بسیار ضروری ‌است. گرچه رسیدن به توافق کلی در مورد استانداردهای کدنویسی سخت است، اما با وجود این آزمایشگاه تحقیقاتی موشک‌های پیشران ناسا (JPL) قوانینی را تحت عنوان ده قانون کلیدی برای کدنویسی ایمن برای برنامه‌نویسان خود وضع کرده است که این قوانین به صورت کلی بر روی زبان برنامه‌نویسی C متمرکز شده‌اند چرا که JPL سابقه‌ٔ طولانی در به‌کارگیری این زبان دارد اما این در حالی است که به راحتی می‌توان این قوانین را در مورد سایر زبان‌های برنامه‌نویسی نیز به کار برد.

بر اساس گفته‌ٔ Gerard J. Holzmann، رهبر فنی تیم جی.پی.ال، این قوانین برای دستیابی به امنیت بالا نوشته شده و باید توسط دولوپرهای این سازمان رعایت شوند که عبارتند از:

۱. روند اجرای کدها در ساختارهای کنترلی بسیار ساده را محدود کنید و از به‌کارگیری دستور goto، ساختارهای longjmp و setjmp و همچنین دستورات Recursion (بازگشتی) مستقیم و غیرمستقیم بپرهیزید.

۲. تمام حلقه‌ها باید دارای حداکثر تعداد Iteration (تکرار) باشند اما در عین حال این قانون شاید شما را به این فکر وا دارد که ممکن است تعریف حداکثر تعداد تکرار حلقه به صورت استاتیک آن را محدود کرده و اجازه‌ٔ پیشروی را ندهد که کاملاً هم درست است (اگر تعیین محدوده‌ٔ تکرار حلقه به صورت استاتیک امکان‌پذیر نیست، از این قانون چشم‌پوشی کنید.)

۳. از تخصیص حافظه‌ٔ دینامیک پس از Initialization خودداری کنید.

۴. فانکشن‌ها و بدنه‌ٔ آن‌ها باید خط به خط و به گونه‌ای نوشته شوند که هم دارای فرمت مناسب با رعایت اصول برنامه‌نویسی باشند و هم به راحتی بتوان آن‌ها را در یک صفحه‌ٔ کاغذ استاندارد چاپ کرد. حدوداً می‌توان گفت تعداد خطوط نوشته شده برای یک فانکشن نباید از مرز ۶۰ خط تجاوز کند.

۵. تعداد اعللان نوتیفیکیشن‌ها برای هر فانکشن حداقل باید دو مورد باشد. نوتیفیکیشن‌ها که برای بررسی شرایط غیرعادی استفاده‌ می‌شوند باید به گونه‌ای مدیریت شوند که به هیچ وجه در نسخه‌ٔ نهایی نرم‌افزار شاهد هیچ‌گونه نوتیفیکیشنی نباشیم. نوتیفیکیشن‌ها هرگز نباید دارای تأثیرات جانبی بوده و باید به صورت تست‌های اصطلاحاً بولین تعریف شوند؛ به عبارتی، فقط دو حالت عادی و غیرعادی را برای آن‌ها در نظر بگیرید. به محض اینکه یک نوتیفیکیشن در اجرا ناموفق بود، باید دستورات بازیابی آن فراخوانی شود (برای مثال، می‌توان پیغام خطا را به فانکشنی که نوتیفیکیشن را اجرا کرده است اصطلاحاً ریتِرن کرد.) به طور کلی، از نوتیفیکیشن‌ها به خوبی استفاده کنید و به سادگی از کنار آن‌ها نگذرید.

۶. آبجکت‌های مبتنی بر داده که حاوی اطلاعات خاصی هستند باید در کوچک‌ترین اِسکوپ ممکن تعریف شوند و این اِسکوپ برای هر آبجکت مبتنی بر داده باید در راستای محتوای دادهٔ آن باشد و نه بیشتر.

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

۸. به‌کارگیری از Preprocessor (پیش‌پردازنده) باید محدود به فایل‌های هِدِر و تعریف ماکروهای ساده باشد. استفاده از توکن، لیست آرگومان‌های متغیر (Ellipses) و فراخوانی بازگشتی ماکروها (RMC) مجاز نیست.

۹. استفاده از Pointer (اشاره‌گر) را محدود کنید. مهم‌تر آنکه استفاده از Referencing (ارجاع‌های چندسطحی) مجاز نیست و نحوه‌ٔ ارجاع اشاره‌گرها نباید در تعریف ماکروها یا در تعریف typedef پنهان شود و به‌ هیچ وجه از پوینترها برای نوشتن یک فانکشن استفاده نکنید.

‍۱۰. تمام سورس‌کدها باید توسط موشکاف‌ترین کامپایلر و با سخت‌گیرترین تنظیمات کامپایل شوند و تمام خطاهای ممکن در هنگام کامپایل از روز اول باید همراه کدها مستند گردد. در آخر، باید تمام کدها با همین کامپایلر و تنظیمات سخت‌گیرانه کامپایل شده و هیچ‌گونه خطایی نداشته باشند. تمام کد‌های نوشته‌شده حداقل روزی یک بار و حتی بیشتر باید توسط جدیدترین تکنولوژی‌‌های آنالیز سورس‌کد بررسی شوند و نتایج آن باید عاری از هرگونه خطای تحلیلی باشند.

به طور کلی نظر ناسا در مورد این قوانین را می‌توان به این صورت خلاصه کرد که:

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

حال نوبت به نظر شما می‌رسد. از دید شما آیا می‌توان این دست قوانین را در پروژه‌های نوشته شده با دیگر زبان‌های برنامه‌نویسی و برای پروژه‌های به مراتب ساده‌تر نیز مورد استفاده قرار داد؟ نظرات و دیدگاه‌ها خود را با سایر کاربران سکان آکادمی به اشتراک بگذارید.