در یک زبان تایپ ایستا مانند جاوا، سی شارپ، Go، تایپ اسکریپت یا حتی دارت، چگونه یک آدرس ایمیل را نشان می دهید؟ خوب، پسورد چطور؟ یک شماره تلفن؟ کد پستی؟ آدرس خانه؟ خوب، در مورد یک شناسه منحصر به فرد چطور؟

اگر پاسخ شما به همه یا بیشتر آنها یک رشته است، پس شما از چیزی رنج می برید که کارشناسان توسعه نرم افزار آن را " وسواس اولیه " می نامند.

در حالی که اولیه‌هایی مانند int ، char ، byte ، short ، long ، float ، double ، boolean ، strings و غیره بلوک‌های اساسی داخلی هر زبان برنامه‌نویسی هستند، وسواس اولیه زمانی است که کد شما برای نمایش بیش از حد به آنها متکی است. در غیر این صورت مفاهیم پیچیده تر

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

آنچه در این مقاله خواهید آموخت

این آموزش، در حالی که بسیار کوتاه است، برای کمک به درک و رسیدگی به موضوع وسواس اولیه در کد طراحی شده است. پس وقتی مطالعه را تمام کردید، باید بتوانید:

موارد بد وسواس اولیه و معایب مرتبط با آن را شناسایی کنید.

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

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

پیش نیاز: آنچه شما باید بدانید

آشنایی با اصول OOP مانند کلاس‌ها، اشیاء، کپسوله‌سازی، وراثت و چندشکلی هنگام طراحی ساختارهای داده سفارشی مفید خواهد بود.

تسلط بر زبان های دارای تایپ ایستا مانند جاوا، سی شارپ، Go، TypeScript و Dart که در آن انواع متغیر در زمان کامپایل اعلان می شوند.

اگر با این مفاهیم آشنا نباشید خوب است - منابع زیادی به صورت آنلاین و در کتاب های درسی در دسترس هستند تا به شما در شروع کار کمک کنند. اما این آموزش یک درک اساسی از این مبانی را فرض می کند و بر اساس آنها برای پرداختن به موضوع وسواس اولیه است.

چه چیزی در مورد وسواس اولیه بد است؟

وسواس بدوی به چند دلیل مشکل ساز است:

تحلیل نوع ضعیف

عملکرد داخلی محدود برای انواع داده های خاص

کاهش قابلیت نگهداری و از دست دادن دانش دامنه

بیایید هر موضوع را با جزئیات تحلیل کنیم:

1. اولیه ها تحلیل نوع ضعیف را ارائه می دهند

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

اگر این کار را انجام دهید، کامپایلر بر سر شما فریاد می‌زند:

 String phoneNumber = "+1-555-229-1234"; int zipCode = 101257; zipCode = phoneNumber; // throws an error

اگر این کار را می کردی چه؟

 String phoneNumber = "+1-555-229-1234"; String zipCode = "1000 AP" zipCode = phoneNumber; //works fine

کامپایل می شود و کاری انجام نمی دهد!

چرا؟

زیرا یک رشته همیشه یک رشته خواهد بود.

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

2. قابلیت داخلی محدود برای انواع داده های خاص.

هنگامی که به شدت به موارد اولیه تکیه می کنید، اغلب برای انجام کارهایی مانند اعتبارسنجی آدرس ایمیل یا قالب بندی شماره تلفن نیاز به نوشتن کد اضافی دارید. و این واقعاً مشکلی نیست.

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

3. کاهش قابلیت نگهداری و از دست دادن دانش دامنه

پراکندگی قوانین تجاری و منطق در سرتاسر پایگاه کد، نگهداری و تکامل نرم افزار را دشوارتر می کند. هنگامی که از ابتدایی ها به طور گسترده استفاده می شود، درک هدف و محدودیت های داده هایی که آنها ارائه می دهند می تواند چالش برانگیز باشد.

کپسوله کردن این منطق در انواع اختصاصی به حفظ دانش دامنه کمک می کند و کد را برای توسعه دهندگان آینده بصری تر می کند.

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

چگونه از وسواس بدوی دور شویم

1. مراقب متغیرهایی با منطق اعتبارسنجی خاص باشید.

برای مثال شماره تلفن را در نظر بگیرید. در نیجریه، جایی که من از آنجا هستم، همه شماره‌های تلفن یازده رقمی هستند و با صفر شروع می‌شوند. رقم دوم معمولاً « 7 »، « 8 » یا «9» است که به شناسایی اپراتور مخابراتی کمک می‌کند. هر عدد دیگری نامعتبر است.

همین امر را می توان در مورد URL وب سایت نیز گفت. به خوبی می تواند با یک رشته نمایش داده شود. اما یک URL در مقایسه با یک رشته اطلاعات و ویژگی های خاص بیشتری دارد (به عنوان مثال، طرح، پارامترهای پرس و جو و پروتکل). و هر قسمت روش اعتبار سنجی متفاوتی دارد.

2. مراقب متغیرها با قوانین مقایسه خاص باشید

فراتر از تحلیل های ساده برابری (==)، اگر متوجه شدید که منطق مقایسه سفارشی را برای یک متغیر بدون کپسوله کردن آن در یک کلاس پیاده سازی می کنید، یک پرچم قرمز است.

به عنوان مثال، مقایسه آدرس‌های ایمیل اغلب بیش از یک تحلیل ساده برابری را شامل می‌شود. ممکن است برای شناسایی دقیق ایمیل‌های منطبق مانند آدرس ایمیل + ورود به سیستم برای افرادی که می‌خواهند سیستم شما را بازی کنند، نیاز به تطبیق بدون حروف بزرگ، حذف فضای خالی، یا مدیریت تغییرات در قالب‌بندی داشته باشید.

daniel@example.com همان آدرس ایمیل daniel+dev@example.com است. ایمیل های ارسال شده به دومی در اولی دریافت می شود.

3. مراقب متغیرهایی با قوانین قالب بندی خاص باشید

هر متغیری که برای استخراج اطلاعات معنی دار نیاز به قالب بندی یا تجزیه خاصی دارد، کاندیدای نمایش غنی تر است.

ارزش ارز مثال خوبی برای این موضوع است. مناطق مختلف از قوانین قالب بندی متفاوتی استفاده می کنند - برخی از کاما و برخی از نقاط اعشاری استفاده می کنند. در مورد تاریخ تولد یا هر چیزی که نیاز به برخی داده ها دارد، این مورد مشابه است.

شناسایی و رفع وسواس بدوی یک فرآیند مستمر است.

شما نمی توانید همه نمونه ها را یکجا دریافت کنید، به خصوص مواردی که در دامنه کسب و کار شما غیر معمول و منحصر به فرد هستند. این کاملاً خوب است - اینطوری باید باشد.

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

تا زمانی که به شما نشان داده نشود آن را نمی بینید

وسواس بدوی در یک دید آشکار پنهان می شود. و این یک مسئله مهم است زیرا برخلاف خطاهای استاتیک، لینترها آنها را علامت گذاری نمی کنند و همچنین برنامه شما در نتیجه خراب نمی شود.

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

پس ذهن باز بمانید، با دیگران تعامل داشته باشید، کدهای منابع مختلف را بخوانید و در پروژه های متن باز مشارکت کنید. اینطوری یاد میگیری در نهایت، همه چیز به یک چیز مربوط می شود: کپسوله سازی - گروه بندی داده ها و روش هایی که روی آن ها در یک مکان برای قابلیت نگهداری کار می کنند.

اعتبارات و منابع:

بوی رمزی که بیشتر از همه به مردم صدمه می زند توسط آرپیت جین.

علائم و نشانه‌های وسواس بدوی توسط گوروی Refactoring.

چگونه می توان وسواس اولیه را توسط سم والپول در هکرنون برطرف کرد.

خبرکاو