جوئل کیست؟

جوئل اسپالسکی، یک مهندس نرم‌افزار اهل نیویورک است، او در سال 2000 شرکت Fog Creek را بنیان نهاد و در سال 2008 به همراه جف آتوود، سایت Stack overflow را ایجاد کرد. شهرت اسپالسکی در کنار موسس Stack overflow بودن، به خاطر وبلاگی که در حوزه توسعه نرم‌افزاری دارد هم هست: Joel On Software

جوئل اسپالسکی

داستان تست جوئل چیست؟

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

آیا تا بحال نام  SEMA (Software Engineering Measurement and Analysis)  را شنیده‌اید؟  SEMA، سیستم نسبتاً مبهمی است برای اندازه گیری شایستگی یک تیم نرم‌افزاری. نه! صبر كنید، به سایت آن نروید، زیرا فقط شش سال طول می‌کشد تا مطالب آن را بفهمید. به همین علت من تست کاملاً نامرتب و نامعتبر (!) خودم را برای ارزیابی كیفیت یک تیم نرم‌افزاری درست كردم. بهترین قسمت ماجرا اینجاست كه فقط سه دقیقه از وقتتان را می‌گیرد. با وقتی كه صرفه جویی می‌كنید، می‌توانید به سراغ حرفه پزشکی بروید!

ویژگی شسته و رفته تست جوئل در این است كه به راحتی می‌توان به هر سؤال جواب بله یا نه داد. شما مجبور نیستید كه تعداد خطهای كد در روز یا تعداد متوسط اشكال در هر قسمت را بشمارید. نقطه ضعف تست جوئل در این است كه نباید از آن برای اطمینان از صحت نرم‌افزار نیروگاه اتمی خود استفاده كنید!

تست شماره 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.

نمایی از مشاهده اطلاعات فایل‌های تغییر یافته در یک changeset در نسخه تحت وب TFS 2012

قبل از اینکه طرفداران 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

همان‌طور که اشاره کردم، استفاده از source control در تیم‌های نرم‌افزاری نیازمند فرهنگ سازی است، در این باره و درباره انتخاب source control در مجالی دیگر خواهم نوشت.

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