فرید بکران فرید بکران
مطالب
مقدمه‌ای بر بازسازی کد (Refactoring)
بازسازی کد یا  Refactoring، یکی از روال‌های بسیار مهم در حفظ کیفیت نرم افزار است. انجام به موقع و مداوم این روال در یک پروژه نرم افزاری، اثرات بلند مدت بسیار مثبتی را برای آن خواهد داشت. این نوشتار مقدمه کوتاهی بر مفاهیم ابتدایی و سوالاتی مهم در این زمینه است. 

تعریف بازسازی کد

از نظر لغوی Refactoring به معنی «بازسازی» است و در منابع مهندسی نرم افزار، بازسازی کد به صورت زیر تعریف شده است: 
بازسازی ساختار درونی یک نرم افزار که باعث سهولت در درک آن و سادگی نگهداری آن می‌شود، بدون تغییر رفتار بیرونی آن  
چند نکته در تعریف بالا قابل توجه است: 
  • Refactoring بازسازی است، نه بازنویسی
  • بازسازی مربوط به ساختار درونی یک نرم افزار است؛ نه رفتاری که مشتریان از یک نرم افزار یا کامپوننت انتظار دارند
  • حاصل بازسازی باید سهولت درک کد و سادگی نگهداری آن باشد 


چرا کد را بازسازی کنیم؟ 

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

1-  طراحی نرم افزار را بهبود می‌بخشد 

زمانیکه کد به طور منظم بازسازی نشود، طراحی کلی آن رو به زوال خواهد رفت. هنگام ایجاد تغییر در بخشی از کد، ممکن است تنها هدف کوتاه مدت درست کار کردن آن بخش، مد نظر برنامه نویس باشد و به دلایل مختلفی مانند کمبود زمان، به نتایج بلند مدت آن تغییر توجه نشود. یکی از مزایای بازسازی کد، ایجاد تعادل بین تاثیرات کوتاه مدت و تاثیرات بلند مدت اعمال تغییرات بر روی کد است؛ به طوری که طراحی و تفکر کلی کد نویسی یک سیستم نرم افزاری، رو به بهبود برود. بهبود طراحی نرم افزار به درک کدهای آن، ایجاد آسان‌تر تغییرات و افزودن امکانات جدید، کمک بسیاری خواهد کرد. 

2-  درک کد را آسان‌تر می‌کند 

یکی از مزیت‌های کد خوب، درک آسان آن توسط سایر افراد است. هنگام بازسازی کد، با کدی مواجه هستیم که کار می‌کند، ولی نظم و طراحی درستی ندارد. درک آسان کد، یکی از کلیدی‌ترین نکات جهت سهولت نگهداری یک نرم افزار است.

 3- به یافتن خطاها کمک می‌کند 

یافتن تمامی باگ‌ها در زمان نوشتن یک کد، به نظر می‌رسد غیر ممکن باشد. اما اقدام به بازسازی کد می‌تواند قدمی باشد برای بازنگری و بهبود ساختار آن. زمانیکه ساختار کد خواناتر و منظم‌تر شد، یافتن برخی باگ‌ها نیز آسان‌تر خواهند شد. 

4-  سرعت توسعه را بالا می‌برد 

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

چه زمانی کد را بازسازی کنیم؟ 

روش‌های مختلفی برای زمان بندی انجام بازسازی کد مطرح است. یکی از پرکاربردترین زمان بندی‌ها برای انجام بازسازی کد به صورت زیر می‌باشد: 
  • زمانیکه امکان جدیدی اضافه می شود 
  • زمانیکه باگ یا اشکالی، رفع می شود 
  • زمان بازبینی کد یا Code review 
‫۷ سال و ۱ ماه قبل، شنبه ۱ مهر ۱۳۹۶، ساعت ۱۲:۵۰
وحید نصیری وحید نصیری
مطالب
لینک‌های هفته اول دی

وبلاگ‌ها و سایت‌های ایرانی

امنیت



ASP. Net


طراحی وب

PHP


اس‌کیوال سرور


سی شارپ


عمومی دات نت


مسایل اجتماعی و انسانی برنامه نویسی


