تست شماره 1: آیا از source control استفاده می‌کنید؟

ضمن اینکه توصیه می‌کنم توضیح جوئل درباره تست اول را بخوانید، من از شما سوال می‌کنم ;) آیا در شرکت/تیم نرم‌افزاری خودتان یا حتی در کارهای شخصی از source control استفاده می‌کنید؟

هر نرم‌افزاری از تعدادی فایل source‌ به زبان‌های مختلف تشکیل شده است، مثلاً این وب سایت که با ASP.NET MVC ایجاد شده، تعدادی فایل کد سی شارپ،‌ تعدادی فایل view با استفاده از Razor، تعدادی فایل css و javascript و ... دارد. اگر من فردا بخواهم قابلیت جدیدی به سایت اضافه کنم یا قابلیت‌های موجود را ارتقاء بدهم یا باگی را برطرف کنم باید در این فایل‌ها دستکاری کنم، اما صبر کنید، چه بلایی سر نسخه قبلی فایل‌ها می‌آید؟

در این موارد 2 راه حل وجود دارد:

1- کپی کردن source های نسخه قبلی و مثلاً rar کردن و بکاپ گرفتن به همراه درج تاریخ بکاپ در عنوان فایل rar!

2- استفاده از نرم‌افزارهای source control

کار اصلی نرم‌افزارهای source control‌ این است که تغییرات داده شده روی فایل‌های source را نگهداری می‌کنند. البته این نرم‌افزارها قابلیت‌های دیگری هم دارند که به آن‌ها اشاره خواهم کرد. مکانیزم اصلی source control ها این است که در یک تیم، اعضاء‌ می‌توانند یک یا تعدادی فایل را دریافت کنند، موقع دریافت این فایل‌ها به آن‌ها تحویل می‌شود (check out)، برنامه‌نویس، تغییرات لازم را در فایل ایجاد می‌کند و بعد دوباره فایل را تحویل می‌دهد (check in یا commit) موقع تحویل دادن می‌تواند کامنتی هم بنویسد که مثلاً فلان باگ را در تابع xyz برطرف کردم.

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

در کنار این قابلیت اصلی، قابلیت‌های دیگری مثل ایجاد یک branch از source اصلی و کار بر روی آن و اعمال تغییرات (merge) از کارهای تیمی نیز وجود دارد و همچنین قابلیت‌های ریز و درشت دیگر که برای خودش یک داستان دیگر دارد و در نوشته‌ای دیگر به آن اشاره خواهم کرد.

متوجه شدم، source control خوبه، حالا از کدام source contol استفاده کنم؟

برای پاسخ به این سوال کمی از شما فرصت می‌خواهم تا به تدریج زوایای پنهان انتخاب source control‌ مناسب و همین‌طور فرهنگ کدنویسی در یک محیط تیمی را در چند نوشته برایتان روشن کنم، اما برای پاسخ اجمالی باید اشاره کنم که source control‌های مختلفی وجود دارند، یک مقایسه کامل از امکانات مختلف نرم‌افزارهای این حوزه را می‌توانید در این صفحه ویکی پدیا مشاهده کنید:

Comparison of revision control software

اگر برای اولین بار هست که دارید از source control‌ها استفاده می‌کنید و در یک محیط ویندوزی، به توسعه نرم‌افزار مشغول هستید از نرم‌افزارهای ساده‌تر شروع کنید چیزی مثل Source Safe (لازم است توضیح بدهم که آخرین نسخه Source Safe مربوط به سال 2005 هست و برای یک تیم بزرگ یا حجم زیاد کد جوابگو نیست) اما اگر از نان گندم استفاده نکردید اما دست مردم دیدید، بروید سراغ نرم‌افزارهای جدید و قوی تر مثل TFS.

قبل از اینکه طرفداران git یا svn مرا به طرفداری و معرفی صرف نرم‌افزارهای مایکروسافتی متهم کنند، خواهش می‌کنم تا نوشته‌ای که به صورت خاص در توضیح source control ها خواهم نوشت صبر کنید، آن زمان لینک نوشته را به این پست هم اضافه خواهم کرد.

اشتباهات رایج در استفاده از source control ها

خب همه چیز مرتب به نظر می‌آید، دیگر از انبوه فایل‌های rar مربوط به source‌ که لیست تغییرات در فایل txt در آن‌ها ذخیره شده خبری نیست، شما یک source control روی سیستم‌تان نصب کردید. صبر کن! چی گفتی؟ روی سیستم خودت نصب کردی؟

اجازه بدهید دوباره من از شما سوال کنم: اگر خدای نکرده هارد سیستم شما افتاد و دیگر هیچ فایلی قابل بازیابی نبود، آیا مهم هست که فایل‌های شما نسخه خورده باشند یا نخورده باشند؟ source control آمده تا در روز گرفتاری، نسخه پشتیبان را به شما برساند، اگر قرار باشد خودش در معرض خطر نابودی قرار بگیرد که اصلی‌ترین هدفش نقض غرض می‌شود!

source control را حتماً روی یک سیستم دیگر نصب کنید و از طریق شبکه با آن کار کنید و هر از گاهی هم یک backup از database مربوط به source control تهیه کنید.

بسیار خب، source control روی سیستم دیگر نصب شد، حالا بروم به سراغ رفع اون 5 تا باگ که دیروز گزارش شد، خب این از این، این هم از این و حالا 5 تا باگ رفع شدند، این هم از check in کد.

اشکال رفتار بالا این است که برنامه‌نویس 5 تا باگ که احتمالاً از بخش‌های مختلفی از کد و در فایل‌های متفاوتی هستند را با هم حل کرده و بعد کد را یکجا check in کرده، این کار، رهگیری تغییرات را در آینده مشکل می‌کند. برای اطلاع از خصوصیات یک commit‌ یا check in‌ خوب این مطلب را مطالعه کنید: What's in a Good Commit