KISS مخفف شدهٔ کلمات Keep It Simple & Stupid است اما در عین حال برخی بر این باورند که این اصطلاح مخفف واژگان Keep It Super Simple است. این سرواژه مخفف هرچه که باشد یک معنی بیشتر نمی‌دهد و آن هم اینکه سعی کنید تا حد ممکن چیزهایی که در اختیار سایرین قرار می‌دهید را ساده طراحی کنید تا ایشان برای استفاده از آن مجبور به فکر کردن نشوند. به طور کلی، اصطلاح KISS در طراحی زیاد به کار می‌رود اما آنچه در این پست قصد داریم مورد بررسی قرار دهیم این است که این اصطلاح چه کاربردی در برنامه‌نویسی می‌تواند داشته باشد و دولوپرها با رعایت این اصل چگونه می‌توانند در کار خود حرفه‌ای‌تر عمل کنند.
یکی از کلید‌های اصلی موفقیت در مهندسی نرم‌افزار می‌تواند همین قانون KISS باشد به طوری که در حال حاضر یکی از مشکلات کاری رایج بین برنامه‌نویسان و دولوپرها این است که آن‌ها سهواً یا عمداً مسائل را بیش از حد برای خود پیچیده کنند! معمولاً زمانی که دولوپرها با مشکلی مواجه می‌شوند، آن را به تکه‌های کوچکتر قابل‌فهم تقسیم می‌کنند و سپس سعی می‌کنند تا راه‌حلی برای حل آن مشکل خاص بیابند اما مشکلی اصلی اینجا است درصد قابل‌توجهی از دولوپرها، به‌خصوص دولوپرهای تازه‌کار و مبتدی، این اشتباه را مرتکب می‌شوند که مسئله را به قسمت‌های کوچکتر و یا قابل‌فهم‌تر بیشتری نمی‌شکنند و نتیجهٔ انجام ندادن چنین کاری، نوشتن کدهای پیچیده برای آسان‌ترین مسائل است که در نهایت منجر به نوشتن به اصطلاح Spaghetti Code می‌شود. اگر بخواهیم به طور خلاصه بگوییم که فایدهٔ قانون KISS در برنامه‌نویسی چیست، بایستی بگوییم که:
- قادر خواهید بود تعداد بیشتری مسئله را در زمان کمتری حل کنید.
- قادر خواهید بود با تعداد کمتری خط کد برای مسائل پیچیده کد بزنید.
- قادر خواهید بود تا کدهایی با کیفیت بهتری تولید کنید.
- قادر خواهید بود سیستم‌های بزرگتری را با قابلیت نگاه‌داری راحت‌تر بسازید.
- سورس‌کد شما منعطف‌تر شده و توسعهٔ آن آسان‌تر می‌گردد و یا در صورت نیاز به ریفکتورینگ، قابلیت اصلاح آسان‌تری خواهد داشت.
- قادر خواهید بود به بیش از آنچه که فکر می‌کردید، از پرفورمنس بیشتری برخوردار گردید.
چهطور می‌توان قانون KISS را در توسعهٔ نرم‌افزار پیاده‌سازی کرد؟
چند گام ساده در این راستا باید برداشته شود. همان‌طور که در تعریف این سرواژه آمد، ساده‌سازی اصلی اساسی در این پروسه است. یک برنامه‌نویس حرفه‌ای می‌بایست متواضع بوده و هرگز فکر نکند که با نوشتن ساختارهای پیچیده، می‌تواند دانشش را به رخ دیگر دولوپرها بکشاند. همچون برخی افراد که به یک زبان خارجی همچون انگلیسی صحبت می‌کنند و سعی می‌نمایند تا از واژگان و اصطلاحات عجیب‌وغریب استفاده کنند تا سواد خود را به رُخ مخاطبشان بکشانند، در برنامه‌نویسی هم برخی دولوپرها فکر می‌کنند که اگر عجیب‌وغریب کد بزنند که سایر دولوپرها در درک آن دچار سردرگمی شوند، این نشان از حرفه‌ای بودن آن‌ها است که این تفکر کاملاً اشتباه می‌باشد.
هر تَسک (کار) را به تَسک‌های زیرشاخه تقسیم کنید تا جایی که برای هر بخش بیش از چند ساعت کار برنامه‌نویسی نیاز نباشد (البته بسته به گستردگی هر تَسک این تایم می‌تواند حتی تا ۱۲ ساعت نیز امتداد یابد.) به طور کلی، هر مسئله باید در قالب یک یا تعداد اندکی کلاس قابل‌حل باشد. همچنین متدهای خود را کوچک نگاه دارید به طوری که هر متد نباید از 30 الی 40 خط کد تجاوز کند و در عین حال، هر متد فقط باید یک مسئلهٔ خاص را حل کند نه اینکه تعداد زیادی مسئله وابسته به آن متد باشد (برای مثال، اگر دستورات شرطی زیادی را باید در متد خود بنویسید، آن‌ها را به متدهای کوچکتر تقسیم‌بندی کنید؛ این کار نه تنها باعث آسان‌تر خوانده شدن و نگاه‌داری برنامه می‌شود، بلکه باگ‌ها هم راحت‌تر پیدا می‌شوند.) علاوه بر این، تعداد کلاس‌ها را نیز محدود نگاه دارید و همان شیوه‌ای که برای متدها اتخاذ کردید را دربارهٔ کلاس‌ها نیز مد نظر داشته باشید.
به عنواهن راه‌کاری دیگر، ابتدا مسئله را روی کاغذ حل کرده سپس دست به کد شوید (که البته بسیاری از دولوپرهای تازه‌کار عکس این را عمل می‌کنند.) مثلاً بسیاری از برنامه‌نویسان در حال کد زدن مسائل را حل می‌کنند و این مشکل‌ساز خواهد بود (البته برخی برنامه‌نویسان که از ذهنی کاملاً تحلیلی برخوردارند، می‌توانند با رعایت این قانون، در حین کدنویسی مسائل را حل کنند.) اگر شما توانایی ذهنی شکستن مسائل را به قسمت‌های بسیار کوچک دارید، پس به هر ترتیب این کار را در حین کدنویسی انجام دهید اما در عین حال باید پی ریفکتور کردن چندین بارهٔ کدهای خود را به تن‌تان بمالید! در حقیقت، این نتیجهٔ نهایی کار است که به حساب می‌آید و تعداد خطوط سورس‌کد تحت هیچ عنوان معیار خوبی یک سورس‌کد نخواهد بود.
به علاوه اینکه اصلاً نگران حذف کردن کدهایتان نباشید به طوری که ریفکتورینگ (دوباره‌نویسی سورس‌کد) به عنوان بخش لاینفک در فرایند توسعهٔ نرم‌افزار است. همان‌طور که در روند کار برنامه‌نویسی با ملزومات جدیدی که وجود نداشتند و یا شما از آن‌ها از ابتدا بی‌خبر بودید مواجه می‌شوید، ریفکتور کردن ممکن است شما را قادر سازد تا مشکلات قبلی و جدید را حتی با روش بهتری حل کنید (در صورتی که از نکتهٔ گفته شده در بالا پیروی کنید، یعنی ابتدا حل مسئله روی کاغذ سپس دست به کد شدن، مسلماً تعداد دفعاتی که مجبور به باز‌نویسی کدها می‌شوید به حداقل خواهد رسید.)
و نکتهٔ آخر اینکه برای تمام موارد دیگر در کارتان هم همین اصل ساده‌سازی و ساده نگاه داشتن را رعایت کنید. رعایت این الگو سخت‌ترین کار ممکن است اما زمانی که به آن تسلط یافتید، به عقب نگاه خواهید کرد و به خود خواهید گفت «اصلاً نمی‌تونم تصور کنم قبلاً چهطور این کار رو انجام می‌دادم!»
آیا برنامه‌هایی هست که با قانون KISS نوشته شده باشد؟
در یک پاسخ کوتاه می‌توان گفت آری. نمونه‌های قابل‌ارائهٔ بسیاری وجود دارد به طوری که بعضی از بزرگترین الگوریتم‌های دنیای برنامه‌نویسی آن‌هایی هستند که کمترین تعداد خط کد را دارند و وقتی به کدهای آن‌ها نگاهی می‌اندازیم، به راحتی می‌توان مفهوم آن‌ها درک کرد. در واقع، ابداع‌کننده آن الگوریتم خاص آن‌قدر یک مسئله را شکسته و ساده کرده که به آسانی توسط سایر دولوپرها قابل‌فهم شده است (یک تمرین خوب این است که به سورس‌کد پروژه‌های #اپن‌سورس که توسط افراد حرفه‌ای نوشته شده‌اند نگاه انداخته و از آن‌ها درس گرفت.)
در پایان در پاسخ به این سؤال که آیا قانون KISS فقط در طراحی و کدنویسی کاربرد دارد؟ بایستی گفت که به طور قطع جواب خیر است. در حقیقت، این قانون نه تنها در اصول طراحی و همچنین توسعهٔ نرم‌افزار قابل پیاده‌سازی است، بلکه قابل تعمیم به بسیاری از دیگر حوزه‌های زندگی هم می‌باشد!
حال نوبت به نظرات شما می‌رسد. آیا با به‌کارگیری قانون KISS در کدنویسی موافقید و تجربه‌ای در این خصوص دارید؟ نظرات، دیدگاه‌ها و تجربیات خود را با سایر کاربران سکان آکادمی به اشتراک بگذارید.
