درسی از یک نرم افزار ۱۵ دقیقه ای

یکی از دوستانم (که برنامه نویس نیز نبود) آرشیو موسیقی مفصلی داشت. یک روز این موضوع برایش پیش آمد که بتواند فایل های صوتی تکراری موجود در هارد دیسکش را یافته و تصمیمی راجع به آنها بگیرد. شروع کرده بود به این که لیست فایل ها را بررسی کند و به صورت دستی فایل های تکراری را پاک کند. بعد از مدت کوتاهی از من پرسید: فرید امکان این وجود دارد برنامه ای بنویسی که فایل های تکراری را پیدا کرده و لیستی از انها به من نمایش دهد؟ چون تعداد فایلهای موجود در آرشیو من خیلی زیاد است.

نرم افزار 15 دقیقه ای

به او گفتم کار سختی نیست. امتحان میکنم. بعد از آن در حدود ۱۵ دقیقه (زمان کار را با toggl.com ثبت کردم) توانستم برنامه ساده ای بنویسم که در درایو خاصی فایل های صوتی تکراری را پیدا کرده و در یک فایل متنی گزارشی به کاربر ارائه دهد.

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

بعد از دیدن عکس العمل دوستم در مورد نرم افزار خیلی ساده ای که تهیه شده بود به این نکته بیشتر فکر کردم که موفقیت یک پروژه نرم افزاری (چه کوچک چه بزرگ) به این که چه مقدار کار فنی عجیب و غریبی برای آن انجام شده است وابسته نیست. یا به این که چه فناوری هایی در آن استفاده شده است.

عامل اصلی در موفقیت یک پروژه نرم افزاری استفاده درست از فناوری های موجود جهت رفع نیازهای اصلی کاربر هدف است.

در صورتی که نیاز اصلی کاربر رفع نشده باشد. واقعا مهم نیست که چه فناوری هایی و چه معماری های مرتبط و منظمی در نرم افزار استفاده شده است.

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

Greenfield development VS Brownfield development

code

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

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

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

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

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

رفع ابهام

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

Brownfield development

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

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

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

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

Greenfield development

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

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

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

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

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

نگاهی به Gartner HypeCycle 2014

در نوشته قبل در مورد روش تحقیق HypeCycle به صورت خلاصه صحبت کردم. در این نوشته قصد دارم مثالی اجمالی از نمودار مذکور ارائه دهم که شرکت Gartner برای بررسی فناوری ها در سال ۲۰۱۴ منتشر کرده است.

HC_ET_2014

 

نمودار بالا فقط نمونه ناچیزی از خروجی های تحقیقاتی شرکت Gartner است. تحقیقات این شرکت در سال ۲۰۱۴ شامل ۲۰۰۰ فناوری در ۱۱۹ دسته بندی بود.

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

معرفی کوتاه HypeCycle

 HypeCycle نمودار گرافیکی ثبت شده از طرف شرکت Gartner است، که برای بررسی و تحقیق در مورد بلوغ و مقبولیت یک فناوری از آن استفاده می شود. معمولا شرکت های بزرگ نرم افزاری یا غیر نرم افزاری با کمک گرفتن از چنین تحلیل هایی، تصمیمات استراتژیک فناوری های مصرفی خود را اتخاذ می کنند. سوالهایی که ممکن است در مورد یک فناوری پیش روی یک سازمان باشد می تواند به صورت زیر باشد:

  • آیا زود هنگام به سمت فناوری مورد نظر حرکت کند؟
  • آیا به صورت معتدل پیش رفته و منتظر پیاده سازی ها و نمونه های موفق اولیه بماند؟
  • آیا تا بلوغ کامل فناوری صبر کند؟

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

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

نمونه ای از این نمودار جالب را در زیر می توانید ببینید.

559px-Gartner_Hype_Cycle.svg

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