آموزش پایتون برای تحلیل داده؛ از صفر تا گزارش فروش

یادگیری پایتون برای تحلیل داده با حفظ‌کردن فهرست دستورها شروع نمی‌شود؛ با توانایی تبدیل یک سؤال به چند گام روشن شروع می‌شود. اگر بتوانید فایل فروش را بخوانید، دادهٔ نامعتبر را جدا کنید و مجموع فروش هر گروه را درست حساب کنید، پایه‌ای ساخته‌اید که بعداً در Pandas و یادگیری ماشین استفاده می‌شود. این مقاله مسیر را حول همین مسئله می‌چیند تا هر مفهوم کاربردی مشخص داشته باشد.

پایتون به دلیل خوانایی و کتابخانه‌های علمی، انتخاب رایجی برای کار با داده است، اما اجرای آسان یک قطعه‌کد نباید با درک برنامه اشتباه گرفته شود. هدف ما نوشتن برنامه‌ای کوچک، قابل‌آزمایش و قابل‌توضیح است. برای شروع به حساب پولی، GPU یا نصب ده‌ها ابزار احتیاج ندارید؛ نسخهٔ پشتیبانی‌شدهٔ Python 3، یک ویرایشگر و چند فایل تمرینی کافی است.

نصب و محیط مجازی؛ یک پایهٔ مرتب

نسخهٔ پایتون را با دستور python --version یا در بعضی سیستم‌ها python3 --version بررسی کنید. نام دستور ممکن است میان سیستم‌ها تفاوت داشته باشد. نصب را از منبع رسمی یا مدیر بستهٔ مورداعتماد انجام دهید. اگر چند نسخه دارید، قبل از نصب کتابخانه بررسی کنید کدام مفسر واقعاً اجرا می‌شود؛ بسیاری از خطاهای «کتابخانه پیدا نشد» از تفاوت مفسر و نصب‌کننده می‌آیند.

برای هر پروژه محیط مجازی جدا بسازید. این محیط کمک می‌کند وابستگی یک تمرین با پروژهٔ دیگر تداخل نکند. استفاده از python -m pip به جای تکیه بر نام pip، ارتباط نصب با مفسر انتخاب‌شده را روشن‌تر می‌کند. پوشهٔ محیط مجازی را وارد مخزن نکنید و دستور نصب وابستگی‌ها را همراه پروژه نگه دارید. شروع مرتب، رفع خطا در مراحل بعدی را بسیار ساده‌تر می‌کند.

python -m venv .venv
# Activate the environment using your operating system instructions.
python -m pip --version

متغیر و نوع داده را با مسئله بشناسید

متغیر نامی برای ارجاع به یک مقدار است. در گزارش فروش، نام محصول یک رشته، تعداد سفارش عدد صحیح و نرخ تبدیل ممکن است عدد اعشاری باشد. پایتون اجازهٔ تغییر نوع مقدار منتسب به یک نام را می‌دهد، اما این انعطاف دلیل خوبی برای نام‌گذاری مبهم نیست. نام‌هایی مثل quantity و unit_price از نام‌هایی مثل x و temp برای دادهٔ تجاری روشن‌ترند.

دادهٔ خوانده‌شده از فایل متنی معمولاً ابتدا رشته است. عبارت "12" عدد دوازده نیست مگر آن را تبدیل کنید. تبدیل باید در مرز ورود داده و با سیاست مشخص انجام شود: اگر مقدار خالی، منفی یا دارای جداکنندهٔ هزارگان بود چه کنیم؟ حذف بی‌صدای نمونه‌ها می‌تواند گزارش را تغییر دهد. برای مبلغ واقعی نیز مراقب نمایش اعشاری باشید؛ در بسیاری از کاربردها نگهداری مقدار در واحد صحیح کوچک‌تر یا استفاده از Decimal مناسب‌تر است.

شرط‌ها برای تصمیم، نه پنهان‌کردن خطا

ساختار if برای شاخه‌بندی منطق به کار می‌رود. مثلاً سفارش لغوشده نباید در فروش قطعی جمع شود. این قانون باید قبل از کدنویسی تعریف شود؛ آیا سفارش مرجوعی مبلغ منفی است یا وضعیت جدا دارد؟ اگر تعریف تجاری روشن نباشد، برنامه‌ای با نحو کاملاً درست هم می‌تواند جواب غلط بدهد. شرط، جای تصمیم‌گیری دربارهٔ معنای داده را نمی‌گیرد.

در پایتون تورفتگی بخشی از ساختار برنامه است. خطوط داخل یک بلوک را با فاصلهٔ یکسان بنویسید و تب و فاصله را مخلوط نکنید. هنگام مقایسهٔ مقدارهای خالی نیز میان None، رشتهٔ خالی و صفر تفاوت بگذارید. شرط کلی if not value ممکن است همهٔ این‌ها را یکسان ببیند، در حالی که صفر فروش با مبلغ ثبت‌نشده معنای متفاوتی دارد. شرط دقیق‌تر از خطای تحلیلی جلوگیری می‌کند.

فهرست، دیکشنری و مجموعه کجا استفاده می‌شوند؟

