درس : شر تکرار ( The Evil of Duplication ) همانطور که دادن دو دانش متناقض به خورد سیستم میتونه یک هوش مصنوعی رو زمین بزنه، این برای کد شما هم صدق میکنه. به عنوان برنامه نویس ما دانش بیزنسها رو جمع آوری، سازماندهی، داکیومنت و در نهایت اونو در اجرای یک کد زنده در میاریم. متاسفانه دانش ها استیبل نیستند، اغلب به سرعت تغییر میکنند. برداشت شما از یک نیازمندی ممکنه در یک جلسه با کاربر تغییر بکنه. دولت ها قوانینو تغییر میدند و برخی منطق های تجاری از رده خارج میشه. همه این بی ثباتی ها به این معنیه که ما قسمت زیادی از وقت خودمونو در حال تعمیر و نگهداری، سازماندهی مجدد و اعمال مجدد دانش ها در سیستم میگذرونیم. بیشتر افراد فکر میکنند که نگهداری ( maintenance ) از وقتی شروع میشه که پروژه رلیز بشه، در صورتی که اصلا اینطور نیست و فهم ما هر روز دستخوش تغییر و تکمیل میشه و ما نگهداری رو به عنوان بخش معمولی از کل فرایند توسعه سیستم میدونیم. تنها راه برای رسیدن به یک نرم افزار قابل اعتماد و استیبل، که توسعه و نگهداری آسان تری رو برامون به همراه داشته باشه، دنبال کردن یک چیزه که ما بهش میگیم اصل خشک ( DRY ) اصل DRY میگه: هر دانش باید دارای یک واحد بدون ابهام و معتبر داشته باشد در کل سیستم. حالا چرا بهش میگیم DRY : مخفف اینه Don ' t Repeat Yourself وقتی شما یک چیزو در چند جای کد تکرار کنید، وقتی نیاز دارید تغییرش بدید باید خاطرتون باشه که کجاها تکرارش کردید و اونجاها رو هم تغییر بدید که اگر یادتون نباشه، گند میزنید به سیستم. در این درس یکسری از مشکلات تکرار در سیستم رو بررسی خاهیم کرد و همچنین یکسری پیشنهاد برای جلوگیری از اون. درای فراتر از کد: در اولین چاپ این کتاب (سال ) ، ما توضیح ضعیفی از این قسمت داشتیم که منظورمون از اصل درای چیه، عده ای این برداشتو کردن که این اصل فقط مربوط به خوده کد هستش یعنی کدها رو کپی پیست نکن و جاهای مختلف برنامه یک کد یکسان رو نزار. خوب این کمترین نکته و برداشت از این اصل هستش، اصل درای در مورد عدم تکرار دانش و محتوا هستش که منجر به همون عدم تکرار در کد هم خاهد شد. فرض کن که یک چیز رو در دو جای کد بیاری و با راه حلای مختلفی هم حلش کنی، ته فاجعه. یک تست اسید هستش که میگه: وقتی قسمتی از کدو نیاز میشه که تغییر بدی، اگر خودتو تو وضعیتی دیدی که باید چند جای مختلفو تغییر بدی (از تمام زوایا، تغییرات بخش های دیگه ای در کد، دیتابیس، داکیومنتها) ، بدون که کدت اصل درای رو رعایت نکرده. چند نمونه رو بررسی میکنیم. تکرار در کد کد زیرو ببینید اگ یکم دقت کنید، اون قسمتی که داره اعداد منفی رو چک میکنه رو با یک فانکشن میشه هندلش کنیم: بهتر شد، اما بازم میشه جلوتر رفت و بسته به شرایط و نیازای کاربر باید بسنجیدش. هر تکراری کدی هم تکرار مفهوم نیست، مثلا فرض کنید توی یک اپلیکیشن سفارش گذاری آنلاین نوشیدنی، شما دارید سن و تعداد سفارش یوزرها رو کپچر و ولیدیت میکنید، طبق سیاست بیزنس اینجوری تحلیل کردید که هر دو باید عدد باشند و هر دو هم بزرگتر از صفر که شده این دو تا فانکشن زیر حین کد رویو شاید به نظرتون بیاد این دو تا فانکشن داپلیکیشن هست چون بادی جفتشون یک منطقو داره اجرا میکنه، ولی نه، این داپلیکیت اون داپلیکیت نیست، چون هر کدوم واسه یک موجودیت جدا داره ولیدیشنی رو چک میکنه، شاید الان یکی باشن ولی توی ادامه پروژه دستخوش تغییرات بشه. تکرار در/با داکیومنت ها خوب واسه این شاهکار باید دوبار وقت بزاریم هم داکیومنتشو بخونیم بعد هم کدو تا بلکه دستگیرمون بشه چی به چیه، نام گذاری خوب متغیرها و بهینه کردن شکل کد خودش میتونه مشکلو حل کنه مثه کد بعدی: این کد خودش داره صحبت میکنه با آدم که داره چکار میکنه. این کد DRY هست و نیازی به داکیومنت اضافه ای نداره. تخلف در اصل درای برای دیتاها حتی ساختارهای داده هم ممکنه اصل درایو رعایت نکنه مثلا کلاس زیرو ببینید: در دید اول شاید منقطی به نظر برسه، کمترین مشخصاتی که میشه برای یک سطر در نظر گرفته، شروع داره پایان داره و ی طول. اما تکرار اینجاست که پراپرتی طول حاصل یک محاسبه هاست اختلاف بین شروع پایان، ینی اینجوری: ممکنه در شرایطی انتخاب شما این باشه که اصل درای رو آگاهانه در قسمتهایی رعایت نکنید، مخصوصا وقتی میریم سراغ استفاده از کش برای عملیات های پر هزینه، در اونجا باید حواستون باشه که اون عدم رعایت اصل درای در معرض دنیای بیرون نباشه، دقیقترش اینکه فقط اعضای یک کلاس باید نگران نگه داشتن اوضاع به شکلی ساده و مستقیم باشند نه خارج از اون کلاس. این کد ی نکته مهم دیگه ام داره، وقتی ماژولی این کلاسو در معرض استفاده میزاره، بایستی به نحوی باشه که استفاده کننده به هیچ وجه درگیر پیاده سازی اون کلاس نشه، از اکسسور فانکشنها استفاده کردیم که خیلی کمک میکنن به این موضوع و همچنین توسعه عملکرد کلاس در آینده هم راحت تر میشه. Representational Duplication (بعضی چیزا رو بهتره ترجمه نکنیم، چون نمیشه ام کرد، معنی لغوی مفهومو نمیرسونه) معمولا وقتی سیستم شما میخاد سیستم، سرویس یا سورس سیستم دیگه ای رو کال بکنه و ارتباطی اکسترنال بین نرم افزارها رخ بده، داپلیکیشن رخ میده، هر سیستم باید اسکیمای دیتایی که سیستم مقابل بهش میده، ارور کدها و. رو بدونه. این مدل تکرار اجتناب ناپذیره ولی قابل کاهشه، در اینجا یکسری استراتژی مفیدو بیان میکنیم: - ارتباط و یا استفاده از api ها مدلهای مختلفی از این حالت ممکنه براتون پیش بیاد ممکنه api های داخلی یک سیستم بزرگ با هم در ارتباط باشن یا api بیرونی رو کال بکنید، از ابزارهایی که api ها رو داکیومنتو قابل تست میکنه میتونید کمک بگیرید مثل OpenAPI ، در استفاده از api های بیرون اگر چیزی پیدا نکردید، شروع کنید و خودتون بسازیدش و در معرض استفاده دیگران هم بزاریدش، قطعا دیگران هم جوین میشن و تکمیل ترش میکنن. - تکرار در دیتاسورسها خیلی از جاها ممکنه شما برای استفاده از دیتاسورس خاصی مجبور باشید کلاس معادل اسکیمای اون دیتا رو بسازید، شایدم نه در صورتی که شرایط پا بده، با استور کردن جیسون، کی ولیو، دیکشنری ها کارتون را بیفته و لازم نباشه الکی کلاس بسازید و اسکیمای اون دیتاسورس رو پیاده کنید. (دیتارو در قالب دیکشنری یا کی ولیو ازش خارج و به شکی که برنامه شما لازم داره استفاده کنید بدون ساخت کلاس استراکچر اون دیتا) ، البته این کاملا بستگی به شرایط پروژه داره و باید خودتون تشخیصش بدید. Interdeveloper Duplication سخت ترین و مضرترین تکرار، بین برنامه نویسها رخ میده، که ممکن در طولانی مدت در قسمت های مختلف پروژه ایجاد بشه و خیلی دیر کشف یا اصلا کشف هم نشه، که قطعا بهترین راه جلوگیری از این شر، ارتباط هستش، ارتباط بین اعضای تیم، استند آپ دیلی ها، رویوی کدها، کانالهای چت یا اسلک پروژه ها، مطلع بودن اعضا از سیستم، بحث و تدابل نظرها. یا حتی یکی از اعضای تیم میتونه به عنوان کتاب دار پروژه انتخاب بشه و کارش این باشه که کد همه رو رویو کنه، تبادل اطلاعات و تحلیل ها رو انجام بده و. دروس مرتبط: , منبع کانال تلگرامی: این وبسایت : t . me / pragmaticprogrammer _ fa