نه گام ساده برای کدهای پایتون با ظاهری بهتر

منتشر‌شده در: وبسایت درباره علم داده به تاریخ ۹ آپریل ۲۰۲۰
لینک منبع: Nine simple steps for better-looking python code

به طور معمول، کدهایی را می‌بینم که مقالات دانشگاهی را تکمیل می‌کنند، مجموعه داده‌ها را منتشر می‌کنند، یا راه‌حل‌های رقابت‌های کاگل را تحلیل می‌کنند.

برای محققانی که کد را برای تولید مجدد نتایج مقاله و نیز افرادی که در رقابت‌های یادگیری ماشین (ML) شرکت می‌کنند و راه‌حل‌های خود را به اشتراک می‌گذارند، احترام زیادی قائلم.

وجود کد بهتر از عدم وجود آن است، اما معتقدم که خوانایی کد می‌تواند بهبود یابد.

کدی که من می‌بینم مرا به یاد کدی می‌اندازد که در دانشگاه می‌نوشتم. خوشم نمی‌آمد. این یکی از دلایلی بود که من به صنعت رفتم. توانایی نوشتن کد در دنیای مدرن به اندازه دانستن زبان انگلیسی مهم می‌شود.

بهترین راه برای بهتر شدن برنامه‌نویس، پیوستن به شرکتی با استانداردهای بالای کدنویسی است. با این حال، در این پست وبلاگ، من در مورد شرایطی صحبت خواهم کرد که شما به تنهایی بر روی این موضوع کار می‌کنید.

مخاطبان هدف برای این متن محققان، دانشمندان علم داده، و جوانان توسعه‌دهنده نرم‌افزار  هستند.

تبدیل شدن به یک برنامه‌نویس بهتر یک فرآیند مداوم است. هر چه کد بیشتری بنویسید، بهتر خواهید شد.

من به شما نخواهم گفت که چگونه خوب شوید، من در مورد این صحبت خواهم کرد که چگونه کد شما با چند تغییر ساده در روند پیشرفت شما بهتر به نظر برسد.

منظور من از ساده، اجرای آسان است، کم‌تر از ۵ دقیقه در هر مرحله، و تغییرات باید شما را مجبور به بهتر انجام دادن کارها کنند.

ما تنبل هستیم. اگر چیزی در دسته «خوب است انجام دهید» قرار گیرد، ما دلایل معتبری برای اجتناب از انجام آن پیدا خواهیم کرد. چیزهایی که مجبور هستید بهتر کار می‌کنند. اول، شما آن‌ها را انجام خواهید داد چون انتخابی ندارید، بعدا طبیعی می‌شود.

دلیل دیگر این است که تصمیم‌گیری نیروی اراده را جذب می‌کند. شما کمی از قدرت اراده خود را صرف یک تصمیم کوچک می‌کنید و در نتیجه شانس خواب بیش از حد به جای رفتن به سالن ورزشی را در صبح روز بعد افزایش می‌دهید. وقتی ما به زور رفتار می‌کنیم، انرژی با ارزش را ذخیره می‌کنیم. برای کسانی که علاقه‌مند هستند، کتاب «قدرت اراده: کشف بزرگ‌ترین قدرت انسان» به طور گسترده در مورد این موضوع صحبت می‌کند.

۱. از سیستم کنترل نسخه برای پی‌گیری تغییرات در کد خود استفاده کنید.

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

نسخه‌گذاری کد و استفاده از مخازن متمرکز در GitHub یا سرویس‌های دیگر یک اجبار است. بسیاری از محققان این کار را انجام می‌دهند، اما اگر شما از علوم کامپیوتر فاصله بگیرید، بیشتر اساتید و دانشجویان تحصیلات تکمیلی در فاز نسخه‌گذاری با استفاده از پوشه‌ها و ارسال کد در ایمیل‌ها هستند.

سوال: چه زمانی باید پروژه خود را شروع کنید؟

پاسخ: از خط اول کد.

سوال: چه زمانی باید یک مخزن در GitHub ایجاد کنید و کد را در آنجا قرار دهید؟

پاسخ: از خط اول کد. اگر معتقدید که کد شما به دلایل قانونی یا دلایل دیگر نمی‌تواند به طور عمومی به اشتراک گذاشته شود، یک مخزن خصوصی ایجاد کنید. در تمام موارد دیگر، به سراغ مخازن عمومی بروید.

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

یک مخزن خصوصی بهتر از نداشتن مخزن است. مخزن عمومی بهتر از مخزن خصوصی است.

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

علاوه بر این، ابزاری به نام سورسگراف وجود دارد که به شما این امکان را می‌دهد تا در سراسر  مخازن عمومی گیت‌هاب به دنبال یک کد جستجو کنید. خیلی راحت. این کار شما را پربازده‌تر می‌کند.

