باشگاه برنامه نویسی مهندس نعمتی

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

دیتابیس ها به دو دسته بزرگ اسیدی و بازی تقسیم میشن. دیتابیس های اسیدی یعنی دیتابیس هایی که چهار خصوصیت رو ساپورت میکنن. این خصوصیات رو توی این اپیزود با هم بررسی میکنیم.

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

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

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

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

ثبات و یکنواختی در توسعه، یکی از رازهای موفقیت یه تیم نرم افزاریه. اینکه پروژه هامون هرچقدر بیشتر شبیه به هم نوشته بشه. اینکه ابزارهای یکسانی استفاده کنیم. اینکه قوانین درون تیمی خوبی داشته باشیم و پایبندی به اون قوانین رو به صورت سیستماتیک تضمین کنیم. اپیزود امروز در مورد معنی Consistency، مزایای اون و راه های رسیدن به اونه.

ما به عنوان مهندس نرم افزار، لازمه که گاهی از رشته های دیگه درس بگیریم.  دنیای پزشکی قدمت بالایی داره، و یکی از شاخه هاش که آناتومی موجودات زنده است، به دنبال اشتراکات موجودات گونه های جانوری میگرده. ما هم توی دنیای نرم افزار گونه های مختلفی از کامپوننت ها و نیازها داریم. مثلا ما مفهومی داریم به اسم "فرم" که کاربر پر میکنه. یا مفهومی داریم به اسم "لیست" که توش یه سری آیتم رو به کاربر نشون میدیم. برای اینکه بتونیم لیست ها رو به خوبی تحلیل و طراحی کنیم، لازمه که بتونیم مفهوم لیست رو به صورت انتزاعی درک کنیم. آناتومی لیست، تحلیل ماست از مفهوم لیست در لایه API و UI.

کنترل کیفیت و تضمین کیفیت یه موضوعه که توی همه صنایع معنا داره. اول یه سری مفهوم ساده در این مورد یاد بگیریم، مثل اینکه کنترل کیفی پیش کنشانه است، و تضمین کیفی واکنشانه، یا مثلا کنترل کیفیت در مقیاس کوچیک در واقع تضمین کیفیت در مقیاس بزرگه. بعد راه هایی رو بررسی میکنیم که بتونیم با ابزارها و روال های مختلف کیفیت رو در کد افزایش بدیم. البته این اپیزود ادامه خواهد داشت. به این دلیل که کیفیت یه موضوع cross-cutting محسوب میشه و از دیتابیس تا UI قابل اعماله.

در نقطه ای که یه برنامه نویس که عضوی از یک تیمه، میخواد کدی که نوشته یا تغییر داده رو بفرسته روی مخزن کدها، یا همون VCS، بهتره مکانیسمی داشته باشیم برای بازنگری کد نوشته شده. در این صورت میتونیم خیلی از قوانین درون تیم رو به خوبی توسط ماشین کنترل کنیم. در دنیای TFVC در کنار Visual Studio، مفهومی داریم به اسم check-in policy که دقیقا به ما امکان این کار رو میده. اپیزود امروز در رابطه با همین موضوعه.