اشتباهات رایج کدنویسی در توسعه وب که باید از آنها اجتناب کنید

c، اپلیکیشن یا تهیه جریان کاری موثر در برنامه نویسی اغلب باعث می شود با مسائلی تکراری مواجه شویم. لازم نیست برای حل این مسایل از صفر شروع کنیم، چرا که Solution ها یا «راه حل» های مربوط به معماری -مانند تکه کدهایی در قطعات کوچک- این امکان را در اختیار ما قرار می دهند تا مجددا از آن ها استفاده کنیم. به هر حال مهارت طراحی سایت چیزی است که با چالش های خاص خود همراه است که در این بین برخی اشتباهات هستند که بیش از بقیه، توسط طراحان مبتدی سایت بارها و بارها تکرار می شوند. در این مقاله با سکان آکادمی همراه باشید تا به ۱۰ مورد از رایج ترین آن ها اشاره یی داشته باشیم.

الگوهای طراحی معمولا راه حل هایی با قابلیت استفاده مجدد در سناریوهای مختلف هستند که می توانند برای حل مسایل رایج هم مورد استفاده قرار گیرند و به ما کمک کنند تا کدمان را بهینه کنیم. در حالی که الگوهای طراحی به دلیل استفاده از فرمول ها و روش های تست شده برای بهبود فرایند توسعه کاربرد مهمی دارند، بعضی وقت ها هم ممکن است ما را دچار اشتباه کنند که در این صورت آن ها را Antipattern یا «ضد الگو» می نامیم.

آنتی پترن ها کدامند؟ 
عبارت آنتی پترن در کتابی به نام AntiPatterns در سال 1998 استفاده شد به معنی راه حل های قابل استفاده مجدد که در ابتدا مفید به نظر می رسند، ولی بعدا مشخص می شود که ضررشان از فایده شان بیشتر است.

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

از ضدالگوها گاهی اوقات با عنوان الگوهای شکست نام برده می شود. خبر خوب این است که می توان آن ها را به موقع تشخیص داد و از آن ها اجتناب کرد. در این مقاله قصد داریم به بررسی 10 ضدالگوی رایج کدنویسی در توسعه وب بپردازیم که ممکن است ما را درباره ی این که کدمان بهینه است یا خیر، به اشتباه بیاندازند (این موارد الزاما با مطالب کتابی که قبلا اشاره شد، همخوانی ندارد.)

Premature Optimization (بهینه سازی زودرس)
زمان بندی دقیق عامل مهمی در بهینه سازی کدها است. به راحتی ممکن است دچار ضد الگوی بهینه سازی زودرس شویم، اگر به بهینه سازی ها و کارایی های کوچک در فرایند توسعه بیش از حد توجه کنیم و آن ها را زودتر از موعد بهینه کنیم قبل از این که بدانیم دقیقا قصد انجام چه کاری را داریم. طبق نقل قول معروف Donald Knuth "بهینه سازی زودرس ریشه همه بدی هاست". شاید کمی اغراق باشد ولی نشان می دهد ممکن است بعدها مشکلات بزرگتری را به وجود بیاورند.

اگر قبل از این که معماری موثری را پیاده کرده باشیم کارایی را بهبود بدهیم، ممکن است باعث کاهش خوانایی کد شویم و دیباگ و نگهداری را سخت تر کنیم و قسمت های غیر ضروری را به کدمان اضافه کنیم.

برای جلوگیری از بهینه سازی زودرس، استفاده از قاعده برنامه نویسی YAGNI مخفف (You Aren’t Gonna Need It) مفید است به این معنی که «شما به آن نیازی نخواهید داشت» به طوری که این اصل حاکی از آن است که «همیشه چیزهایی را به کار ببرید که واقعا به آن ها نیاز دارید نه وقتی که پیش بینی می کنید به آن ها نیاز خواهید داشت.»

Reinventing the Wheel (اختراع مجدد چرخ)
این ضدالگو گاهی اوقات «طراحی در خلاء» نیز نامیده می شود و وقتی اتفاق می افتد که می خواهیم هر چیزی را خودمان انجام دهیم و از ابتدا کدنویسی کنیم، بدون مطالعه متدها، APIها و لایبرری های موجود. اختراع مجدد چرخ فقط اتلاف وقت نیست، بلکه این راه حل های سفارشی، مخصوصا برای کاربردهای اصلی و بنیادی، به ندرت به خوبی نمونه های استاندارد هستند که توسط بسیاری از کاربران و توسعه دهندگان آزمایش شده اند.

Dependency Hell (جهنم وابستگی ها)
در سمت مخالف «اختراع مجدد چرخ» چیزی به عنوان «جهنم وابستگی ها» است. اگر به جای نوشتن هرچیزی از ابتدا، از تعداد زیادی لایبرری شخص ثالث استفاده کنیم که خود آن ها وابسته به نسخه های خاصی از لایبرری های دیگر هستند، در موقعیتی قرار می گیریم که هنگام آپدیت ایجاد مشکل خواهد کرد، چرا که این وابستگی های فرعی در بسیاری از موارد با یکدیگر ناسازگار هستند.

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

Spaghetti Code (کدهای به هم ریخته)
اسپاگتی کد شاید شناخته شده ترین آنتی پترن باشد و به طور کلی Spaghetti Code حاکی از آن است که به خاطر عدم استفاده از معماری مناسب، دیباگ و اصلاح اپلیکیشن سخت خواهد شد.

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

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

Programming by Permutation (برنامه نویسی با جایگشت)
برنامه نویسی با جایگشت یا برنامه نویسی تصادفی وقتی اتفاق می افتد که با امتحان کردن تغییرات کوچک، آزمایش کردن و ارزیابی یکی یکی تکه کدها و در آخر پیاده سازی چیزی که برای اولین بار به نتیجه می رسد اقدام به پیدا کردن راه حل مسئله می کنیم.

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

Copy and Paste Programming (برنامه نویسی کپی پیستی)
برنامه نویسی با کپی پیست هنگامی رخ می دهد که ما از قاعده Don’t Repeat Yourself که به اختصار DRY گفته می شود به معنی «کار تکراری نکن» استفاده نکنیم و به جای ایجاد راه حل های عمومی، اقدام به درج تکه کد های موجود در جاهای دیگر کنیم و بعدا برای تناسب با زمینه مورد استفاده، اقدام به ویرایش نماییم. این اقدام باعث ایجاد کدهای تکراری می شود که دارای اختلافات ناچیزی هستند.

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

Cargo-Cult Programming (برنامه نویسی بارپرستانه)
نام برنامه نویسی بار پرستانه از پدیده قومی خاصی به نام Cargo Cult به معنی «بارپرستی» گرفته شده است. بار پرستان که در جزایر اقیانوس آرام جنوبی زندگی می کردند، بعد از جنگ جهانی دوم، در مواجهه با تمدن های پیشرفته، کشتی هایی را دیده بودند که اجسام و بارهایی برای سفیدپوستان می آوردند از قبیل کوکاکولا، تلویزیون، یخچال و غیره که فکر کردند این بارها فرستاده نیروهای ماورائی است و اگر آن ها هم مناسک جادویی شبیه به کارهای غربی ها را به درستی انجام دهند، کشتی های باری دوباره خواهند آمد و به جای سفیدپوستان به آن ها هدیه خواهند داد.

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

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

Lava Flow (جریان گدازه ای)
این ضدالگو مواقعی رخ می دهد که می خواهیم با کدی که قسمت های زائد و بی کیفیتی دارد کار کنیم ولی به نظر می رسد در برنامه به درستی کار می کنند و نمی دانیم دقیقا چه کاری انجام می دهند یا چه تاثیری روی عملکرد کلی اپلیکیشن دارند. این چیزها باعث می شود حذف کردن آنها هم مشکل ساز باشد.

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

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

در تئوری می توانیم با آزمایش های وسیع و ریفکتورینگ از شر جریان های گدازه ای خلاص شویم ولی در عمل، اجرای این کار اغلب سخت یا حتی غیر ممکن است. به خاطر این که جریانات گدازه ای معمولا در بخش Performance (پرفورمنس یا کارایی) هزینه سنگینی به بار می آورند، پس بهتر است با به کارگیری معماری با طراحی مناسب و جریان کاری حساب شده از ابتدا، از این ضد الگو اجتناب کنیم.

Hard Coding (کدنویسی استاتیک)
هاردکدینگ یکی از آنتی پترن های شناخته شده است که بیشتر آموزش های توسعه وب هم در ابتدا درباره ی آن به ما هشدار می دهند. برای مثال هاردکدینگ هنگامی اتفاق می افتد که مثلا به جای گرفتن شناسه ی کاربر از دیتابیس، آن را به صورت دستی -مثلا یورز آی دی ۱۲- وارد کنیم. گرچه اپلیکیشن ما به درستی کار خواهد کرد اما این در حالی است که کدهای ما فقط در محیط خاص به درستی کار می کنند و وقتی شرایط تغییر می کند ما هم باید سورس کدمان را معمولا در جاهای مختلف اصلاح کنیم.

Soft Coding (کدنویسی فوق دینامیک)
اگر بیش از حد سعی کنیم دچار هارکدینگ نشویم ممکن است از آن طرف پشت بام بیفتیم. این مساله که سافت کدینگ نامیده می شود، دقیقا در نقطه مقابل هارد کودینگ قرار دارد. در این ضدالگو، ما چیزهایی که باید در سورس کد موجود باشد را در منابع خارجی قرار می دهیم، برای مثال Business Logic یا «منطق اصلی وب اپلیکیشن» را در دیتابیس ذخیره می کنیم. رایج ترین دلیل برای انجام این کار این است که می ترسیم قوانین کاری در آینده تغییر کند، بنابراین نیاز به بازنویسی کدها خواهیم داشت.

در بیشتر موارد، برنامه ای با ویژگی سافت کد، می تواند بسیار انتزاعی و پیچیده باشد که درک آن تقریبا غیر ممکن است (مخصوصا برای اعضاء جدید تیم) و نگهداری و دیباگ آن هم کار طاقت فرسایی است.

طراحی وب سایت

• طراحی سایت
• طراحی اپلیکیشن
• بهینه سازی وب سایت
• هاستینگ و ثبت دامنه
• تبلیغات اینترنتی
• خدمات برندینگ
• طراحی گرافیکی هویت سازمانی