نحوه نوشتن کد تمیز

پاک و زیبا کردن کد خود راهی عالی برای رعایت ضرب الاجل ها است.رابرت مارتین با یکی از اظهارات محتاطانه خود ضربه ای به سر زد: «تنها معیار واقعی کیفیت کد واحد What-The-F**ks/Minute است. "" در اصل). بگذارید توضیح دهم که این به چه معناست. هر بار که من کد را مرور می کنم، مغزم یکی از سه احساس زیر را طی می کند:

• "WTF؟! چه لعنتی؟!" (با انزجار) - این نیست ... همه چیز خیلی بد است ....
• "WTF؟! چه لعنتی؟!" (با تحسین) - هوم، یک پسر باهوش این کار را کرد!
• "WTF؟! چه لعنتی؟!" (با عصبانیت) - نوعی سردرگمی، ما در مورد چه چیزی صحبت می کنیم؟!

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

آنچه در یک نام است

کندریک لامار (هنرمند آمریکایی هیپ هاپ - یادداشت سردبیر) یک بار به دقت خاطرنشان کرد: "اگر قرار است داستان واقعی را بگویم، باید با نام خود شروع کنم." نام در توسعه نرم افزار همه جا وجود دارد. ما توابع، کلاس‌ها، آرگومان‌ها، بسته‌ها، برنامه‌ها - همه چیز را نام‌گذاری می‌کنیم. ما فایل های منبع و کتاب های مرجع و هر چیزی که به آن مرتبط است را نام می بریم. ما چیزها را بی پایان نامگذاری می کنیم، و این بخش مهمی از کار برای ایجاد کد پاک می شود. نامی که به چیزی می‌دهید باید هدف را نشان دهد. پیدا کردن یک نام خوب آسان نیست، زمان می برد، اما همچنین زمانی که باید با کد مقابله کنید و شرایط پیچیده می شود، در زمان زیادی صرفه جویی می کند. بنابراین مراقب این روند باشید و اگر چیزی مناسب تر پیدا کردید، بعداً از تغییر نام نترسید. همه کسانی که با کد شما سروکار دارند از شما بسیار سپاسگزار خواهند بود.

"یک عملکرد" ​​- یک چیز

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

1. آنها باید کوچک باشند
2. آنها باید یک کار، یک کار، و آن را به خوبی انجام دهند

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

"نظرات کد بد را جبران نمی کنند"

ونوس ویلیامز، تنیسور آمریکایی و قهرمان پنج دوره ویمبلدون، وقتی گفت: «همه نظرات خود را می‌گویند. اینگونه شایعات ظاهر می شوند . » کامنت ها مثل شمشیر دولبه هستند کامنت درست کار بسیار مفیدی است. از سوی دیگر، هیچ چیز بیشتر از نظرات بیهوده و بیهوده فضا را شلوغ نمی کند. اما مضرترین نظرات آنهایی است که اطلاعات نادرست و دروغ را منتشر می کنند. خلاصه اظهار نظر نوعی شر ضروری است. نه همیشه، اما در بیشتر موارد. چرا؟ ساده است، هر چه کامنت قدیمی‌تر باشد، نگهداری آن دشوارتر است و همانطور که می‌دانید اکثر برنامه‌نویسان همیشه نظرات را همراه با تغییرات در کد تغییر نمی‌دهند. کد حرکت می کند و تکامل می یابد. بخش هایی از کد به جلو و عقب منتقل می شوند، اما هیچ نظری وجود ندارد. و این یک مشکل می شود!

"قالب بندی کد همیشه در اولویت است"

این را کسی جز رابرت سی. مارتین (رابرت سیسیل مارتین)، با نام مستعار عمو باب، توسعه‌دهنده، نویسنده کتاب‌های زیادی در زمینه توسعه نرم‌افزار، مشاور، نویسنده مشترک مانیفست چابک و غیره گفته است. و افزود: قالب بندی کد نوعی ارتباط است. و ارتباط برای هر توسعه دهنده حرفه ای اولویت اصلی است. بیانیه بالا را نباید دست کم گرفت، زیرا یکی از مهم ترین ویژگی های یک توسعه دهنده عالی را نشان می دهد. کدهای فرمت شده به شما اجازه می دهد تا عمیقاً به ذهن خود نگاه کنید. ما می خواهیم مردم را با آراستگی، توجه به جزئیات، توانایی سازماندهی و بیان واضح افکارمان تحت تاثیر قرار دهیم. اما اگر وقتی مردم به کد نگاه می‌کنند، نوعی سردرگمی را مشاهده می‌کنند که یادآور یک وینیگرت است، نه شروع و نه پایان، این تلاش شما را نفی می‌کند و اعتبار توسعه‌دهنده را کاهش می‌دهد. حتی شک نکن! اگر فکر می کنید که نکته اصلی در این تجارت این است که "کد فقط کار می کند" بسیار دور از واقعیت هستید. عملکردی که امروز ایجاد می کنید به احتمال زیاد در نسخه بعدی تغییر خواهد کرد، اما خوانایی کد تغییر نخواهد کرد. سبک کد و خوانایی خوب آن، حفظ کد را برای مدت طولانی آسان تر می کند، حتی پس از تغییر کد اصلی غیرقابل تشخیص.

