نظریه پنجره شکسته؛ از خیابون تا کد و دیتا

نظریه "پنجره شکسته" (Broken Windows Theory) در اصل یه نظریه توی حوزه جرم‌شناسیه که اولین بار تو سال ۱۹۸۲ توسط "جیمز کیو. ویلسون" و "جورج کلینگ" مطرح شد. این نظریه می‌گه وقتی توی یه محیط شهری، علائم کوچیکی از بی‌نظمی یا خرابی — مثل یه پنجره شکسته، دیوارای پر از گرافیتی یا زباله‌های ریخته‌شده — رها می‌شن و کسی بهشون رسیدگی نمی‌کنه، کم‌کم مردم فکر می‌کنن کسی به اینجا اهمیت نمی‌ده و بعدش جرم و خرابکاری‌های بیشتری اتفاق می‌افته. یعنی بی‌توجهی به مسائل کوچیک، می‌تونه باعث شکل‌گیری مشکلات بزرگ‌تر بشه.

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

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

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

🤍

راهنمای دوستانه‌ی PEP8 – برای نوشتن کدی مرتب، خوانا و حرفه‌ای در پایتون

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

کلمه PEP8 مخفف Python Enhancement Proposal 8 هست و هدف اصلی اون، افزایش کیفیت، خوانایی و ساختار مناسب در کدهای پایتونیه. این راهنما کمک می‌کنه تا برنامه‌نویس‌ها بدون نیاز به توضیح اضافی، بتونن کدهای یکدیگر رو راحت‌تر بخونن و در پروژه‌های گروهی هم هماهنگی بیشتری بین اعضا برقرار بشه.

نکاتی از PEP8 که دونستنش برای همه‌ی پایتونیست‌ها مفیده

🔹 تو رفتگی (Indentation):

بهتره در کدهای پایتون برای هر سطح تو رفتگی، از چهار فاصله (space) استفاده بشه.

🔹 حداکثر طول خط:

هر خط کد بهتره بیشتر از ۷۹ کاراکتر نباشه. این مسئله باعث می‌شه کد توی هر صفحه‌نمایشی خواناتر باشه و نیاز به اسکرول افقی هم از بین بره.

🔹 فاصله‌گذاری بین توابع و بخش‌ها:

برای مرتب‌کردن ظاهر کد و جدا کردن بخش‌های مختلف، معمولاً از خطوط خالی استفاده می‌شه. مثلاً بین دو تابع، بهتره دو خط فاصله باشه تا ساختار کد بهتر دیده بشه.

🔹 نام‌گذاری متغیرها، توابع و کلاس‌ها:

اسم توابع و متغیرها باید با حروف کوچک و آندرلاین نوشته بشه (مثل: get_data)

اسم کلاس‌ها با حروف بزرگ اول هر کلمه و بدون آندرلاین نوشته می‌شه (مثل: UserInfo)

برای ثابـت‌ها هم از حروف بزرگ به همراه آندرلاین استفاده می‌شه (مثل: MAX_SIZE)

🔹 کامنت‌نویسی مؤثر:

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

🔹 ایمپورت ماژول‌ها (Imports):

ترتیب وارد کردن ماژول‌ها هم اهمیت داره. اول باید کتابخانه‌های داخلی پایتون نوشته بشن، بعد کتابخانه‌های نصب‌شده، و در نهایت فایل‌های داخلی پروژه. این نظم باعث می‌شه ساختار کد مشخص و قابل‌مدیریت باقی بمونه.

ابزارهایی برای بررسی رعایت PEP8

برای کسانی که می‌خوان مطمئن بشن کدشون مطابق PEP8 هست، ابزارهایی مثل flake8، pylint و black گزینه‌های مناسبی هستن. این ابزارها می‌تونن به صورت خودکار مشکلات ساختاری رو گزارش کنن یا حتی ظاهر کد رو اصلاح کنن.

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

برای اطلاعات بیشتر میتونید به داک پایتون در این لینک مراجعه کنید.

🔆

تو سایت زیر مجموعه از مقالات با تمرکز بر دیتاساینس لیست شده که بهتون کمک می‌کنه کد پایتون رو بهینه‌تر و بهتر و سریعتر بنویسید، از دستش ندید!

لینک سایت

🦒

چطور می‌تونیم کدهای Pandas رو سریع‌تر و بهینه‌تر بنویسیم؟

یکی از نکات خیلی مهم موقع کار با کتابخونه‌ی pandas اینه که بدونیم چطوری از عملیات‌های برداری (vectorized operations) استفاده کنیم تا هم کدهامون سریع‌تر اجرا بشن، هم خواناتر و بهینه‌تر باشن. خیلی وقتا پیش میاد که ناخواسته از روش‌هایی استفاده می‌کنیم که کندتر هستن، در حالی که pandas ابزارهای خیلی قوی‌ای برای سریع‌تر انجام دادن محاسبات در اختیارمون گذاشته.

