تو این چند سال با خیلیا کار کردم، دولوپرای فرانت اند، بک اند و فول استک ها
خیلی از مشکلاتی که بهشون برخورد کردم شبیه هم بودن و حتی منم هر از گاهی قربانی این اشتباهات شدم. تو این مقاله سعی دارم این اشتباهات رایج رو با شما در میون بذارم.
تقریبا همه ما با این اشتباه مواجه شدیم. خیلی از برنامه نویسا برای تحویل یه پروژه ساده، درگیر پیاده سازی امکاناتی میشن که انگار قراره این پروژه میلیون ها کاربر داشته باشه و ویژگی های بهش اضافه می کنن که توی اون مقطع هیچ احتیاجی به اونا نیست. این اشتباه یه سری عواقب داره. پیچیدگی بیش از حد پروژه، طولانی تر شدن زمان پیاده سازی، عقب افتادن زمان تحویل پروژه و انجام تست های بیشتر از جمله اونان.
به جای این کار سعی کنید به همون تسکی که دستتونه فکر کنید، نه این که این پروژه بعدها قراره به کجا برسه. وقتی که کاربرا شروع به استفاده از اپ شما کردن وقتشه که به فکر اضافه کردن ویژگی هایی باشید که باعث بهتر شدن اپتون میشه.
وقتی که میخواین شروع به پیاده سازی یه پروژه کنین، انتخاب مناسب ابزار خیلی نکته مهمیه. سعی کنین ابزاری رو انتخاب کنین که مطمئن و تست شده باشه و صرفا نیازی که دارین رو برطرف کنه. دقت کنین که پروژه شما قراره قابلیت هایی که ازش انتظار دارین رو برآورده کنه، پس از انتخاب ابزارایی که به دردتون نمیخوره پرهیز کنین. ممکنه حین انتخاب اونا با خودتون بگین تا وقتی که پروژم تموم بشه نسخه نهاییش ریلیز میشه پس فعلا کارمو با همینی که کامل کار نمی کنه ادامه بدم، یا بگین این ویژگیی که میخوام قطعا تا چند ماه دیگه بهش اضافه میشه. اگه این اتفاق افتاد بدونین که مسیر رو اشتباه میرین.
برای انتخاب ابزار مناسب به چنتا نکته باید دقت کنین، بازه های آپدیت شدن، تعداد open issue ها و تعداد افرادی که روش کار می کنن ازین موارد هست. اصولا ابزاری که خیلی وقته کسی براش آپدیت نداده یا توسط یه نفر پیاده سازی میشه گزینه خوبی برای انتخاب نیستن.
خیلی از زبونای برنامه نویسی راه های مشخصی برای قفل کردن نسخه ابزارها دارن و نسخه ای که احتمالا شما میخواین روش قفل بشه آخرین نسخه major اون هست. بعد ازین کار شاید ده ها نسخه جدیدتر ازون ابزار ریلیز بشه ولی وقتی کارتون با همون نسخه ای باهاش کار می کنین را میفته نیاز به آپدیت نیست. بنابراین وقتتون رو صرف آپدیت های بیخود نکنید و به جاش تمرکزتون رو روی پروژه بذارین.
اگر از فریم ورک استفاده می کنین، قطعا راه هایی برای حل مشکلاتی که باهاشون مواجه میشین وجود داره. خیلی از راه حل هارو دیدم که میتونست خیلی راحت تر از طریق helper هایی که خود فریم ورک در اختیارمون قرار میده انجام بگیره. برای اینکه این راه حل هارو بهتر بشناسیم، قبل ازینکه شروع به انجام یه تسک کنین، حتما مشکلات احتمالی رو از documentation فریم ورک بررسی کنین. از اینکه وارد کدای فریم ورک بشین ترسی نداشته باشین. ممکنه اوایل فهمیدن اونا یه مقدار سخت باشه، ولی این کار نه تنها باعث کامل تر شدن درک شما از فریم ورک میشه بلکه با دیدن کدایی که توسط افراد باتجربه تر نوشته شده باعث افزایش مهارت شما میشه.
نکته دیگه در مورد IDEییه که استفاده می کنین. مطمئن شید برای زبونی که باهاش برنامه نویسی می کنین بهترین IDE رو انتخاب کرده باشین. چون یاد گرفتن shortcutها و code snippetهاش میتونه تاثیر زیادی رو سرعت کدنویسیتون داشته باشه. حتی بهتره بعد از یه مدتی code snippetهای مخصوص به خودتون رو داشته باشین تا مواقعی که بهشون نیاز دارین به راحتی بتونین ازونا استفاده کنین.
و از همه مهمتر اینه که debug کردن رو به خوبی یاد بگیرید. اینکه برای چک کردن مقدار یه متغییر اونو تو خروجی چاپ کنین یا با گذاشتن یه علامت مطمئن شین که کدتون وارد یه بلاک بخصوص میشه یا نه debug کردن نیست. اگر انجام اینکار باعث حل مشکل تو مدت کوتاهی میشه مشکل خاصی نداره ولی اگه قراره بیشتر از یه دقیقه طول بکشیه حتما از debugger استفاده کینن. با این کار میتونین مقادیر همه متغیرهاتون رو به راحتی بررسی کنین و مسیرهای احتمالیی که کدتون طی می کنه رو در نظر بگیرین.
کامنت به درد نخور چه کامنتیه؟ کامنتیه که هیچ اطلاعات اضافیی بهمون نمیده.
مثلا اگر قرار باشه برای یه متد با اسم FetchExtractProcessData کامنت بذارین چی مینیویسین؟ اگر نوشته باشین این متد مسئول Fetch و Extract و Process کردن دیتاست، کامنت خوبی ننوشتین. چون نه تنها هیچ توضیحی نمیده حتی ممکنه بیشتر گیجمون کنه.
از مثال های دیگه کامنت به دردنخور، کامنت هایی هستن که بعد از تغییر کد، آپدیت نشدن و باعث میشن اطلاعات درستی ندن. یا حتی کامنت هایی که مشکل گرامری دارن و اگه کسی اونارو بخونه هیچی ازشون نفهمه.
پس یادتون باشه، اگر دارین کامنتی میذارین که بود و نبودش هیچ فرقی به حال بقیه نمی کنه بهتره اصلا ننویسینش.
تو قسمت قبلی متدی رو مثال زدم که اسمش این بود: FetchExtractProcessData
اگر شما هم متدهاتون رو مثل این متد نامگذاری می کنین بدونین کدتون به هیچ وجه خوانا نیست. چون هیچ توضیحی در مورد علت اصلی وجود این متد و کارکرد نهاییش نمیده و صرفا چنتا فعله که پشت سر هم چیده شده. خیلی مهمه که متدها، کلاس ها و متغیرهاتون جوری نامگذاری بشن که هم بامفهوم باشن و هم کسی که اونارو میبینه با یک بار خوندنش اطلاعات خوبی نسبت بهش بدست بیاره. هیچ وقت از اختصار یا از کلمات پیچیده استفاده نکنین و به جاش سعی کنین به زبون ساده توضیحش بدین، ولی سعی کنید این اسامی از 4 یا 5 کلمه بیشتر نشن. حتما از Code Linter مخصوص به IDEتون برای مرتب و تمیز بودن کدهاتون استفاده کنین و قبل شروع کار با زبون جدید حتما الگوهای نوشتاری استاندارد مخصوص به زبونتون رو چک کنین.
این سوال همیشه بین برنامه نویسا بوده که کودوم سمته که کار مهمتر رو انجام میده. جواب من اینه که فرانت اند مهمتره. نیاز نیست وقتی یه پروژه رو شروع کردین نگران Caching, Performance یا Optimization بک اند باشین، چون قرار نیست از همون اول میلیون ها کاربر از اپتون استفاده کنن. خودتون به اپ هایی که هر روز باهاشون کار می کنین دقت کنین. دلیل اینکه باعث شده شما ازونا خوشتون بیاد چیه؟ این که از آخرین تکنولوژی استفاده می کنن؟ این که همه متدهاشون در بهینه ترین حالت ممکنه؟ مسلما این طور نیست. دلیلش اینه که نحوه ارائه محتوا به شکلیه که احساس خوبی بهتون میده و استفاده ازونا به هیچ وجه گیج کننده و خسته کننده نیست. البته معنی حرفم این نیست که بک اند مهم نیست. مطمئن باشید اگه فرانت به بهترین شکل خودش باشه ولی بک اند مشکل داشته باشه قطعا باعث شکست پروژه میشه.
نکته ای که از همه مهم تره اینه که وقتتون رو صرف کارایی که فقط خودتون یا تعداد خیلی کمی از کاربرا ممکنه متوجهش بشن نکنین. به پروژه به عنوان یه محصول نگاه کنین، محصولی که قراره کاربرا رو جذب خودش کنه. پس از هدر دادن وقتتون روی کارایی که هیچ تاثیری توی ادامه مسیر پیشرفتتون ندارن پرهیز کنید.
خیلی مهمه افرادی که قراره با اپتون کار کنن رو به خوبی بشناسین و تجربه کاربریتون، بر همین اساس طراحی بشه. جملاتی رو استفاده نکنین که فقط یه دولوپر میتونه اونارو بفهمه. جملاتی مثل "خطای سیستمی" یا "خطا در شبکه" یا حتی نشون دادن exceptionهای کدتون اصلا خوب نیستن و کاربراتون رو فراری میده. از جملات کامل، بامفهوم و ساده استفاده کنین. همین موضوع باعث میشه اونا در مقایل دیدن یه سری ازین خطاها حس بدی نگیرین و به کارشون تو اپ ادامه بدن. به عنوان مثال وقتی کاربر تو اپتون لاگین میکنه به جای نشون دادن "لاگین موفقیت آمیز" میتونین جمله ای رو نشون بدین که حس تعاملی بهتری به کاربر بده.
خیلیا از خودشون میپرسن چجوری میشه برنامه نویس حرفه ای شد؟ این اتفاق نمی تونه یه شبه رخ بده. حرفه ای شدن تو انجام دادن تسک های روزانمون اتفاق میفته، تو نوع نگاهمون به حل مشکلاتی که اغلب مواقع با اونا موجه میشیم. سعی کنید وقتی یه تسکی رو انجام میدین به بهترین شکلش انجام بدین و صرفا انجام دادنش براتون مهم نباشه. برای درک بهتر این موضوع به پروژه هایی که تا حالا انجام دادین فک کنین. آیا انجام دادن اونا تو پیشرفت و رسیدن به نقطه فعلیتون تاثیر مثبت داشته؟ یا صرفا یه کار تکراری بوده مثل بقیه پروژه های قبلیتون؟
سعی کنید نکاتی که گفته شد رو حین انجام پروژه با خودتون مرور کنید تا کدزنی روز به روز براتون لذت بخش تر بشه.
یادتون نره برنامه نویسی هیچ وقت نباید تکراری و عادی بشه.
نسخه صوتی همین مقاله تو قسمت دوم پادکست کافه برنامه نویس وجود داره:
از طریق لینک های زیر هم میتونین این پادکست رو دنبال کنید:
