چگونه يك كد تميز بنويسيم؟

در طول اولین دوره کارآموزی ام، از من سؤال شد که آیا کتاب « کد تمیز» اثر روبرت سی.مارتین را خوانده ام یا نه. من هیچ نظری در رابطه با این کتاب نداشتم اما بعداً نظرم تغییر کرد و اعتقاد پیدا کردم که هر توسعه دهنده ای باید آن را بخواند.

در اولین کارم به عنوان یک توسعه دهنده، من باید روی یک برنامه ای که از شرکت دیگری خریداری شده بود، کار می کردم. این برنامه خیلی درهم و برهم بود به طوری که چندین روز از وقتم را گرفت تا سر از برخی کارکرد های آن در بیاورم. همکار دیگرم بعد از اینکه نگاهی به برنامه انداخت آن را کنار گذاشت و از من خواست روی پروژه ی دیگری کار کنم.

هر وقت با گیت هاب کار می کنم، می توانم اسم توسعه دهندگان آن برنامه را ببینم. هرگز آن ها را به هیچ کس معرفی نمی کنم.

بعداً، به عنوان بخشی از مراحل جذب شغلی که الان به آن مشغولم از من خواسته شد که یک کار کوچکی را کد بزنم. من به سختی کار می کردم. سعی می کردم که کدم بهترین کارکرد را داشته باشد. توسعه دهنده ای که کارم را باید ارزیابی می کرد، بعداً به من گفت که کدم را چک نکرده است. او فقط متوجه شده بود که من « README.md » را نوشته ام و اینکه اسم کلاس ها و متغیر ها خیلی ساده و قابل فهم بود. من آن کار را گرفتم!

در این مقاله من نکات کوتاهی را بیان می کنم که از نظر نظم و ترتیب برای نوشتن یک کد خوب خیلی مهم هستند.

1. ساختار

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

2. نام گذاری

ممکن است بگویید که این مطلب واضح است و هر فردی می داند که انتخاب نام خوب برای کلاس ها، متدها و متغیر ها خیلی مهم است. بلکه، شاید! اما وقتی کدی را می نویسید، این مطلب را فراموش نکید که شما همیشه می نوانید RspValidation.java را به ResponseValidation.java یا print() را به printResponse() تغییر دهید. نام متغیرها باید مناسب با هدف و کاری باشد که انجام می دهند. امیدوارم که هرگز String asd را در برنامه هایم نبینم.

پیدا کردن نام ها و کلمات صحیح و مناسب برای کدتان، به عدم نیاز برای توضیحات اضافه در مورد کدتان کمک می کند. همچنین من پیشنهاد می کنم که برای متد هایی که ممکن است ما را به اشتباه بیاندازند یا مواقعی که پیاده سازی استاندارد نیست، از توضیحات استفاده شود.

فراموش نکنید که از مدل « Camel Cases» برای کدهای جاوا استفاده کنید. اسم کلاس ها با حروف بزرگ شروع شود!

3. حل یک مشکل خاص

اگر اسم کلاستان «ResponseValidator.java» است، مطمئن شوید که این کلاس فقط مسئول پاسخ دادن به اعتبار سنجی است. و کار دیگری انجام نمی دهد. اگر شما می خواهید چیز دیگری اضافه کنید، کلاس دیگری ایجاد کنید یا اسم کلاس را تغییر دهید. این یک تمرین خوب برای داشتن صرفا یک متد عمومی در کلاس است و چیزهای دیگر « متد های خصوصی » باید برای رسیدن شما به هدفی که از ایجاد این کلاس داشته اید، کمک کند.

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

4. پارامترهای متد

از استفاده تعداد زیادی پارامتر در متد بپرهیزید. چرا که ممکن است کار کردن با متدی که دارای تعداد زیادی پارامتر است، سخت باشد. به عنوان مثال کد زیر را:

private addUserInformation(String name, String street, String houseNumber, String city, String country).

می توانیم به این صورت ویرایش کنیم:

private addUserInformation(String name, Address userAddress).

5. دوباره کاری ( موازی کاری)

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

بهترین IDEها توانایی خلاصه کردن کدها را دارند. تنها با دو کلیک ساده کد های تکراری را در یک متد مجزا خلاصه می کنند.

6. کد نویسی سخت:

از این بپرهیزید! من می دانم... وقتی عجله دارید، کد نویسی سخت خیلی راحتتر است. اما استفاده زیاد از کدنویسی سخت، کامل کردن کدها و برطرف کردن خطاها و اشتباهات را بسیار سخت می کند. تا حد امکان از کلاس های ثابت، .yml، .properties، generic ها، و هر چیز دیگری که تیمتان تایید می کنند، استفاده کنید.

7. لاگ ها ( Logs)

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

در این مقاله من مهمترین قواعدی که به تمیزی کدتان کمک می کند بیان کردم، این به نظر ساده می آید اما حتی توسعه دهندگان ارشد هم باید کدهایشان را مرور کنند. تا نسبت به قابل فهم و قابل خواندن بودن کدهایشان اطمینان کسب کنند.

درست همانند یک جواهری که از گردنبند آویزان شده، شما می توانید آن را تمیز کنید تا کامل شود امام ارزیابی شرایط پروژه و اولویت ها را فراموش نکنید.

ترجمه شده از Medium