Printable View
کلام اول
همه ی ما میدونیم که امروزه ساخت برنامه های تحت وب چقدر فراگیر شده. این قضیه با فراگیر شدن اینترنت رشد بیشتری هم کرده. در گذشته صفحات وب شاید فقط یه سری صفحات ساده ی HTML با یه سری متن و عکس بودند. ولی امروزه صفحات وب شکل جدیدی پیدا کردن. دینامیک شدن. پیچیده شدن. و بسیار پرکاربرد شدن. هدف ما توی این آموزش اینه که به شما ده تا از اشتباهاتی که در ساخت برنامه های تحت وب ممکنه دچارش بشید رو گوش زد کنیم و بگیم که لطفاً از این اشتباهات جلوگیری کنید.
اشتباه شماره 1: اعتبارسنجی ناکافی داده ها
بذارید همینجا بهتون بگم که هیچوقت به داده های ورودی کاربر در صفحاتتون اعتماد نکنید. کاربرها می توانن هر چیزی وارد کنن. حتماً باید به اعتبارسنجی داده ها (Data Validation) در سمت کلاینت و سمت سرور فکر کنید. یکی از بزرگترین مشکلاتی که عدم انجام این کار می توانه براتون پیش بیاره SQL Injection هست. این موضوع خیلی خطرناکه. در واقع کاربر یا یک هکر با استفاده از این تکنیک می تونه به بانک اطلاعاتی شما دسترسی پیدا کنه و دیگه بقیشو خودتون می دونید. جالبه بدونید که اغلب محیط های توسعه ی برنامه های تحت وب به راحتی می توانن اعتبارسنجی داده ها رو براتون انجام بدن. خیلی از این محیط های توسعه به شما کمک می کنند که در سمت کلاینت به راحتی این کار رو انجام بدید و در سمت سرور هم اغلب با استفاده از یک سری Data Annotation هایی این کار به راحتی انجام پذیره. پس شما اگر می خواین یه توسعه دهنده ی درست حسابی در سطح وب باشید حتما به اعتبارسنجی داده های وارد شده توسط یوزر چه در سمت کلاینت چه در سمت سرور بطور جدی فکر کنید.
منبع وبسایت پرووید
اشتباه شماره 2: کنترل حق دسترسی کاربر بدون کنترل هویت کاربر
بذارید برای اینکه مطمئن بشیم همه مون معنی و مفهوم این دو کلمه رو می دونیم یه بار دیگه تعریفشون کنیم:
کنترل هویت کاربر (Authentication): کنترل هویت کاربر یعنی اینکه بدونیم یه شخص همون کسی هست که ما فکر می کنیم. چرا؟ چون احتمالاً یوزر نیم و پسورد درست رو وارد کرده یا اینکه به یه سوال امنیتی به درستی جواب داده.
حق دسترسی کاربر (Authorization): حق دسترسی کاربر یعنی اینکه هر کاربر به چه منابعی می تونه دسترسی داشته باشه و چه کارهایی رو میتونه انجام بده یا نده.
در واقع Authentication یعنی اینکه یه نفر کی هست و Authorization یعنی اینکه یه نفر چیکار می تونه بکنه.
حالا که این تعاریف مشخص شدند بذارید اشتباه شماره ی دوم رو با یه مثال بگیم. فرض کنید که مرورگر اطلاعات مربوط به کاربرها رو بعد از لاگ این کردنشون به این صورت داره:
{
username:'hamid',
role:'worker',
token:'123456789'
}
حالا فرض کنید که کاربر می خواد پسورد رو تغییر بده. خب اون این متد رو در حالت POST اجرا می کنه:
POST /changepassword/:username/:newpassword
خب کاری که شما باید انجام بدید چیه؟ اینه که اول چک کنید که این یوزر لاگ این کرده باشه و بعد اون توکن منقضی نشده باشه و بعدش پروفایل کاربر رو پیدا می کنید و نهایتاً پسوردشو عوض می کنید. پس کاری که شما کردید اینه که اول مطمئن شدید کاربر لاگ این کرده و بعد هم درخواستشو عملی کردید، یعنی پسوردشو تغییر دادید. درسته؟
متاسفانه باید بگم که این کار کاملاً اشتباهه. کاری که باید انجام بدیم اینه که مطمئن بشیم کاربری که داره درخواست تغییر پسورد میده همون کسی هست که نهایتاً پسوردش عوض میشه. نکته اینجاست که اطلاعات ذخیره شده درون مرورگر به راحتی می تونن تغییر داده بشن. یه کاربر نسبتاً کاربلد می تونه به راحتی رکورد بالا رو به این زیری تغییر بده:
{
username:'Administrator',
role:'worker',
token:'123456789'
}
این کار رو هم فقط با استفاده از قابلیت های مرورگر می تونه انجام بده و نیاز به هیچگونه کدنویسی و ... نیست. کاری که ما اینجا کردیم فقط Authentication بود. یعنی فقط مطمئن شدیم که کاربر لاگ این کرده. حتی می تونیم کنترل کنیم که متد changepassword فقط توسط کاربرهایی قابل انجام باشه که لاگ این کردن ولی باز اینم کافی نیست.
کاری که باید انجام بدیم Authorization هست. یعنی چی؟ یعنی اینکه کنترل کنیم کسی که درخواست تغییر پسورد داده با اون یوزر نیم ی که توی متد changepassword اومده یکی باشن (که در اینصورت کاربر می تونه پسورد رو تغییر بده) و در نهایت مطمئن باشیم که کاربر فقط می تونه پسورد خودشو عوض کنه.
لطفاً همه دقت کنن که Authorization و Authentication کنار هم خوبن. اینا عین دوتا داداشن. لطفاً جداشون نکنید. خدا رو خوش نمیاد.:لبخند:
منبع وبسایت پرووید
اشتباه شماره 3: عدم مقیاس پذیری
مقیاس پذیری می دونید که یعنی چی؟ یعنی اینکه مثلاً وب سایت شما بتونه بر اساس رشد و کاهش تعداد درخواست های کاربرها، رشد و کاهش داشته باشه. وقتی درخواست ها زیاد شدند از پردازنده های بیشتری استفاده کنه تا بتونه کارشو به درستی ادامه بده. وقتی درخواست ها کم شدند از منابع کمتری استفاده کنه که به هدر نرن. اینو میگن مقیاس پذیری و توی ساخت برنامه های تحت وب بسیار مهمه. حالا که تعریف مقیاس پذیری رو فهمیدیم بریم سراغ بحث اصلی مون.
یه بحثی تحت عنوان MVP توی دنیای وب وجود داره. این موضوع یعنی اینکه اغلب کسب و کارها سعی می کنند خیلی سریع وب سایت های خودشونو عملیاتی کنن، محصولاتشونو به کاربر ارائه بدن و در نهایت توی کورس رقابت پیش برن. یکی از مشکلاتی که این نیاز به سرعت کار بالا به وجود میاره اینه که خیلی از مسائل کوچیک و ریز از دید بهترین برنامه نویس ها هم مخفی می مونن. بذارید یه مثالی بزنیم.
فرض کنید که یه وب سایت ساختید. توی این وبسایت به درستی اومدید لایه لایه برنامه نویسی کردید و قسمت های مختلف رو جدا کردید. بانک اطلاعاتی تون رو کنترل کردید و خیلی چیزهای دیگه. فقط یه کاری کردید اونم اینکه یه سری عکس مربوط به پروفایل کاربرها رو ذخیره می کنید و توی وب سرورتون قرار می دید. این موضوع کاملاً عملی هست و هیچ مشکلی براتون پیش نمیاره ولی بعدها که سایتتون رشد کرد و کاربرهاتون زیاد شدن و خواستید یه وب سرور دیگه هم بیارید توی کار شما رو دچار مشکل می کنه. حتی ممکنه برای چند ساعتی خطاهای زشت 404 رو تولید کنید.
این کار رو می تونستید خیلی راحت از اول کنترل کنید. ممکن بود فقط نیاز به چند ساعتی کار داشته باشه ولی دیگه هیچ مشکلی با رشد سایتتون ایجاد نمی شد. می تونستید فایل ها رو بریزید توی یک منبع ثانویه، توی یک دیتابیس و هر جای دیگه و از ریختنشون توی وب سرور جلوگیری کنید.
منبع وبسایت پرووید
اشتباه شماره 4: کج فهمی های SEO
خیلی از توسعه دهندگان برنامه های تحت وب خیال می کنند که یک متخصص SEO هستند در صورتی که اینطوری نیست. اینکه گوگل، یاهو و بینگ بر اساس چه الگوریتم هایی کار ایندکس کردن صفحات رو انجام میدن و چه سیاست هایی را دنبال می کنن خیلی پیچیده است. برای اینکه یه نفر ادعا کنه که متخصص SEO هست هیچ راهی نداره مگر اینکه به طور مکرر تحقیق کنه، تست کنه و مرتباً کار کنه. الگوریتم های ایندکس گذاری گوگل مرتباً تغییر می کنه و اگر کسی از این موضوع فاصله بگیره بدون شک نمیتونه ادعا کنه که متخصص SEO هست.
به علاوه، اغلب توسعه دهنده ها فکر می کنند که باید عملیات مربوط به SEO رو بذارن برای آخر کار، در صورتی که این موضوع اصلاً درست نیست. بهینه سازی سایت برای SEO باید از همون اول کار در نظر گرفته بشه. از این گذشته، SEO فقط مربوط به پست کردن مطلب جدید، تگ و عکس و ... نیست. اینکه سرعت سایت و بانک اطلاعاتی چقدر بالاست و یا اینکه Back Link ها در نظر گرفته شدند هم از تکنیک های SEO هست.
یادتون باشه که شبیه اشتباه قبلی، سعی کنید کارهای مربوط به SEO رو از همون اول کار انجام بدید وگرنه یه موقع می بینید بهبود وب سایتتون برای SEO خودش یه پروژه ی عظیم دیگه میشه.
منبع وبسایت پرووید
اشتباه شماره 5: انجام کارهای زمان بر در جواب به درخواست کاربر
یکی از مشکلاتی که اغلب توسعه دهنده های وب دارن و اغلب هم بهش توجه نمی کنن اینه که در جواب به درخواست های کاربر میخوان کارهایی انجام بدن که بسیار زمانگیر هست و اغلب سرعت برنامه رو شدیداً کاهش می ده. برای اینکه مسئله روشن تر بشه بذارید مثالی بزنم.
فرض کنید یه وب سایت ساختید که یک سری مشتری سفارش آنلاین ثبت می کنن و شما به محضی که مشتری سفارشی رو ثبت کرد یه ایمیل براش ارسال می کنید که سفارش رو تایید کنه. این موضوع ممکنه اول کار شما رو دچار مشکل نکنه چون تعداد سفارشها در روز کم هست. ولی وقتی وب سایت رشد میکنه و روزی صدها سفارش ثبت میشه ارسال ایمیل توسط SMTP خیلی کار نادرستی هست. اغلب توسعه دهنده ها فکر می کنن که SMTP خیلی سریع و سبک وزن هست در صورتی که اینطور نیست. شما اگر بخواین صدتا یا چند صدتا ایمیل رو با SMTP بعد از ثبت سفارش کاربر ارسال کنید یا برنامه خطا میده یا سرعت شدیداً پایین میاد. روش درست انجام این کار اینه که وظیفه ی ارسال ایمیل رو بسپارید به پردازش دیگه و هر چه زودتر نتیجه ی درخواست HTTP کاربر رو بهش ارسال کنید.
این چیزی که شرح داده شد فقط یه مثال بود. در کل همیشه در نظر داشته باشید که کارهای زمانگیر رو بسپارید به یه پردازش دیگه و در جواب به درخواست های HTTP کاربر انجامشون ندید.
منبع وبسایت پرووید
اشتباه شماره 6: بهینه نکردن پهنای باند
یادتون نره که وقتی دارید کار توسعه ی یک وب سایت رو انجام میدید اغلب از یک کانکشن پر سرعت محلی استفاده می کنید، ولی وقتی که وب سایت رو روی سرور مستقر می کنید و در دسترس مردم قرار میدید این موضوع دیگه از بین میره.
وقتی یه وب سایت رو توی شبکه ی محلی سیستم خودتون با سرعت 1 گیگ باز می کنید و فکر می کنید سرعت خیلی عالیه باید به این فکر کنید که یه کاربر ممکنه بخواد همین صفحه رو با اینترنت 3G از روی تبلتش باز کنه. برای اون کاربر سرعت چجور خواهد بود؟ اغلب توسعه دهنده ها به این موضوع فکر نمی کنند و نتیجه ی کار میشه نارضایتی کاربرها و ترک کردن سایت شما.
کارهای خیلی ساده ای وجود داره که بتونید پهنای باند مصرفی توسط وب سایتتون رو کاملاً کاهش بدید. مثلاً:
- همه ی فایل های جاوااسکریپت رو فشرده کنید.
- همه ی فایل های CSS رو فشرده کنید.
- فرمت عکس ها رو تغییر بدید تا حجمشون پایین بیاد.
- از فشرده سازی سمت سرور برای HTTP استفاده کنید.
یادمه که توی وبسایت پرووید در رابطه با مقایسه ی ASP.NET MVC و ASP.NET Web Forms نوشته بودم که سرعت پاسخ های HTTP در MVC نسبتاً بالاتره و دلیلش هم اینه که ViewState نداریم. پس اینم یه نکته ی دیگه: می تونید به جای Web Forms از MVC استفاده کنید.
منبع وبسایت پرووید
اشتباه شماره 7: عدم پشتیبانی از سایز صفحات مختلف
همونطور که ممکنه فکر کرده باشید امروزه استفاده از تبلت و گوشی ها هوشمند فراگیر تر از قبل شده. خیلی از کاربرها کار وبگردی رو با تبلت و اسمارت فون انجام میدن. اینکه وب سایت شما نتونه از این سایز از صفحات پشتیبانی کنه خیلی جالب نیست. روراست تر بخوام بگم باید بگم که خیلی از بازدیدکنندگان سایت شما میپرن.
خوشبختانه اینکه صفحات وب رو طوری بسازیم که روی هر سایز از صفحه ای به درستی نشون داده بشن کار سختی نیست. این قضیه رو تحت عنوان واکنش گر بودن (Responsive) می شناسیم. پلت فرم های زیادی برای ساخت صفحات واکنش گر وجود دارن که یکی از محبوب ترینشون Bootstrap هست. این پلت فرم ترکیبی از جاوا اسکریپت، CSS و HTML هست که به ما امکان میده صفحات واکنش گر بسازیم. لطفاً دقت کنید که توی ساخت صفحات وبتون حتماً آپشن واکنش گر بودن رو به خاطر داشته باشید.
منبع وبسایت پرووید
اشتباه شماره 8: عدم پشتیبانی از مرورگرهای مختلف
همه ی ما میدونیم که کاربرهای اینترنت از مرورگرهای مختلف استفاده میکنند. بعضی ها از کروم، بعضی ها از فایر فاکس و بعضی ها از اوپرا و ... برنامه ای که شما دارید می سازید باید طوری طراحی بشه که از حداکثر این مرورگرها پشتیبانی کنه و اینجوری نباشه که فقط توی یک مرورگر به درستی نشون داده بشه.
لطفاً اینم فراموش کنید که بعضی از مرورگرها خیلی محبوب نیستن و خیلی ازشون استفاده نمیشه یا اینکه خیلی قدیمی هستن. باید سعی کنید تا اونجایی که می تونید و زمان اجازه میده طوری برنامه رو طراحی کنید که توی این مرورگرها به درستی نشون داده بشه. خیلی از شرکتها هستن که از مرورگرهای قدیمی استفاده می کنن و روند به روز رسانی توشون خیلی کند پیش میره. اونها رو از دست ندید.
خوشبختانه این موضوع هم چیز سختی نیست. یه کم نیاز به کار و حوصله داره. استاندارهای CSS و HTML در دسترس هستند و با یه کم کار کردن می تونید این موضوع رو کنترل کنید. یه نکته ی نهایی رو هم بگم. فکر نکنید توی روند توسعه مجبورید وب سایت رو هر دفعه توی همه ی مرورگرها چک کنید. این کار خیلی وقت گیره. به جاش می تونید هر چند روز یه بار مرورگر رو تغییر بدید و اینجوری خطاهای احتمالی رو همون اول کار پیدا کنید و رفع کنید.
منبع وبسایت پرووید
اشتباه شماره 9: عدم پشتیبانی از قابل حمل بودن
قابل حمل بودن (Portability) برنامه های تحت وب هم بسیار مهم هستن. خیلی وقتها دیده شده که برنامه نویس ها از Connection String هایی استفاده می کنن که به صورت دستی توی کدها نوشته شده، مسیر عکس هایی که دستی نوشته شده و خیلی کارهای اینجوری. این کارها اصلاً درست نیست چون وقتی برنامه در سرور مستقر میشه و محیط توسعه ی برنامه (سیستم محلی شما) با سیستم سرور عوض میشه همه چیز به هم میریزه.
لطفاً سعی کنید از فایل Web.config برای ذخیره کردن چیزهایی شبیه Connection String ها استفاده کنید. به هیچ وجه فرض نکنید که سیستم سرور دقیقاً شبیه سیستم محلی شماست. خیلی وقتها یادم میاد که برنامه هایی می دیدم که روی سیستم طرف به درستی کار می کرد ولی وقتی برای من میفرستاد از کار می افتاد. دلیلش هم این بود که آدرس بانک اطلاعاتی رو زده بود درایو و فولدر سیستم شخصی خودش و یا اینکه فرض کرده بود چون خودش یه اسمبلی خاصی رو روی سیستمش داره پس منم دارم. لطفاً مواظب اینجور فرضیات نادرست باشید. همه ی این فرضیات قابل حمل بودن رو زیر سوال میبره.
منبع وبسایت پرووید
اشتباه شماره 10: عدم استفاده از آخرین به روز رسانی ها
توی ساخت برنامه های تحت وب تکنولوژی های زیادی مورد استفاده قرار می گیرند، HTML، CSS و jQuery بعضی از اونا هستن. اول اینو بگم که روی وبسایت پرووید برای همه ی اینا آموزش ویدئویی در نظر گرفته شده، و دوم اینکه سعی کنید از آخرین نسخه های این تکنولوژی ها استفاده کنید. از HTML 5 استفاده کنید و از قابلیت ها و تکنیک های جدید که توش ارائه شده باخبر بشید. از قابلیت های CSS 3 استفاده کنید. در مورد jQuery اینو بگم که اگر از nuget استفاده کنید به راحتی می توانید آخرین نسخه شو به برنامه تون اضافه کنید. (اگر نمی دونید nuget چیه بسته ی آموزش تصویریش توی وبسایت پرووید منتظر شماست.) توی به روز رسانی هایی که برای تکنولوژی ها انجام میشه خیلی موضوع ها در نظر گرفته میشه. بهبودهایی هم بدون شک انجام میشه. به عنوان یه توسعه دهنده سعی کنید خودتون رو ملزم کنید که همیشه از جدیدترین ابزارها استفاده کنید.
منبع وبسایت پرووید
کلام آخر تا اینجای کار حرف ما تموم شد، ولی فکر نکیند که اشتباهات رایج در ساخت برنامه های تحت وب به همین ده تا محدود میشه. سعی کردیم مهم ترین ها رو اینجا مطرح کنیم. خیلی از چیزها با تجربه کردن به دست میاد. البته تجربه کردن هر چیزی هم یه سری غرامت هایی داره. هدف ما این بود که شما رو از ده تا اشتباه رایج باخبر کنیم و امیدوار باشیم دچار اونها نشید. امیدواریم که این آموزش هم براتون مفید بوده باشه. راستی برای یادگیری برنامه نویسی با ویدئوهای فارسی به وبسایت پرووید بیاین. یا حق.
منبع وبسایت پرووید