پیوندها:

۲. مستقیم روی شاخه اصلی منتشر نکنید

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

وقتی به تنهایی کار می‌کنید، از مرور کد لذت نمی‌برید، اما قدرت چک‌های اتوماتیک هنوز وجود دارد.

ضروری است که تنظیمات لازم را در گیت‌هاب انجام دهید تا حتی اگر بخواهید هم نتوانید مستقیما به شاخه اصلی کد بفرستید. همانطور که در بالا بحث کردیم، این امر مانع از لغزش و صرفه‌جویی در انرژی اراده می‌شود.

۳. استفاده از سیستم‌های یکپارچه‌سازی پیوسته/تحویل پیوسته (CI/CD)

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

سرویس‌های زیادی وجود دارند که قابلیت CI/CD را فراهم می‌کنند. GitHub Actions, CircleCi, Travis, Buildkite و غیره

شخصا GitHub Actions را توصیه می‌کنم. رایگان است، هم در مخازن خصوصی و هم در مخازن عمومی کار می‌کند، و راه‌اندازی آن آسان است.

همه اینها ممکن است بسیار پیچیده به نظر برسند، اما در عمل، شما فقط باید یک فایل پیکربندی به مخزن اضافه کنید.

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

مهم! شما باید تنظیمات را در مخزن گیت‌هاب تغییر دهید تا جلوی ادغام درخواست‌های واکشی بدون کنترل در منطقه سبز نباشید.

پیوندها:

۴. قالب‌بندی کد

راه‌های زیادی برای فرمت کردن قطعه کد یک‌سان وجود دارد.

  • چه میزان فاصله بین توابع وجود داشته باشد؟
  • خطوط کد چقدر می‌توانند طولانی باشند؟
  • ترتیب import ها چگونه باشد؟
  • چه علامتی باید برای تعریف یک رشته استفاده شود؟
  • غیره

ابزارهایی به نام قالب‌بندی کد وجود دارند. اگر آن‌ها را بر روی کد خود اجرا کنید، آن‌ها کد را طوری تغییر خواهند داد که مطابق با الزامات قالب‌بندی باشد.

قالب‌بندی نوع عمومی:

  1. YAPF: بسیار انعطاف‌پذیر، می‌توانید آن را طوری پیکربندی کنید که متناسب با سبک موردنظر باشد.
  2. Black: غیر انعطاف‌پذیر. تنها طول خط می‌تواند پیکربندی شود.

یکی را انتخاب کنید و آن را به پیکربندی CI/CD خود اضافه کنید. من Black را دوست دارم. این باعث می‌شود تمام پروژه‌های من و دیگر پروژه‌هایی که از Black استفاده می‌کنند یک‌سان به نظر برسند.

فرمت های کد، سوئیچینگ متن را کاهش می‌دهند که خواندن کد را آسان‌تر می‌کند.

فرمت‌های خاص‌تری هم وجود دارند. برای مثال isort isort تنها import ها را مرتب می‌کند.

شما باید فرمت‌کننده را در دو مکان اجرا کنید:

  1. در CI / CD. در اینجا شما آن را در یک حالت بررسی اجرا می‌کنید: قالب‌بندی‌کننده به شما خواهد گفت فایل‌هایی وجود دارند که باید فرمت شوند، اما کد دست‌نخورده باقی خواهد ماند.
  2. به طور محلی قبل از انجام تغییرات. در اینجا کد شما فرمت خواهد شد

پیوندها:

۵. قلاب از پیش از کامیت

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

مثلا ما از Black و isort استفاده می‌کنیم.

ما باید دستور زیر را اجرا کنیم:

black .isort

این آزار دهنده است. راه‌حل بهتر این است که یک اسکریپت پایه با این فرمان‌ها ایجاد شود، مثلا «code_formatter.sh» و اجرا شود.

ایجاد چنین برنامه‌هایی یک رویکرد محبوب است، اما مساله این است که، دوباره، مردم این کار را انجام نخواهند داد مگر اینکه شما آن‌ها را مجبور کنید.

راه‌حل بهتری به نام قلاب از پیش تعیین‌شده وجود دارد. این ایده شبیه به اسکریپت bash است، اما چیزهایی که شما می‌خواهید قبل از هر کامیت اجرا کنید دقیقا زمانی که انجام می‌دهید اجرا خواهند شد.

git commit -m “<commit message>”

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

سوال: PyCharm قالب‌بندی خوبی انجام می‌دهد. چرا من به یک قلاب پیش از کامیت نیاز دارم؟

پاسخ: ممکن است فراموش کنید که کد خود را با PyCharm قالب‌بندی کنید. علاوه بر این، وقتی شما دو یا چند نفر دارید، می‌خواهید مطمئن شوید که فرمت همه یک‌سان است. با قلاب پیش از کامیت، همه افراد همان پیکربندی را خواهند داشت که بخشی از مخزن شما است. من توصیه می‌کنم هر دو کار را انجام دهید، یک قلاب پیش از کامیت داشته باشید و کد را با PyCharm  قالب‌بندی کنید.