کتاب‌های رایگان جدید


متفرقه
  • آهن بجای کروم! (یک برنامه نویس آلمانی قسمت‌هایی از مرورگر کروم را که در جهت جمع آوری اطلاعات برای گوگل بکار می‌رفته، حذف کرده و مرورگر دیگری به نام آهن را ارائه داده است!)

‫۱۵ سال و ۱۱ ماه قبل، پنجشنبه ۵ دی ۱۳۸۷، ساعت ۰۵:۰۶
ژوپیتر ژوپیتر
نظرات اشتراک‌ها
درس خوندن، ارزشش رو داره؟
گذشته از بحث مدرک محوری که متاسفانه کشور رو به جهت نامناسبی کشونده و باعث خیلی بی عدالتی‌ها و عقب ماندگی‌ها و ... در کشور شده (به خصوص در سیستم هایی که مستقیم یا غیر مستقیم دولتی هستند!)، ماهیت دانشگاه بسیار مهم است.
در دانشگاه چیزهایی مثل نحوه یادگیری، کارگروهی، بالا بردن انگیزه، حس رقابت، حس پیشرفت، اعتماد به نفس و خیلی چیزهای دیگه به طور عادی یا اجباری یاد داده می‌شود که کسی که دانشگاه نرفته قطعا این موارد رو هم تجربه نخواهد کرد بنابراین دیدگاه یک شخص تحصیل کرده از زمین تا آسمان با نمونه دانشگاه نرفته آن تفاوت دارد. (صد البته رتبه دانشگاه نیز در یادگیری و میزان این تجربیات تاثیر فراوان دارد یعنی نمیشه دو تا فارغ التحصیل دانشگاه رو که مثلا یکی در صنعتی اصفهان درس خونده رو با دانشگاه غیر انتفاعی فلان شهرستان(!) مقایسه کرد که از لحاظ وسعت اندازه یک مدرسه هم نیست و هر دو هم کارشناس تربیت می‌کنند.)
اما برای بچه‌های نرم‌افزار به نظرم قضیه حتی مهم‌تر از مابقی رشته‌ها هم هست. یعنی عقیده دارم دانشگاه رفتن برای کسایی که دوست دارند تو حوزه نرم‌افزار کارآفرین، کارشناس، یا هرچیزه دیگه ای بشن خیلی مهمه. چرا؟
(برای مثال) تو دانشگاه اسمبلی به شما یاد می‌دهند به همراه ریزپردازنده و معماری کامپیوتر که با ترکیب نظریه زبان‌ها و کامپایلر دانشجو می‌فهمه از زمانی که یک خط در کامپیوتر به عنوان برنامه در هر زبانی نوشته می‌شه این یک خط چطور توسط کامپایلر از لحاظ نحو، دستور بررسی می‌شه و چطور کد معادل سطح پایین ایجاد می‌شه و کد رو پردازنده چطوری با کمک چه ثبات‌هایی و چه دستوراتی در سطح ماشین اجرا می‌کنه.
یا درسی مثل طراحی الگوریتم‌هاست که انواع و اقسام الگوریتم‌های مختلف که تا الان ارائه شدند بررسی می‌کنه و از لحاظ سرعت و زمان (Order) مورد تحلیل قرار می‌ده که مثلا الگوریتم Quick Sort در چه زمانی یک لیست رو مرتب می‌کنه و Bubble Sort در چه زمانی و یا اینکه ضرب یک ماتریس n*n در حالت تک پردازنده و یا بصورت موازی چطور انجام می‌شه و چقدر زمان نیاز داره؟
یا شبیه سازی پنجره ویندوز در مد گرافیک در زبان C چه کتابخانه‌ها و سخت‌افزارهایی رو درگیر می‌کنه و یا منظور از نرمال سازی در سطح 3NF در مفاهیم پایگاه داده رابطه‌ای چی هست و چطور میشه به اون رو در واقعیت رسید. (که خیلی از مدعیان کار با MS SQL SERVER یا ... هستند که حتی اصول و مفاهیم ساده پایگاه داده رو هم نمی‌دونند.)
اینها چیزهایی هستند که کسانی که دانشگاه نرفتن و صرفا با یادگیری یک زبان برنامه نویسی وارد این حوزه شدند و حتی مدعی هم هستند(!)، نمی‌دانند.
ممکنه فکر کنید خوب دونستن اینها چه فایده‌ای داره؟
زمانی که سرباز بودم از مافوقم پرسیدم با وجود این‌همه سلاح اتوماتیک و سبک و کوچک و جدید چرا ما باید از کلاشینکف صد سال پیش روسی استفاده کنیم؟ جواب این بود که با یادگیری کامل این سلاح می‌تونید تقریبا با همه سلاح‌های موجود کار کنید و کلیات ماجرای همه این سلاح‌ها از همین کلاشینکف و ژ-۳ ارث بری‌می‌کند(!) و یادگیری بقیه با دونستن اطلاعات پایه تنها یادگیری بخش جدیدی که به این سلاح‌ها اضافه شده وگرنه پایه همان است.
شبیه همین جواب را زمانی شنیدم که از استادم پرسیدم یادگیری ساختار پردازنده 80X86 زمانی که الان پردازنده با ساختار چند هسته‌ای توسط اینتل تولید می‌شه چه فایده‌ای داره؟
بنابراین کسی که واقعا این مسائل پایه‌ای رو خوب یاد گرفته باشه توانایی فوق‌العاده‌ای در درک مسائل جدید در آینده خواهد داشت و قطعا محصول بسیار باکیفیت‌تر و بهینه‌تری تولید خواهد کرد و ذهن بسیار خلاق‌تری خواهد داشت و اگر شرایط اجتماعی برایش فراهم باشد موجب افتخار یک کشور نیز خواهد شد.
نکته آخر:
اگر فیلم  The Social Network  رو دیده باشید حتما اون بخشی رو که مارک زاکربرگ وارد کلاس دانشگاه هاروارد میشه و با بی‌حوصلگی تمام سرکلاس به مطالب استاد گوش می‌ده و می‌خواد کلاس رو ترک کنه که استاد ازش یک سوال درسی می‌پرسه (برای مسخره کردنش!) و مارک ایستاده و روی پله‌ها جواب استاد رو میده که هیج ، کمی جلوتر از فکر استاد پیش میره و جواب می‌ده که کلاس هنوز به اون بخش نرسیده و همه مات و مبهوت مونده‌اند...
بله، درسته خیلی از بزرگان این رشته دانشگاه نرفته‌اند و یا ترک تحصیل کرده‌اند ولی علت این بوده که درس‌های ارائه شده در دانشگاه اون‌ها رو سیراب نمی‌کرده و اونها نیاز به چیزی فرای درس‌های ساده دانشگاه داشتند که در دانشگاه هیچ وقت به اون نمی‌رسیدند.
این افراد رو نمیشه با کسانی که در دانشگاه برای پاس کردن فلان درس به هر دری می‌زنند تا به مدرک برسن یا ذهنشون توانایی حل یک معادله ساده درجه ۲ رو نداره که بخوان براش برنامه بنویسن، یکی کرد.
بنابراین امثال جابز و گیتس نوابغ بشری بودند و هستند که تونستند در جامعه‌ای که زمینه براشون مهیا بوده بدون نیاز به دانشگاه موفق بشن و شهرت جهانی پیدا کنند.
موفق باشید.
‫۱۰ سال و ۸ ماه قبل، پنجشنبه ۱۵ اسفند ۱۳۹۲، ساعت ۱۳:۵۱
وحید نصیری وحید نصیری
مطالب
خلاصه اشتراک‌های روز یک شنبه 1 آبان 1390