فهرست برای دنباله‌ای از نمونه‌ها مناسب است؛ مثلاً ردیف‌های فروش. دیکشنری رابطهٔ کلید و مقدار را نگه می‌دارد و برای نمایش یک ردیف با نام ستون‌ها خواناست. مجموعه برای بررسی عضویت یا نگهداری مقدارهای یکتا کاربرد دارد. انتخاب ساختار داده باید از عملیات موردنیاز بیاید: ترتیب مهم است، جست‌وجوی تکرار مهم است یا دسترسی با نام ستون؟

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

حلقه و تجمیع داده با مثال

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

rows = [
    {"category": "book", "quantity": 2, "unit_price": 120},
    {"category": "course", "quantity": 1, "unit_price": 500},
    {"category": "book", "quantity": 3, "unit_price": 100},
]
totals = {}
for row in rows:
    amount = row["quantity"] * row["unit_price"]
    key = row["category"]
    totals[key] = totals.get(key, 0) + amount
assert totals == {"book": 540, "course": 500}
print(totals)

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

تابع؛ تبدیل منطق به واحد قابل‌آزمایش

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

نام تابع بهتر است عمل مشخصی را بیان کند. تابع summarize_sales روشن‌تر از process است. ورودی‌ها را محدود و خروجی را قابل‌پیش‌بینی نگه دارید. نیازی نیست از همان روز نخست کلاس، الگوی طراحی یا چند لایهٔ انتزاع بسازید. ابتدا تکرار واقعی را ببینید و بعد منطق مشترک را جدا کنید. تابع خوب، فهم برنامه را آسان می‌کند؛ تقسیم بی‌دلیل برنامه به ده‌ها تابع کوتاه الزاماً چنین اثری ندارد.

خواندن فایل CSV و حفظ دادهٔ خام

CSV را با کتابخانهٔ csv بخوانید، نه با شکستن هر خط بر اساس ویرگول؛ زیرا مقدار یک خانه خودش می‌تواند ویرگول یا نقل‌قول داشته باشد. کدگذاری فایل را مشخص کنید و برای فایل‌های صادرشده از بعضی ابزارها احتمال وجود نشان BOM را در نظر بگیرید. فایل اصلی را تغییر ندهید؛ خروجی پاک‌شده و گزارش خطا را در فایل دیگری ذخیره کنید تا فرایند قابل‌برگشت باشد.

در DictReader هر ردیف بر اساس نام ستون‌ها قابل‌دسترسی است. قبل از محاسبه بررسی کنید ستون‌های لازم وجود دارند و قراردادشان روشن است. سپس تبدیل نوع را انجام دهید و ردیف‌های نامعتبر را با شمارهٔ ردیف ثبت کنید. اگر فایل بزرگ شد، پردازش ردیف‌به‌ردیف می‌تواند از بارگذاری همهٔ داده در حافظه بهتر باشد. نیاز واقعی پروژه تعیین می‌کند چه زمانی به Pandas یا ابزار دیگری مهاجرت کنید.

خطاها را دقیق بخوانید

پیام خطا معمولاً نوع مشکل و مسیر رسیدن به آن را نشان می‌دهد. آخرین بخش traceback نقطهٔ شروع خوبی است، اما باید خط مرتبط با کد خودتان را هم پیدا کنید. ValueError هنگام تبدیل عدد با KeyError برای نام ستون غایب تفاوت دارد. تلاش برای پوشاندن هر دو با یک except عمومی، برنامه را ظاهراً آرام و نتیجه را غیرقابل‌اعتماد می‌کند.

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

آزمون‌های کوچک با اثر بزرگ

برای تابع محاسبهٔ مبلغ، حالت معمولی، تعداد صفر و ورودی نامعتبر را بررسی کنید. برای تجمیع، دادهٔ خالی و تکرار دسته را بیازمایید. انتظار نتیجه را پیش از اجرای برنامه بنویسید تا صرفاً خروجی فعلی را درست فرض نکنید. برای شروع می‌توانید از assert در تمرین محلی استفاده کنید؛ در پروژهٔ جدی‌تر، unittest ساختار و گزارش مناسب‌تری می‌دهد.

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

چه زمانی به NumPy و Pandas برویم؟

وقتی خواندن حلقه، تابع و دیکشنری برایتان روشن شد، کتابخانه‌های داده را وارد کنید. NumPy برای محاسبهٔ عددی آرایه‌ای و Pandas برای کار جدولی مناسب است. هدف حذف فکرکردن دربارهٔ داده نیست؛ همان سؤال‌ها دربارهٔ نوع، مقدار خالی و تکرار همچنان باقی می‌مانند. کتابخانه می‌تواند عملیات را کوتاه کند، اما تعریف نادرست فروش یا واحد پول را اصلاح نمی‌کند.

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

پروژهٔ پایان مقاله و معیار آماده‌بودن

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

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

خوانایی و ساختار یک پروژهٔ کوچک

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

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

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

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

پرسش‌های متداول

آیا باید قبل از تحلیل داده شیءگرایی را کامل یاد بگیرم؟

نه. شناخت تابع، ساختار داده، فایل و مدیریت خطا برای شروع بسیاری از تمرین‌های تحلیلی کافی است. مفهوم کلاس را بعداً برای خواندن کتابخانه‌ها و طراحی نیازهای واقعی گسترش دهید. یادگیری همهٔ امکانات زبان پیش از نخستین پروژه معمولاً تمرین را عقب می‌اندازد و باعث می‌شود ارتباط مفهوم‌ها با مسئله فراموش شود.

چرا کد روی دستگاه دیگر اجرا نمی‌شود؟

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