سوال: اگر من از خط فرمان کامیت نکنم و مستقیما آن را از PyCharm انجام دهم چه؟

پاسخ: شما می‌توانید PyCharm را برای اجرای قلاب پیش از کامیت، پیکربندی کنید.

پیوندها:

۶. لینترها

ابزارهایی که کد شما را تغییر نمی‌دهند اما آن را بررسی می‌کنند و به دنبال مشکلات احتمالی می‌گردند. رایج‌ترین آن‌ها، flake8 است.

این ابزار می‌تواند مشکلات زیر را کشف کند:

  • اشتباهات و هشدارهای Pep8.
  • قراردادهای نامگذاری سازگار.
  • پیچیدگی چرخه‌ای توابع شما.
  • و چیزهای دیگر از طریق یک سری افزونه‌ها.

این یک ابزار قدرتمند است، و من اضافه کردن آن به پیکربندی CI/CD و همچنین در قلاب پیش از کامیت را توصیه می‌کنم.

پیوندها:

۷. ابزار Mypy: بررسی‌کننده انواع استاتیک

با شروع از پایتون ۳، می‌توانید برچسب نوع را به توابع کد خود اضافه کنید. این کار اختیاری است اما شدیدا توصیه می‌شود.

یکی از دلایل آن این است که خواندن کدی که دارای برچسب نوع است، بسیار آسان‌تر است.

وقتی کد را می‌بینید:

x: pd.DataFrame

بسیار قابل‌فهم‌تر است تا فقط

x

البته شما نباید در وهله اول متغیرهای خود را x نام ببرید. با این حال، در این پست وبلاگ، من در مورد روش‌های ساده و اتوماتیک برای بهبود کد صحبت می‌کنم، و نامگذاری خوب کمی سخت‌تر از ساده است. :)

یادداشت‌های تایپ اختیاری هستند. کد بدون آن‌ها به خوبی کار می‌کند. ابزاری به نام Mypy وجود دارد که چک می‌کند:

  • وجود برچسب نوع برای توابع و پارامترهای ورودی
  • سازگاری بین انواع متغیرها و عملیات بر روی آن‌ها

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

شما را مجبور می‌کند تا کدی را بنویسید که خواندن آن آسان‌تر است، تا توابعی که بیش از حد پیچیده و بد نوشته شده را بازنویسی کنید و به شناسایی باگ‌ها کمک کنید.

چک‌های دستی باید به CI / CD و قلاب پیش از کامیت اضافه شوند.

پیوندها:

۸. بررسی‌های بیشتر برای قبل از کامیت

ممکن است قلاب پیش از کامیت خود را با چیزهای مختلف گسترش دهید.

  • حذف فاصله‌های اضافی در انتهای خطوط کد
  • وجود خط جدید خالی در پایان فایل
  • مرتب‌سازی متن نیازمندی‌ها
  • بررسی فایل‌های yaml برای فرمت درست.
  • غیره

شما می‌توانید قلاب‌های خود را برای قالب‌بندی و بررسی کدی که باید به طور خودکار اتفاق بیفتد، ایجاد کنید.

پیوند:

۹. ابزارهای خارجی

ابزارهایی مانند Deepsource.io و Deepcode.ai وجود دارند که می‌توانند به عنوان کنترل اضافی برای بازبینی خودکار کد در هنگام درخواست واکشی استفاده شوند.

آن‌ها برای مخازن عمومی رایگان هستند. من دلیلی نمی‌بینم که از آن‌ها برای کدهایی که در مخازن عمومی منتشر می‌کنید استفاده نکنید.

پیوندها:

نتیجه‌گیری

اگر فردی حداقل برخی از این تکنیک‌ها را اجرا کند، خواندن کد او آسان‌تر خواهد شد.

اما این تنها گام اول است.

تکنیک‌های استاندارد دیگری نیز وجود دارند مثل:

  • آزمایش‌های قطعه‌ای
  • آزمایش‌های قطعه‌ای با فرضیه
  • متغیرهای محیطی پایتون
  • ساختن بسته‌ها
  • داکرسازی
  • مستند‌سازی خودکار
  • غیره

اما به سادگی گام‌هایی که در بالا شرح دادم، قابل‌اجرا و الزام نبودند. بنابراین آن‌ها را به زمان دیگری موکول می‌کنیم. :)

این متن با استفاده از ربات ترجمه مقاله علم داده ترجمه شده و به صورت محدود مورد بازبینی انسانی قرار گرفته است.در نتیجه می‌تواند دارای برخی اشکالات ترجمه باشد.