کد پاک – قسمت 1

Summarize this content to 400 words in Persian Lang
این یک مقاله از سری 6 قسمتی در مورد Clean Code است. من از ویدیوی (YT) از رابرت سی مارتین با نام مستعار عمو باب به عنوان مرجع استفاده کردم. اگر می‌خواهید در هر موضوعی که در اینجا بحث می‌شود غواصی کنید، لطفاً به ویدیو و/یا کتاب «کد پاک اثر رابرت سی. مارتین» مراجعه کنید.

حالا بیایید شروع کنیم.

چرا باید به Clean Code اهمیت دهید؟

وقتی با هم تیمی های خود روی پروژه ای کار می کنید یا روی یک پروژه متن باز کار می کنید، کد پاک مانند یک پروتکل ارتباطی کاملاً تعریف شده عمل می کند. شما می خواهید کدی بنویسید که نه تنها توسط ماشین، بلکه توسط برنامه نویسان همکارتان قابل درک باشد. رایانه می تواند 10 هزار خط کد را درک کند (اگر از نظر نحوی درست نوشته شود) حتی اگر آن را در یک خط بدون فاصله قرار دهید، اما شرط می بندم که همتایان شما برای درک آن مشکل خواهند داشت. کد پاک اشکال زدایی، خواندن کدها (که بیشتر از نوشتن در نرم افزار Egeering انجام خواهید داد)، شاید آموزش؟ و غیره را بسیار آسان تر و کارآمدتر می کند.

به هر حال Clean Code چیست؟

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

قوانین عملکرد

یک تابع باید از 4 تا 20 خط کوچک باشد. فقط یک کار را باید انجام دهد. چگونه متوجه می شوید که یک تابع بیش از یک کار را انجام می دهد؟ اگر تابعی را می بینید و می توانید تابع دیگری را از آن استخراج کنید، آن تابع اصلی بیش از یک کار را انجام می داد. شما باید به استخراج توابع از یکدیگر ادامه دهید تا زمانی که استخراج بیشتر منطقی نباشد. هر تابع باید یک نام مناسب داشته باشد و باید بخشی از کلاس ها و ماژول های مناسب (برنامه نویسی تابعی؟) باشد.

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

آرگومان ها/پارامترهای تابع

تابع چند آرگومان باید بگیرد؟

یک تابع نباید بیش از 3 آرگومان داشته باشد (قانون نرم). هر چیزی بیش از سه باید یک شی باشد.

در صورت امکان باید از ارسال یک Boolean به توابع اجتناب شود. چرا؟

زیرا زمانی که شما یک بولین را برای عملکرد ارسال می کنید، به احتمال زیاد a وجود خواهد داشت if/else عبارت در آن تابع و کد در if/else بلوک را می توان به عنوان دو تابع مختلف استخراج کرد.

اجتناب کنید switch بیانیه ها

switch دستورات برای موارد مجموعه های کوچک، محدود و به خوبی تعریف شده عالی هستند، مانند تجزیه دستورات یا گزینه ها، اما اگر ماژول های مختلف را در دستورات سوئیچ خود فراخوانی می کنید، می توانند به یک مشکل دردناک مدیریت وابستگی تبدیل شوند.

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

اصل بسته-باز – موجودیت‌های نرم‌افزار (مانند کلاس‌ها، ماژول‌ها و توابع) باید برای توسعه باز باشند اما برای اصلاح بسته باشند.

بدون عوارض جانبی

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

چند نمونه از توابع عوارض جانبی می تواند باشد open() و new در C++ این توابع عوارض جانبی به صورت جفتی مانند باز کردن/بستن، جدید/حذف، کسب/آزادسازی و غیره ارائه می شوند.

یعنی نباید از این توابع استفاده کنیم؟ البته اگر به زبان C/C++ بنویسید از آنها استفاده خواهید کرد، اما نکته مهم در اینجا این است که مطمئن شوید که آنها را به درستی مدیریت می کنید. به همین دلیل است که برخی از زبان‌های برنامه‌نویسی با مجموعه Garbage برای جلوگیری از نشت حافظه ارائه می‌شوند، اما هنوز هم در بیشتر موارد باید بسیاری از موارد را با دست مدیریت کنید.

اما عوارض جانبی تنها به روش‌ها/توابع داخلی زبان محدود نمی‌شود، ما می‌توانیم به راحتی آن‌ها را معرفی کنیم و در هنگام اشکال‌زدایی یا هنگام تلاش برای درک کد شخص دیگری، متضرر شویم. به عنوان مثال، ما int userId ممکن است به راحتی یک شناسه کاربری را در پایگاه داده وارد کرده و آن را برگرداند. چگونه از آن اجتناب کنیم؟ پاسخ: جداسازی فرمان و پرس و جو.

Command and Query Separation (CQS) یک اصل طراحی نرم‌افزار است که بیان می‌کند که یک متد (یا تابع) یا باید یک عمل (یک فرمان) را انجام دهد یا داده‌ها (یک پرس و جو) را برگرداند، اما نه هر دو.

خوب همین است، اما برای اعمال مدیریت مناسب منابع/معاملات مانند خواندن از یک فایل و بستن آن، اتصال به پایگاه داده و بستن اتصال، ارائه درخواستی که می تواند دو یا چند حالت را تغییر دهد و غیره چه کاری می توانید انجام دهید؟ پاسخ: رسیدگی به استثناشما می توانید یک finally بلاکی که منبع را آزاد می کند یا می تواند پاکسازی را برای شما انجام دهد اگر نمی خواهید یک درخواست تکمیل شود و غیره. اما از داشتن یک سری کد قبل از بلوک try و کد بعد از بلاک جز/نهایتاً خودداری کنید. تابع/روشی که این منطق مدیریت استثنا را دارد فقط باید توابع/روش هایی را فراخوانی کند که می توانند پرتاب شوند. همچنین، هرگز از بلوک‌های تودرتو امتحان/گرفتن استفاده نکنید.

خشک

خودت را تکرار نکن

IG بسیار خود توضیحی؟ فقط سعی کنید از تکرار کد در همه جا جلوگیری کنید. کدهای مکرر را در توابع (در صورت نیاز، آرگومان ها را ارسال کنید) و ماژول ها را جابجا کنید.

کد خود را تست کنید

از کجا متوجه می شوید که کدی که نوشته اید خراب نمی شود؟ خوب، من ویژگی را تست کردم و کار می کند.

اما اگر در مجموعه‌های مختلف استدلال‌ها/موقعیت‌ها شکست بخورد یا رفتار متفاوتی داشته باشد، چه؟ اگر نوع داده صحیح انتخاب نشده باشد یا رشته های بیشتری در آرایه رشته با اندازه ثابت خود داشته باشید، یک عملیات حسابی ساده می تواند سرریز شود، چه؟ تغییرات/اضافات کوچک یا بزرگ به نرم افزار می تواند سیستم را خراب کند یا می تواند گلوگاهی در خط لوله باشد و ممکن است مجبور شوید ساعت 3 صبح بیدار شوید تا آن را برطرف کنید یا پشتیبان بگیرید و می تواند روی مشتریان تأثیر بگذارد.

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

–برای این مقاله تمام شد. Lmk اگر چیزی نادرست است یا گم شده است. متشکرم.