پایتون و اتوماسیون

ساخت ابزارهای توسعه‌دهنده با پایتون

نویسنده: Hadi ZareZadeh۱۲ بهمن ۱۴۰۴۱۷۶۱ بازدید
ساخت ابزارهای توسعه‌دهنده با پایتون

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

قدم ۱: ثابت کنید درد واقعی است

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

قدم ۲: اول CLI، رابط گرافیکی هرگز (معمولاً)

ابزارهای خط فرمان سریع‌تر ساخته می‌شوند، تستشان آسان‌تر است و با ابزارهای دیگر ترکیب‌پذیرند. typer یا click پایتون در یک بعدازظهر یک CLI صیقلی به شما می‌دهد:

import typer

app = typer.Typer()

@app.command()
def deploy(env: str = "staging", dry_run: bool = False):
    """اپ را به محیط داده‌شده مستقر کن."""
    if dry_run:
        typer.echo(f"در صورت اجرا روی {env} مستقر می‌شد")
        return
    # منطق واقعی استقرار اینجا
    typer.echo(f"روی {env} مستقر شد")

if __name__ == "__main__":
    app()

قدم ۳: مسیر خوشحال را بدیهی کنید

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

بهترین ابزار داخلی آن است که کسی با اجرای help کشفش کند، نه با پرسیدن از شما در اسلک.

قدم ۴: توزیعش کنید

آن را در ریپو زیر scripts/ یا tools/ بگذارید، یک هدف Makefile اضافه یا در README مستندش کنید. ابزارهایی که کسی از آن‌ها خبر ندارد همان بهتر که وجود نداشته باشند.

نمونه‌هایی که جواب دادند

  • بررسی‌کننده تفاوت محیط — متغیرهای محیطی لازم را قبل از استقرار بین محیط‌ها مقایسه می‌کند.
  • اجراکننده seed — seed کردن پایگاه داده را با تأیید و لاگ‌گیری می‌پیچد.
  • تولیدکننده یادداشت انتشار — عناوین PRهای merge‌شده از آخرین تگ را می‌کشد.

اشتباهات رایج

  • ساختن برای کاربران خیالی. اول مسئله خودتان را حل کنید؛ بعد اگر لازم شد تعمیم دهید.
  • نبود تست برای خود ابزار. یک اسکریپت استقرار خراب بدتر از نبود اسکریپت است.
  • وابستگی‌های پنهان. نسخه‌ها را پین و پیش‌نیازها را مستند کنید.

بهترین شیوه‌ها

  • یک نسخه حداقلی در یک جلسه تحویل دهید؛ بر اساس استفاده واقعی بهبود دهید.
  • از همان ابتدا --help و --version اضافه کنید.
  • بازخورد را بی‌سروصدا جمع کنید — ببینید آیا مردم بدون درخواست استفاده می‌کنند.

جمع‌بندی

ابزارهای توسعه‌دهنده تقویت‌کننده‌هایی هستند که از آزردگی روزمره ساخته می‌شوند. کاری را که سه بار تکرار کرده‌اید پیدا کنید، آن را در یک CLI کوچک با typer یا click بپیچید، مسیر خوشحال را مستند کنید و جایی بگذارید که تیم پیدایش کند. خودِ آینده‌تان — و هم‌تیمی‌هایتان — در گزارش دوشنبه بعدی از شما ممنون خواهند بود.