‫۱۲ سال و ۱۳ ماه قبل، دوشنبه ۲ آبان ۱۳۹۰، ساعت ۰۳:۳۵
وحید نصیری وحید نصیری
مطالب
خواندنی‌های 12 تیر

اس کیوال سرور

امنیت

توسعه وب

دات نت فریم ورک

دبلیو سی اف

دبلیو پی اف و سیلور لایت

سایت‌های ایرانی

شیرپوینت

لینوکس

متفرقه

محیط‌های مجتمع توسعه

مرورگرها

مسایل انسانی، اجتماعی و مدیریتی برنامه نویسی

پی اچ پی

‫۱۵ سال و ۵ ماه قبل، جمعه ۱۲ تیر ۱۳۸۸، ساعت ۲۱:۳۴
بابک داوودی بابک داوودی
اشتراک‌ها
معرفی بزرگان حوزه کامپیوتر و نرم افزار، مخترعین زبان ها و ...

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

معرفی بزرگان حوزه کامپیوتر و نرم افزار، مخترعین زبان ها و ...
‫۶ سال و ۱ ماه قبل، دوشنبه ۵ شهریور ۱۳۹۷، ساعت ۰۴:۱۹
وحید نصیری وحید نصیری
مطالب
آشنایی با آزمایش واحد (unit testing) در دات نت، قسمت 2

دلایل شانه خالی کردن از آزمایش واحد!

1- نوشتن آزمایشات زمان زیادی را به خود اختصاص خواهند داد.

مهمترین دلیلی که برنامه‌نویس‌ها به سبب آن از نوشتن آزمایشات واحد امتناع می‌کنند، همین موضوع است. اکثر افراد به آزمایش به‌عنوان مرحله آخر توسعه فکر می‌کنند. اگر این چنین است، بله! نوشتن آزمایش‌های واحد واقعا سخت و زمانگیر خواهند بود. به همین جهت برای جلوگیری از این مساله روش pay-as-you-go مطرح شده است (ماخذ: کتاب Pragmatic Unit Testing در سی شارپ). یعنی با اضافه شدن هر واحد کوچکی به سیستم، آزمایش واحد آن‌را نیز تهیه کنید. به این صورت در طول توسعه سیستم با باگ‌های کمتری نیز برخورد خواهید داشت چون اجزای آن‌را در این حین به تفصیل مورد بررسی قرار داده‌اید. اثر این روش را در شکل زیر می‌توانید ملاحظه نمائید (تصویری از همان کتاب ذکر شده)




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

بنابراین اگر عنوان می‌کنید که وقت ندارید آزمایش واحد بنویسید، به چند سؤال زیر پاسخ دهید:
الف) چه مقدار زمان را صرف دیباگ کردن کدهای خود یا دیگران می‌کنید؟
ب) چه میزان زمان را صرف بازنویسی کدی کرده‌اید که تصور می‌رفت درست کار می‌کند اما اکنون بسیار مشکل زا ظاهر شده است؟
ج) چه مقدار زمان را صرف این کرده‌اید که منشاء باگ گزارش شده در برنامه را کشف کنید؟

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



تصویری از کتاب xUnit Test Patterns ، که بیانگر کاهش زمان و هزینه کد نویسی در طول زمان با رعایت اصول آزمایشات واحد است

2- اجرای آزمایشات واحد زمان زیادی را تلف می‌کند.

نباید اینطور باشد. عموما اجرای هزاران آزمایش واحد، باید در کسری از ثانیه صورت گیرد. (برای اطلاعات بیشتر به قسمت حد و مرز یک آزمایش واحد در قسمت قبل مراجعه نمائید)

3- امکان تهیه آزمایشات واحد برای کدهای قدیمی ( legacy code ) من وجود ندارد

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

4- کار من نیست که کدهای نوشته شده را آزمایش کنم!

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

5- تنها قسمتی از سیستم به من واگذار شده است و من دقیقا نمی‌دانم که رفتار کلی آن چیست. بنابراین آن را نمی‌توانم آزمایش کنم!

اگر واقعا نمی‌دانید که این کد قرار است چه کاری را انجام دهید به طور قطع الان زمان مناسبی برای کد نویسی آن نیست!

6- کد من کامپایل می‌شود!

باید دقت داشت که کامپایلر فقط syntax کدهای شما را بررسی کرده و خطاهای آن‌را گوشزد می‌کند و نه نحوه‌ی عملکرد آن‌را.

7- من برای نوشتن آزمایشات حقوق نمی‌گیرم!

باید اذعان داشت که به شما جهت صرف تمام وقت یک روز خود برای دیباگ کردن یک خطا هم حقوق نمی‌دهند! شما برای تهیه یک کد قابل قبول و قابل اجرا حقوق می‌گیرید و آزمایش واحد نیز ابزاری است جهت نیل به این مقصود (همانند یک IDE و یا یک کامپایلر).

8- احساس گناه خواهم کرد اگر تیم فنی کنترل کیفیت و آزمایشات را از کار بی کار کنم!!

نگران نباشید، این اتفاق نخواهد افتاد! بحث ما در اینجا آزمایش کوچکترین اجزا و واحدهای یک سیستم است. موارد دیگری مانند functional testing, acceptance testing, performance & environmental testing, validation & verification, formal analysis توسط تیم‌های کنترل کیفیت و آزمایشات هنوز باید بررسی شوند.

9- شرکت من اجازه اجرای آزمایشات واحد را بر روی سیستم‌های در حال اجرا نمی‌دهد.

قرار هم نیست بدهد! چون دیگر نام آن آزمایش واحد نخواهد بود. این آزمایشات باید بر روی سیستم شما و توسط ابزار و امکانات شما صورت گیرد.


پ.ن.
در هشتمین دلیل ذکر شده، از acceptance testing نامبرده شده. تفاوت آن با unit testing به صورت زیر است:

آزمایش واحد:
توسط برنامه نویس‌ها تعریف می‌شود
سبب اطمینان خاطر برنامه نویس‌ها خواهد شد
واحدهای کوچک سیستم را مورد بررسی قرار می‌دهد
یک آزمایش سطح پائین ( low level ) به شمار می‌رود
بسیار سریع اجرا می‌شود
به صورت خودکار (100 درصد خودکار است) و با برنامه نویسی قابل کنترل است

اما در مقابل آزمایش پذیرش به صورت زیر است:
توسط مصرف کنندگان تعریف می‌شود
سبب اطمینان خاطر مصرف کنندگان می‌شود.
کل برنامه مورد آزمایش قرار می‌گیرد
یک آزمایش سطح بالا ( high level ) به شمار می‌رود
ممکن است طولانی باشد
عموما به صورت دستی یا توسط یک سری اسکریپت اجرا می‌شود
مثال : گزارش ماهیانه باید جمع صحیحی از تمام صفحات را در آخرین برگه گزارش به همراه داشته باشد


ادامه دارد...

‫۱۵ سال و ۱۱ ماه قبل، یکشنبه ۸ دی ۱۳۸۷، ساعت ۱۷:۱۶
مسعود پاکدل مسعود پاکدل
نظرات مطالب
Senior Developer به چه کسی گفته می شود؟
زمانی که شخص رزومه خود را برای استخدام در یک شرکت ارسال می‌کند اگر هم صادقانه نباشد به طور قطع در مراحل بعدی استخدام نظیر مصاحبه حضوری مشخص خواهد شد که فرد دارای چه رتبه ای است
البته این مطلب را عنوان کنم که فقط حدود 20 تا 30 درصد مصاحبه‌های حضوری برای استخدام در شرکت‌ها دارای استاندارد لازم هستند و در خیلی مواقع فرد مصاحبه کننده  صلاحیت لازم برای این امر را ندارد. خود من حدود یک سال پیش برای استخدام به عنوان برنامه نویس ارشد در یک شرکت حضور پیدا کردم که در نهایت با 60 سوال کتبی (معادل 6 صفحه پشت و رو) مواجه شدم. فقط سه سوال اول رو مطالعه کردم که مربوط به تعاریف Interface و Property و Method بود که به نوعی تداعی خاطره آزمون دروس برنامه نویسی در دانشگاه بوده است. در ضمن هنگام تهیه و مطالعه رزومه باید به عناوین تسلط و آشنایی و آگاهی دقت لازم را داشته باشیم. چون معنی و مفهوم هر سه کلمه کاملا با هم متفاوت است.
‫۱۱ سال و ۳ ماه قبل، شنبه ۵ مرداد ۱۳۹۲، ساعت ۰۳:۲۲
وحید نصیری وحید نصیری
اشتراک‌ها
پایتون و VSCode

«...اگر برنامه نویس پایتون باشید حتما محیط Pycharm را بهترین و راحت‌ترین گزینه برنامه نویسی با این زبان می‌دانید. اما در چند سال اخیر حضور قدرتمند Visual Code را نمی‌توانید نادیده بگیرید...» 

پایتون و VSCode
‫۵ سال و ۵ ماه قبل، چهارشنبه ۱۱ اردیبهشت ۱۳۹۸، ساعت ۱۶:۳۲
وحید نصیری وحید نصیری
مطالب
Roslyn #1
معرفی Roslyn

سکوی کامپایلر دات نت یا Roslyn (با تلفظ «رازلین») بازنویسی مجدد کامپایلرهای VB.NET و #C توسط همین زبان‌ها است. این سکوی کامپایلر به همراه یک سری کتابخانه و اسمبلی ارائه می‌شود که امکان آنالیز زبان‌های مدیریت شده را به صورت مستقل و یا یکپارچه‌ی با ویژوال استودیو، فراهم می‌کنند. برای نمونه در VS.NET 2015 تمام سرویس‌های زبان‌های موجود، با Roslyn API جایگزین و بازنویسی شده‌اند. نمونه‌هایی از این سرویس‌های زبان‌ها، شامل  Intellisense و مرور کدها مانند go to references and definitions، به همراه امکانات Refactoring می‌شوند. به علاوه به کمک Roslyn می‌توان یک کامپایلر و ابزارهای مرتبط با آن، مانند FxCop را تولید کرد و یا در نهایت یک فایل اسمبلی نهایی را از آن تحویل گرفت.


چرا مایکروسافت Roslyn را تولید کرد؟

پیش از پروژه‌ی Roslyn، کامپایلرهای VB.NET و #C با زبان ++C نوشته شده بودند؛ از این جهت که در اواخر دهه‌ی 90 که کار تولید سکوی دات نت در حال انجام بود، هنوز امکانات کافی برای نوشتن این کامپایلرها با زبان‌های مدیریت شده وجود نداشت و همچنین زبان محبوب کامپایلر نویسی در آن دوران نیز ++C بود. این انتخاب در دراز مدت مشکلاتی مانند کاهش انعطاف پذیری و productivity تیم کامپایلر نویس را با افزایش تعداد سطرهای کامپایلر نوشته شده به همراه داشت و افزودن ویژگی‌های جدید را به زبان‌های VB.NET و #C سخت‌تر و سخت‌تر کرده بود. همچنین در اینجا برنامه نویس‌های تیم کامپایلر مدام مجبور بودند که بین زبان‌های مدیریت شده و مدیریت نشده سوئیچ کنند و امکان استفاده‌ی همزمان از زبان‌هایی را که در حال توسعه‌ی آن هستند، نداشتند.
این مسایل سبب شدند تا در طی بیش از یک دهه، چندین نوع کامپایلر از صفر نوشته شوند:
- کامپایلرهای خط فرمانی مانند csc.exe و vbc.exe
- کامپایلر پشت صحنه‌ی ویژوال استودیو (برای مثال کشیدن یک خط قرمز زیر مشکلات دستوری موجود)
- کامپایلر snippet‌ها در immediate window ویژوال استودیو

هر کدام از این کامپایلرها هم برای حل مسایلی خاص طراحی شده‌اند. کامپایلرهای خط فرمانی، با چندین فایل ورودی، به همراه ارائه‌ی تعدادی زیادی خطا و اخطار کار می‌کنند. کامپایلر پشت صحنه‌ی ویژوال استودیوهای تا پیش از نسخه‌ی 2015، تنها با یک تک فایل در حال استفاده، کار می‌کند و همچنین باید به خطاهای رخ داده نیز مقاوم باشد و بیش از اندازه گزارش خطا ندهد. برای مثال زمانیکه کاربر در حالت تایپ یک سطر است، بدیهی است تا اتمام کار، این سطر فاقد ارزش دستوری صحیحی است و کامپایلر باید به این مساله دقت داشته باشد و یا کامپایلر snippet‌ها تنها جهت ارزیابی یک تک سطر از دستورات وارد شده، طراحی شده‌است.

با توجه به این مسایل، مایکروسافت از بازنویسی سکوی کامپایلر دات نت این اهداف را دنبال می‌کند:
- بالا بردن سرعت افزودن قابلیت‌های جدید به زبان‌های موجود
- سبک کردن حجم کاری کامپایلر نویسی و کاهش تعداد آن‌ها به یک مورد
- بالا بردن دسترسی پذیری به API کامپایلرها
برای مثال اکنون برنامه نویس‌ها بجای اینکه یک فایل cs را به کامپایلر csc.exe ارائه کنند و یک خروجی باینری دریافت کنند، امکان دسترسی به syntax trees، semantic analysis و تمام مسایل پشت صحنه‌ی یک کامپایلر را دارند.
- ساده سازی تولید افزونه‌های مرتبط با زبان‌های مدیریت شده.
اکنون برای تولید یک آنالیز کننده‌ی سفارشی، نیازی نیست هر توسعه دهنده‌ای شروع به نوشتن امکانات پایه‌ای یک کامپایلر کند. این امکانات به صورت یک API عمومی در دسترس برنامه نویس‌ها قرار گرفته‌اند.
- آموزش مسایل درونی یک کامپایلر و همچنین ایجاد اکوسیستمی از برنامه نویس‌های علاقمند در اطراف آن.
همانطور که اطلاع دارید، Roslyn به صورت سورس باز در GitHub در دسترس عموم است.


تفاوت Roslyn با کامپایلرهای سنتی

اکثر کامپایلرهای موجود به صورت یک جعبه‌ی سیاه عمل می‌کنند. به این معنا که تعدادی فایل ورودی را دریافت کرده و در نهایت یک خروجی باینری را تولید می‌کنند. اینکه در این میان چه اتفاقاتی رخ می‌دهد، از دید استفاده کننده مخفی است.


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


خلاصه‌ی مراحل رخ داده در کامپایلر سی‌شارپ را در تصویر فوق ملاحظه می‌کنید. در اینجا ابتدا کار parse اطلاعات متنی دریافتی شروع می‌شود و از روی آن syntax tree تولید می‌شود. در مرحله‌ی بعد مواردی مانند ارجاعاتی به mscorlib و امثال آن پردازش می‌شوند. در مرحله‌ی binder کار پردازش حوزه‌ی دید متغیرها، اشیاء و اتصال آن‌ها به هم انجام می‌شود. در مرحله‌ی آخر، کار تولید کدهای IL و اسمبلی باینری نهایی صورت می‌گیرد.
با معرفی Roslyn، این جعبه‌ی سیاه، به صورت یک API عمومی در دسترس برنامه نویس‌ها قرار گرفته‌است:


همانطور که مشاهده می‌کنید، هر مرحله‌ی کامپایل جعبه‌ی سیاه، به یک API عمومی Roslyn نگاشت شده‌است. برای مثال Parser به Syntax tree API نگاشت شده‌است. به علاوه این API صرفا به موارد فوق خلاصه نمی‌شود و همانطور که پیشتر نیز ذکر شد، برای اینکه بتواند جایگزین سه نوع کامپایلر موجود شود، به همراه Workspace API نیز می‌باشد:


Roslyn امکان کار با یک Solution و فایل‌های آن را دارد و شامل سرویس‌های زبان‌های مورد نیاز در ویژوال استودیو نیز می‌شود. برفراز Workspace API، یک مجموعه API دیگر به نام Diagnostics API تدارک دیده شده‌است تا برنامه نویس‌ها بتوانند امکانات Refactoring جانبی را توسعه داده و یا در جهت بهبود کیفیت کدهای نوشته شده، اخطارهایی را به برنامه نویس‌ها تحت عنوان Code fixes و آنالیز کننده‌ها، ارائه دهند.

‫۹ سال و ۱ ماه قبل، پنجشنبه ۲۶ شهریور ۱۳۹۴، ساعت ۱۹:۰۵