اشتباهات رایج برنامهنویسی که تقریباً همه ما تجربه کردهایم
اگر چند سالی برنامهنویسی کرده باشید، احتمالاً به این نتیجه رسیدهاید که سختترین بخش کار، نوشتن کد نیست؛ بلکه نوشتن کدی است که بعداً قابل فهم، قابل نگهداری و قابل توسعه باشد.
واقعیت این است که اکثر مشکلات پروژهها نه از تکنولوژی، بلکه از اشتباهات رایج در شیوه کدنویسی به وجود میآید. جالبتر اینکه بسیاری از این اشتباهات را تقریباً همه برنامهنویسها در مقطعی از مسیرشان انجام دادهاند.
بیایید چند مورد از رایجترین آنها را مرور کنیم.
اولین اشتباه: نوشتن کد برای «الان» به جای «آینده»
خیلی وقتها فقط میخواهیم یک فیچر سریع پیادهسازی شود و کار راه بیفتد. در نتیجه کدی مینویسیم که فقط در همان لحظه کار میکند اما بعد از چند ماه تبدیل به کابوس نگهداری میشود.
برنامهنویسی حرفهای یعنی همیشه از خودمان بپرسیم:
«اگر شش ماه بعد دوباره به این کد برگردم، فهمیدنش راحت خواهد بود؟»
کدی که خوانا نباشد، دیر یا زود هزینه خودش را از تیم میگیرد.
اشتباه دوم: متدها و کلاسهای غولپیکر
یکی از نشانههای کد ناسالم، متدهایی است که چند صد خط کد دارند و چندین کار مختلف انجام میدهند.
در طراحی تمیز، هر متد باید یک مسئولیت مشخص داشته باشد. اگر یک متد هم داده میگیرد، هم اعتبارسنجی میکند، هم ذخیره میکند و هم لاگ مینویسد، احتمالاً چند مسئولیت مختلف در یک جا جمع شدهاند.
اصل Single Responsibility دقیقاً برای جلوگیری از همین وضعیت است.
اشتباه سوم: نامگذاری ضعیف
نام متغیرها و متدها شاید در نگاه اول موضوع کوچکی به نظر برسد، اما در عمل یکی از مهمترین عوامل خوانایی کد است.
متغیری با نامهایی مثل:
data
temp
obj
value
تقریباً هیچ اطلاعاتی به خواننده کد نمیدهد.
در حالی که نامهایی مثل:
userEmail
orderTotalPrice
isPaymentSuccessful
بلافاصله منظور کد را منتقل میکنند.
نامگذاری خوب یعنی کد شما تا حد زیادی خودش را توضیح بدهد.
اشتباه چهارم: کپیپیست کد
یکی از وسوسههای همیشگی برنامهنویسها این است که وقتی یک تکه کد جواب میدهد، آن را در چند جای دیگر هم کپی کنند.
مشکل اینجاست که وقتی بعداً لازم باشد آن منطق تغییر کند، باید همه نسخههای کپیشده را پیدا و اصلاح کنیم.
این دقیقاً همان چیزی است که اصل DRY (Don't Repeat Yourself) سعی میکند از آن جلوگیری کند.
اگر کدی در چند جا تکرار شده، احتمالاً باید آن را به یک متد یا سرویس مستقل تبدیل کرد.
اشتباه پنجم: بیتوجهی به ساختار پروژه
گاهی پروژهها به مرور زمان تبدیل به مجموعهای از فایلها و کلاسهایی میشوند که ساختار مشخصی ندارند.
در چنین شرایطی، پیدا کردن محل مناسب برای اضافه کردن یک قابلیت جدید سخت میشود.
استفاده از معماریهای شناختهشده مثل Clean Architecture یا Layered Architecture کمک میکند پروژه ساختار قابل پیشبینیتری داشته باشد.
در این حالت هر بخش از سیستم مسئولیت مشخصی دارد و تغییرات راحتتر مدیریت میشوند.
در نهایت باید قبول کنیم که اشتباه در برنامهنویسی اجتنابناپذیر است. هیچ توسعهدهندهای از روز اول کد تمیز نمینویسد.
اما چیزی که یک برنامهنویس حرفهای را از بقیه جدا میکند، این است که دائماً به کدهای گذشته خودش نگاه میکند، از آنها درس میگیرد و سعی میکند هر بار کمی بهتر از قبل کد بزند.
چون در نهایت، برنامهنویسی فقط حل مسئله نیست؛
بلکه ساختن سیستمی است که دیگران هم بتوانند آن را بفهمند و ادامه دهند.