برای اینکه بهتر متوجه بشیم، بیاین با یه مثال ساده شروع کنیم. فرض کنیم یه DataFrame داریم با ستونی به اسم "India" و می‌خوایم مقادیر این ستون رو تقسیم بر ۱۰۰ کنیم و نتیجه رو تو یه ستون جدید ذخیره کنیم.

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

import pandas as pd

df = pd.DataFrame({
    "India": [100, 200, 300, 400, 500]
})

# vectorized operation
%timeit df["India_fraction"] = df["India"] / 100

خروجی:

65.7 µs ± 1.01 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

همون‌طور که می‌بینید، این روش خیلی سریع و بهینه‌ست؛ به‌طور میانگین فقط حدود ۶۵ میکروثانیه زمان نیاز داره.

تو مرحله بعد، همین عملیات رو با استفاده از تابع apply و یه تابع lambda انجام می‌دیم:

# apply
%timeit df["India_fraction"] = df["India"].apply(lambda x: x / 100)

خروجی:

87.7 µs ± 302 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

اینجا باید به یه نکته مهم توجه کنیم:
📌 زمانی که عملیاتی که می‌خوایم انجام بدیم به صورت آماده (built-in) تو pandas یا NumPy وجود نداره، استفاده از apply می‌تونه گزینه‌ی خوبی باشه. باهاش می‌شه هر تابع دلخواهی رو روی یه ستون اجرا کرد.
ولی باید بدونیم که apply نسبت به روش برداری مستقیم یه مقدار سربار (overhead) داره و طبیعتاً یه‌کم کندتره.

در نهایت، بیاین نگاهی بندازیم به حالتی که همین کار رو با پیمایش ردیف به ردیف (با استفاده از iterrows) انجام می‌دیم:

# iterrows
%timeit df["India_fraction"] = [row["India"] / 100 for index, row in df.iterrows()]

خروجی:

348 µs ± 4.14 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

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

جمع‌بندی:

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


💞

⭕ تفاوت باگ Bug و دیباگ Debug در چیست؟!

▪️باگ Bug :

باگ یا خطا (Bug) به هر نوع ایراد یا خطای پیش‌آمده در برنامه‌های کامپیوتری گفته می‌شود. این خطاها می‌توانند از اشتباهات کد نوشته‌شده تا مشکلات در محیط اجرایی نرم‌افزار ناشی شوند. باگ‌ها ممکن است منجر به عملکرد نادرست یا غیرمنتظره برنامه شوند و معمولا نیاز به دیباگ دارند.

▪️دیباگ Debug :

دیباگ (Debug) فرآیند شناسایی و رفع باگ‌ها یا خطاهای موجود در یک نرم‌افزار است. این فرآیند شامل استفاده از ابزارها و تکنیک‌های مختلف برای پیدا کردن و برطرف کردن باگ‌ها می‌شود. دیباگ معمولا توسط برنامه‌نویس یا تیم‌های توسعه انجام می‌شود تا اطمینان حاصل شود که نرم‌افزار به صورت صحیح کار می‌کند.

🔹تفاوت اصلی بین باگ و دیباگ :

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

🐞

این Api یعنی چی؟!

رابط برنامه‌نویسی نرم‌افزار application programming interface

ساده بگم: API یه پل ارتباطیه بین دو نرم‌افزار یا دو سیستم که اجازه می‌ده با هم ارتباط برقرار کنن و داده رد و بدل کنن بدون اینکه نیاز باشه طرف مقابل رو کامل بشناسن یا ببینن چجوری کار می‌کنه. 😔

#api
🛠️

👨🏻‍💻 معرفی ۵۰ کانال یوتوب برای آموزش برنامه نویسی در تمام زمینه ها


💎

بلکه به درد بخوره

🫧

#Rust

Code Like a Pro in Rust
Explore the latest features of Rust 2018 for building fast and
secure apps

- By Brenden Matthews
- 265 Pages

@DevTwitter

‏🟢 5علامت که نشون میده داری مسیر رو درست میری (در برنامه نویسی)

🦜

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

اصل کلی:
Fail fast, fail safe, fail cheap.

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


🦓

به اون کاری که امروز کردی نگو "ریفکتور" (Refactor). اگه تست نداره، اون فقط یه "گندکاریِ تمیزه".
این فقط یه جمله‌ی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ‍️ تو یه پروژه‌ی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکه‌تیکه‌اش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفه‌ای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد. کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطق‌های تجاری پنهان و وابستگی‌های زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کم‌بهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تله‌ی کد تمیز"ئه. مهم‌ترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تست‌های مشخصه‌یابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همه‌ی باگ‌هاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.

🦓