اصل WET – همه چیز را دوبار بنویسید

ما از اصل DRY استفاده می کنیم و به طور فعال از آن استفاده می کنیم و اکنون ، پس از صرف 2.5 سال پوند برای ساخت و نگهداری کتابخانه های داخلی ، به عنوان تعریف ( نه به عنوان جایگزین) برای DRY ، احساس نیاز می کنم که WET را معرفی کنم. اصل.

تیم "به نوعی" از WET برای توسعه استفاده می کند اما این اصل هنوز به درستی تعریف نشده است/اعلام نشده است/عمداً مورد استفاده قرار نگرفته است.

نکته مهم: اصل WET ، روشی که من معرفی می کنم در حال حاضر ، فقط برای اجزای قابل استفاده مجدد قابل استفاده است: قطعات بزرگتر کد با منطق تجاری مستقل جداگانه یا اجزای UI قابل استفاده مجدد.

انگیزه

ما چندین مولفه در کتابخانه اصلی خود داریم که به اندازه کافی بالغ نیستند ، هدف اجزا روشن است ، قابلیت استفاده مجدد قطعاً راه است اما پارامترهای داخلی (API) ، قراردادهای نامگذاری مورد بررسی قرار نگرفته اند و مخصوص محصول هستند که استفاده مجدد را تقریباً غیرممکن می کند. وقتی به محصول دیگری معرفی می شوید (اجزای در اینجا: یک برنامه جداگانه ، کامل و مستقل که با هدف خاصی برای یک دامنه خاص ایجاد شده است) این اجزا مانند گیره های مربعی در سوراخ های گرد احساس می شوند.

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

بر اساس تجزیه و تحلیل گذشته نگر ، تیم دقیقاً با مشکلات DRY روبرو است: با استخراج نابالغ از قطعات کاربردی بزرگ که مستقل و منطق خاص محصول (در لحظه استخراج). خشک کردن ابزارهای کوچک و روشهای سطح کلاس تشویق می شود و بیشتر اوقات بدون مشکل پیش می رود.

راه حل: WET (همه چیز را دوبار بنویسید)

می توانید از خود بپرسید "آیا این را قبلاً ننوشته ام؟" دو بار ، اما هرگز سه بار (نگاه کنید به [1] در منابع)

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

نقشه راه آینده

با اصل WET استاندارد و کامل شده ، همه اجزای قابل استفاده مجدد باید از اصل بسته بودن پیروی کنند. تنظیمات رفتاری یا منطقی خاصی باید به صورت افزایشی انجام شود که در آن جزء قابل استفاده مجدد یک بسته بندی انتزاعی خاص محصول است که عملکرد آن را به ارث برده است. ساخته شده ، ما نیاز به ارزیابی و احتمالاً ادغام کردن مترجمان/ترنسپلیترهای خارجی مانند TypeScript داریم که با برقراری ارتباط/مستندسازی کاملاً واضح جزء A به Open-Closed کمک می کند. PI ها با انواع و رابط ها.

منابع

[1] https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33
[2] https : //overreacted.io/the-wet-codebase/