برنامه‌ نویسان NASA چگونه کدنویسی میکنند؟!

برنامه‌ نویسی به روش برنامه نویسان NASA 

begin

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

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

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

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

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

۳- از تخصیص حافظه‌ی پویا بعد از مقداردهی یا Initialization، خودداری کنید.

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

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

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

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

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

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

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

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

 یک نکته جالب فقط جهت اطلاع اینست که در سال 2004 که سفینه ی مریخ پیما با مدیریت هموطن عزیزمان دکتر فیروز نادری با موفقیت بر روی خاک مریخ فرود آمد در حدود 500 هزار خط کد جاوای مربوط به پروژه ، توسط شرکت توسعه دهنده گارانتی شده بود! بدیهی ست در صورت وجود باگی که منجر به شکست پروژه میشد شرکت فوق مبلغی در حدود 2 میلیارد دلار جریمه میشد!

end.