در توسعه نرم افزار مفهومی وجود دارد به نام KISS یا اصل سادگی که به روایت های مختلفی بیان می شود:
“Keep it simple, silly”, “keep it short and simple”, “keep it simple and straightforward”, “keep it small and simple”, “keep it stupid simple”
در ویکی پدیا اینگونه تعریف شده است:
“این اصل بیان می‌کند که اکثر سیستم‌ها چنانچه ساده و به دور از پیچیدگی بمانند، عملکرد بهتری خواهند داشت؛ بنابراین، سادگی باید هدف اصلی طراحی سیستم‌ها باشد و از پیچیدگی‌های بیهوده اجتناب کرد.”
برای آنکه به درک مشترکی برسیم من اسمش را “سادگی جذاب مشتری” می گذارم که یک مالک محصول توانمند و متخصص از آن به عنوان ابزاری برای کسب اقبال بیشتر مشتریان و کاربران استفاده می کند. اما در سوی دیگر این میدان سادگی، توسعه دهندگان محصول (یا سیستم) قرار دارند. جایی که برنامه نویسان وظیفه اصلی پیاده سازی این سادگی را دارند و متاسفانه محل بروز چالش ها و اشاره همیشگی چوب های سرزنش در مشکلات و خطاهای سیستم هستند!
یک رویکرد بسیار متداول بین برنامه نویسان این است که کد نویسی به گونه ای انجام شود که در مرحله اول صرفاً کد عملیاتی شده و سیستم کار کند. اما دقیقاً تأکید همینجاست “در مرحله اول”.
مشکل زمانی بروز می کند که این سادگی در کدنویسی تا آنجایی ادامه یابد که امکان گسترش و تعمیم آن در سطوح دیگر برنامه (یا برای scale بزرگتر) وجود نداشته باشد.
این مورد را می توان “سادگی جذاب برنامه نویس” نامید که در نقطه مقابل بشدت منفور مالک محصول و سرمایه گذاران است. چرا که دیر یا زود گریبان گیر شده و آن ها را با گلایه و شکایت های کاربران مواجه می کند. این همان “بدهی فنی” (Technical Debt) است.
“بدهی فنی در نتیجه تصمیمات بد یا انتخاب های ضعیف فنی ایجاد می شود.”
بدهی های فنی می بایست بطور مستمر رسیدگی و رفع شوند. در صورت انباشت به مرور زمان سرعت توسعه و تحویل محصول را کاهش داده و در نهایت حتی می توانند مانع تولید increment و خروجی نهایی برای زمان طولانی شود.
بدون شک کد گسترش می یابد. کاربران سیستم شما بیشتر می شوند و مهمتر از همه از نوشتن کد فعلی زمان می گذرد و آنوقت بهبود آن روز به روز سخت تر شده و هزینه عملیاتی بیشتری به همراه خواهد داشت.
به طور مثال در طراحی شیء گرا یکی از اصول پنج گانه SOLID این است که کلاس ها، توابع، متدها و … باید گسترش پذیر باشند و در عین حال برای تغییر کردن بسته باشند.
چالش دیگر همراه با ایجاد اصل سادگی این است که باید همراه با حفظ و ارتقا کیفیت محصول باشد و از طرف دیگر این سادگی در طراحی سمت کاربر زمانی که بیش از اندازه باشد می تواند کاربر را سردرگم کند. طراحان UI/UX شما در این زمینه متخصص هستند پس به آن ها اعتماد کنید.
بطور مثال اگر شما در سیستمتان یک پنل کاربری دارید عملیات های مختلف باید به راحتی و سریع در دسترس کاربر باشند اما اگر همین پنل شامل ۲۰ عملیات مختلف باشد برای فراری دادن کاربرانتان می توانید همه آن ها را در یک آیتم بگنجانید. باید خیلی احتیاط کنیم که بقول همان ضرب المثل معروف از آن طرف بوم نیفتیم!
به خاطر داشته باشیم که اصل سادگی، بسیار ارزشمند و مهم است اما نه به هر قیمتی.
