Greenfield development VS Brownfield development

code

به دنبال ترجمه فارسی این دو اصطلاح نیستم. مدتی پیش مقاله ای در مجله MSDN مطالعه می کردم که به اصطلاح Brownfield development مواجه شدم. به طور ساده تعریف این دو عبارت به صورت زیر هستند

Greenfield development: زمانی فعالیت های برنامه نویسی شما در این دسته قرار می گیرند که شما پروژه ای را از صفر شروع کرده باشید. پروژه ای که هیچ کدی از قبل در آن وجود نداشته باشد. یا پروژه ای که به صورت دوباره نویسی کامل انجام خواهد شد.

Brownfield development: زمانی که شما روی یک پروژه موجود کار می کنید و با تغییراتی که در آن ایجاد می کنید نسخه نرم افزار را هم افزایش می دهید، فعالیت های شما در این دسته قرار می گیرند.

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

خصوصیات این دو نوع برنامه نویسی چیست؟ چه تخصص هایی برای انجام هر چه بهتر هر یکی از این انواع نیاز است؟

رفع ابهام

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

Brownfield development

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

  • خواندن کد های نوشته شده توسط دیگران دانش و تجربه شما را افزایش خواهد داد. (همان طور که در اینجا مطرح کرده ام)
  • برنامه نویسی روی کارهای دیگران نیازمند این است که شما قوه یادگیری و انطباق سریعی داشته باشید و این خصوصیت شما تقویت خواهد شد

البته ناگفته نماند که کار روی کدهای موجود از نظر یادگیری وقتی بیشترین بازده را دارد که برنامه نویس های قبل از شما از نظر سواد و تجربه در سطح بالاتری از شما باشند.

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

Greenfield development

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

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

برنامه نویسی در پروژه ای که از ابتدا شروع شده است لذت های خاص خود را دارد ولی می تواند معایبی نیز داشته باشد.

  • عدم یادگیری مدیریت زمان: به این معنی که شما همیشه درگیر ایجاد امکانات جدیدی هستید و همیشه حق خود می دانید که زمان در نظر گرفته شده برای کارهایتان بیشتر از حد انتظار شود. چون بالاخره کار جدید است و قبلا انجام نشده است.
  • سندروم ایجاد همه چیز از نو: اگر شما به این سندروم مبتلا باشید اصلا علاقه ای به استفاده مجدد کدهای قبلی نخواهید داشت. به طور مثال اگر یک سیستم مدیریت دسترسی قبلا در سیستم های شرکت کار می کرده، شما تصمیم می گیرید از آن استفاده نکنید و معادل جدیدتر و به روزتر آن را ایجاد کنید. البته بعضی زمان ها امکان استفاده از کد های قدیمی وجود ندارد چون صورت مسئله دوباره نویسی همان ابزارها است.
  • تبدیل شدن به دانشمند برنامه نویسی: این مورد با مورد یک و دو بسیار هم راستا است. زمانی که شما علاقه خیلی زیاد به یادگیری الگوهای معماری و طراحی دارید و نوشتن نرم افزار بهانه ای می شود برای تمرین کردن آن الگوها، نه رفع نیازهای کاربران (که حقوق شما را تامین می کنند!)

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

معیارهای انتخاب فریم ورک یا کامپوننت های برنامه نویسی

vs

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

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

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

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

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

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

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

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