تا حالا شده یه پروژه نرم‌افزاری رو شروع کنی و با خودت بگی:
«بابا این که چیز خاصی نیست، دو هفته‌ای جمعش می‌کنیم!»
بعد دو هفته بشه یک ماه،
یک ماه بشه سه ماه،
و آخرش یکی توی جلسه بگه:
«بچه‌ها چرا این پروژه انقد پیچیده شده؟»
و همه خیلی عاقلانه به مانیتور خیره بشن که یعنی ما هم دقیقاً همین سؤال رو داریم. 😂
واقعیت اینه که خیلی از مشکلات پروژه‌های نرم‌افزاری نه به خاطر بلد نبودن برنامه‌نویسی، بلکه به خاطر بد شروع کردن پروژه اتفاق می‌افتن و اینکه از اول نمیدونستیم دقیقا داریم چی میسازیم.
اینجاست که می‌رسیم به چیزی به اسم SDLC.
SDLC مخفف Software Development Life Cycle یا به فارسی خودمونی‌تر:
چرخه عمر توسعه نرم‌افزار
اسمش شاید شبیه اسم یک درس دانشگاهی باشه که از جلسه سوم به بعد دیگه کسی نمی‌فهمه استادش چی میگه! 😅
ولی مفهومش خیلی ساده‌ست.
SDLC یعنی:
قبل از اینکه بپریم وسط کدنویسی، مشخص کنیم که قراره چی بسازیم، چرا بسازیم، چطوری بسازیم، تستش کنیم و در نهایت تحویلش بدیم.
یعنی حواسمون باشه به همون ضرب‌المثل معروف خودمون:
«خشت اول چون نهد معمار کج، تا ثریا می‌رود دیوار کج.»
اگر پروژه رو از اول کج شروع کنیم، احتمالاً آخرش هم یک دیوار نرم‌افزاری خیلی قشنگ ولی کاملاً کج داریم! 😄
به‌طور معمول SDLC رو میشه به چند مرحله تقسیم کرد:
Planning → Requirements → Design → Development → Testing → Deployment → Maintenance
حالا بیایید این مراحل رو بدون کلمات قلمبه‌سلمبه بررسی کنیم.
اول باید بفهمیم اصلاً قراره چی بسازیم.
مثلاً فرض کنین می‌خوایم یه اپلیکیشن سفارش غذا درست کنیم.
اینجا باید درباره چیزهایی مثل این فکر کنیم:
هدف پروژه چیه؟
کاربران چه کسانی هستن؟
چه مشکلی رو قراره حل کنیم؟
چقدر زمان داریم؟
چه منابعی داریم؟
چه کسانی روی پروژه کار می‌کنن؟
این مرحله شاید خیلی هیجان‌انگیز نباشه.
ولی اتفاقاً یکی از مهم‌ترین بخش‌های پروژه است.
چون جمله‌ی معروف:
«فعلاً شروع کنیم، بعداً درستش می‌کنیم»
در پروژه نرم‌افزاری می‌تونه هزینه خیلی زیادی داشته باشه. 😅
حالا فهمیدیم قراره چی بسازیم.
ولی هنوز یک سؤال مهم داریم:
دقیقاً چه امکاناتی باید داشته باشه؟
مثلاً در اپ سفارش غذا، کاربر باید بتونه:
ثبت‌نام کنه
رستوران‌ها رو ببینه
غذا انتخاب کنه
سفارش بده
آدرس وارد کنه
پرداخت کنه
وضعیت سفارش رو ببینه
اینجا باید مطمئن بشیم چیزی که کارفرما یا صاحب محصول می‌خواد با چیزی که تیم فنی فهمیده یکیه.
چون اگر این مرحله درست انجام نشه، ممکنه تیم چند ماه روی یه قابلیت کار کنه و آخرش بشنوه:
«خیلی خوبه... ولی من همچین چیزی نگفته بودم!»
برنامه‌نویس: 🙂
برنامه‌نویس در دل:
«پس من برای کی داشتم کار می‌کردم؟» 😂
حالا می‌دونیم چی می‌خوایم.
وقتشه تصمیم بگیریم چطور بسازیمش.
توی این مرحله درباره چیزایی مثل این تصمیم می‌گیریم:
معماری سیستم چطور باشه؟
دیتابیس چه ساختاری داشته باشه؟
APIها چطور طراحی بشن؟
فرانت‌اند و بک‌اند چطور با هم ارتباط داشته باشن؟
رابط کاربری چه شکلی باشه؟
مثل ساختن یک ساختمونه.
قبل از اینکه آجر بذاریم، بهتره بدونیم دیوار قراره کجا باشه.
چون اگر وسط ساخت ساختمان یادمون بیفته:
«راستی بچه‌ها، آسانسور هم می‌خواستیم!»
احتمالاً کمی دیر شده. 😂
توی نرم‌افزار هم طراحی خوب می‌تونه جلوی مقدار زیادی دوباره‌کاری رو بگیره.
بالاخره رسیدیم به قسمت محبوب برنامه‌نویس‌ها:
کدنویسی!
حالا چیزهایی که در مراحل قبلی مشخص کردیم، تبدیل به نرم‌افزار واقعی می‌شن.
فرانت‌اند نوشته میشه، بک‌اند توسعه پیدا می‌کنه، دیتابیس ساخته میشه و کم‌کم محصول شکل می‌گیره.
البته توی این مرحله یک جمله معروف هم زیاد شنیده میشه:
«این فیچر خیلی ساده‌ست.»
و چند ساعت بعد:
دو تا باگ جدید به وجود اومده
یک API جواب نمی‌ده
دیتابیس قهر کرده
و یک نفر هم میگه:
«روی سیستم من که کار می‌کنه!» 😂
خب، نرم‌افزار ساخته شد.
پس تمومه؟
نه عزیز من!
حالا شاید بهتره بجای اینکه ببینیم چقدر ساختیم، باید ببینیم چقدر خرابش کردیم! 😄
در مرحله Testing نرم‌افزار رو بررسی می‌کنیم تا مشکلاتش رو قبل از رسیدن به دست کاربر پیدا کنیم.
مثلاً:
اگر رمز اشتباه وارد بشه چی؟
اگر اینترنت قطع بشه چی؟
اگر کاربر دوبار روی دکمه پرداخت کلیک کنه چی؟
اگر کاربر کاری انجام بده که ما اصلاً به ذهنمون نرسیده باشه چی؟
و جواب سؤال آخر تقریباً همیشه اینه:
کاربر دقیقاً کاری رو انجام میده که هیچ‌کس بهش فکر نکرده بود. 😂
تست کمک می‌کنه این اتفاق‌ها رو قبل از انتشار تا حد ممکن پیدا کنیم.
حالا فرض کنیم تست‌ها انجام شده و نرم‌افزار آماده است.
وقتشه ببریمش روی محیط واقعی؛ یعنی جایی که کاربران واقعی قراره ازش استفاده کنن.
این مرحله میشه Deployment.
و اینجا یک قانون نانوشته در دنیای نرم‌افزار وجود داره:
چیزی که روی سیستم من کار می‌کرد، ممکنه روی Production تصمیم بگیره یک زندگی جدید برای خودش شروع کنه! 😂
برای همین انتشار نرم‌افزار هم نیاز به برنامه‌ریزی داره.
قرار نیست اولین کاربر واقعی تبدیل بشه به تستر پروژه.
هرچند بعضی وقت‌ها زندگی راه خودش رو میره! 😅
نرم‌افزار منتشر شد.
همه خوشحالن.
تیم توسعه نفس راحتی می‌کشه.
مدیر پروژه میگه:
«خب، بالاخره تموم شد.»
و نرم‌افزار از گوشه اتاق:
«نه داداش، تازه شروع شد.» 👀
بعد از انتشار ممکنه:
باگ‌های جدید پیدا بشن
کاربران قابلیت جدید بخوان
سرعت سیستم نیاز به بهبود داشته باشه
مشکلات امنیتی پیدا بشه
نیازمندی‌های جدید به وجود بیاد
پس کار روی نرم‌افزار با انتشار تموم نمیشه.
اتفاقاً از اینجا وارد مرحله‌ای می‌شیم که باید نرم‌افزار رو نگهداری و بهتر کنیم.
بیایید همه مراحل رو با یک مثال جمع کنیم.
فرض کنین می‌خوایم یک اپ سفارش پیتزا بسازیم.
Planning: می‌خوایم مردم بتونن آنلاین پیتزا سفارش بدن.
Requirements: کاربر باید بتونه پیتزا انتخاب کنه، آدرس بده و پرداخت کنه.
Design: دیتابیس، API، رابط کاربری و معماری سیستم رو طراحی می‌کنیم.
Development: برنامه‌نویس‌ها شروع به ساخت محصول می‌کنن.
Testing: بررسی می‌کنیم که وقتی کاربر پیتزا سفارش میده، واقعاً پیتزا ثبت بشه، نه مثلاً یک یخچال! 😂
Deployment: نسخه نهایی منتشر میشه.
Maintenance:
کاربر میاد میگه:
«چرا نمیشه نصف پیتزا پپرونی باشه و نصفش مرغ؟»
تیم توسعه:
«خب... دوباره برگشتیم به Requirements.» 😐
و این چرخه دوباره ادامه پیدا می‌کنه.
SDLC قرار نیست کاری کنه که پروژه هیچ‌وقت باگ نداشته باشه.
اگر چنین چیزی وجود داشت، احتمالاً شغل Tester از دنیا حذف می‌شد! 😂
هدف SDLC اینه که توسعه نرم‌افزار منظم‌تر، قابل پیش‌بینی‌تر و کم‌ریسک‌تر باشه.
کمک می‌کنه:
دوباره‌کاری کمتر بشه
نیازمندی‌ها واضح‌تر باشن
مشکلات زودتر پیدا بشن
تیم بدونه قدم بعدی چیه
و پروژه کمتر تبدیل به یک جنگ تمام‌عیار بشه!
اگر بخوایم SDLC رو خیلی ساده تعریف کنیم:
فکر کن > نیازها رو مشخص کن > طراحی کن > بساز > تست کن > منتشر کن > نگهداری کن
همین!
SDLC قرار نیست کار برنامه‌نویس رو سخت‌تر کنه؛ قراره کمک کنه قبل از اینکه با سرعت نور شروع کنیم به کدنویسی، بدونیم داریم چی میسازیم.
چون در پروژه نرم‌افزاری هم مثل ساختمان‌سازی:
خشت اول رو درست بذاریم؛ وگرنه تا ثریا باگ داریم! 🐛😂
