اهمیت Code Review

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

  1. کیفیت کد.
  2. ریسک  جدا شدن اعضای تیم.CodeReview

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

  • یک کد را حداقل دو نفر به خوبی می شناسند.
  • خطاهای هنگام برنامه نویسی به شدت کاهش می یابد.
  • یکی از عوامل تاثیر گذار در مهارت های برنامه نویسی خواندن کد دیگران است و بنابراین مهارت اعضای تیم بالا می رود.
  • نظارت دقیق تری روی کیفیت وجود خواهد داشت.
  • افراد تازه وارد به تیم سریعتر در جریان کارها قرار می گیرند.
  • سطح برنامه نویسان را راحتر می توان مشخص کرد.

همانطور که ملاحظه کردید Code Review واقعا برای یک تیم نرم افزاری حیاتی است ولی بد نیست به مشکلات اجرایی آن نیز نگاهی بیندازیم:

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

بنابراین با توجه به ریسکها وهمچنین مزایا ، Code Review بهتر است که به صورت مدیریت شده وارد تیم شود تا بتوان این مفهوم را درتیم نهادینه کرد و شاهد بهبود روند تولید بود.

AlwaysOn در SQL Server

در Sql server راهکارهای متفاوتی برای دسترس پذیری بالا و همچنین برای مراقبت از داده وجود دارد.راهکار ها برای هر پروژه بسته به نوع و اندازه پروژه متفاوت هستند .به عنوان مثال زمانی که می خواهیم در یک فروشگاه داد هایمان را حفظ و نگهداری کنیم، بسیار متفاوت از زمانی است که در یک بانک باید داده هایمان را مدیریت کنیم.

راه کار های موجود در SQl Server

Log Shipping: این مدل یکی از ساده ترین راهکارهای موجود برای نگهداری داده است.در این مدل کار به صورت backup و restore انجام می شود.یعنی لاگ هر transaction به سرور دوم ارسال می شود و در آن جا restore می شود.در این روش می توانیم از سرور دوم برای کارهایی(مثل گزارش گیری) که روی سرور اصلی ممکن است بار بگذارند استفاده کنیم.اگر مشکلی برای دیتابیس اصلی پیش بیاید وظیفه انتقال از دیتابیس اصلی به دیتابس دوم به صورت دستی باید انجام شود.

SQLServerLogShippingMirroring :یکی دیگر از راه کارهای sql server برای دسترس پذیری و همچنین  مراقبت از داده ها Mirroring است.در این روش ما یک دیتابس اصلی داریم ویک دیتابیس ثانویه.این دو دیتابیس دقیقا مثل هم هستند و تمام transaction های ما در دو دیتابیس اجرا می شوند.هم به صورت sync و هم async می توانند این تراکنش ها اجرا شوند.زمانی که تراکنش ها به صورت سینک اجرا می شوند باید حتما دیتابس اصلی acknowledge انجام تراکنش در دیتابیس ثانویه را دریافت کنند.در این روش اگر دیتابیس اصلی دچار مشکل شود به صورت اتوماتیک کلاینت ما روی سرور دوم سوئیچ می کند و این کار می تواند در connection string پیکربندی شود.

4073.DatabaseMirroring.jpg-650x0

failover cluster:در راهکارهای که در بالا گفته شد یک نیاز اساسی تامین نشده بود و آن هم دسترس پذیری در سطح instance است و نه دیتابیس.شما با failover cluster می توانید تمامی دیتابیس های موجود در یک instance را به صورت یکپارچه مدیریت کنید و دراقع اگر یک سرور دچار مشکل شد به صورت اتوماتیک روی سرور دوم سوئیچ می کند.این راهکار نیاز به سخت افزار های بیشتری نسبت به دو راهکار قبل دارد.دو سرور ، برای هر کدام دو کارت شبکه ، یکی جهت ارسال هارت بیت و دیگر برای Lan ، یک storage از نوع SAN یا NAS بین سرور ها می خواهیم که باید بین دو سرور به اشتراک گذاشته شود(می تواند سخت افزاری یا نرم افزاری باشد).روی دو سرور باید failover cluster ویندوز راه اندازی شود.بعد از آن Sql server را به صورت failover cluster نصب می کنیم.به دو sql می بایست یک آی پی مجازی داد و در واقع کاربران به آن وصل خواهند شد.سپس در سرور دوم هم یک node جدید برای کلاستر در نظر می گیریم.از آن مرحله به بعد هر کاربری که به آی پی مجازی وصل شود به نود فعال هدایت خواهد شد و در صورتی که نود اصلی برایش مشکلی پیش بیاد به نود ثانویه وصل خواهد شد.در این مدل معمولا نود ثانویه بیکار است.

4377.ActivePassiveCluster.jpg-650x0

AlwaysOn IC544366

تا به این جا انواع راهکارهای sql برای دسترس پذیری بالا و همچنین برای مراقبت از داده ها گفته شد.مایکروسافت از sql 2012 قابلیت جدیدی را به نام  AlwaysOn معرفی کرد که دارای قابلیت های  high-availability و disaster-recovery است.این قابلیت می تواند روی گروهی از دیتابیس ها که به آن availability group گفته می شود اعمال شود.به دیتابیسی که در یک availability group وجود دارند availability database گفته می شود.

 

Availability Group به ازای هر دیتابیس، یک دیتابیس اصلی (خواندن و نوشتن) و تا ۸ دیتابیس فرعی (فقط خواندنی)را در خود نگهداری می کند.دیتابیس اصلی قابلیت خواندن و نوشتن  را دارد ولی در دیتابیس های فرعی داده به صورت فقط خواندنی هستند و معمولا برای کارهایی مثل گزارش گیری از آنها استفاده می شود.

در این روش  نیز می توانیم داده ها را به صورت sync وasync ،  از سرور اصلی به سرور ها ی ثانویه منتقل کنیم .علاوه بر آن ما نیاز به storage از نوع SAN یا NAS نداریم.

یکی دیگر از مزیت های این مدل دسترس پذیری بالا به دیتابیس های ثانویه است.یعنی اگر ارتباط بین سرور اصلی به سرور ثانویه قطع شود در صورتی که ما به دیتابیس ثانویه دسترسی مستقیم داشته باشیم می توانیم از آن به صورت مستقیم استفاده کنیم.(این امکان در sql 2014 افزوده شده است.).

برای راه اندازی این قابلیت باید از Windows Server Failover Cluster استفاده شود.

یکی از امکانات جالب این روش Availability Groups است که به ما اجازه مدیریت چند دیتابیس با هم دیگر را می دهد به عبارت دیگر می توان چند دیتابیس را یکجا failover کرد.

در آخر نیاز به یک واسط داریم که کلاینت ها به آن وصل شوند و در صورت down شدن هر کدام از دیتابیس ها ،متوجه این اتفاق نشوند.در AlwaysOn به آن واسط Availability Group Listener گفته می شود که درواقع یک server name مجازی است.


منابع: