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

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

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

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

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

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

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

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

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

9 دیدگاه برای «درسی از یک نرم افزار ۱۵ دقیقه ای»

  1. ممنون، نکته ی خوب و جالبی بود ولی شاید چون درس ساده ای بود ما هم خیلی ساده از روش بگذریم .
    درمورد این حرفتون که “موفقیت یک پروژه نرم افزاری (چه کوچک چه بزرگ) به این که چه مقدار کار فنی عجیب و غریبی برای آن انجام شده است وابسته نیست” ، به نظرم ما بیشتر از اینکه دنبال “حل مسئله” باشیم، ناخوداگاه دنبال “کارای عجیب و غریب کردن” هستیم.
    چون یاد نگرفتیم مسئله رو چجوری حل کنیم و چجوری به دنبال راه حل باشیم. همیشه ازمون خواستن خودمون حل کنیم. و کسایی هم که دنبال راه حل گشتن، هیچ وقت مورد تایید نبودن.
    در نتیجه کسایی که میتونستن مسائل رو حل کنن، ذهنشون یاد گرفته که پیچیده فکر کنن و دسته دوم هم معمولا سرخورده میشن. درحالیکه درستش این بود یادبگیریم از هردوی این روش ها استفاده کنیم و هدف حل مسئله باشه نه دادن یک راه حل..
    و نهایتا شدیم اینی که الان هستیم، در مورد هرمسئله ای خودمون میخوایم از صفر یه راه حل بدیم! و برا پیدا کردن راه حل، خیلی سریع ذهنمون پیچیده میشه! چون همیشه تو این شرایط مورد تایید و تحسین قرار گرفتیم. حتی وقتی خودمون نتونیم حل کنیم و ناچارا! بگردیم راه حل پیدا کنیم، دچار نوعی عذابوجدان هم میشیم:|
    بهمون گفتن “نیاز، مادر اختراع است” و ماهم عاشق اختراع و کارای عجیب و غریب برای هر کاری شدیم..

      1. بله همینطوره. و معمولا هم افراد تو دوره دانشجویی تو یه حال و هوای خاصی قرار دارن. سرشار از انرژی، ذوق و شوق برای کارای بزرگ، ایده های بزرگ و کارای عجیب و غریب.. شاید همه این حالت رو تجربه کردند ولی متاسفانه بعد از دانشگاه و وارد شدن به محیط کاری و تجاری دیر یا زود این احساسات و انرژیها سرکوب و خاموش میشه.. دیر یا زود شکست رو تجربه میکنیم که رو خودمون هم تاثیر منفی میذاره.
        معمولا من صحبت های بقیه رو که گوش میدم یا بحث هاشون رو میخونم این دو جمله رو زیاد شنیدم. “میخوام….، دوست دارم …” و درجواب هم: “منم یه زمانی مث تو فک میکردم…”.

  2. «کار فنی عجیب و غریب» يعني چي دقيقا؟ كمي مبهم هست.
    جاوا اسكريپت هم يك زماني براي حل مسايل ساده و دم دستي درست شد. به همين جهت واژه‌ي «اسكريپت» رو به دنبال خودش داره. بعد از يك مدت ديدن اگر بخوان اينترفيس TFS رو با اون پياده سازي كنند، به هزاران خطاي ناشناخته بر مي‌خورن اون هم توسط حرفه‌اي‌ها. بعد مجبور شدند TypeScript رو اختراع كنند تا قابليت نگهداري پروژه در طول زمان بهبود پيدا كنه. خلاصه بستگي داره هدف چي باشه؟ چه مقياسي داشته باشه؟

    1. کار فنی عجیب و غریب به نظرم یعنی برای یک برنامه ساده ای که دوستم نیاز داشت همون نسخه اول installer درست میکردم. با کلی shortcut و یا مثلا با wpf مینوشتمش.

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

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *