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

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

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

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

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

این قوانین به صورت کلی بر روی زبان برنامه‌نویسی C متمرکز شده‌اند چرا که JPL سابقه‌ٔ طولانی در به‌کارگیری این زبان دارد اما این در حالی است که به راحتی می‌توان این قوانین را در مورد سایر زبان‌های برنامه‌نویسی نیز به کار برد.

بر اساس گفته‌ٔ آقای جرارد هولزمن، رهبر تیم تحقیقاتی JPL، این قوانین برای دستیابی به امنیت بالا نوشته شده و باید توسط دولوپرهای این سازمان رعایت شوند. این ۱۰ قانون کدنویسی ناسا عبارتند از:

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

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

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

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

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

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

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

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

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

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

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

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

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

منبع