ابتدا یک بلوک "try-catch-finally" ایجاد کنید

ژرژ کانگویلهم (مورخ علم، فیلسوف) به درستی خاطرنشان کرد: "اشتباه کردن برای شخص طبیعی است، اما اصرار بر اشتباهات از جانب شیطان است . " عیب یابی کاری است که همه برنامه نویسان انجام می دهند. ممکن است داده های نامعتبر وارد ورودی شود و دستگاه ها از کار بیفتند. و به عنوان توسعه دهندگان، ما باید مطمئن شویم که کد همان کاری را که قرار است انجام دهد انجام می دهد. مسئله فقط رسیدگی به خطا نیست، بلکه مدیریت خطا "مطب و خوانا" است. بسیاری از برنامه ها با مدیریت خطا سازگار می شوند. اگر این کار را انجام دهید، همه چیز به چنان آشفتگی فرو می رود که هدف و منطق کد اصلی از بین می رود. این اشتباه است، نباید اینطور باشد. کد باید تمیز و قابل اعتماد باشد، و رسیدگی به خطا باید به طور یکپارچه و به طور طبیعی در کد بافته شود. این نشانگر یک برنامه نویس با کلاس بالا است. و یکی از راه‌های رسیدن به این هدف از طریق تودرتوی مناسب و پوشش دادن همه خطاها در بلوک‌های try-catch است. این بلوک ها محدوده کد شما را مشخص می کنند. وقتی کد را در بخش try یک بلوک try-catch-finally اجرا می‌کنید، بیان می‌کنید که اجرا می‌تواند در هر زمان لغو شود و سپس در catch از سر گرفته شود. بنابراین، توصیه می کنیم هنگام نوشتن کد، ابتدا با try-catch-finly شروع کنید. این به تعیین اینکه کاربر می‌تواند از کد انتظار داشته باشد، کمک می‌کند، صرف نظر از اینکه کد در طول امتحان چه مشکلی دارد.

بیایید آن را جمع بندی کنیم

یک عبارت غیر معمول به ما کمک می کند تا همه موارد فوق را خلاصه کنیم. این حس کد یا «حس کد مشترک» است، نوعی برنامه‌نویس معادل حس مشترک. به قول رابرت مارتین: «نوشتن کدهای تمیز مستلزم استفاده منظم از بسیاری از تکنیک‌های کوچک است که در نتیجه حس دقیق و تا حدودی دردناک «پاکیزگی» به کار می‌رود. این تکنیک های کوچک در مجموع حس کد نامیده می شوند . برخی از ما از همان ابتدا این "حس کد صدا" را داریم، در حالی که برخی دیگر باید آن را از طریق تمرین مداوم توسعه دهیم. این غریزه نه تنها به تشخیص تفاوت بین کد بد و خوب کمک می کند، بلکه به شکل گیری استراتژی هایی با هدف تبدیل کد بد به خوب کمک می کند. کد بد همه چیز را خراب می کند. اگر به صورت مجازی صحبت کنیم، اگر لذیذترین کیک را با چروک های سگی بپوشانید، پس... اوه... به سختی کسی آن را دوست ندارد. حس کد به برنامه نویس کمک می کند تا از ابزارهای مناسب برای دستیابی به هدف خود یعنی ایجاد کد تمیز استفاده کند. برنامه نویسی که درک می کند که حس کد چیست، هنرمندی است که می تواند یک اثر هنری را روی یک صفحه خالی خلق کند که برای سالیان دراز در خاطر خواهد ماند. همانطور که هارولد «هال» آبلسون، استاد علوم کامپیوتر در Mit و مدیر مؤسس Creative Commons و بنیاد نرم‌افزار آزاد، آن را خلاصه کرد: «برنامه‌ها باید ابتدا نوشته شوند تا مردم بتوانند آن‌ها را بخوانند، و سپس به طوری که بتوانند آن‌ها را بخوانند. اعدام شد.» ماشین» . آنچه می توانید در مورد این موضوع بخوانید: "راهنمای کاردستی نرم افزار چابک" - رابرت مارتین. «راهنمای برآورد چابک» - مایک کوهن درباره نویسنده: راوی شانکار راجان یک مدیر برنامه جهانی فناوری اطلاعات از بمبئی (هند) است. وبلاگ نویس مشهور، شاعر هایکو، مشتاق باستان شناسی و تاریخ. می توانید در توییتر ، مدیوم ، لینکدین با او ارتباط برقرار کنید