چرا بیشتر نرم‌افزارها برعکس ساخته می‌شوند

بیشتر نرم‌افزارها برعکس ساخته می‌شوند.

این اتفاق به این دلیل می‌افتد که افراد به چیزهای اشتباه پاداش می‌دهند.

ویژگی‌ها توجه جلب می‌کنند، اما معماری نه. اعلان‌ها توجه جلب می‌کنند، اما مستندات نه. قابلیت‌های جدید توجه جلب می‌کنند، اما نگهداری نه.

تیم‌ها با بخش‌های مرئی شروع می‌کنند و از زیربنا غافل می‌شوند.

سوالات رایج در مورد نرم‌افزار بر مرحله اشتباهی تمرکز دارند:

  • چه ویژگی‌هایی باید بسازیم؟
  • داشبورد باید چگونه باشد؟
  • از چه یکپارچه‌سازی‌هایی (integrations) باید پشتیبانی کنیم؟
  • بعد از این چه چیزی را می‌توانیم اعلام کنیم؟

این سوالات خیلی زود مطرح می‌شوند. شما باید قبل از ساختن ویژگی‌ها، سیستم را درک کنید.

ساختن یک خانه را تصور کنید. شما با رنگ دیوارها شروع نمی‌کنید. شما با این‌ها شروع می‌کنید:

  • زیربنا
  • سازه
  • لوله‌کشی
  • سیستم برق‌کشی

جزئیات مرئی به سیستم‌های نامرئی وابسته هستند. نرم‌افزار هم به همین شکل کار می‌کند.

رابط کاربری (User interface) مرئی است، اما معماری نه. ویژگی‌ها مرئی هستند، اما سیستم‌های پشتیبان آن‌ها نه.

سیستم‌ها تعیین می‌کنند که آیا یک نرم‌افزار موفق می‌شود یا خیر.

ویژگی‌ها مشکلات فردی را حل می‌کنند. سیستم‌ها دسته‌هایی از مشکلات را حل می‌کنند. ویژگی‌ها قابلیت ایجاد می‌کنند، اما سیستم‌ها ثبات (consistency) ایجاد می‌کنند.

اگر روی ویژگی‌ها تمرکز کنید، پیچیدگی رشد می‌کند. اگر روی سیستم‌ها تمرکز کنید، پیچیدگی نظم می‌یابد.

مستندات حقیقت را آشکار می‌کنند. یک سیستم با طراحی خوب، مستندات شفافی دارد. یک سیستم با طراحی ضعیف، به توضیحات طولانی و پیچیده نیاز دارد. اگر یک گردش کار (workflow) به صفحات دستورالعمل نیاز دارد، احتمالاً مشکل از خودِ گردش کار است.

کاربران ویژگی‌های مجزا را تجربه نمی‌کنند؛ آن‌ها سیستم‌ها را تجربه می‌کنند.

کاربران این‌ها را نمی‌بینند:

  • احراز هویت (Authentication)
  • APIها
  • پرس‌وجوهای پایگاه داده (Database queries)
  • خط لوله‌های استقرار (Deployment pipelines)

کاربران این‌ها را تجربه می‌کنند:

  • قابلیت اطمینان
  • سرعت
  • سادگی
  • اعتماد

این احساسات از کل سیستم نشأت می‌گیرند.

ساختن برعکس، درک کردنش آسان است. ویژگی‌ها در یک اسکرین‌شات جا می‌شوند. شما می‌توانید یک ویژگی را اعلام کنید، اما نمی‌توانید به راحتی یک سیستم را اعلام کنید.

کارهای نامرئی بیشترین ارزش را خلق می‌کنند.

من رویکردم را تغییر دادم. دیگر نمی‌پرم که یک پروژه به چه ویژگی‌هایی نیاز دارد؛ بلکه می‌پرسم در حال ساخت چه سیستمی هستم.

یک سیستم محدودیت‌ها را ایجاد می‌کند. یک سیستم اولویت‌ها را تعیین می‌کند. یک سیستم جهت‌گیری ایجاد می‌کند.

وقتی زیربنا وجود داشته باشد، ساخت ویژگی‌ها آسان‌تر می‌شود.

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

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

منبع: https://dev.to/stinklewinks/why-most-software-is-built-backwards-46i