بیشتر توسعهدهندگان پس از چندین سال کدنویسی، با یک دیوار بدون شکاف غیرقابلعبور مواجه میشوند. عبور از این دیوار همان چیزی است که توسعهدهندگان متوسط را از کدنویسان متخصص که برنامههای کاربردی واقعی مینویسند، جدا میکند؛ اما تعداد زیادی هم هستند که فقط سر خود را به دیوار میکوبند بدون اینکه هیچ امیدی برای عبور از آن داشته باشند.
اگر شما احساس میکنید که برای شروع ساخت یک برنامه کاربردی واقعی آماده هستید، باید یادبگیرید کدی بنویسید که قابل پشتیبانی، قابلاستفاده مجدد و قابلآزمایش باشد. بسته به اینکه چقدر فرد مستعدی هستید، این پروسه از چندین ماه تا سال و حتی دهه طول میکشد؛ اما با استفاده از این 5 نکتهای که ما برای کدنویسی بهتر در اینجا ارائه کردیم، همینالان میتوانید مهارت کدنویسی خود را ارتقا دهید.
کدتان را قابلخواندن کنید
نوشتن کد جدید سخت است، اما تلاش برای درک کد ضعیفی که توسط شخص دیگری نوشته شده است، میتواند مثل یک کابوس شبانه باشد. بیش از چندین سال است که توسعهدهندگان بر قراردادهای قطعی کدنویسی تسلط دارند، بیشتر آنها در قالب استانداردهایی مثل Zend Framework Coding Standard ،PSR-1 & PSR-2 و یا Google's Style Guides کدنویسی شدهاند.
استانداردهای کدنویسی هرچیزی را از دندانهگذاریهای مناسب گرفته تا استفاده از فضاهای سفید و نامگذاری متغییرها و تعاریف را پوشش میدهند. هدف آنها کمک به توسعهدهندگان است که بتوانند کدی بنویسند که ساختاری خوب و امکان پشتیبانی آسانی داشته باشد و قابلخواندن باشد.
برای مثال، آنها گاهی استفاده از اسامی توصیفنشده را برای متغیرها ممنوع میکنند و روی اهمیت استفاده از اسامی معنیدار مثل tempStatus$ یا myHeaderDiv$ تأکید میکنند.
برای آنکه کد قابلخواندن باشد، باید بهصورت مناسب تعریف بشود. نوشتن کامنت مفید ازآنچه به نظر میآید، دشوارتر است. توسعهدهندگان تمایل دارند که فهرستی از مفروضات را بنویسند و اغلب انتظار دارند که دیگران همهچیز را درمورد کد آنها بدانند؛ که احتمالاً آنها هم نمیتواند بدانند.
از طرف دیگر، توسعهدهندگان معمولاً فقط مبهمترین قسمتها را کامنتگذاری میکنند چون میترسند که دیگران آنها را برای توضیح واضحات مورد تمسخر قرار دهند.
بااینکه مدتزمان زیادی طول میکشد، اما بردباری و تلاش برای یادگرفتن هنر کامنتنویسی، یک مهارت ضروری است که هر توسعهدهندهای باید برای نوشتن کد بهتر و متخصص شدن در این زمینه، کسب کند.
از متغیرهای global (سراسری) پرهیز کنید
بیایید زمانی را مثال بزنیم که شما یک برنامه کاربردی ساده با یک لاگین برای ورود میسازید و میدانید که باید نام کاربری کاربر را در چندین موقعیت مختلف نمایش دهید. شما احتمالاً با این مشکل در زوایای مختلف مواجه شدهاید، اما ساختن یک متغیر global بهطور قابلبحثی مسیری با کمترین مقاومت است.
مشکل این است که متغیرهای global مانند بمب ساعتی هستند که میتوانند با یک اشتباه کوچک منفجر شوند و کل پروژه شما را تا مدت زیادی غیرقابل اجرا کنند.
ازآنجاکه متغیرهای global بهخودیخود همهجا در دسترس هستند، ممکن است زمانی که فکر میکنید از یک متغیر local (محلی) استفاده کردهاید درواقع از متغیر جهانی استفاده کرده باشید و یا برعکس. متغیرهای global هم بهطور قابلملاحظهای روند تست را پیچیده میکنند و هم درک کدها را دشوار میسازند.
البته مواردی هم وجود دارد که استفاده از متغیرهای global دلیل منطقی دارد مثل زمانی که یک افزونه ساده مینویسید یا زمانی که با زبانی کار میکنید که از متغیرهای local خیلی کم پشتیبانی میکند، اما اینها موارد استثنایی هستند.
بهطورکلی اگر که میخواهید کد بهتری بنویسید و به خاطر عادات خوبی که دارید همواره مورد تحسین دیگران قرار بگیرید، باید از متغیرهای global تا جایی که ممکن است، پرهیز کنید.
کدهای دیگران را بخوانید تا کد بهتری بنویسید
کدنویسی درنهایت برای حل چالشهای بوجود آمده است و بهندرت پیش میآید که تنها یک راه برای حل یک چالش خاص وجود داشته باشد. در بیشتر موارد مشکل مشابه میتواند از زوایای مختلفی ایجاد شود و معمولاً تصمیمگیری درمورد اینکه کدامیک از راهحلهای ممکن بهتر است، دشوار میباشد.
اگر کدنویسی شغل شماست، احتمالاً از اولین راهحلی که به ذهنتان میآید استفاده میکنید و زمان کافی برای پیداکردن راهحل بهتر ندارید. به همین دلیل بسیار مهم است که کد دیگران را در اوقات فراغتتان بخوانید.
وقتیکه شما کد دیگران را میخوانید، میتوانید ببینید که یک شخص دیگر چگونه مشکلی را که شما از یک زاویه کاملاً متفاوت به آن نگاه کرده بودید، حل کرده است.
بههرحال، مهم است که به خاطر داشته باشید همانطور که خواندن کد دیگران یک راه عالی برای کدنویسی بهتر است، کپی کردن کد دیگران راه خوبی نیست. درواقع کورکورانه پذیرفتن راهحلهای دیگران میتواند مانع رشد شما شود که شما قطعاً این را نمیخواهید.
از پروسه اصلاح کد استقبال کنید
بیشتر نویسندگان از خواندن کار خودشان نفرت دارند و بیشتر توسعهدهندگان از دوباره نوشتن آنچه قبلاً روی آن کارکردهاند بیزارند. اگرچه پروسه اصلاح کد یا ریفکتور کردن کدهای کامپیوتری موجود بدون تغییر رفتار خارجی آنها کار جذابی نیست، اما خیلی ضروری میباشد.
Joshua Kerievsky نویسنده «اصلاح الگوها» میگوید: «با بهبود مداوم کد، ما کارکردن با آن را آسان و آسانتر میکنیم. این کاملاً در تضاد با چیزی است که معمولاً اتفاق میافتد: میزان کمی از اصلاحات و توجه زیادی به اینکه ویژگیهای جدید به طرز مناسبی افزوده شده باشند. اگر انجام مداوم اصلاحات برای شما به یک عادت تبدیل شود، متوجه میشوید که این کار از توسعه و پشتیبانی کد کار راحتتری است.»
اصلاح کد یک موضوع خیلی مهم است اما نقش ضروری آن در این است که شما باید همیشه سعی کنید توابع و روشهای بزرگ را به بخشهای کوچکتر تقسیم کنید. اگر توابع شما بیشتر از 25 خط باشند، یک فرصت خوب است که آن را به دو و یا حتی سه تابع کوچکتر تقسیم کنید و بهاینترتیب قابلیت خواندن کد خود را افزایش دهید.
از مزیتهای VCSها کمک بگیرید
زمانی که جاوااسکریپت بهعنوان یک زبان کوچک درنظر گرفته میشد، پیگیری تغییرات در فایلهای کامپیوتری و هماهنگ کردن کارها روی آن پروندهها بین افراد مختلف، دو کار بسیار دشوار بود. خوشبختانه از آن زمان تا امروز همهچیز بهطور چشمگیری تغییر کرده است و version control software پیگیری روند تغییرات را در هر مجموعه فایلی بسیار آسان کرده است.
از Git تا Fossil تا Mercurial تعداد زیادی نسخه عالی از version control software بهعنوان راهحل، امروزه در دسترس هستند و تمام توسعهدهندگانی که میخواهند بهتر کدنویسی کنند، باید از آنها برای بهبود جریان کاری خود استفاده کنند. در اینجا که مقایسه همراه با جزئیات از version control software بیان شده است، میتوانید نکات خوبی برای شروع پیدا کنید.
نتیجهگیری
کد خوب کدی است که بهصورت مطلوبی قابل پشتیبانی و استفاده مجدد باشد درحالیکه کد بد کدی است که همهچیز را پیچیده میکند و کدنویس آن بدنام میشود. اگر شما میخواهید کد بهتری بنویسید و توسعهدهندهای شوید که مورد تحسین همگان است، باید جاده طولانی پیش رویتان را طی کنید اما این 5 نکتهای که ما به آنها اشاره کردیم یک نقطه خوب برای شروع است.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید