دوری از انبارداری در برنامه‌نویسی

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

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

شاید با خودتان بگویید به‌عنوان برنامه‌نویس چرا باید به چنین نکاتی توجه کرد؟ پروسه تولید نرم‌افزار، نکاتی دارد که به اصطلاح به آن جمع‌کردن انبار می‌گویند. چیزهایی که در این نقاط جمع می‌شود می‌تواند باعث به هدر رفتن وقت و پول زیادی شود. احتمالا با خود می‌پرسید مگر نرم‌افزار هم شبیه کارخانه است؟

فرض کنید ایده تولید نرم‌افزار شما، همان مواد خام است. با توجه به پروسه پیش رو، این ایده به نقاط مختلفی انتقال می‌‌یابد و در نهایت به‌عنوان فیچر به مشتری ارائه می‌شود:

1ـ مرحله تصمیم‌گیری

2 ـ مرحله طراحی (ویژگی‌ها، طرح‌های اولیه و ...)

3 ـ مرحله پیاده‌سازی (کدنویسی)

4 ـ مرحله آزمایش (یافتن باگ‌ها)

5 ـ مرحله دیباگ (رفع باگ‌ها)

6 ـ پیاده‌سازی (ارسال کد به مشتری یا قرار دادن در وب‌سایت و ...)

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

هر محصول نرم‌افزاری با جمع‌آوری ایده همراه است، یک برنامه نصفه و نیمه را به هر شرکتی ببرید، با چند جلد کتاب ایده‌ تخصصی بیرون خواهید آمد. متاسفانه این ایده‌ها به همان سرعت که جنریت می‌شوند، قابل برنامه‌نویسی نیستند و حتی بسیاری از این ایده‌ها بد هستند و برای این‌که به احساسات طرف مقابل توهین نکنید، آنها را هم یادداشت کرده‌اید. مشکل اینجاست که 90درصد موارد یادداشت شده پیاده‌سازی نخواهد شد، بنابراین هر دقیقه‌ای که این ایده‌ها را یادداشت می‌کنید، به آنها می‌اندیشید یا در مورد قابلیت‌هایشان ایده‌پردازی می‌کنید، هدر خواهد رفت. به اندازه تیم خود نگاه کنید. اگر تیم برنامه‌نویسی بزرگی زیر دستتان است، هیچ وقت ایده‌های بیشتر از یک ماه را یادداشت نکنید و حتی در موردش هم حرف نزنید. اگر خودتان یک برنامه‌نویس آزاد هستید، این بازه زمانی را به هفته یا روز کاهش دهید و نگذارید فکرتان مشغول ایده‌هایی باشد که بیشتر از این بازه زمانی وقت می‌گیرند.

دیتابیسی از باگ‌ها بسازید تا گزارش‌گیری خطاها سریع، دقیق و قابل بررسی باشد؛ اما باید احتیاط کرد که به تمام باگ‌ها رسیدگی شود وگرنه صلاحیت این دیتابیس از کار می‌افتد. فرض کنید باگ‌هایی را نبسته‌اید که متعلق به سه نسخه پیش‌تر نرم‌افزار است و این باعث ورشکستی باگ‌ها می‌شود و دیگر دیتابیس باگ‌ها به درد نخواهد خورد.

امیربهاءالدین سبط‌الشیخ