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

دیتابیس های بازی با این هدف ایجاد شدن که برای جاهایی که دیتابیس های اسیدی ناکار هستن، با تغییر نیازها و کارکردها بتونیم یه ساختار ذخیره سازی کارا داشته باشیم.

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

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

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

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

و اینکه نمیدونم چرا به جای اکسپتنس تست میگم اکسپتنت تست. انگار مغزم زمان ضبط گیر کرده. درستش اکسپتنس تسته. 

ما در طراحی شی گرا، با دو مفهوم کلی سر و کار داریم. خود اشیاء، و ارتباط اشیاء.

ارتباط اشیاء انواعی دارن که شناخت درست اونا میتونه به تحلیل و طراحی ما کمک کنه.

آیا شیء اول نوعی از شیء دومه؟

آیا شیء اول از شیء دوم تشکیل شده؟

آیا شیء اول از شیء دوم استفاده میکنه؟

آیا شیء اول در واقع یه تجسم از شیء دومه؟

اینا مدل های مختلف ارتباط هستن که در این اپیزود بررسی میکنیم.

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

اینجا به مساله Continuous integration میرسیم و این مفهوم رو بعد از تعریف مورد بررسی قرار میدیم.

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

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

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

اپیزود امروز در مورد معنی Consistency، مزایای اون و راه های رسیدن به اونه.

ما به عنوان مهندس نرم افزار، لازمه که گاهی از رشته های دیگه درس بگیریم. 

دنیای پزشکی قدمت بالایی داره، و یکی از شاخه هاش که آناتومی موجودات زنده است، به دنبال اشتراکات موجودات گونه های جانوری میگرده.

ما هم توی دنیای نرم افزار گونه های مختلفی از کامپوننت ها و نیازها داریم. مثلا ما مفهومی داریم به اسم "فرم" که کاربر پر میکنه. یا مفهومی داریم به اسم "لیست" که توش یه سری آیتم رو به کاربر نشون میدیم.

برای اینکه بتونیم لیست ها رو به خوبی تحلیل و طراحی کنیم، لازمه که بتونیم مفهوم لیست رو به صورت انتزاعی درک کنیم.

آناتومی لیست، تحلیل ماست از مفهوم لیست در لایه API و UI.

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

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

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

توی اکثر نرم افزارها ما باید قسمت هایی از نرم افزار رو فقط برای کاربرانی فراهم کنیم که بتونیم بشناسیمشون. و بعد از شناخت بتونیم میزان دسترسی اونها رو مدیریت کنیم. و ازشون اطلاعات کاربریشون رو ذخیره داشته باشیم.

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

یه ماژول معمولی AAA از سه قسمت تشکیل میشه. یه قسمت برای کاربری که هنوز لاگین نکرده، یه قسمت برای کاربری که لاگین کرده، و یه قسمت هم برای ادمین که بتونه کاربرا رو مدیریت کنه.

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

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

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

پشته فناوری یکی از آیتم های مهم هر شخص برنامه نویس، هر شرکت نرم افزاری، و هر دست اندکار این حوزه اس.

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

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

به این زیرساخت میگیم VCS که مخفف Version Control System هستش.

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

بعد از حفظ کردن حتما باید مرورشون کنیم تا یادمون نره. به همین دلیل باید از یه اپلیکیشن استفاده میکنیم به اسم Anki.

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