این مطلب از سری مطالب چه چیزهایی یاد بگیرم است!

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

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

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

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

در انتخاب یک فریم ورک و  یا ابزار خاص خوب است به نکات زیر توجه کنید. البته بیشتر موارد زیر ناشی از تجربیات خود من در انتخاب های ناردست! یا درستی بوده است که تا الان داشته ام. سوالات زیر را در مورد گزینه های موجود بپرسید.

• واقعا مفید است؟!
  این سوال را در اولین مرحله از خودتان بپرسید. آیا واقعا مفید است؟ یا چون یک برنامه نویسی که خیلی خفن به نظر می رسد آن را پیشنهاد داده، به آن علاقه مند شده اید؟ مفید بودن معیار های مختلفی دارد. ولی در این مرحله بپرسید که آیا به طور کلی مسئله من را حل خواهد کرد؟!
• دانش درون شرکتی در این مورد موجود است؟
  چقدر دانش در درون شرکت در مورد آن وجود دارد؟ نیاز است فردی یا تیمی را به عنوان مشاور به شرکت دعوت کنید؟ نیاز است افراد شرکت چه مقدار از زمان خود را صرف یادگیری آن کنند؟ اصلا به طور کلی فردی در شرکت قادر خواهد بود با آن کار کند و مسئله را حل کند؟ آیا با توجه به زمانی که از نیروهای شرکت می گیرد ارزش استفاده کردن دارد؟
• دانش بومی در ایران در این مورد موجود است؟
  در واقع این سوال را طور دیگری بپرسیم. آیا اگر برنامه نویسی که به آن تسلط دارد به هر دلیلی قطع همکاری کرد در زمان معقولی جایگزینی برای آن یافت خواهد شد؟ یا نیاز مبرم به آموزش افراد جدید الورود خواهد بود؟ بدیهی است که گزینه هایی که به شدت دانش موجود در ایران درباره آنها کم است، از حاشیه امنیت پایین برخوردار هستند و ریسک بالای دارند. البته در بعضی موارد هم استفاده از یک گزینه با توجه به این مورد نیز به صرفه خواهد بود. مثلا وقتی پروژه ای را انجام می دهید که برای اولین بار در ایران در حال انجام است.
• چه مقدار تغییر در زیرساخت های فعلی نیاز است تا از این مورد استفاده شود؟
  از خودتان بپرسید چه مقدار تغییرات در فرایند ها یا زیرساخت های فعلی نیاز است تا بتوان از آن استفاده کرد؟ اگر تغییرات زیاد بود و استفاده از گزینه مورد نظر ارزش افزوده بالایی داشت خوب تغییرات را اعمال کنید. ولی همیشه در ذهن داشته باشید هر چه قدر پروژه به جلو پیش برود و بیشتر در فاز نگهداری باشید تغییرات بنیادین هزینه بر و بی فایده خواهند بود. شاید بعضی وقتها دوباره نوشتن یک محصول پاسخ بهتری برای بعضی مشکلات باشد.
• متن باز است؟ متن باز بودن امکانات یا اختیاراتی در اختیار برنامه نویسان و شرکت قرار می دهد؟
  آیا گزینه مورد نظر شما متن باز است؟ این متن باز بودن چه امکاناتی به شما می دهد؟ فقط نگویید خودمان می توانیم کدش را بگیریم و تغییرات بدهیم. چون این کار را نخواهید کرد. متاسفانه عادت جدید برنامه نویسان لااقل در ایران این است که وقتی ابزاری را انتخاب کردند و بعد از کار با آن یک مقدار اذیت شدند خیلی به دنبال رفع مشکل در آن ابزار یا پیدا کردن راه حل مخصوص آن ابزار نخواهند رفت، به دنبال ابزار مشابه دیگری خواهند رفت. به این مورد اطمینان دارم. وقتی به این فکر کردید که کد پروژه ای را خودتان ویرایش خواهید کرد به آخرین باری فکر کنید که این کار را انجام داده اید. امیدوارم منظورم را متوجه شده باشید. علاوه بر همه این ها نگهداری از پروژه های بزرگ متن باز معمولا کار زمان بری است و اگر پروژه یا ابزار کاربران زیاد فعالی در اینترنت نداشته باشد این کار دشوارتر هم خواهد شد.
• شرکتی پشتیبانی آن را بر عهده دارد؟ شرایط و هزینه پشتیبانی چگونه است؟
  خیلی وقت ها ممکن است پروژه ای به صورت اولیه متن باز باشد. ولی شرکت یا شرکت هایی کارهای مربوط به پشتیبانی و نگهداری آن را به صورت رایگان یا غیر رایگان به عهده گرفته باشند. به نظر من اگر پروژه یا ابزاری به صورت باشد خیلی خیلی مفید خواهد بود. چون علاوه بر این که شما یک پشتیبانی منسجم و مستمر را در اختیار دارید، می توانید از مزایای متن باز بودن آن نیز استفاده کنید. به نظر من همیشه تلاش کنید پشتیبانی از یک ابزار را برون سپاری کنید، شاید هنوز امادگی مدیریت و نگهداری چند ابزار را به صورت بومی در سازمان خود نداشته باشید.
• نمونه پروژه موفق تجاری ای دارد؟
  آیا گزینه مورد شما در پروژه ها یا محصولات تجاری به صورت جدی استفاده شده است یا فقط یک سری نمونه کد یا پروژه های ساده از آن وجود دارد؟ یا به طور کلی توجه کنید که کاربران آن بیشتر طرفدار دو آتشه هستند یا این که واقعا در پروژه های خود از آن استفاده کرده اند؟ موفق بوده اند؟
• نقشه راه آن چگونه است؟
  آیا مسئولین پروژه یا ابزار مورد نظر شما در حال برنامه ریزی برای ارائه نسخه major هستند؟ آیا در حال برنامه ریزی برای ادغام با پروژه ای دیگر هستند؟ ایا پروژه مورد نظر شما deprecated شده است؟ آیا کار بر روی آن قطع شده است یا در حال قطع شدن است؟ پاسخ به سوالاتی از این دست به شما در تصمیمتان کمک بزرگی خواهد کرد.
• آیا به صورت مستمر روی آن کار می شود؟
  این که روی یک پروژه به صورت مستمر کار شود به شما این اطمینان را خواهد داد که در مدت زمان قابل قبولی با از بین رفتن ابزار و ناپدید شدن آن روبرو نخواهید شد. روش های مختلفی برای تشخیص کار مستمر روی یک پروژه وجود دارد. به طور مثال بررسی تاریخ های بروزرسانی نسخه ها. حجم تیکت های پشتیبانی موجود و مدت زمان پاسخگویی به آنها. وجود مشاوره فعال برای پروژه. وجود کتاب، وجود وبلاگ های بروز، وجود مقالات در سایت های مختلف، و یکی از مهمترین ها وجود سوال و جواب های بروز در سایت stackoverflow.com

به امید انتخاب های خوب.